How should e-commerce merchants confirm that their site is not susceptible to script-based attacks under SAQ A?

How merchants prove their site is script-resistant under SAQ A

For SAQ A, the practical question is whether the merchant page can be altered or observed in a way that lets malicious script reach the checkout flow. The answer is not just “we use a hosted payment page.” Merchants need evidence that script execution on their page is controlled, monitored, or excluded by the payment design.

That evidence can come from two paths: merchant-side controls that align to PCI DSS Requirements 6.4.3 and 11.6.1, or documented confirmation from the TPSP or payment processor that its embedded payment page, when used as instructed, includes protections against script attacks.

What a valid confirmation should actually cover

A useful confirmation should be specific to the page and payment flow, not a generic statement that the merchant “uses a compliant provider.” The merchant should be able to show whether scripts on the payment page are inventoried, authorised, integrity-checked, and monitored for tampering. If the TPSP hosts the payment page, the confirmation should describe the exact integration conditions under which the provider’s protections apply.

That distinction matters because script-based attacks usually exploit the merchant-controlled page, the supply of third-party scripts, or a mismatch between the documented flow and the live implementation. PCI DSS for E-commerce Payment Page Scripts Guide is the most direct reference for the control pattern behind 6.4.3 and 11.6.1, including script inventory, authorisation and tamper detection.

Merchants should keep the confirmation tightly tied to the actual checkout architecture, because SAQ A eligibility can change if the merchant modifies the page, injects additional scripts, or steps outside the payment processor’s documented integration model. The merchant should be able to prove that the live implementation matches the documented one.

How to test the merchant-side path before relying on it

If the merchant is relying on its own controls, the test is whether it can detect script changes quickly enough to matter and explain which scripts are permitted to run. That means inventorying first-party and third-party scripts, defining approval for additions and changes, and validating that change or tamper detection is active on the payment page itself.

For teams preparing evidence, PCI DSS Readiness Checklist is useful because it frames SAQ route, payment page scripts, and the evidence pack together rather than as separate tasks. The point is not just compliance paperwork, but a defensible control story.

Merchants also need to preserve logs or alerts that show monitoring actually runs in production. A script control that only exists in design documents does not demonstrate resistance to script attacks if no one can prove it detects unexpected changes.

When the provider confirmation path is enough, and when it is not

If the payment page is embedded or hosted by a TPSP, the merchant can rely on provider confirmation only when the provider states the protections clearly and the merchant follows the stated integration model. The confirmation should explain what the provider protects, what the merchant is responsible for, and any conditions that would invalidate the assurance.

A broad provider statement is not enough if the merchant customises the page, adds uncontrolled code, or changes the checkout path. In that case, the merchant has reintroduced script risk and should treat the page as something that needs its own control evidence rather than inherited assurance.

PCI DSS 4.0 Guide helps anchor the broader SAQ and requirement context, while Card Payments Security for Small Merchants Guide is a practical starting point when merchants need to understand where SAQ A ends and where merchant-side responsibility begins.

Risk and Threat Considerations

Script-based attacks are attractive because they can steal card data or alter payment details without breaking the checkout flow in an obvious way. If a merchant cannot prove script resistance, the site may look compliant while still allowing page-skimming, injected code, or unexpected third-party execution.

Failure mechanism: An attacker or compromised third-party script alters the payment page, intercepts inputs, or exfiltrates checkout data before the merchant or customer notices.

Impact: Card data exposure, checkout manipulation, failed SAQ A assumptions, and possible loss of trust in the hosted-payment control model.

Practitioner Guidance

What to verify: Confirm that the current production checkout matches the documented SAQ A flow, including all allowed scripts, embedded components, and provider-hosted elements. If the page is modified in any way, recheck whether your assurance still holds.

Decision rule: If you can evidence active script inventory and tamper detection on the merchant page, retain the merchant-side control path. If you cannot, obtain a provider confirmation that is explicit about the embedded payment page, the allowed use case, and the protections in force.

Practitioner takeaway: The real test is not whether a merchant uses a third-party processor, but whether the live checkout path can be shown to resist script tampering under the exact way it is deployed.

Related resources from NHI Mgmt Group

• How should merchants interpret the new SAQ A eligibility criteria for script attacks on payment pages?
• How should merchants adapt their web script controls to keep qualifying for SAQ A under the updated PCI eligibility criteria?
• How should security teams prevent script-based attacks in modern application pipelines?
• How should payment security teams protect checkout flows from script-based skimming and overlay attacks?