§Free payment page script checker
Who's running on your checkout?
Every script on a payment page can read what a customer types. Paste the URL of your checkout: we list every script the page loads, where it comes from and whether it's pinned to a known version, and check the headers that limit what can run.
01Payment page scripts
Every script can read the card.
A script on a web page can read everything on that page, including what a customer types into a payment form. That's how e-skimming works: attackers compromise one script, often a third-party one nobody on the team thinks about, and copy card details as they're typed.
PCI DSS v4.0.1 answers with two requirements that became mandatory on 31 March 2025. Requirement 6.4.3 asks for an inventory of every script on a payment page, with a written justification for each and a way to confirm each one is authorised and intact. Requirement 11.6.1 asks for a mechanism that detects unauthorised changes to those scripts and to the page's security-impacting headers, at least weekly.
If your checkout embeds a payment provider's form in an iframe, the scripts inside it are the provider's responsibility, but the scripts on your page around it are yours. Merchants validating with SAQ A now confirm instead that their site isn't susceptible to attacks from scripts, and PCI's FAQ 1588 names the techniques in 6.4.3 and 11.6.1 as one way to do it. Either way, the first step is knowing what runs on the page.
02How it works
Four steps, no guessing.
01
Page
We fetch the page the way a browser gets it before anything runs: public addresses only, ten seconds and five megabytes at most.
02
Scripts
We list every script tag, external and inline, and fetch up to 40 script files to hash them.
03
Integrity
Where a script has an integrity attribute, we check it against the file. Where it doesn't, we show the value you could add.
04
Policy
We read the Content Security Policy and check which scripts it allows, then HTTPS, HSTS, framing and cookies, and look through the code for exposed keys.
03What it checks
Scripts, policy, transport.
- ✓Every script tag on the page, external and inline, with where it comes from and whether it's first- or third-party.
- ✓A SHA-384 and SHA-256 hash of each script file as we fetched it, and whether its integrity attribute matches.
- ✓Tag managers that load more scripts after the page arrives.
- ✓The Content Security Policy: enforced, report-only or missing, 'unsafe-inline', 'unsafe-eval', wildcards, and which scripts it would block.
- ✓Iframes, and card fields in the page's own HTML.
- ✓HTTPS, scripts loaded over HTTP, HSTS, X-Content-Type-Options and protection against framing.
- ✓The Secure, HttpOnly and SameSite flags on cookies the server sets.
- ✓Secret keys left in the page or its scripts, such as secret API keys, private keys and database passwords, shown masked. Publishable keys aren't flagged.
- ✓A CSV inventory with columns for justification and sign-off, and a comparison with a CSV from an earlier check.
04What it can't see
Where code stops.
- —Whether you're PCI DSS compliant. This is an inventory, not an assessment or an ASV scan. Compliance is validated with PCI SSC's official forms, through your acquirer or assessor.
- —Scripts added after the page arrives, by tag managers or by other scripts. We read the HTML before anything runs, so they won't be listed.
- —Pages behind a login or a basket. We see what an anonymous visitor gets from that URL, so test a checkout URL that loads without a session, or a staging copy.
- —Scripts inside your payment provider's iframe. Those are the provider's responsibility, and we don't open them.
- —Cookies set by scripts, and secrets that only appear once the page runs or after signing in. Check those in your browser's developer tools (Application tab).
- —Changes over time. Comparing two exports helps, but it isn't the automated, at-least-weekly detection requirement 11.6.1 asks for.
05Questions
About Roll Call
- Is it free?
- Yes. There's no account and no email gate on the results. A captcha keeps automated traffic out, and each visitor can run up to ten checks every ten minutes.
- Does a clean result mean we're PCI DSS compliant?
- No. Roll Call lists what's on the page and checks a few controls that help with requirements 6.4.3 and 11.6.1. Compliance is validated with PCI SSC's official forms, through your acquirer or a Qualified Security Assessor, and no tool replaces that.
- Is this an ASV scan?
- No. An ASV scan is the quarterly external vulnerability scan that PCI DSS requirement 11.3.2 asks for, run by a company PCI SSC has approved. Roll Call reads one page and the scripts it loads.
- Our card form is in our provider's iframe. Does this still matter?
- Yes, for the page around it. PCI DSS makes the provider responsible for the scripts inside its iframe, but the scripts on the page that embeds it are still in scope for 6.4.3 and 11.6.1. Merchants on SAQ A confirm instead that their site isn't susceptible to attacks from scripts, and these techniques are one way to show it.
- Do we need Subresource Integrity on every script?
- No. PCI DSS doesn't mandate a specific integrity mechanism; PCI's guidance gives CSP and SRI as examples. SRI suits files that never change. For scripts a provider updates in place, such as many payment SDKs, a strict CSP and change detection work better.
- Can it watch the page for changes?
- Not on its own. Export the CSV after each check and load the previous one next time: Roll Call shows what appeared, disappeared or changed. Requirement 11.6.1 asks for automated detection at least weekly; if you'd like that set up, talk to us.
- Do you store what I check?
- No. We fetch the page and its scripts, check them and discard them. Results are held in memory for ten minutes so a recheck is instant. Our analytics record that a check ran, never which URL. A CSV you load to compare is read in your browser and never sent to us.
Beyond the inventory
Listing the scripts is step one. Keeping them honest is the work.
The inventory takes an afternoon. Justifying every script, tightening the policy and catching a change before a customer does take a process. We wrote about cutting through scanner noise in Most of your scan findings are noise.