Third-party scripts on the payment page: what PCI DSS requires

Every script that runs on the payment page (chat, analytics, tag manager, reviews, marketing pixels) can, in principle, see what the customer types. That is why PCI DSS requirement 6.4.3 calls for an inventory of all those scripts with a justification, a method to authorize each one and another to make sure they have not been altered; and requirement 11.6.1 calls for a mechanism that detects changes to the page as the customer receives it and alerts staff, at least once a week. Both became mandatory on March 31, 2025.

Why third-party scripts are the weak link

A third-party script does not live on your server: the customer's browser fetches it from the vendor's server on every visit. If that vendor is breached or changes the file, your page changes too, without your team publishing anything. The PCI Security Standards Council's guidance on payment page security, published in March 2025, also points out that these scripts can load others from their own partners, and lists analytics, marketing, tag management, form validation and even payment tools among those that can be manipulated to capture data.

A Visa case study shows the multiplier effect. The investigation began with a bank's tip about a single restaurant, but the malicious code sat in a legitimate file hosted by the online ordering provider, not on the restaurant's website. The same file was used by many of the provider's more than 1,500 customers, and a third of them were compromised. Visa traced the source ten days after the infection.

What PCI DSS asks, in plain language

Requirement 6.4.3: inventory, authorization and integrity

Every script loaded and run in the customer's browser on the payment page needs three things:

• Authorization: a method to confirm each script was approved. The standard does not say how or by whom; according to the PCI SSC guidance, approval can happen before a script is added or changed, or as soon as possible afterwards, since vendors can change files without notice.
• Integrity: a method to ensure the script contains nothing unauthorized, both when it is introduced and with each update.
• Inventory: a list of all scripts, with a business or technical justification for each. In simple environments, the guidance says, a spreadsheet may be enough.

Scripts used for 3-D Secure authentication are exempt from this validation. And a vendor whose scripts have nothing to do with payment may not count as a service provider for other parts of the standard, but its scripts remain subject to 6.4.3 and 11.6.1.

Requirement 11.6.1: detecting changes

You need a mechanism that alerts staff to unauthorized changes (scripts that appear, change or disappear, and changes to security headers) on the page as the customer's browser receives it. It must run at least weekly or at a frequency set by a targeted risk analysis. The PCI SSC itself recommends frequent or real-time monitoring where feasible, because a malicious change can operate unseen between checks.

How to build the inventory in practice

1. Map the pages. Include the page that displays the payment provider's form. On single-page sites, where the browser does not reload between steps, scripts loaded earlier are still active at payment, and the guidance treats every view as in scope.
2. List what the browser receives, not just what is in your code: open the page as a customer, because tag managers add scripts on the fly.
3. Document each script: source address, vendor, internal owner, purpose, justification, who approved it and when.
4. Decide: keep it, drop it or move it to another page. No justification, no script.
5. Choose how to ensure integrity: an allow-list of permitted sources, verification of the file's fingerprint, or a specialized tool. PCI DSS does not mandate a method.
6. Record expected behavior: which fields the script needs to read and where it sends data.
7. Review on every change, including the ones the vendor makes on its own.

What can go wrong

• The spreadsheet goes stale. An inventory nobody updates becomes an old snapshot of the page.
• Approving the vendor, not the version. The file changes on their server, and the old approval does not cover the new code.
• Forgetting the page around the form. Using the provider's form reduces scope, but the page that displays it remains your responsibility.
• Alerts with no owner. If the mechanism only alerts and does not block, the PCI SSC stresses that the response must be fast; decide who receives alerts and who acts.
• Treating the minimum as the goal. A weekly check leaves days of exposure.

Proteside produces this evidence while it protects: it records the authorized scripts on the payment page, checks in the shopper's browser what changes and where data goes, and blocks what should not be there. See how the PCI DSS compliance solution and card payment protection work, and try it free for 14 days.