E-commerce SAQ A Recovery
How an online merchant stopped treating SAQ A as an assumption and rebuilt its payment-flow, third-party, and evidence review around the architecture it actually operated.
PCI DSS v4.0.1 · SAQ A eligibility review
Engagement overview
- Environment
- Merchant-managed storefront with a third-party payment processor
- Primary question
- Does the implemented payment architecture satisfy every applicable SAQ A criterion?
- Engagement
- Payment-flow mapping, eligibility review, and evidence recovery
The Challenge
The merchant expected to complete SAQ A because payment processing was outsourced. A readiness review showed that the label alone did not establish eligibility: the checkout architecture, payment-page elements, third-party scripts, and provider responsibilities had not been documented well enough to support that conclusion.
- The team had not separated a full redirect, an embedded payment page, and merchant-controlled payment-page elements in its documentation.
- The origin and responsibility for checkout scripts were not fully inventoried.
- Provider compliance evidence and implementation guidance were not connected to the merchant’s actual configuration.
- External scanning, vendor-management, and payment-page evidence were incomplete for the intended validation path.
Investigation
The review treated SAQ A as an eligibility decision to be evidenced, not as a default outcome of using a third-party processor.
- Mapped the browser, storefront, payment processor, tokenization, and post-payment flows.
- Reviewed whether payment-page elements originated from the merchant, a PCI DSS compliant TPSP, or another source.
- Inventoried scripts and examined which protections and provider confirmations applied to the implemented payment page.
- Collected provider attestations, responsibility assignments, scan evidence, policies, and change records.
- Compared the actual architecture with SAQ A and SAQ A-EP eligibility criteria before selecting a validation path.
Readiness Findings
The merchant could not responsibly claim SAQ A until the architecture and evidence were reconciled.
- Outsourcing payment processing did not by itself prove that all SAQ A eligibility criteria were met.
- An embedded payment page required a specific review of protection from script-based attacks where the criterion applied.
- The merchant’s evidence did not clearly show which party owned payment-page security, script governance, and scan responsibilities.
- The correct result could have been SAQ A, SAQ A-EP, or another validation path depending on the final architecture and acquirer guidance.
Recovery Plan
The recovery plan prioritized an accurate validation path over a more convenient questionnaire label.
- Documented the intended payment architecture and removed unnecessary payment-page elements from the merchant storefront.
- Validated the processor’s PCI DSS status, implementation instructions, and responsibility boundaries.
- Established a script inventory and the applicable protection and evidence process for the chosen payment architecture.
- Closed gaps in external scanning, third-party management, policies, and payment-flow change control.
- Reassessed SAQ A eligibility with the entity receiving the validation, rather than declaring eligibility from processor use alone.
PCI DSS v4.0.1 guidance note
For PCI DSS v4.0.1 SAQ A, the applicable script-attack eligibility criterion is specific to e-commerce pages with an embedded TPSP/payment-processor payment page or form. Techniques such as those described in Requirements 6.4.3 and 11.6.1 may inform protection, or the compliant TPSP may provide the applicable confirmation; those requirements are not being presented here as automatic direct SAQ A obligations for every merchant.
Outcome
The representative merchant finished with a documented payment flow and a defensible decision process. The study intentionally does not claim SAQ A eligibility without evidence that every applicable criterion is satisfied.
- The merchant can explain which systems and payment-page elements are in scope and why.
- Provider evidence and merchant responsibilities are mapped to the implemented architecture.
- The final SAQ decision is based on eligibility evidence and acquirer or payment-brand confirmation—not on the use of a third-party processor alone.
Key controls addressed
- SAQ A eligibility criteria for outsourced and embedded payment models
- Requirement 11.3.2: External vulnerability scanning where applicable
- Payment-page script inventory and protection evidence where applicable
- Third-party service provider responsibility and evidence management
Lessons learned
- A payment processor relationship is not a substitute for architecture-level SAQ eligibility analysis.
- Redirects, embedded payment pages, and merchant-generated payment elements create different validation questions.
- When the evidence is incomplete, the safe outcome is to pause the SAQ claim and determine the correct path.
Continue the review
Need a clearer PCI readiness path?
Start with the architecture, scope, and evidence questions that determine what your organization should do next.