Payment Page Script
Also: Payment Page Scripts
PCIComplianceHubLast updated
Any script that loads and executes in the consumer's browser as part of a payment page, including analytics, tag managers, chat widgets, fonts and third-party libraries as well as the merchant's own code. PCI DSS Requirement 6.4.3 requires each such script to be authorized, its integrity assured, and an inventory maintained with a written business justification for every entry. The requirement addresses client-side skimming, where a compromised or malicious third-party script harvests card data directly from the page. This was future-dated at publication and became mandatory on 31 March 2025.
Applies to. Every script the consumer's browser interprets on a payment page: the merchant's own code, and anything loaded by analytics, tag managers, chat widgets, fraud tools and the provider's library. Markup and stylesheets are not scripts in the Council's sense; HTML and CSS are outside the 6.4.3 inventory.
Example. A checkout page loads the merchant's cart code, a tag manager, and through the tag manager a heat-mapping script nobody at the merchant chose. All three are payment page scripts. The third needs an inventory entry with a written justification, or removal.
Limits. Authorisation is a decision about a script's presence and integrity is about its content: a script can be authorised and still be tampered with, which is why 6.4.3 asks for both and 11.6.1 watches for change. The requirement is judged in the browser, so a script that never touches the merchant's server is still in scope. It has applied in full since 31 March 2025; before that it was a best practice.
In PCI DSS v4.0.1. 6.4.3 (Payment page script inventory)