Payment Page Script Checker

What the Payment Page Script Checker checks

Enter the address of your checkout or payment page and this tool lists every script it runs: files from your own site, files from other services, inline code, and scripts that other scripts add after the page has loaded (we see those through a real browser run in Google PageSpeed). For each file it shows whether an integrity hash (SRI) pins its content and whether your Content Security Policy allows it to load.

The same run checks the scripts against Google’s malware lists and known compromised hosts, and looks for packed loaders and code from newly registered domains. It is passive: the page is loaded once, like a visitor would, and no script is downloaded or executed on our side.

Why it matters

Card skimmers (often called Magecart or e-skimming) don’t attack your payment provider. They add one script to your checkout page that copies what customers type and sends it elsewhere. Because every script on the page can read the form, a single compromised plugin, tag manager entry or third-party library is enough.

That is why PCI DSS 4.0, mandatory since 31 March 2025, added two requirements for e-commerce. 6.4.3 asks for an inventory of every script on payment pages, a written reason for each one and a way to confirm its integrity. 11.6.1 asks for a mechanism that notices unauthorised changes to the page. This tool gives you the inventory and the integrity status to start from; it is not a compliance certificate, and your assessor decides what evidence they need.

How to fix common problems

Go through the list with whoever owns the checkout. Remove every script that has no business reason on a payment page, such as chat widgets, heatmaps and social pixels. For third-party files that never change, add an integrity attribute so the browser refuses a modified copy, or host the file yourself.

Add a Content Security Policy that allows only the sources you listed, ideally with nonces and strict-dynamic, and start in report-only mode to see what would break. Then monitor the page from your account: we compare the third-party scripts on every run and e-mail you when a new one appears, which supports the change detection 11.6.1 asks for. Pro monitors run daily.

Questions

Does this make my site PCI compliant?

No tool can do that on its own. It gives you the script inventory and integrity status that 6.4.3 and 11.6.1 are about; the written justifications, processes and the assessment are yours.

Why are some scripts marked “added after the page loaded”?

They aren’t in the HTML. Another script (often a tag manager) inserted them while the page ran in a real browser. They matter most, because they are easy to miss in a code review.

Can I check a page behind a login or a basket?

Only pages that load without signing in. Many checkouts have a public payment step; for steps behind a login, run the checks in your own browser or ask your payment provider about a hosted payment page.

Why doesn’t SRI apply to scripts added later?

We can only see an integrity attribute in the HTML. Scripts injected by other scripts are loaded by code, so their protection depends on that code and on your CSP.