PCI DSS 4.0.1 Drags Checkout Scripts Into Scope, and Most Merchants Aren't Ready
Independent QSA assessment puts Reflectiz against the new client-side rules. The verdict: the script soup running on your payment page is now an auditable surface.

The deadline came and went on 31 March 2025. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 are now in force, and they push the security boundary of a payment page out into the customer's browser — where merchants have almost no visibility.
A new Qualified Security Assessor report tested the client-side monitoring vendor Reflectiz against those two requirements and concluded the platform meets them. That detail matters less than the underlying problem the report describes.
Here is the shape of it.
When a shopper types a card number into a checkout, the browser is executing far more than the merchant's own code. Analytics tags. A tag manager. A chat widget. A payment iframe. A consent banner. A modern checkout routinely loads dozens of third-party scripts, often loaded by other third-party scripts, and any one of them can be modified upstream to skim card data.
That attack pattern has a name and a long rap sheet: Magecart. Variants have hit British Airways, Ticketmaster, Newegg and hundreds of smaller Shopify and Magento storefronts since 2018. The British Airways breach alone exposed roughly 400,000 card records and drew an initial £183 million ICO fine, later reduced to £20 million.
Requirement 6.4.3 tells merchants they must maintain an inventory of every script loaded on a payment page, justify why each one is there, and confirm its integrity. Requirement 11.6.1 demands a mechanism to detect unauthorised modifications to the HTTP headers and script contents delivered to the consumer's browser, with alerts at least weekly.
Neither requirement is satisfied by a CSP header alone. Content Security Policy can block unknown domains but does not tell you when a permitted vendor silently swaps a function inside an approved script — which is exactly how the recent Polyfill.io supply-chain incident hit an estimated 100,000+ sites.
The QSA write-up walks through how a client-side monitoring tool is supposed to handle this: continuous inventory of first- and third-party scripts, behavioural baselines per script, change detection on form fields and network beacons, and evidence artefacts an assessor can actually pull during a Report on Compliance.
The uncomfortable part for merchants is the audit math. A SAQ A merchant who outsources the entire payment page to a PSP iframe is largely off the hook. Everyone else — SAQ A-EP and full ROC level 1 retailers — owns the script inventory problem, and acquirers have begun asking for evidence.
Forensics firms expect a wave of non-compliance findings during the first full assessment cycle under 4.0.1. The scripts were always there. The auditors are only now required to look.


