The Payment Card Industry Data Security Standard (PCI DSS) applies to every business that accepts card payments. Version 4.0 replaced version 3.2.1, which was retired at the end of March 2024, and a set of requirements first introduced as best practice became mandatory on 31 March 2025. Two of them target the code running on your checkout pages.
Why scripts on payment pages became a priority
Card-skimming attacks, often grouped under the name Magecart, inject malicious JavaScript into a checkout page. The script copies card details as customers type and sends them to the attacker, while the purchase completes normally. The store and the customer usually notice nothing until fraud reports arrive. Attackers frequently get in through a compromised third-party script, such as an analytics or chat tool, rather than through the store itself.
Requirement 6.4.3: control every script on the payment page
- Keep an inventory of every script loaded on payment pages, with a written business justification for each.
- Have a method to confirm each script is authorised.
- Have a method to assure the integrity of each script, for example Subresource Integrity hashes or a Content Security Policy that only allows approved sources.
Requirement 11.6.1: detect unauthorised changes
A change- and tamper-detection mechanism must alert you to unauthorised modifications to the HTTP headers and contents of payment pages as received by the customer’s browser. It must run at least weekly, or at a frequency set by your risk analysis. In practice this means monitoring the live page from the outside, not just your source code.
Does this apply if we use a hosted payment form?
Using a payment provider’s hosted page or embedded fields greatly reduces your scope, because card data never touches your systems. The PCI Security Standards Council has issued guidance on how these script requirements apply to merchants eligible for the shortest self-assessment, SAQ A, and the conditions have been refined since 4.0 was published. Confirm your obligations with your acquiring bank or a Qualified Security Assessor; the parent page that hosts an embedded payment form can still be a target.
Practical steps for any online store
- Use your payment provider’s hosted fields or checkout, so card data is entered on their domain.
- Remove marketing and analytics tags from checkout pages that do not need them.
- Set a strict Content Security Policy for checkout and report violations.
- Monitor the rendered checkout page for script changes and alert on anything new.
- Require multi-factor authentication for everyone with admin access to the store, hosting and code repository.
- Keep platform, plugins and dependencies patched; most compromises start with a known vulnerability.
