PCI SAQ A: what changed for embedded checkout

SAQ A is the shortest PCI self-assessment, and it is the one product teams reach for when a gateway says “you can stay out of scope”. The reach is often wrong. SAQ A describes a merchant who does not electronically store, process or transmit account data at all, and who has handed the payment page to a PCI-validated provider.

If your server sees the PAN, or your JavaScript reads it before handing it off, you are not in SAQ A. Tokenisation after the fact does not pull you back in. The question is whether the number touched your systems, not whether you kept it.

The piece that changed, and the piece worth reading carefully, is the eligibility rule PCI SSC added for e-commerce pages that embed a provider’s payment form.

What SAQ A has always required

The questionnaire’s own eligibility criteria, carried through the v4.0.1 documents, say the merchant:

• accepts only card-not-present transactions
• outsources all processing of account data to a PCI DSS compliant provider
• does not electronically store, process or transmit account data on its own systems
• has checked that provider’s Attestation of Compliance for the service in use
• keeps any leftover account data on paper only, not in electronic form

For e-commerce, the payment page delivered to the browser has to originate from that provider. A redirect to the provider’s hosted page is the clean version of this. An embedded form is the version the 2025 rule is about.

SAQ A is not for face-to-face, and it is not for service providers. A gateway does not fill in SAQ A. The merchant does, and only if the acquirer agrees that this is the right questionnaire. PCI SSC says to confirm that with the organisation the SAQ will be submitted to. Do not pick it because it is short.

What changed in January 2025

PCI SSC published a revised SAQ A in January 2025, effective 31 March 2025, and retired the October 2024 version of SAQ A on that date.

Two things happened at once.

The requirements that had been added to SAQ A for payment-page scripts — PCI DSS 6.4.3 and 11.6.1, and the targeted risk analysis in 12.3.1 that supported 11.6.1 — were removed from the questionnaire. They were not removed from PCI DSS itself. A merchant in some other SAQ can still have them. SAQ A merchants stopped having to answer those items on this form.

In their place, eligibility gained a sentence: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the e-commerce system.

FAQ 1588 says that confirmation can be either:

• techniques such as those in 6.4.3 and 11.6.1, deployed by the merchant or by a third party, or
• written confirmation from the PCI-compliant provider of the embedded payment page that, implemented as they instruct, their solution includes techniques that protect the page from script attacks

The FAQ is explicit about scope. The new criterion applies to a page that includes the provider’s embedded payment form, for example an iframe. It does not apply to a redirect (HTTP 30x, a meta refresh, or a JavaScript redirect) and it does not apply to a merchant who fully outsources payment, such as emailing the customer a link to the provider’s own site.

So “we removed 6.4.3 from SAQ A” does not mean embedded checkout got easier to ignore. It means the script question moved from a list of requirements inside the form to a yes-or-no at the door. If you cannot say yes, you are not eligible for this SAQ.

What this means for the integration

Integration	Account data on your systems?	SAQ A eligibility, on the published criteria
Redirect to the provider’s page	No	The script criterion in FAQ 1588 does not apply. The rest of the criteria still do.
Link or email to the provider’s site	No	Same.
Iframe or embedded fields served by the provider	No, if you never read the PAN	Eligible only if you can make the script confirmation.
Your JavaScript collects the PAN and tokenises it	Yes, it transmitted account data	Not SAQ A.
Server-side charge with the PAN on your API	Yes	Not SAQ A.

“Embedded fields” is the row engineers argue about. The test is not the brand name of the component. The test is whether any element of the payment form that takes account data is served from the provider, and whether your own scripts can reach that data. A script you added for analytics, a tag manager, a chat widget, sitting on the same page as an iframe, is the attack the eligibility sentence is pointing at. PCI SSC’s January 2025 note says a provider of scripts that are unrelated to payment, and that cannot affect account data, is not a third-party service provider for this purpose. A script that can affect the payment page is your problem even when you did not write it.

None of this is changed by a token in your database. The token is what you keep after a provider who was in scope did the collection. If you collected the number yourself and then exchanged it, you were in scope for that request.

The same line shows up in the engineering guides on this site. 3-D Secure assumes the gateway runs authentication. Webhook handlers assume the body you verify is a notification, not a card.

What not to conclude

Removing two requirements from a questionnaire is not a finding that those controls are unnecessary. PCI SSC said the opposite: the requirements remain in the standard. It is also not legal advice, and it is not your acquirer’s decision. Acquirers can ask for a different SAQ.

Figures and requirement numbers above are from the Council’s own posts and from the SAQ A eligibility text, checked 26 September 2026. The document to fill in is the one your acquirer tells you to use, not a summary of it.

Sources

• Important updates for merchants validating to SAQ A, PCI SSC, January 2025. Removal of 6.4.3, 11.6.1 and 12.3.1 from SAQ A; new eligibility criterion; October 2024 SAQ A retired 31 March 2025.
• FAQ on the new SAQ A eligibility criteria, PCI SSC. FAQ 1588: how a merchant confirms the site is not susceptible to script attacks, and which e-commerce setups the criterion covers.
• SAQ A for PCI DSS v4.0, eligibility criteria for the card-not-present merchant who fully outsources account data. The v4.0.1 questionnaire is the one in force; the criteria quoted in the Council’s 2025 posts are the ones to follow where they differ.

This is a reading of those publications, not a compliance opinion. If the integration is close to the iframe row in the table, the useful next step is the provider’s implementation guide plus the acquirer, not a tighter paraphrase of this page.