For years the Payment Card Industry Data Security Standard had little to say about the specific way modern checkouts get robbed. Version 4.0 changed that. Two requirements, in force for every merchant handling card data since 31 March 2025, are aimed squarely at payment-page skimming. They are numbered 6.4.3 and 11.6.1, and between them they describe the defence this whole subject comes down to: know every script on your payment page, and notice when the page changes.
You do not need to be pursuing formal certification for these to be worth following. They are a plain checklist of what protects a checkout, written by the people who see the fraud. If you take card payments on a website, this is the shape of what you should be doing.
6.4.3: manage the scripts on the page
Requirement 6.4.3 says that every script loaded and executed on a payment page must be managed. It breaks into three plain obligations. First, each script must be authorised: someone has decided it belongs there and can say why. Second, the integrity of each script must be assured: you have a way of knowing it has not been tampered with. Third, you keep an inventory of the scripts with a written justification for each.
Read plainly, that is: keep a list of what runs on your checkout, be able to explain why each item is there, and have a mechanism that would tell you if one changed. The mechanisms that satisfy the integrity part are the ones worth knowing anyway, Subresource Integrity to pin files that have fixed versions, and monitoring for the ones that do not. The authorisation and inventory parts are mostly discipline: the exercise of listing every script on the payment page and asking, of each, whether it earns its place. Most sites doing this for the first time remove several.
11.6.1: detect changes to the page
Requirement 11.6.1 asks for a change-and-tamper detection mechanism on the payment page. It must alert the relevant people if there is an unauthorised modification to the HTTP headers and the content of the payment page as received by the browser, and it must run at least weekly, or at a frequency you can justify from a risk assessment.
The important phrase is “as received by the browser”. This is not a check on the files on your server. It is a check on what a real visitor’s browser actually loads, because that is where the skimmer lives and that is where a supply-chain change shows up. In practice it means something fetches the live payment page on a schedule, records its scripts and security-relevant headers, and compares each run against the approved baseline, raising an alert on any difference. A Content Security Policy in reporting mode contributes here too, because its violation reports are a live signal of the page reaching somewhere new.
The cheap way to satisfy both
There is a shortcut that makes much of this far easier: reduce what is in scope. If the card fields live in hosted fields served by your provider, rather than in your own page, the sensitive part of the checkout is no longer your page to inventory and monitor to the same depth. The requirements are scoped to the pages that handle card data, so moving the card data off your page shrinks what they cover. It does not remove the obligations entirely, the surrounding page still matters, but it turns a heavy job into a light one.
Combined, the practical programme is short. Move the card fields into hosted fields. Inventory the scripts that remain and cut the ones without a reason. Pin what you can with Subresource Integrity. Add a Content Security Policy with reporting. Put a weekly check on the live page against a known-good baseline, pointed at a person. That satisfies the spirit of both requirements and stops the attack they were written for.
The short version
PCI DSS 4.0 requirement 6.4.3 says know and vouch for every script on your payment page; 11.6.1 says detect when the page or its headers change in a real browser, at least weekly. Both have been mandatory since March 2025. You meet them with an inventory, Subresource Integrity, a Content Security Policy and a scheduled page check, and you make the whole job smaller by moving the card fields off your page in the first place.