Key points
• First confirm that the entity is permitted to self-assess and which document the acquirer or payment brand will accept.
• SAQ A is available only when every eligibility criterion is met; an iframe or redirect does not prove eligibility by itself.
• SAQ A-EP addresses e-commerce environments that do not receive account data but can affect transaction security; verify the current official criteria.
• A merchant that does not qualify for a narrower SAQ generally uses SAQ D; an SAQ-eligible service provider can use only SAQ D for Service Providers.
Quick answer and the boundary of this decision tree
An SAQ is selected from entity type, payment channels, architecture, and the complete eligibility criteria. Before beginning self-assessment, PCI SSC recommends asking the acquirer, payment brand, or other compliance-accepting entity whether the organization may use an SAQ and which questionnaire is appropriate.
This guide compares common e-commerce merchant routes A, A-EP, and D. It does not replace the questionnaire instructions and cannot determine merchant level, whether a QSA assessment is required, or whether self-assessment is accepted under a specific agreement.
Stop rule
If the architecture is not verified or one eligibility criterion is not met, do not continue as if the selected SAQ applies. Record the gap and confirm a different validation route.
SAQ A, A-EP, and D in one table
Use the table only for initial classification. Make the final decision against every eligibility criterion in the current PCI SSC questionnaire.
| Questionnaire | Typical candidate | Question to resolve |
|---|---|---|
| SAQ A | A card-not-present merchant that fully outsources account-data functions to PCI DSS-compliant TPSPs and does not electronically store, process, or transmit account data in its own environment. | Does the actual iframe or redirect meet every criterion, including merchant-site, TPSP, paper-data, and applicable ASV obligations? |
| SAQ A-EP | An e-commerce merchant that outsources account-data processing but has a website or systems that can affect transaction security and does not qualify for the narrower SAQ A. | Does account data remain outside the merchant environment, and does the architecture meet every A-EP criterion? |
| SAQ D for Merchants | A merchant that does not meet another SAQ's criteria, has a broader or mixed environment, or stores, processes, or transmits account data itself. | Is scope complete, and does the accepting entity require a ROC or QSA-led assessment instead of self-assessment? |
| SAQ D for Service Providers | A service provider that the accepting entity permits to self-assess. | Has self-assessment eligibility been confirmed? This is the only SAQ type available to an SAQ-eligible service provider. |
An e-commerce decision tree
Answer these questions in order and retain the architecture, contract, or evidence supporting each answer. A failed eligibility criterion cannot be offset by arguing that the associated risk is low.
- 1. Is the entity a merchant or service provider, and has the accepting entity permitted self-assessment?
- 2. Do merchant systems electronically store, process, or transmit account data?
- 3. Who creates every payment-form element, and where does the browser submit the data?
- 4. Can a merchant page, script, tag manager, server, or administrator affect transaction security?
- 5. Are all current SAQ A criteria met? If not, test A-EP; if that also fails, evaluate D.
- 6. Are there mixed channels such as e-commerce, MOTO, call center, paper records, POS, or other processes that change scope?
- 7. Has the final document and assessment period been confirmed by the acquirer, payment brand, customer, or QSA?
Technical facts required beyond “we use an iframe”
A commercial integration label is insufficient. For embedded fields, iframe, redirect, and Direct Post, document form-element origin, submission endpoints, merchant code around the form, redirect-modification paths, third-party scripts, administrative access, and systems that publish the page.
For each TPSP, retain a current AOC, covered-service scope, responsibility matrix, and integration instructions. A provider AOC does not prove that the merchant integration is correct or that every responsibility has transferred.
- Iframe and redirect analysis: Payment page security after PCI DSS 4.0.1: SAQ A, iframe, and evidence
- Why an iframe does not remove all client-side risk: Why an iframe payment form does not remove every client-side risk
Worked example: one store, three possible outcomes
Case 1: the store redirects to a processor, receives no account data, meets every questionnaire criterion, and has an accepted validation model. SAQ A may be a candidate, while merchant-site, provider, ASV, and other-channel obligations still require evidence.
Case 2: a payment form is embedded while merchant scripts, a tag manager, and the application can affect the page. Do not declare SAQ A automatically: verify the script-attack protection criterion and all other conditions. If a criterion fails, assess A-EP or a broader route.
Case 3: a merchant server receives form data or stores account data. The narrow A and A-EP e-commerce questionnaires generally do not match that architecture; scope and validation must address the broader requirement set.
A decision record that remains reviewable
A defensible record includes date, questionnaire version, entity type, accepting entity, payment channels, data-flow diagram, each eligibility answer, TPSPs, AOCs, exceptions, owner, and review date. Reassess it after changing the processor, form, payment domain, tag manager, CDN, checkout code, or contractual model.
The CSV below captures the decision without account data or secrets. Its rows are examples; replace them with facts from the real environment and use protected evidence references.
E-commerce SAQ decision record
CSV fields for architecture facts, criteria, evidence, accepting entity, owner, and review date.
CSV · example with no payment data
Five errors that make the conclusion unreliable
Most errors happen before questionnaire responses are entered, when the team bends the architecture description toward the preferred SAQ. Review these cases explicitly.
- Selecting SAQ A only because an iframe is visible.
- Selecting a questionnaire from transaction volume without architecture and accepting-entity rules.
- Ignoring tag managers, CMS, CI/CD, CDN, and administrative systems that can alter the page.
- Treating a provider AOC as proof that the merchant integration is compliant.
- Copying last year's decision after checkout or TPSP conditions changed.
What to do after selecting the questionnaire
Map every applicable requirement to an owner, control, system, test, and evidence source. Then perform a gap analysis and test control operation with real samples. A completed PDF does not prove that controls operated throughout the assessment period.
For e-commerce, separately verify ASV scanning, TPSP governance, public-application vulnerabilities, script-attack protection, script state, and change detection where those controls apply to the selected architecture.
- Complete PCI DSS 4.0.1 guide: PCI DSS 4.0.1: 12 requirements and readiness plan
- Audit evidence map: PCI DSS audit evidence map
Practical steps
1
Confirm entity type and self-assessment eligibility with the accepting entity.
2
Map the actual data flow and origin of every payment-form element.
3
Identify merchant and TPSP systems that can affect transaction security.
4
Test every current SAQ A and A-EP eligibility criterion without exceptions.
5
Record the selection or move to SAQ D with evidence and an accountable owner.
6
Obtain confirmation of the validation route and assign a review date.
Questions on this topic
Does SAQ A always fit a store that uses a redirect?
No. A redirect is one architecture fact. The environment must meet every current questionnaire criterion, and the validation route must be accepted by the receiving entity.
How does SAQ A-EP differ from SAQ A?
Both address card-not-present e-commerce with outsourced payment processing, but A-EP covers a merchant environment that can affect transaction security and does not meet the narrower A criteria. Use the complete official criteria for the decision.
Can a failed SAQ eligibility criterion be marked N/A?
No. N/A treatment for an individual requirement within an appropriate questionnaire does not make an ineligible questionnaire valid.
Can a service provider select SAQ A or A-EP?
No. PCI SSC states that SAQ D for Service Providers is the only SAQ available to an SAQ-eligible service provider.