Know every script on the checkout. Hear when one changes.
PCI DSS 6.4.3 asks a merchant to know every script on a payment page and why it is there. 11.6.1 asks to be told when the set or the content changes. Both have been mandatory since 31 March 2025.
The problem
A script arrived and nobody decided to let it in
A plugin update brings a tag manager. A marketing contractor pastes in a pixel. A theme loads a font from a CDN that loads something else. Half of the agencies managing a hundred or more sites say client-added third-party scripts are a problem they have (CloudLinux, State of WordPress Agencies 2026). On a page that takes card numbers that stops being a tidiness question, because the merchant is treated as having authorised whatever loads there — whether or not anyone did.
How it works
How payment-page scripts works
- 1
We find the pages that really take card details
A card field, a payment-provider iframe, or a provider’s own script. A URL that merely looks like a checkout is not enough: /checkout on a brochure site is not a payment page and is not reported as one.
- 2
The first pass is the inventory
Every script on those pages — external by URL with the query dropped, inline by the hash of its source. Nothing is approved on a fresh site, so the first report lists what is there. Approving what you expect is what turns later runs into a change detector.
- 3
After that it reports changes
A script not on your list, graded higher when it is third-party. An inline script you never approved. An approved script whose body hash no longer matches — the one observation this check grades critical. An approved third-party script with no integrity attribute.
Why it matters
What you get
Priced per site, not per pageview
The dedicated script monitors all sell by traffic, which does not divide into a portfolio: one busy client eats the tier and the other thirty-nine ride along. This is priced per site, like the rest of your stack.
An allowlist you own
The approved set is yours, per site. Approving a script records the hash of what you approved, and that recorded hash is what makes a later change reportable instead of invisible.
We report; an assessor assesses
A finding names the script, the page and the requirement it relates to. Only a qualified assessor says whether a merchant meets 6.4.3 or 11.6.1, and the report says so on the page.
Not sold on its own
This is one check of six, in one report
A script inventory on its own is a tool, and there are good free ones. What an agency can hand a client every month is the whole crawl in one document — so that is what this is priced and sold as.
Cookies before consent
The crawl loads each site cold, as a first-time visitor, and reports the cookies set and the trackers fired before anyone agreed to anything.
Accessibility (WCAG 2.2 AA)
axe-core in a real browser against WCAG 2.2 AA, plus a draft accessibility statement that names the parts only your client can answer.
Known plugin vulnerabilities
Plugin, theme and core versions read off a site’s own public pages, matched daily against the Wordfence Intelligence advisory feed.
Security headers and TLS
Six response headers per page and one TLS handshake per host: expiry, protocol version, chain and hostname. A missing header is reported as a missing header.
Legal pages
Privacy notice, terms, cookie policy, imprint and accessibility statement: present and loading, linked but broken, or a page with nothing in it.
FAQ
Questions, answered
c/side does this free. Why would I pay you for it?
You would not, and we do not sell it on its own. c/side is good at this one job and its free tier is real. What it does not do is accessibility, cookies before consent, plugin advisories, headers or legal pages, and it has no per-client branded document — and it prices by pageviews, which does not divide into a portfolio. This check earns its place as one of six in one report, not as a product.
Our client uses Stripe Elements, so the payment page is out of scope — isn’t it?
Worth checking with their acquirer rather than taking our word for it. The January 2025 SAQ A revision removed 6.4.3 and 11.6.1 from the questionnaire, but added an eligibility criterion that the payment page is not susceptible to attacks from scripts — which is a statement about the scripts on the page. An inventory is useful either way; what it is not is an answer to the questionnaire.
Do you install anything on the site?
No. The crawl loads pages the way a browser does and reads what the page served. There is no tag, no snippet and no plugin to add, which also means there is nothing of ours on a client’s payment page.
Features
More features
White-label client reports
One PDF per client per month, carrying your logo, your colours and their name. Nothing in it mentions us except the disclaimer.
Learn moreCookies before consent
The crawl loads each site cold, as a first-time visitor, and reports the cookies set and the trackers fired before anyone agreed to anything.
Learn moreAccessibility (WCAG 2.2 AA)
axe-core in a real browser against WCAG 2.2 AA, plus a draft accessibility statement that names the parts only your client can answer.
Learn moreStart with one page.
Paste a client’s checkout address and see what a crawl reports. No account, no card, and the report has a link you can send to anyone.