Payment page security and page integrity

This is the question worth asking before you choose anything. Compliance is assessed as of the time of the breach, not the time of your last questionnaire. A forensic investigation that finds the client-side control was inadequate affects your liability position, the fines passed through your acquirer, and in many cases whether your cyber-insurance responds at all. Being able to show what was monitored, and when, is the difference between an argument and a record.

This is the right question to ask of any client-side security product, and the answer is that our own tag is integrity-checked when it loads. If what arrives in the browser is not the script we published, it does not run. This matters more than it first sounds: a monitor an attacker can silently modify is worse than no monitor at all, because it reports all-clear while the page is compromised. It is worth asking every vendor you evaluate whether their agent verifies itself on load, because not all of them do.

Yes. The iframe belongs to your provider and reduces your scope meaningfully, but the page hosting it is yours. A script on that page can overlay a fake form, capture keystrokes before the iframe receives them, or change the iframe's source. Monitoring has to run on the parent page to see any of that.

No, though it reduces the value of what can be stolen after submission. Tokenisation protects the card once your provider holds it. It does nothing about the moment the customer is typing into a form, which is precisely when a skimmer reads it.

In short: the property that the page received matches the page intended. Assuring it means detecting change across the scripts that execute, the HTTP headers the browser received, and the page content itself. The three surfaces fail differently and are evidenced separately.

With selector rules. You define the URL patterns that constitute your payment scope, and that named scope becomes what both requirements are measured against. It also keeps the rest of your site out of the page-view count, so scope and cost move together.

Sometimes, and it is a separate decision. PCI only requires it on payment pages. Teams often extend monitoring to login and account pages, because the same class of script can harvest credentials or personal data, and because GDPR and HIPAA exposure does not stop at the checkout.

This works, and it needs care in configuration. In an SPA the payment step may not be a distinct document load, so scope is defined by the route and the presence of the payment form rather than by a server-rendered URL. Worth confirming during setup so your scope and your evidence line up.