How it reads

What the two requirements ask

Requirement 6.4.3 of PCI DSS v4.0.1 covers every script that loads and runs on the payment page in the shopper's browser. Each one needs a way to confirm it is authorised, a way to assure it has not been altered, and a line in an inventory with a written business or technical reason for why it is there.

Requirement 11.6.1 asks for a mechanism that alerts someone when the payment page's scripts or its security-relevant HTTP headers change, as the shopper's browser receives them. It runs at least once a week, or as often as the merchant's own risk analysis sets.

Both became mandatory on 31 March 2025.

The SAQ A line, and FAQ 1588

SAQ A is the short self-assessment a merchant signs when the card form belongs to the processor. Its revision dropped 6.4.3 and 11.6.1 from the form and added one eligibility criterion in their place:

“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).”

On 28 February 2025 the PCI Security Standards Council published FAQ 1588, which names two ways to make that confirmation:

“Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant's webpage from scripts targeting account data.”

“Obtaining confirmation from the merchant's PCI DSS compliant Third-Party Service Providers (TPSPs)/payment processor … that the TPSP's/payment processor's solution includes techniques that protect the merchant's payment page from script attacks.”

The criterion applies to “e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes)).” It does not apply to a merchant who sends the shopper to the processor's own page, or who has outsourced payments entirely. If that is your checkout, neither the criterion nor this product applies to you.

Sources: the Council's post FAQ clarifies new SAQ A eligibility criteria for e-commerce merchants (28 February 2025), and the FAQ index, where 1588 sits.

What one read does

A headless Chromium opens your address from a Vercel data centre in the eastern United States. Before it does, the server resolves the host and refuses anything that is not https on the default port, or that resolves to an address inside a private network. Every request the page then makes is checked the same way, and redirects are followed one hop at a time through that check, three at most for the page itself.

The browser waits for the load event, then up to 20 more seconds for the network to go quiet. The whole read, browser start included, stops at 25 seconds. The read skips media and fonts, so it never downloads the page's pictures. Scripts are always fetched: every script tag in the finished page, inline ones included, and every script another script pulled in without leaving a tag. JSON-LD and other data blocks run nothing, so they stay off the list.

Each script's SHA-256 is computed from the bytes the browser received; an inline script is hashed from its text. One read takes up to 60 scripts and 6 MB of script, and the ledger says where it stopped if a page runs past that. The page's own response supplies the five headers in the second table: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options and Referrer-Policy.

The justification column

The reader knows 67 script hosts: payment processors, fraud screens, tag managers, analytics, chat and consent tools. Each entry names the vendor, the category, one sentence on what the script does, and a link to the vendor's own documentation. Every link was opened on 9 October 2026; four answered with a bot block instead of the page.

A host the reader does not know is printed as a dotted field with the word “blank” in it. The justification under 6.4.3 is your sentence about your page, and a guessed line would be a false entry in your evidence. The free list shows the vendor and category; the watch prints the sentence and the source link beside each script's hash.

The receipt and the Monday read

A receipt is the inventory written as canonical JSON (keys sorted, no whitespace), named by the SHA-256 of those bytes and signed with Ed25519. The public key is served at /.well-known/receipt-key.json, and Check a Receipt repeats the check in your browser. A deployment without a signing key writes receipts that say “hashed only” and still re-hash to their own name.

Each Monday between 06:00 and 17:00 UTC the server reads every watched page again, compares it with the baseline line by line, and mails the changes: scripts added, removed or altered, integrity attributes dropped, headers changed. A week with no change gets a one-line receipt, because the run is the evidence. The address and the baseline ride on your subscription's record at Stripe; there is no database of ours to leak.

What one read cannot see

The read happens from outside the page, once a week, from one place. It will not see a script that is swapped for one visitor in one country for one hour. An assessor can read 11.6.1 as asking for detection inside the shopper's browser at the moment the page is served, and that is a reading this product does not meet.

One browser in one location sees one version of the page. A script served only to visitors from elsewhere, only after a cart exists, or only after a login, is outside what the read can reach. The browser identifies itself as headless Chrome, and a checkout behind bot protection may answer it with a challenge page; the ledger then lists the challenge's scripts, and the address in its heading shows where the read landed.

A ledger is a list of findings. Your assessor, or your own assessment, decides what it proves.

Other ways to do this, at their published prices

All three watch from inside the page or its traffic, through a script or a reporting header on your checkout, and that is how they see what each real visitor's browser loads. It catches the one-visitor swap this page cannot. PayPageWatch reads from outside and adds nothing to your page, at $49 a month per checkout domain however many shoppers arrive in the week you sell most.