How to build a payment-page script inventory
The hard part is never writing the list. It is knowing what belongs on it, because vendors load vendors and the browser does not care who added what.
TL;DR
Building the inventory
START FROM REALITY
Record what actually executed in real sessions. A list built from memory is wrong on day one.
CAPTURE THE CHAIN
Who loaded whom. The chain is what answers 'how did this get here', which is the first question anyone asks.
JUSTIFY PER SCRIPT
Not per vendor. A vendor fine on your homepage may have no business on your checkout.
Short on time? The inventory is the foundation for everything else in 6.4.3 and 11.6.1.
How do you build a payment-page script inventory?
Record every script that executes on your payment pages in real user sessions, capture which script loaded each one, then review the list and attach a written business justification and an integrity check to every entry you keep. PCI DSS 6.4.3 requires an inventory with a written justification per script, plus a method to confirm each script is authorized and to assure its integrity. The requirement does not care whether you added a script or your vendor's vendor did, because the browser does not either. Building the list from observed execution rather than from memory is the only approach that produces a complete one.
You approve a vendor, the vendor loads its own vendors. 6.4.3 applies to every script that executes, not only the ones you added yourself.
Why a list built from memory is always wrong
A tag manager is a mechanism for loading other people's code. The vendors it loads frequently load their own, so what executes on your page is a tree rather than a list. Approving a vendor is a commercial decision about a company. What executed was a chain, and the last link is often somebody you have never heard of.
The consistent experience when teams first look is not the number of scripts but the depth: scripts two and three links away from anything anyone approved.
What each inventory entry needs
Field
Why it is there
Script URL or identifier
How you refer to it. Inline scripts need an identity too
Origin domain
Where it loaded from
Loaded by
The parent in the chain. This is the field that explains surprises
Payload hash
The integrity anchor. A URL is not enough, contents change without it
Business justification
Why this script is necessary on this page
Owner
A named person or team who decides whether it stays
State
Approved, requires action, blocked or ignored
First and last seen
Establishes when something appeared, which matters after an incident
Start the inventory from what is executing on your checkout right now.
Writing justifications that hold up
The test is whether the justification explains this script on this page. 'Analytics' fails. 'Measures checkout completion rate, owned by growth, reviewed quarterly' passes, and has the useful side effect of making it obvious when a script should be removed.
Three questions produce most of them: what does it do here, who owns keeping it, and what breaks if it goes. A surprising number of scripts have no answer to the third, and deleting those is the cheapest compliance work available.
Pinning integrity to the payload
A vendor can change file contents without changing the URL. If your integrity check is 'still loading from the approved domain', you will not notice. Recording the payload hash you approved turns a vendor update into a review item instead of a silent inheritance.
Keeping it current without an annual scramble
An inventory is a living record, and the failure mode is organisational rather than technical. The workable shape is a weekly queue containing only what changed: new scripts, new destinations, and approved scripts whose payload moved. Everything stable stays quiet, and a ten-minute weekly review actually happens.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read. Primary sources: PCI SSC FAQ on 3DS scripts.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
Yes. 6.4.3 covers all scripts loaded and executed in the consumer's browser on a payment page, which includes your own. Your own code is usually the easiest to justify, so it is quick work.
They count, and they need an identity of their own since they have no URL. Hashing the inline content is the usual approach. Injected inline scripts are also a common attack shape, so they are worth attention rather than exclusion.
By recording what actually executed rather than what you configured. The call stack at load time names the script that triggered each load, which is what lets you reconstruct the chain rather than guess at it.
Weekly is the practical rhythm if the review surfaces only changes. Annually is what happens when the review surfaces everything, and annual review is how inventories drift out of date.
No. 6.4.3 covers scripts loaded and executed on the payment page, not only those that interact with the form. A script's current behaviour is not a guarantee of its future behaviour, which is rather the point of monitoring it. The one documented exception is 3-D Secure: PCI SSC says scripts used for their 3DS function do not need validating under 6.4.3.
It still belongs in the inventory, and it is often the interesting one. A script appearing in a small share of sessions is exactly what a targeted payload looks like.
No, not for PCI. Many teams do it anyway for login and account pages, because the same class of script can harvest credentials, and because consent and privacy obligations are site-wide.
There is a middle path that usually survives the conversation: keep the script and remove one capability, such as reading form fields. It is a smaller and more defensible action than removing the vendor entirely.
Partly. The inventory itself can be a spreadsheet. The integrity assurance half of 6.4.3 is the problem, because a static document cannot detect that a vendor changed their payload.
They test it: they will look for a justification per script, check that it is current against what is actually on the page, and ask how you would know if a script changed. An inventory that does not match live reality is the common finding.
No, not for their 3DS function. The PCI Security Standards Council says scripts loaded for 3-D Secure, through the iframe your 3DS server provides, do not need validating under 6.4.3, because of the trust relationship you already have with your 3DS provider. Any script that runs for another purpose on the same page is still in scope.
Related articles
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
PCI DSS
PCI DSS 4.0.1 requirements: what changed and when
The changes that matter, the dates that already passed, and the two requirements most teams missed.
PCI DSS
How to comply with PCI DSS 6.4.3 and 11.6.1
A step-by-step method, from defining payment-page scope to handing an assessor the evidence.
PCI DSS
SAQ A and the script requirements: who is exempt
The January 2025 carve-out is narrower than most people think. Here is what it actually says.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.