PCI DSS 4.0 and Your Website: The Script Requirements Caught Everyone Out

PCI DSS is the card industry's security standard, enforced through your acquirer and payment providers rather than by a government regulator. Version 4.0 replaced 3.2.1, and a large block of its new requirements were future-dated, becoming mandatory on 31 March 2025 after a transition period.

Two of those future-dated requirements are specifically about websites, and they changed what merchants have to do in a way that a lot of businesses did not see coming, including some that had assumed a hosted checkout put the whole subject somewhere else.

The two that matter for a website

Managing the scripts on payment pages. The standard requires that scripts loaded and executed in the consumer's browser on a payment page are authorized, that their integrity is assured, and that an inventory is maintained with a written business justification for each one. In plain terms: know every script on your checkout, be able to say why it is there, and be able to tell if it changes.

Detecting change on payment pages. The standard also requires a mechanism that detects tampering with the HTTP headers and content of payment pages, alerting on unauthorised modification, with evaluation performed at least weekly or at a frequency justified by a risk analysis.

Both exist because of card skimming. The attack described in the Magento guide, where a small piece of injected JavaScript copies card details as they are typed, is invisible to the merchant and to the customer. These requirements are an attempt to make it visible.

Why this surprised people

Many merchants had reasoned that using a hosted or embedded checkout from a certified provider moved the whole problem to the provider. That reasoning is largely right about card data storage and processing, and it is why hosted checkouts remain the correct architecture for most businesses.

It is not right about the page. If your page loads the payment form, the scripts on your page are in a position to observe what the customer types into it, regardless of who processes the payment afterwards. That is precisely the gap these requirements address, and it is why they reach merchants who had understood themselves to have minimal obligations.

Whether and how they apply to your specific situation depends on how you take payments and which self-assessment questionnaire you complete, and the eligibility criteria for the simplest questionnaires were themselves revised around this. That is a question for your acquirer or a QSA, not for a web page.

The other 4.0 changes worth knowing

Beyond the payment page requirements, three general changes commonly affect website operations. Multi-factor authentication is required for access into the cardholder data environment, broadening earlier expectations. Password minimums increased, with twelve characters as the current baseline where passwords are used. And public-facing web applications require an automated technical solution that detects and prevents web-based attacks, which in practice means a web application firewall rather than the previously permitted alternative of periodic manual review.

The WAF point in particular has a practical consequence: an option that many small merchants relied on has effectively been removed, and a CDN-level firewall is now the straightforward way to satisfy it. See how a CDN layer handles this.

What to actually do

Start with the inventory, because everything else depends on it. List every script that executes on your payment pages, including tag manager containers and anything they inject, with a business justification for each. Most merchants doing this find scripts belonging to tools they no longer use.

Then remove what is not justified, restrict what remains, and put a change-detection mechanism in place so that a new script or a modified page raises an alert. A content security policy restricting script sources is a strong complement, though not by itself a substitute for detection.

Confirm which requirements apply to you with your acquirer or QSA before assuming either that you are covered or that you are exempt. Compliance obligations here are contractual and enforced through your payment relationships, and the consequences of getting it wrong show up as liability after a breach rather than as a fine beforehand.

A caution about dates and detail

PCI DSS is revised, and both the standard and its self-assessment questionnaires have been updated during the 4.0 lifecycle. Treat the specifics above as a pointer to check against the PCI Security Standards Council's own documents and your acquirer's guidance rather than as a citation to act on directly. This is an area where following stale guidance confidently is worse than knowing you need to look it up.

For where this sits among your other obligations, see website legal requirements, and for the platform view, website security by platform.