For an e-commerce merchant, the SAQ depends on how much of the payment page you control. If every payment page element comes from a PCI DSS compliant provider, SAQ A may fit. If your site controls the redirect, SAQ A-EP may fit. Anything else defaults to SAQ D. Confirm the choice with your acquirer.
The questions to ask
- Does your server ever receive card data? If yes, you are likely in SAQ D territory.
- Where do the payment form elements come from? Redirect to the processor, an embedded processor frame, or fields served by your own site make three different answers.
- Is the provider PCI DSS compliant? If any element of a payment page comes from a non-compliant provider, the setup is not eligible for SAQ A or A-EP.
- Does your page include scripts you control or load from third parties? That matters since the January 2025 SAQ A update.
The three common outcomes
| Setup | Usual SAQ |
|---|---|
| Redirect to processor page, or customer emailed a pay link | SAQ A |
| Processor iframe embedded in your page, no scripts that could affect it | SAQ A, with the script criterion |
| Your page controls the redirect or serves some payment elements, but never receives card data | SAQ A-EP |
| Your servers store, process or transmit card data, or none of the above fits | SAQ D |
These descriptions follow PCI SSC material for SAQ A as it was revised in early 2025. The fallback is SAQ D for merchants not described by other types. Other SAQs exist for terminal based setups, so card present businesses should look at those.
The script criterion in SAQ A
In January 2025 the Council changed SAQ A. Requirements 6.4.3, 11.6.1 and 12.3.1 were removed from the questionnaire, and a new eligibility criterion was added: the merchant has confirmed that the site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council stressed that the underlying PCI DSS requirements were not weakened.
FAQ 1588 explains two ways to meet the criterion. You can protect the page yourself using techniques such as those in 6.4.3 and 11.6.1, or you can obtain confirmation from a PCI DSS compliant provider that its solution, implemented per its instructions, protects the payment page from script attacks. The criterion applies where your page embeds a provider's payment page, such as an iframe. It does not apply to redirects or full outsourcing.
Practical consequences
- Moving from embedded fields to a full redirect can simplify validation, at a cost in checkout experience.
- If you choose an iframe, ask the provider for its written confirmation, and keep it with your records.
- Third party tags on the checkout page, such as analytics and chat widgets, deserve review whatever SAQ you use.
- A mid year change in checkout design may change your SAQ, so re-check after any redesign.
Who decides
The Council states that whether an entity must comply or validate, and how, is up to the organizations that manage compliance programs, such as payment brands and acquirers. Ask yours which SAQ they expect, and in writing.
Click through it at your own pace, or open it full screen.
Quick check
Do I need SAQ A if I use a redirect?
SAQ A is the usual fit for a redirect or fully outsourced setup if the provider is PCI DSS compliant, but confirm with your acquirer.
Is SAQ D only for big companies?
No. It is the fallback for any merchant not covered by another SAQ type, so size is not the test.
Sources
- Important Updates Announced for Merchants Validating to SAQ A
- FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants
- PCI DSS v4.0 SAQ D for Merchants
Last reviewed: 19 October 2026.
