Tamper detection on a page you do not fully control
A payment page legitimately varies between visitors. Tamper detection has to separate variance from change, or it produces noise nobody reads.
Start for free
Talk to an expert
What is tamper detection?
Tamper detection is a mechanism that notices when the page a customer received stops matching the page you intended to serve, and tells a human about it. PCI DSS 11.6.1 requires one on payment pages. The engineering difficulty is that modern payment pages differ legitimately between visitors because of A/B tests, locale, consent state and login status, so a mechanism that alerts on every difference is useless and a mechanism tuned until it is quiet is usually tuned past the point of value.
Variance is not change
A different hero image for half your traffic is variance. A new script origin, a changed payload hash on an approved script, a security header taking a value it has never taken, or a new outbound destination: those are changes. The distinction is what makes the alerts worth reading.
Evidence, not just detection
11.6.1 asks you to alert personnel. Detection without a recorded alert is half the control, and the alert record is the part assessors ask to see. Every detection carries a timestamp, the page, the before and after values, and who was notified.
It runs continuously, which clears the weekly floor
The requirement says at least once every seven days. Continuous evaluation means you never have to argue about the interval, and the evidence pack can state the real frequency instead of the minimum.
A targeted skimmer fires for a slice of traffic: one country, one card BIN, one hour. Sampling is the norm in this category, commonly 10% of sessions and sometimes as low as 1%. That is a coin flip against an attack designed to be rare.
Related platform capabilities
Script inventory
Every script, with a justification per script.
Header monitoring
Distinct values seen per header, per week.
Vendors and load chains
Who loaded whom, and from where.
Script blocking
By URL, hash, domain, or single action.
Monitor-only mode
The same evidence, nothing stopped.
Alerts
Three channels: email, webhook, or S3.
Frequently asked questions
Read the FAQ
This is the central design problem. Only changes against an established baseline raise alerts, and approved scripts stay quiet until their payload hash moves. The weekly digest contains only what changed, so a stable week produces a short read rather than a long one.
Three surfaces: the set of scripts executing and their payload hashes, the security headers as the browser received them, and structural properties of the payment form itself.
Yes, for the technical control the requirement describes, provided you have alerts routed to a real person and you keep the evidence. Your assessor makes the final call, which is why the evidence pack is built around what they ask for.
No, and nobody can. Browser same-origin policy prevents any script on your page from inspecting inside a third-party cross-origin iframe, and that is a security feature rather than a limitation of the product. What is detectable, and what matters, is the parent page: a script overlaying the iframe, changing its source, or capturing keystrokes before it.
See it on your own payment pages.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.