Use this hosted checkout data flow
Inspect the browser, not the product label. Record every iframe, redirect, script, and card field used during checkout. Note whether a merchant-controlled page can change the provider destination or read payment data.
| Item | Check or owner | Evidence |
|---|---|---|
| Browser to merchant | Checkout initiation | Check scripts and redirect control |
| Browser to provider | Card entry | Confirm provider-owned fields |
| Provider to merchant | Payment result | Verify callback and token handling |
| Merchant back office | Refund and support | Check stored data and access |
Apply the evidence map
PCI SSC lists v4.0.1 in its document library. Take the actual browser flow to the acquirer or assessor to confirm validation path and SAQ eligibility. Keep the script inventory and a checkout trace. A redirect to a provider does not make the merchant website irrelevant.
Evidence to keep
Draw separate arrows for card data, payment token, and payment status. The merchant should know which of those enters its own systems. Inspect network requests during both successful and failed checkout. If an error page sends the card number in a query string, the intended hosted design did not match the real flow. PCI SSC guidance also treats embedded forms and redirects differently for SAQ A script criteria. Document which one is used before asking an acquirer to confirm the validation path.
Recheck the current SAQ A rule
PCI SSC announced a change to SAQ A in 2025: Requirements 6.4.3 and 11.6.1 were removed from that questionnaire, and an eligibility criterion about payment-page script attacks was added for merchants using embedded forms. This does not say those requirements vanished from PCI DSS for every entity or every validation path. Read the current SAQ, map the browser flow, and ask the acquirer or assessor to confirm the right path.
For a sandbox test, use a harmless script change against the chosen page protections. Record whether prevention blocks it or monitoring detects it under the stated alert target. Save the script list, page build, browser trace, alert time, and recovery action. This test checks a defense; it does not establish SAQ eligibility on its own. The PCI SSC update explains the SAQ A change; it does not replace the full standard or the acquirer’s validation decision.
Match the evidence to SAQ A eligibility
PCI SSC FAQ 1588 applies its script-related SAQ A eligibility criterion to embedded processor forms. It excludes the redirect examples it lists from that specific criterion. It describes merchant or third-party protections and a confirmation route from the compliant payment processor when the integration follows its instructions. Other SAQ eligibility criteria still apply.
The January 2025 update removed Requirements 6.4.3 and 11.6.1 from SAQ A and added the eligibility criterion. That change took effect on 31 March 2025. It did not remove those controls from PCI DSS for every entity. Keep the current questionnaire, provider compliance evidence, secure integration instructions, and acquirer’s validation decision together.
A harmless sandbox script-change exercise tests your chosen defenses; it cannot certify SAQ eligibility. If the defense is monitoring, record what changed, when it was detected, who was alerted, and how the page was restored. If it is browser policy, record the enforced policy and allowed origins. A browser policy cannot stop every trusted script from changing the DOM. Test failure paths and checkout logs for card data too.