PCI DSS script monitoring for ecommerce checkouts
Your checkout runs code from analytics, chat, personalisation, reviews, affiliates and a tag manager that loads more of them. All of it executes on the page where the card is typed.
Start for free
Talk to an expert
TL;DR
Ecommerce and the client-side requirements
THE OBLIGATION
PCI DSS 6.4.3 and 11.6.1 have been mandatory since 31 March 2025 for any page where a cardholder enters, reviews or confirms card data.
THE SPECIFIC DIFFICULTY HERE
Marketing tags accumulate on checkout because nobody owns removing them, and each one is both an attack path and a 6.4.3 line item.
WHAT THE TAG PRODUCES
A script inventory with justifications, a weekly header change record, runtime blocking, and an evidence pack for your assessor.
Short on time? A hosted checkout does not take the page around it out of scope.
Hosted payment pages and PCI
Does ecommerce need PCI DSS script monitoring?
Yes, if you operate any page where a cardholder enters, reviews or confirms card data, which includes pages that embed a payment iframe. Your checkout runs code from analytics, chat, personalisation, reviews, affiliates and a tag manager that loads more of them. All of it executes on the page where the card is typed. Requirements 6.4.3 and 11.6.1 apply to those pages regardless of platform, and have done since 31 March 2025.
Where the exposure is
Marketing tags accumulate on checkout because nobody owns removing them, and each one is both an attack path and a 6.4.3 line item
The platform's own plugins and themes add scripts you did not choose and may not know about
A compromised ecommerce plugin is one of the most common Magecart entry points
Peak trading is exactly when nobody wants to touch the checkout, and exactly when an attack is most valuable
What the inventory shows you
Every script on the cart, checkout and confirmation pages, including plugin and theme scripts
Scripts that read payment form fields when that is not their purpose
A vendor shipping changed code, caught by payload hash rather than by URL
New outbound destinations from scripts that previously only talked to their own domain
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
The two requirements, in this context
Frequently asked questions
Read the FAQ
Often yes. If the payment form is an iframe served by your provider, the iframe is theirs but the page hosting it is yours, and a script on that page can overlay it or capture keystrokes before it. The parent page stays in scope for 6.4.3 and 11.6.1.
Yes, marginally, like any tag, and it is designed not to be felt: small, asynchronous and fail-open, so if our service is unavailable your checkout still completes.
There is a middle path. Block a single capability rather than the whole script, so the tag keeps working while losing its ability to read the payment form. That is usually the version that survives the conversation.
See the scripts on your own payment pages.
Free forever on 1,000 page views a month, no credit card. Unlimited domains on every plan.
Free forever plan. No credit card.