Script monitoring for ticketing and event checkout pages

It is the canonical case and worth knowing precisely. In 2018 a customised JavaScript file supplied by Inbenta, a third-party chat supplier, was altered and served on Ticketmaster payment pages, capturing card data. Ticketmaster did not write the code and it was not on Ticketmaster infrastructure, which is the point: 6.4.3 exists because a page you own can execute code you did not write and cannot see change.

Yes, and continuous monitoring fits it better than scheduled scanning does. 11.6.1 asks for change detection at least every seven days, but a scan run on a Tuesday tells you nothing about a Friday onsale. Reporting from real sessions means the traffic you actually had is the traffic you have evidence for.

Yes. The tag is small, asynchronous and fail-open, so if our service is unreachable your checkout still completes. We are a monitoring dependency, never an availability dependency.

Yes, and this is the common case. Authorise the tag, record the justification and who required it, then block the single capability you are not willing to grant, such as reading form fields. The tag keeps working and the contractual obligation is met.

No. Domains are unlimited on every plan, and teams let you keep each client’s scope, alerting and evidence separate under one organisation.

No, not the page around it. The iframe is your provider’s, the page hosting it is yours, and an overlay drawn on top of an iframe collects cards perfectly well.

A generated pack: scope with the selector rules that matched each page, the script inventory with a justification per script, every security-header change with timestamps, and the alerts raised and acknowledged.

No, and we would rather say so. This covers script integrity and the two client-side PCI requirements. Scalping is a bot management problem and needs a different tool.