PCI DSS 6.4.3 Payment Page Script Inventory Auditor

Five lines in a Shopify checkout template were enough to put a UK merchant outside PCI DSS 6.4.3 - and every one of them had been sitting there, reviewed and approved, since before the requirement bit.

Since 31 March 2025 requirements 6.4.3 and 11.6.1 of PCI DSS v4.0.1 are no longer future-dated. 6.4.3 says that every script loaded and executed in the consumer's browser on a payment page must be authorised by some method, have its integrity assured by some method, and appear in an inventory with a written justification for why it is needed. 11.6.1 says a change- and tamper-detection mechanism must alert someone to unauthorised modification of the payment page and its HTTP headers, and must run at least once every seven days.

The five lines were ordinary. A tag manager, because marketing wanted it. A session-recording script, because support wanted it. A CDN script pinned to @latest, because that is what the docs showed. An integrity hash with no crossorigin attribute - which browsers silently ignore, so the hash was decorative. And one card input rendered by the store's own template rather than the provider's iframe.

That last one is the expensive line. SAQ A eligibility requires that all card fields come from the payment provider. One field of your own and SAQ A-EP or SAQ D applies instead, which brings 6.4.3 and 11.6.1 back in full. This is also the point most answers get wrong in both directions: the Council removed 6.4.3 and 11.6.1 from SAQ A on 31 March 2025 and replaced them with an eligibility criterion, which is not the same thing as an exemption.

None of the five needed a scanner to find. They needed someone to look at the template with the three bullets of 6.4.3 in hand. That is what this extension does: it reads the page source you already have open and lists what fails, with line numbers, before your acquirer's questionnaire does it for you.