If your checkout page embeds a payment form, such as in an iframe, SAQ A eligibility includes a criterion that your page is not susceptible to attacks from scripts. The PCI SSC FAQ gives two ways to meet it: apply protective techniques, or get confirmation from your payment provider. Merchants that fully redirect are outside this criterion.
What the FAQ says
The PCI Security Standards Council FAQ for e-commerce merchants says a merchant can confirm its webpage is not susceptible to script attacks in one of two ways.
The first is using techniques such as, but not limited to, those in PCI DSS Requirements 6.4.3 and 11.6.1, to protect the page against scripts targeting account data. The merchant or a third party may deploy them.
The second is obtaining confirmation from the merchant's PCI DSS compliant payment service provider that its embedded payment form, implemented per its instructions, includes protections against script attacks.
The FAQ states the criterion applies when the payment form is embedded, for example in an iframe. It does not apply to merchants that redirect customers to a provider or fully outsource payment functions.
Why this exists
Your page is where the embedded form lives, so any script on that page can try to change, overlay or watch what happens around the form. Attacks on e-commerce checkouts that inject script are well known. The criterion pushes merchants to treat the parent page as part of the risk, not just the iframe.
Practical steps for the first path
- Inventory every script on the checkout page: first party, tag managers, analytics, chat widgets, A/B tools.
- Justify each one. Remove anything without an owner and a reason.
- Detect changes. Monitor those scripts for unexpected change, and alert someone who can act.
- Limit the page. Keep checkout lean. A page with three scripts is easier to protect than one with thirty.
- Use a content security policy that restricts where scripts can load from, and test it in report mode first.
Read Requirements 6.4.3 and 11.6.1 in the current PCI DSS text for the exact wording; this post does not restate them.
Practical steps for the second path
Ask your provider, in writing, what protections their embedded form includes and what you must do to implement it as instructed. Keep that reply with your SAQ. If you change how the form is embedded, ask again.
Which path to choose
If your site is small and static, provider confirmation plus a lean page is often simplest. If marketing tags change weekly, you need your own monitoring either way, because the provider's protection covers their form, not your tag manager.
Safeguard's dependency and SBOM scanning helps with first party packages that ship to the browser. It is not a client side script monitor, so do not rely on it for the checkout page itself. Whether you qualify for SAQ A is a decision for you and your acquirer or assessor.
Quick check
Does a full redirect to a payment provider trigger this criterion?
Per the FAQ, no. It applies to merchants that embed the payment form, not those that redirect or fully outsource.
Sources
Last reviewed: 19 October 2026.
