Your Payment Iframe Does Not Cover the Page Around It: The SAQ A Line to Read

If your checkout embeds a payment form from Stripe, Adyen or Braintree inside an iframe, there is a sentence in the current SAQ A that you have to be able to answer for before you sign it, and it is not about card data. It is about JavaScript on the page around the iframe. If instead you send the customer away to the processor's own page and they come back afterwards, the sentence does not apply to you at all. That single architectural difference decides an afternoon of work, and most merchants have never been told it exists.

The sentence

PCI DSS v4.0.1 SAQ A r1 added an eligibility criterion that reads, in the Council's own words:

The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).

That is a condition of using SAQ A, not a requirement inside it. The distinction matters: if you cannot make the confirmation, you are not eligible for the short questionnaire, and the fallback is a considerably longer one.

Myth: the iframe makes scripts the processor's problem

This is the belief worth killing first. The payment fields inside a hosted iframe are the processor's responsibility, and card data never touches your server. But the page that frames it is yours, and a script running on that page can redraw the checkout, overlay a fake form on top of the iframe, or read what a customer types before the iframe ever sees it. The Council's FAQ clarifying the criterion is explicit about which setups it targets: merchants who embed a third-party payment form, "for example, via an iframe". It does not apply to merchants who redirect using an HTTP 30x, a meta redirect or a JavaScript redirect, nor to those who fully outsource payment by, for example, emailing a payment link.

Fact: there are exactly two accepted ways to confirm it

FAQ 1588 sets out both, and you only need one.

Route one, do the work. Confirm by "using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant's webpage from scripts". Those two requirements were removed from SAQ A itself when v4.0.1 took effect on 1 April 2025, so you are borrowing their methods rather than completing them as line items.

Route two, get it in writing. Confirm by "obtaining confirmation from the merchant's PCI DSS compliant Third-Party Service Providers (TPSPs)/payment processor" that their solution includes script attack protections. This is free, takes one support ticket, and is the right first move for a small shop. It is also the route with a catch, covered below.

Which route your checkout points you to

One caveat that overrides everything in that table: which SAQ you are entitled to use is set by your acquirer or the card brand, not by you and not by a blog. Use the table to know what to ask them, then get the answer in writing.

The email to send your processor today

Route two only works if the answer is specific. A support reply saying "we are PCI DSS Level 1 compliant" is about their infrastructure and does not address your page. Ask for this instead, by name:

For PCI DSS v4.0.1 SAQ A eligibility, we need written confirmation on one point. Our checkout embeds your payment form via iframe at [URL]. Under FAQ 1588, does your embedded solution include protections against script-based attacks on the merchant page that frames it, such that we can confirm our site is not susceptible to attacks from scripts affecting our e-commerce systems? A reference to your published documentation is fine. Please confirm whether this covers scripts loaded by our own page outside your iframe.

That last sentence is the one that produces a useful answer. Most processors will confirm protections within their own frame and decline to speak for your page, which tells you route one is where you actually live.

What route one looks like on a small site

The Cloud Security Alliance published a deep dive on 6.4.3 and 11.6.1 on 23 July 2026 that sets out the obligations plainly. Requirement 6.4.3 asks you to maintain an inventory of the scripts on the payment page, ensure each is authorised before it loads, and justify why each is necessary. As that analysis notes, the standard is deliberately vague about how the authorisation happens, who does it, or whether it is manual or automated. Requirement 11.6.1 asks you to detect unauthorised changes to page content and the introduction of new scripts. The same analysis makes the point that matters for tooling budgets: external scanners and crawlers are ineffective here, because malicious script can be served selectively to real users and withheld from anything that looks like a scanner.

Start by enumerating what is actually on the page. In a browser console on your live checkout, after the page has fully loaded and any consent banner has been accepted:

[...document.querySelectorAll('script')].map(s => s.src || '[inline]')

Run it twice, once before and once after accepting cookies, because a tag manager will inject a different set each time. Then build the inventory as a table your assessor can read:

The second row is the one that decides most of these projects. A tag manager on the payment page means any person with container access can add a script to your checkout without a deployment, which is exactly the authorisation gap 6.4.3 is written about. Removing the tag manager from the payment page alone, and keeping it on every other page, resolves more of this requirement than any monitoring product you could buy.

A worked row, and what it costs

Take a shop on Shopify or WooCommerce with a Stripe element, Google Tag Manager, a live chat widget and a reviews widget on the checkout. Four entries in the inventory. Two of them, chat and reviews, have no business reason to run on the payment step at all, so they come off, and the inventory drops to two. The tag manager either comes off the checkout template or gets its container permissions cut to two named people with change history enabled. Stripe's script stays, justified, with a Content-Security-Policy header naming the hosts allowed to load scripts on that page. That is an afternoon, it costs nothing, and it produces the evidence file that answers the eligibility sentence honestly rather than optimistically.

None of this is a substitute for asking your acquirer which questionnaire you owe. It does mean that when they answer, the work is already done. If you are weighing checkout architecture more broadly, the fee side of the same decision is in our comparison of what platforms charge for using an outside gateway, and the downstream consequence of a compromised checkout is the dispute volume covered in our small store defence plan. The general habit of enumerating what is reachable before an assessor does it for you is the same one in our API endpoint audit.