The questions we get asked most about payment page monitoring, PCI DSS requirements 6.4.3 and 11.6.1, and what our service does and does not do. If you want the longer explanations, start with what requirement 6.4.3 asks for, what requirement 11.6.1 asks for, and how our monitoring works.
Can I add an integrity hash to the Google Ads or Google Analytics script?
No, and you should not try. Subresource Integrity works by hashing a file that never changes, and Google updates gtag.js, the Google Tag Manager container script, and the Google Ads conversion tags on its own schedule. An integrity attribute on any of them works until the next update and then blocks the script silently in every visitor's browser. Google does not publish hashes for these scripts. Use a Content Security Policy to constrain what may load, write the business justification the requirement asks for, and monitor the script's contents so a change is something you find out about.
Our guide to script integrity on payment pages goes through this in full, including running Google Tag Manager under a CSP with a nonce.
Which scripts on my checkout can I hash?
The ones with fixed, versioned URLs. A library pulled from cdnjs, jsDelivr or unpkg with a version number in the path is exactly the case Subresource Integrity was designed for. So is any file you build and deploy yourself with a content hash in the name. Those URLs never change their contents, so the hash stays correct. Remember that an integrity attribute on a script from another domain also needs a crossorigin attribute, or the browser blocks the script instead of checking it.
Is payment page monitoring the same as a PCI scan?
No. They are different services covering different requirements. An ASV vulnerability scan probes your server from the internet and produces a pass or fail against requirement 11.3.2, and it is what your acquiring bank usually asks for quarterly. Monitoring loads your payment page in a browser and produces an inventory and a change history against requirements 6.4.3 and 11.6.1. Monitoring never issues a verdict on your site and it does not produce an Attestation of Scan Compliance.
If a scan is what you need, start there and switch monitoring on during signup. Our note on scanning versus penetration testing covers the third thing people confuse these with.
Do I need this if I validate with SAQ A?
Probably not as a numbered requirement, and quite possibly as work you have to do anyway. The SAQ A published in January 2025 does not list 6.4.3 or 11.6.1. In their place is an eligibility criterion you have to meet before the form is available to you at all. Every element of the payment page must come only and directly from a PCI DSS compliant provider, and you must have confirmed your site is not susceptible to script attacks. Whether that touches you depends on how you take payment. A full redirect sends the customer off your site, so your page never renders the payment form. An embedded form does render on your page, so it does.
Your acquiring bank decides which SAQ you may use and can ask for more than the questionnaire does. Our SAQ selection guide walks through the decision.
My card fields are in a Stripe iframe. Does any of this apply to me?
Yes, to the page hosting the iframe. Stripe Elements, Braintree Hosted Fields and similar integrations keep the card number out of your DOM entirely, which is the right architecture and is why your server never sees a card number. But your page is still the thing that renders around the frame. A script injected into your page can move the frame, cover it with a fake form, or read what the customer types into your own fields. The scripts on the hosting page are in scope for exactly that reason.
How often do you check?
Every day. Requirement 11.6.1 sets a floor of once every seven days, or a different frequency you justify with a targeted risk analysis under 12.3.1. Checking daily clears the floor without needing that analysis. The practical argument is stronger than the compliance one. A skimmer that sits on your checkout for six days before anybody looks has had six days of card numbers.
Will I get an alert every time Google updates its tag?
Only if you want one. Google Tag Manager and the Cloudflare beacon change their contents most weeks, and alarming on every one of those trains people to clear alerts without reading them, which is worse than not monitoring. So when you write the justification for a script, there is a box you can tick. It says this vendor updates its script on its own schedule, and routine changes to its body should not be flagged. It is pre-ticked for vendors we recognize as shipping their own code, and never for your own domain, an unknown host, or a package CDN.
What that setting never suppresses is a new host, a new subdomain, or an integrity attribute disappearing. A new name is not a routine update, whoever the vendor is. The change is still recorded either way, and the setting is part of the justification, with a date and a person against it, so an assessor can see who decided that and when.
Can you see the scripts that my tag manager loads?
Yes. Monitoring loads your page in a real browser rather than just fetching the HTML, so scripts a tag manager pulls in after the page starts running are visible to us. This is the main difference between monitoring and our free one-off check, which reads the page source only and cannot see them. Every report also states how much of the page that day's scan actually covered, so the limit of any given run sits on the evidence you hand an assessor rather than hidden inside it.
Do you write the justifications for me?
No, and no tool honestly can. Requirement 6.4.3 asks for a business reason, in words, for why each script is on a page where somebody types a card number. Only you know why a marketing tag is on your checkout. What we do is hold the answers, show you which scripts are still missing one, and flag it the moment a script turns up without a reason.
Do I have to install anything or add a tag to my site?
No. We load your page from outside, the way a customer's browser does, so there is nothing to install, no snippet to add, and no access to your server or your CMS required. You add the page's URL from the dashboard and confirm it is yours. That is deliberate. The point of the requirement is to see what actually arrived at the customer, and a script we asked you to add to your own page would be reporting on itself.
How many pages can I monitor, and does it cover subdomains?
One subscription covers one domain, including every subdomain of it, and you can watch up to five pages on that domain. You add each page yourself from the dashboard. Five is usually more than enough, because most sites have one checkout, but it covers the case of a separate payment page per currency, per brand, or per region.
What if my site is behind Cloudflare or a WAF?
It still works, and this is a question worth asking any vendor. A firewall or bot filter may answer an automated request with a challenge page or a 403 instead of your real checkout. That response is real HTML, so a careless tool will read it, find none of your scripts, and report that everything is clean. That is the worst possible failure, because it looks like good news. We tell a page we read apart from a page we never saw. We will not mark scripts absent on the strength of a challenge response, and a page we cannot reach for long enough is reported as a problem rather than as a clean result.
What happens if you cannot reach my page one day?
It is recorded as a day we did not reach it, and you can see that in the history. This matters more than it sounds. A monitoring service that only emails you about changes is indistinguishable, from your inbox, from one that broke months ago. So we send a weekly email when nothing has changed, as well as an email when something has. The quiet week is the message that proves the noisy one still works.
What do I actually hand an assessor?
A dated inventory of every script on the page, showing who serves it, the date it was first seen rather than just that it is there now, and the justification you wrote for it. Alongside that, the record of what changed and when, which days a scan reached the page, and what was decided about each finding. You can take it as a spreadsheet or as a report you can print.
How long do you keep the records?
Thirteen months of raw observations, which is four quarterly reports plus the thirteenth month a year-on-year comparison needs. The findings themselves, their history, your written justifications and the alerts we sent are not deleted on that schedule. "When did you first tell me, and what did I write down about it" has to outlive the raw data behind it.
Does it tell me whether I pass?
No, and that is deliberate. This service produces an inventory and a record of changes. It does not issue a verdict on your site, it is not an ASV scan, and it does not carry our site seal. Whether you meet 6.4.3 and 11.6.1 depends on the justifications you wrote and the decisions you made, which are yours and not ours to grade.
Will it remove a bad script for me?
No. We tell you what is there and when it appeared. Deciding what comes off the page is your call, and it is worth saying that taking a script off is usually the better answer than justifying it. A support chat widget, a review widget or an advertising pixel often has a good reason to be on a product page and no reason at all to be on the checkout. Removing one is the cheapest security improvement available to most merchants.
What does it cost?
Monitoring on its own is $24 a quarter or $77 a year. As an option on a scanning subscription, chosen when you sign up, it is $20 a quarter or $64 a year on top of the scan. Paying for a year works out cheaper than four quarters either way, and the add-on route means one subscription and one renewal date.
Our pricing page has the full table.
I already buy scanning from you. Can I add it?
Yes. Monitoring is an option on the scanning subscription, so it goes on the same subscription with the same renewal date rather than becoming a second thing to manage. Add it from the scanning signup.
Can I see what is on my checkout before I decide anything?
Yes. Our free payment page check reads your checkout page once. It lists the scripts written into its HTML, which of them come from a domain other than yours, and which carry an integrity attribute. No sign-up, and nothing is published. It is a snapshot rather than a monitor, so it cannot tell you what changed, but most people find at least one entry they cannot immediately explain.