SAQ A is the lighter validation path, but only when the merchant can confirm the site is not susceptible to attacks from scripts that could affect the e-commerce system. If that condition cannot be met, the merchant may need to move to SAQ A-EP, which carries a broader assessment burden and substantially more requirements. The distinction is driven by exposure, not preference.
Why the SAQ A to SAQ A-EP Boundary Moves When Script Risk Cannot Be Ruled Out
SAQ A is only appropriate when the merchant can rely on a very narrow hosting and payment-flow condition set, including confidence that the site is not exposed to scripts that can interfere with the checkout experience. If script resistance cannot be confirmed, the validation scope expands because the merchant can no longer assume the hosted page is isolated from e-commerce compromise paths.
That shift is about control exposure, not paperwork preference. Once a page can be influenced by browser-side code in a way the merchant cannot confidently bound, the assessor has to treat the site as having a broader attack surface and a higher validation burden.
The underlying issue is that browser scripts can alter what the customer sees, submits, or transmits during payment. For example, client-side compromise can redirect data, inject fields, or manipulate form behaviour in ways that make a “lightweight” attestation unsafe.
When that assurance is missing, the distinction between the two Self-Assessment Questionnaire paths becomes operational rather than theoretical: the merchant needs the more conservative form because the security boundary is no longer self-evident.
What Changes in Practice Between the Two Validation Paths
SAQ A is designed for merchants with the smallest feasible PCI DSS validation footprint, so long as the site remains outside the conditions that would let scripts affect payment security. SAQ A-EP exists for merchants whose websites still matter to the security of cardholder data collection, even if the actual payment processing is outsourced.
That is why the question is not “which one is easier,” but “can the merchant justify the narrower scope?” If script resistance cannot be confirmed, the site may need controls and evidence that align with a broader web application risk profile, including stronger oversight of the checkout page and adjacent integrations.
A useful way to think about the boundary is that SAQ A assumes the merchant has effectively delegated the sensitive payment interaction to a trusted external environment, while SAQ A-EP assumes the merchant site still participates in a way that can materially change payment security. The latter pulls the merchant closer to the integrity of the page itself, not just the payment provider relationship.
For practitioners, the practical consequence is that the merchant should assess the exact customer journey, the third-party scripts present, and whether any code on the page can influence payment data flow before deciding the questionnaire path. In many cases, the deciding factor is not the payment page branding, but whether the merchant can actually demonstrate safe containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
PCI DSS v4.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 12.3.1 — Usage Restrictions for Third-Party Scripts | Script resistance is central to hosted checkout eligibility and page integrity. |
| 6.4.3 — Script Integrity and Authorization | Merchant-side script control determines whether the checkout page can be trusted. | |
| 11.6.1 — E-commerce Tamper and Change-Detection | Cannot-confirm-script-resistance requires detection of payment-page tampering. | |
| Recommendation — Inventory and restrict third-party scripts on checkout pages, then verify they cannot alter payment collection. Authorize and monitor client-side scripts used on payment pages to prevent unauthorized modification. Implement tamper detection for e-commerce pages and alert on unauthorized client-side changes. | ||
Practitioner Guidance
What to verify: Confirm whether any scripts on the checkout or embedded payment page can read, alter, redirect, or intercept payment-related interactions. If you cannot demonstrate that boundary, do not treat the site as eligible for the lighter validation path.
Decision rule: If the merchant cannot confidently prove script resistance, prepare for SAQ A-EP scoping and the associated increase in evidence, control expectations, and assessment effort.
Common mistake: Treating hosted payment processing as sufficient by itself. Hosted checkout reduces scope only when the merchant can also show that browser-side code and page behaviour do not reintroduce payment-page influence.
Practitioner takeaway: The key question is not where the payment data eventually lands, but whether the merchant-controlled page can still be influenced in ways that change the security of collection or submission.
Related resources from NHI Mgmt Group
- What is the difference between implementing script protection on the merchant page and relying on TPSP confirmation?
- What is the difference between passwordless authentication and full ransomware resistance?
- What is the difference between phishing resistance and secure rollout for passkeys?
- What is the difference between FIDO2 and OTP-based MFA for phishing resistance?
