PCI DSS payment page scripts: requirements 6.4.3 and 11.6.1 explained

What the PCI DSS payment page script requirements are

PCI DSS payment page scripts are governed by two requirements in version 4.0.1. Requirement 6.4.3 sits under Requirement 6, Develop and Maintain Secure Systems and Software, and deals with managing every script loaded and run on the page where a customer enters card details. Requirement 11.6.1 sits under Requirement 11, Test Security of Systems and Networks Regularly, and deals with detecting tampering on that page. One prevents, the other detects, and each leaves a gap without the other.

Both belong to the 51 requirements that v4.0 introduced as best practice and that became mandatory on 31 March 2025.

The wider picture of what else changed in v4.0.1 is in PCI DSS v4.0.1: what changed and what your next assessment tests.

Why scripts on the payment page became a PCI DSS concern

A modern checkout is rarely one piece of code. The page a customer sees is assembled in the browser from your own files and from third parties: analytics, tag managers, chat widgets, fraud tools, consent banners, advertising pixels and the payment provider's own library. Every one of those scripts runs with the same privileges on the page. If any of them is altered, at its source or on the way, it can read what the customer types into the card fields and send it elsewhere.

This is e-skimming, and the PCI Security Standards Council has published an information supplement on payment page security and preventing it. It is hard to notice from the inside: transactions complete normally and your servers see nothing unusual.

Which pages and which scripts the requirements reach

The answer depends on how the payment page reaches the customer, and it is the first question to settle with your QSA or, for a self-assessment, with your acquirer. The table sets out the questions Sterling works through for each common model; it is a starting point for that conversation, not a ruling on applicability.

Merchants that self-assess face one more question. In January 2025 the Council removed 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion instead, under which the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The requirements themselves remain in the standard. How that criterion decides between SAQ A and SAQ A-EP is covered in Which SAQ applies to you: eligibility explained.

The Council has also answered, in a published FAQ, how Requirement 6.4.3 applies to 3-D Secure scripts called from a merchant checkout page. If your checkout uses 3-D Secure, review it with your QSA.

Requirement 6.4.3 in practice: the script inventory

The heart of 6.4.3 is knowing, at any moment, exactly which scripts run on the payment page, why each one is there, that someone with authority approved it, and that the copy running today is the copy that was approved. In practice that becomes a living inventory tied to change control, with an integrity method for each entry.

The worked example below shows part of an inventory for a mid-sized online retailer whose checkout loads its own code and several third-party scripts. The column headings are the ones Sterling uses so that a QSA can trace each script to its approval and its check; the standard does not prescribe a format.

The last row matters as much as the others. The quickest way to reduce the work of 6.4.3 is to remove scripts that have no reason to be on the payment step. Marketing and customer-service tools often arrive through a tag manager without anyone in security knowing, and a tag manager on the checkout is effectively a door through which new scripts can appear without a release.

Requirement 11.6.1 in practice: detecting unauthorised change

Where 6.4.3 controls what should run, 11.6.1 asks how you would know if the page changed anyway. The requirement calls for a change- and tamper-detection mechanism on the payment page as the customer's browser receives it, with alerts when something unauthorised appears. Checking the files on your web server is not the same thing, because the attack often lives in a third-party file your server never holds.

The frequency of the check is supported by a targeted risk analysis under Requirement 12.3.1, and the PCI SSC's January 2025 SAQ A update named 12.3.1 alongside 11.6.1 for exactly that reason.

Detection only counts when someone acts on it. An assessor will ask who receives the alerts, how quickly they are triaged, how a genuine release is told apart from an attack, and what happens next. That last step should lead into your incident response plan, since a confirmed skimming script is a suspected compromise of account data and the acquirer's rules on notification apply.

What a QSA samples, and what goes wrong

Expect the assessor to load the payment page, list the scripts the browser actually runs and compare that list with your inventory. Any script missing from the inventory, or present in the inventory without an approval, becomes a question. Change records, the detection set-up and closed alerts are sampled next.

The failures Sterling sees most often are consistent:

• An inventory built once for the assessment and never updated, so the live page no longer matches it.
• Approval recorded for the team's own code but not for scripts added by marketing through a tag manager.
• Integrity checks on the web server only, blind to changes in third-party files served from elsewhere.
• Alerts routed to a mailbox nobody reads.
• Assuming an embedded or hosted payment form removes every obligation, while the parent page keeps loading unreviewed code.
• A targeted risk analysis for detection frequency that is missing or is a single unsupported sentence.

These sit alongside the other recurring failures described in PCI DSS common mistakes: the ten that fail assessments. Where a script control cannot be met as written, the routes available are set out in PCI DSS compensating controls and the customised approach.

PCI DSS payment page scripts: questions buyers ask