An approved list
Every script on a page that takes card details, with a written reason it is there, a named person who approved it, and a way of confirming it has not been altered.
Card rules have required a list of every script on your payment pages since March 2025, and a way to spot when one changes. Most shops have neither, and no idea what is actually there.
Works where you host your own checkout. If the fields live on someone else's domain we will say so rather than guess.
Three scripts on your payment page are not on any list.
A specimen reading, from a store that agreed to be shown, 12 Sep 2026. Two of them we cannot read the contents of, so a change would go unnoticed.A real reading, from a store that agreed to be shown
Two requirements, in force since 31 March 2025. Neither is complicated; both are tedious to do by hand and impossible to do from memory. Last reviewed against PCI DSS v4.0.1 in September 2026.
Every script on a page that takes card details, with a written reason it is there, a named person who approved it, and a way of confirming it has not been altered.
Something that notices when the page or its security headers change without authorization, checked at least weekly, as the customer's browser received them.
The honest answer is that your acquiring bank decides, and it turns on one thing: where the card fields live. SAQ A or SAQ A-EP is the questionnaire question underneath this.
| Your setup | Card fields are | Usually |
|---|---|---|
| WooCommerce with a gateway on the page | On your own site | in scope |
| Custom or headless build | On your own site | in scope |
| Magento, Stripe Elements embedded | In an embedded frame on your page | depends on your acquirer |
| BigCommerce with its own checkout | On the store software | reduced, ask them |
| Shopify hosted checkout | On Shopify | usually reduced |
We are not assessors and this table is not advice. If you are unsure, the question to put to your acquirer is short: which self-assessment questionnaire do you expect from us, and do 6.4.3 and 11.6.1 apply?
Tracking checks need nothing installed. This does, and the reason is uncomfortable.
Card-skimming scripts check whether the browser is being driven by software and go quiet if it is. A scanner gets served the clean version of a compromised page. That is the whole point of the technique.
One small script in your page reports what real customers' browsers actually received. It never blocks the page, it fails silently, and it is the only way to see what a scanner cannot.
Requirement 6.4.3 exists to police scripts on payment pages. Putting one more script on those pages is a real cost, and a serious buyer will ask what it can see. The answer has to be specific.
Script URLs, content hashes, and the security headers the browser received. That is the inventory and the change signal. Nothing else.
Form fields, card numbers, names, addresses, cookies that belong to the shop, or anything typed into the payment session. It has no reason to, and it is written so that it cannot.
The tag is itself an authorized script. Its hash is on the inventory and is monitored the same way as every other row. A change to Tagnovo is a change record, not a silent edit.
One script, one line, or a store-software app install. Never through a tag manager — a manager can drop or rewrite it without the inventory noticing the delivery path.
A generated pack, not a spreadsheet someone kept up to date by hand. Every check we ran in the period, every change we saw, who reviewed it, and a checksum on the cover so nobody can argue it was edited afterwards.
A specimen pack
Price is on the catalog, in your currency. Tagnovo is not a QSA and does not certify compliance. It produces the inventory and the change record an assessor asks to see.