Requirement 6.4.3 says you must know every script running on your payment page, authorise each one, and be able to show that none has changed without your knowledge. It became mandatory on 31 March 2025 alongside 11.6.1, which asks for tamper detection on the page itself. Both exist because card details are stolen in the browser now, not from your database.
What the requirement actually asks for
You need three things: an inventory of scripts loaded on the payment page, a written justification for each, and a method of assuring their integrity. That covers your own code and everything a third party delivers, which is where the work sits. A typical checkout loads analytics, a tag manager, a chat widget, a fraud tool and a fonts library, and several of those load further scripts of their own. Requirement 11.6.1 then asks for a mechanism that alerts you when the security-impacting headers or the script content on that page change, checked at least weekly.
Why the browser became the target
Skimming attacks moved to the client because that is where the card number exists in plain text. An attacker who can add or alter one line of JavaScript on your checkout captures the card details as the customer types them, and your server logs show nothing unusual because the data goes straight to the attacker’s endpoint. Tag managers make this easier: marketing teams add scripts without a code release, so the change never passes through your development process. When this happens the incident is a personal data breach as well as a card one, which brings the ICO into the conversation alongside your acquirer.
“The tag manager is the control gap in nearly every checkout I look at. Development has a code review process, a pipeline and an audit trail, and then somebody in marketing can inject arbitrary JavaScript into the payment page through a web interface with a shared login. Lock that down first, because the rest of 6.4.3 is paperwork by comparison.”
William Fieldhouse, Director, Aardwolf Security Ltd
Practical ways to meet it
Start by cutting the list. Every script you remove is one you never have to justify or monitor, and most checkout pages carry at least two that nobody can explain. Then apply subresource integrity to scripts loaded from a fixed URL, which makes the browser refuse a file whose hash has changed. Add a content security policy that restricts which origins may load scripts on the payment page, and use it in report-only mode first so you can see what breaks. For the monitoring requirement, either use a client-side monitoring service or build a scheduled check that fetches the page, extracts the script list and hashes, and alerts on any difference.
Proving it to an assessor
Bring evidence rather than intentions. Assessors want the inventory with dates, the approval record for each script, and screenshots or logs showing the integrity mechanism working, including an alert that fired when something changed. Keep a record of the review that removed scripts, because a shrinking inventory demonstrates the process is real. Web application testing supports this by confirming that the policy actually blocks an injected script rather than merely reporting it, and a vulnerability scan of the hosting infrastructure covers the server-side half that 6.4.3 does not address.
Frequently asked questions about payment page scripts
These questions come up when a checkout is reviewed against the current standard.
Does using a hosted payment page remove the requirement?
It reduces it considerably. If the card fields sit inside an iframe served by your provider, their page is in scope rather than yours, though the page hosting that iframe still needs care because a script there can redirect the customer elsewhere.
Is a content security policy enough on its own?
No. It restricts where scripts may come from and does not tell you what an allowed script does. Pair it with integrity checking and a change alert, which is what the requirement asks for.
