Know every script on your payment page.
Each week a real browser visits your payment page, lists every script that runs on it and compares the scripts, the security headers and the payment form with what you last approved. When something changes, you hear about it straight away, and every check leaves the record your assessor asks for.
Why payment pages are a target
Card-skimming attacks don't break into your payment provider. They add a few lines of script to your own page, often through a plugin, a tag manager or a third-party library, and copy card details as the shopper types them. The page keeps working, so nobody notices. PCI DSS v4.0.1 answers this with two requirements, in force since 31 March 2025.
6.4.3: manage every script
Keep an inventory of every script on the payment page with a written reason it's needed, confirm each one is authorised, and make sure each one hasn't been tampered with.
11.6.1: detect changes and tampering
Alert your people to unauthorised changes to the page's security headers and to the scripts as the shopper's browser receives them, at least once a week.
What the requirements ask, and how it's answered
Assessors don't ask whether monitoring is switched on. They ask you to show that every script was authorised and that you checked the page every week for the past year.
| What PCI DSS asks | What the dashboard does |
|---|---|
| 6.4.3 An inventory of all scripts on the payment page |
Every script is listed automatically on each check: script files, scripts added later by other scripts such as tag managers, inline code, and scripts inside embedded frames. Each one shows who serves it and what loaded it. |
| 6.4.3 Each script authorised, with a written justification |
You approve or reject each script. Approving needs a written reason, and every decision records who made it and when, in a history that can't be edited. |
| 6.4.3 The integrity of each script assured |
Each script's content is fingerprinted (SHA-256) on every check and compared with the version you approved. A changed script, a new one, or a rejected one still loading goes up for review. |
| 11.6.1 Unauthorised changes to security-impacting HTTP headers |
The page's security headers are compared with the last reviewed check. A removed or weakened Content-Security-Policy, HSTS, X-Frame-Options, nosniff or cookie protection is marked as needing attention, with the reason in plain words. |
| 11.6.1 Changes to the payment page as the browser receives it |
Alongside the scripts, the check watches the payment form: where it sends data, its fields (including card fields outside a form), embedded frames, and where shoppers are sent to pay. It can also type test details like a shopper, holding back anything the page tries to send and flagging any address it doesn't recognise. |
| 11.6.1 Personnel alerted |
The person responsible for the page and your account's owners and admins get an email and a dashboard notification as soon as a check finds something. |
| 11.6.1 At least weekly, or as your targeted risk analysis defines |
Weekly by default, at a time that varies. Monthly only with an approved targeted risk analysis, and back to weekly automatically if that analysis lapses. |
How it works
We set the check up with you, including any steps a shopper takes to reach the payment page. After that, each week looks like this.
The page is checked
A real browser visits the page the way a shopper would, records every script, header and form field, and takes a screenshot.
You review the changes
New and changed scripts wait for your decision. Anything that looks like a skimming pattern is marked as needing attention.
Someone signs it off
A named person signs off each check. Nothing is ever marked as fine on its own, and a check can't be signed off while a script still needs a decision.
The evidence builds up
Each signed check is added to the page's weekly history with its report, so a year of checks is ready when the assessor asks.
What you hand the assessor
- The script inventory, with each script's reason, who approved it and when.
- A log of every weekly check that shows any missed week, rather than hiding it.
- The signed report of each check: scripts, changes found, headers and a screenshot.
- The network record behind each check that found a change.
- One download that maps each file to the part of 6.4.3 or 11.6.1 it answers.
- A script management policy and an incident procedure to adapt, as Word documents.
Who it's for
- SAQ A-EP and SAQ D merchants whose own page hosts, embeds or hands off to the payment form.
- Service providers and Level 1 merchants with an assessor who needs a year of evidence.
- ISOs and resellers, who can see open changes across the merchants they manage.
Questions
Does this apply to me if my payment provider hosts the card form?
If your page embeds the provider's form or sends shoppers to it, that page is yours. On SAQ A-EP, SAQ D or a Report on Compliance, 6.4.3 and 11.6.1 apply to it. SAQ A doesn't include the two requirements, but to use SAQ A you confirm your site isn't open to attacks from scripts, and monitoring is one way to back that up.
How often is the page checked?
Every week, at a time that varies so the check can't be predicted. A page can move to monthly only with a targeted risk analysis approved in the dashboard; if that analysis lapses, the page goes back to weekly and you're told.
Will the check affect my shop or my customers?
It is one visit a week by a real browser, like a shopper's. It never pays: it stops before the hand-off to your payment provider, and the test details it types are held back, never sent.
What happens when something changes?
You get an email and a notification in the dashboard straight away. The review screen shows what changed and what needs attention; you approve or reject each script, and can raise a security incident from a change in one click.
Is a Content-Security-Policy enough on its own?
It helps a lot: an enforced policy stops scripts that don't belong from running. But 11.6.1 also asks for changes to be detected and people alerted, and 6.4.3 for a reviewed inventory with a reason for each script, which a policy doesn't give you. The two work best together.
Can it check a payment page behind a basket or a login?
Yes. The check can follow the steps a shopper takes, such as adding an item and going to checkout, and can sign in with a test account. The account's password is stored encrypted.
What do I give my assessor?
A download with the script inventory and each script's written reason, a log of every weekly check that shows any missed week, the signed report of each check and the network records behind it, mapped to the parts of 6.4.3 and 11.6.1 they answer.
Where is the data kept?
In the EU. Screenshots and network records are deleted 12 months after monitoring of a page is switched off.
Start monitoring your payment page
If you're on SAQ A-EP, SAQ D or a Report on Compliance, talk to us about setting up monitoring for your payment page. We'll go through how shoppers reach it and have the first check running with you.