SAQ A Isn't a Free Pass: The Iframe Decision Behind Your PCI Scope

Most US merchants who "outsourced payments" believe the PCI question is closed. They embedded Stripe, Adyen, Braintree or a similar provider's payment form, picked the shortest self-assessment questionnaire, and moved on. That belief is where the risk sits. Whether you qualify for SAQ A is no longer a matter of which provider you chose. It depends on how the payment form reaches your customer's browser, and on a confirmation you now have to make about scripts.

Quick answer: who qualifies for SAQ A?

A merchant can use SAQ A when it fully outsources cardholder data handling to a PCI DSS-compliant provider, using a redirect or an embedded iframe, and confirms its site is not susceptible to attacks from scripts. A merchant that delivers any element of the payment page or form itself falls under SAQ A-EP, which carries a much larger set of requirements.

What changed in SAQ A

Under PCI DSS v4.0.1, two requirements drew attention for payment pages: 6.4.3 (inventory, authorize and verify the integrity of every script on the payment page) and 11.6.1 (detect unauthorized changes to payment page content and headers). In its early-2025 revision, the PCI Security Standards Council removed the individual questions for these two requirements from SAQ A. In their place it added an eligibility criterion: the merchant has confirmed that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

That is not a relaxation. It moved the burden. Instead of answering two defined questions, you now attest to an outcome, and the PCI SSC's FAQ on the topic is explicit about how you get there. For an embedded iframe, you either use techniques on your own page to protect against malicious scripts, such as script allow-listing and tamper detection, or you obtain confirmation from your PCI DSS-compliant provider that the embedded iframe includes techniques to defend against script attacks. Security firm TrustedSec has described the vagueness of "not susceptible" as the hidden trap: if you cannot back the statement, you risk losing SAQ A eligibility and facing the heavier requirements of SAQ A-EP or a fuller assessment.

Redirect, iframe, or your own fields: three very different scopes

The architecture decision made in the first sprint of a checkout build usually settles your scope for years. There are three common patterns.

Full redirect to a provider-hosted page

The customer leaves your domain to pay. Your page never contains a payment field, so there is little for a malicious script on your pages to read. This is the cleanest scope position, and the usual trade-off is brand and conversion control.

Embedded iframe from the provider

The payment fields live inside a frame served by the provider, but the frame sits on a page you control. Your page is still the container. A compromised third-party script on that page can alter the surroundings, swap the iframe, or overlay a fake form. This is exactly the scenario the script-attack criterion exists for.

Fields rendered by your own code

If your code builds or controls any part of the payment form, even while a provider tokenizes the card, the PCI SSC guidance places you in SAQ A-EP territory. Many stores land here by accident: a developer wraps a hosted-field library in custom components, and the scope quietly changes.

The evidence question most teams can't answer

Auditors and acquiring banks don't accept "our provider is PCI compliant" as an answer to a script question. A recent engineering write-up on keeping an embedded iframe SAQ A-eligible makes the point that a generic provider compliance statement doesn't explain whether protection applies to your specific embedded form. You need the specific product, the specific integration mode, and the provider's written description of what it defends against.

The same write-up notes that, under PCI SSC FAQ 1604 (June 2026), merchant pages containing provider iframes fall within the ASV scanning applicability for SAQ A, including nested arrangements. If your checkout page loads a provider frame that loads another frame, scanning scope follows it. Confirm the current wording of that FAQ with your acquirer or QSA before relying on this summary.

A defensible evidence file for a US D2C or wholesale store should hold:

• The integration mode, by name, for every payment path: web checkout, B2B portal checkout, saved-card update, and any quick-pay button.
• The provider's written statement on script-attack protection for that mode.
• An inventory of every script that loads on the pages that contain or surround the payment frame, with an owner and business justification for each.
• A record of how changes to those pages are detected and reviewed.

Why this lands hardest on B2B and wholesale

Wholesale portals tend to accumulate marketing tags, chat widgets, analytics, and ERP connectors across years. Several payment paths often run side by side: card, ACH, net terms with card on file. Each path is a separate scope question. MnT Future builds managed commerce platforms with PCI DSS compliance with this in mind: we treat the payment surface as a short, owned list of scripts, and we decide on redirect, iframe or hosted fields before design starts, because that single choice drives how much evidence a merchant has to maintain afterwards.

Note that SAQ eligibility is not only a PCI DSS question. Payment brand and acquirer rules, which depend on your transaction volume, ultimately decide which validation you owe. Your acquiring bank is the authority on that, not a blog post and not your developer.

A practical checklist before your next assessment

1. List every page where a card can be entered, including the ones nobody remembers: reorder pages, invoice-pay links, subscription card updates.
2. Name the integration mode on each page: redirect, provider iframe, or your own fields.
3. Ask your provider, in writing, what script-attack protection covers that exact integration.
4. Remove every script on payment pages that has no owner or business reason.
5. Decide how you will detect unauthorized page changes, and record the process.
6. Confirm your SAQ type and validation obligations with your acquirer.

Where to go from here

If you can't answer step 2 for every payment path in under ten minutes, you have a scoping gap worth closing before it becomes an assessment finding. MnT Future offers a free strategy session where our senior engineers walk through your checkout architecture and identify where the payment surface is wider than it should be. Book it here.

This article is general information, not legal or compliance advice. Confirm your validation requirements with your acquirer or a Qualified Security Assessor.