Do gateway-hosted card fields solve everything?

No. Gateway-hosted card fields (shown inside a window embedded in your page and served by the payment provider) keep card data out of reach of your server and your page's code, and that is why they cut PCI DSS scope significantly. But the page around them is still yours, and that is where an attack can happen: a fake form shown before the real one, the window swapped for another, a button that leads somewhere else. The PCI Security Standards Council itself says the page that embeds the provider's form remains in scope.

What hosted fields solve

In this model, the card number, expiry and security code fields are not part of your page: they live in a small embedded window (an iframe) whose content comes from the provider's address. Browsers isolate content from different addresses, so code running on your page (including malicious code) cannot read what the customer types inside that window. The data goes straight to the provider.

That is a real gain. Less data passes through the store, fewer requirements apply, and many merchants can use the simplest self-assessment questionnaire, SAQ A, if they meet its eligibility criteria. If you use hosted fields, keep using them. The point is not to confuse reducing scope with removing risk.

Where the risk remains

The PCI SSC's guidance on payment page security, published in March 2025, is clear: embedding a third party's form does not completely remove the page that displays it from scope, nor does it make requirements 6.4.3 and 11.6.1 inapplicable. The merchant is responsible for the scripts on that page, and when a script creates the window, that script is covered too. In practice, criminals have several routes that never touch the provider's fields:

• A fake form before the real one. In February 2026, the research firm Sansec reported the case of a supermarket chain with an international presence whose real card form came from the payment provider. Code injected into the store's page first displayed a fake form; customers typed their details there, then saw the legitimate form and typed them again. According to Sansec, it is precisely because card entry has moved to provider-hosted forms that criminals have come to favor this kind of overlay.
• Swapping or covering the window. It is your page that tells the browser where to load the payment window from. If the code that does this is altered, the window can come from a look-alike address, or sit hidden under an identical layer.
• Diverting the button. The pay button and the steps before it also belong to your page and can be changed to send the customer elsewhere.
• Data outside the window. Name, email, phone and address are usually typed into your page, not the provider's.
• Single-page sites. When the browser does not reload between steps, scripts loaded early in the visit are still active at payment; the guidance treats every view as in scope.

What changed in SAQ A, and what still applies

In January 2025, the PCI SSC removed requirements 6.4.3 and 11.6.1 from SAQ A, but added an eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council stressed that the changes "do not remove or diminish the underlying requirements" of PCI DSS.

In February 2025, FAQ 1588 explained that this criterion applies to merchants whose page embeds the provider's form, not to those that redirect customers to the provider's site. There are two ways to meet it: apply techniques such as those in requirements 6.4.3 and 11.6.1 to protect the page from scripts targeting account data, either directly or through a third party; or obtain confirmation from the PCI DSS-compliant provider that its solution includes that protection for the merchant's page, when implemented according to its instructions. In other words, the questionnaire got shorter, but the question about your page is still there.

Checklist for merchants using hosted fields

• Ask your provider in writing whether its solution protects your page from scripts and under what conditions, and follow the implementation instructions to the letter.
• Treat the page that displays the form as sensitive. Keep only essential scripts on it and know who can change it.
• Inventory and monitor that page's scripts, as the customer's browser receives them.
• Check on the shopper's screen that the payment window comes from the provider's address and that no other card form appears before or on top of it.
• Protect what sits outside the window, such as name, email and address.
• Take reports of double card entry seriously.
• Confirm with your acquirer which questionnaire applies to your store.

Proteside protects exactly the page around the provider's fields: it checks, in the shopper's browser, that the form on display is the legitimate one and comes from the right address, blocks overlays and produces evidence for requirements 6.4.3 and 11.6.1. Explore card payment protection and the PCI DSS compliance solution, and try it free for 14 days.