SECURITYPAYMENT PROCESSING
SAQ A is an eligibility test now, and most online merchants have not read it
P
Payment Review Editorial Team
Payment Review Editorial Team
If you sell online and your payment page comes from your processor, you almost certainly validate PCI compliance on SAQ A — the shortest of the self-assessment questionnaires, a couple of dozen questions, usually a web form your acquirer emails you once a year. In January 2025 the PCI Security Standards Council changed it. The form got shorter. The obligation did not.
The change is easy to misread, and most summaries do misread it, because it looks like a deletion. Three requirements came out of SAQ A. What replaced them is not another requirement. It is a condition on whether you are allowed to use the form.
This is worth reading in the Council's own words rather than in a summary. The document is PCI DSS v4.0.1 SAQ A, revision 1, publication date January 2025. Under "Merchant Eligibility Criteria", after the general conditions about outsourcing, it adds two more for e-commerce:
The document's own change log is equally direct about what happened in January 2025: it removed Requirements 6.4.3, 11.6.1 and 12.3.1 and added an eligibility criterion for merchants to confirm that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems.
The distinction is the whole story. A requirement sits inside the questionnaire; you read it, you assess yourself against it, you mark it in place or not applicable, and if you cannot meet it you have a documented compensating control conversation with your assessor or acquirer.
A criterion sits before the questionnaire. Signing the attestation asserts that you already meet it. There is no box to tick "not applicable", no partial credit, and no remediation plan attached to it. If it is not true, you were never eligible for the form you just signed.
So the paperwork shrank and the assertion widened. The Council was explicit that removing the requirements from SAQ A does not remove or diminish the underlying requirements within PCI DSS; it changes how SAQ A merchants report on them.
Requirement 6.4.3 is about scripts on the payment page: every script authorised, integrity-assured, inventoried. Requirement 11.6.1 is about tamper detection on the payment page and its HTTP headers. Both are scoped to the page where card data is entered.
The eligibility criterion is scoped to "their site" and to "the merchant's e-commerce system(s)". That is your marketing pages, your tag manager, the analytics snippet somebody added for a campaign in 2023, the chat widget, the A/B testing script. The reason is not pedantry: e-skimming attacks usually do not start on the payment page. They start somewhere with weaker change control and move.
This is the part of the change that most merchants have not absorbed. A hosted checkout does not, by itself, make the criterion true. It makes the first criterion true — the payment page comes from the provider. The second one is about everything else you serve.
SAQ A itself notes that requirements about protecting computer systems — Requirements 2, 6, 8 and 11 — apply to the merchant webpage that carries a redirect mechanism, and to the merchant webpage that contains a provider's embedded payment form. Those pages are in scope, the Council says, because they affect how account data is transmitted, even though they never receive it.
The Council's FAQ on the new criterion, published alongside the change, applies only to merchants using an embedded form or iframe. It explicitly does not apply to merchants who fully outsource or who redirect the customer to the provider's own site. That is a useful signal: an iframe is not disqualifying, it is precisely the case the criterion was written for.
Where the published guidance genuinely diverges is the middle ground — hosted fields and JavaScript components that render provider-controlled inputs inside your page. Some security vendors treat any embedded component as SAQ A-EP territory; others treat provider-served iframes, which is what most of those components actually are, as SAQ A. We are not going to pretend that is settled. SAQ A tells you to consult your compliance enforcing entity about validation questions, and that is the right answer here: your acquirer decides which form you file, and their answer is the one that counts.
The second route the Council offers is the one most small merchants should take, and it produces an artefact you should keep. Ask your provider to confirm that, when implemented according to their instructions, their solution includes techniques that protect your payment page from script attacks. That is close to the Council's own wording, and it is a reasonable thing to ask a compliant provider for.
Providers vary a great deal in how ready they are to answer. Adyen publishes a documented SAQ A eligibility guide that quotes both criteria back at merchants and commits to describing the security measures for each integration; our review notes it charges no separate PCI fee at all. Braintree offers hosted fields and a drop-in UI, which is exactly the integration shape the criterion is written about, so the question to ask them is a specific one rather than a general one.
Ask the same question of whoever you use. Stripe sells both a prebuilt hosted checkout and embedded components, and those two choices put you in different places against the first criterion even though the invoice looks identical. Square bundles its own online checkout, which removes the question for merchants who use it end to end and reopens it for anyone embedding Square into a site they built.
There is a second, more mundane reason to care about which questionnaire you file: some processors bill for it and some do not, and the fee is unrelated to the work.
Our review of Stripe records no separate PCI fee, and the same is true of Adyen. Shopify Payments does list an annual PCI DSS compliance and security fee, varying by region and merchant agreement. With Authorize.net it depends who sold it to you: our review notes that some resellers and processors charge separate PCI compliance fees. A non-compliance fee is a different animal again — that is a monthly charge for not having filed, and it is entirely avoidable by filing.
If you are choosing a processor rather than auditing one, the integration model belongs on the shortlist next to the rate, because it decides which questionnaire you live with for the next several years. Our guide to the best payment processors for e-commerce covers the same providers on price and fit.
Then you validate on SAQ A-EP or SAQ D, where 6.4.3 and 11.6.1 are answered directly rather than assumed. SAQ A-EP is a much larger document — it covers most of the standard, minus stored cardholder data and some physical controls — and merchants discover it at the worst possible moment, usually during a breach investigation or an acquirer review.
The cheaper path is almost always to make the criterion true: inventory what your site loads, remove the scripts nobody owns any more, put change control on what remains, and get the provider confirmation in writing. That is a week of work for most small stores, and it is the same work the requirement would have made you do.
