Script monitoring for airline and transit booking flows
A booking flow is long, multi-step, and carries more third-party code than almost any other checkout: seat maps, ancillaries, insurance, loyalty, currency and fare-comparison tags.
Start for free
Talk to an expert
TL;DR
Airlines and transit and the client-side requirements
THE OBLIGATION
PCI DSS 6.4.3 and 11.6.1 have been mandatory since 31 March 2025 for any page where a cardholder enters, reviews or confirms card data.
THE SPECIFIC DIFFICULTY HERE
Payment is one step in a flow of many, so payment-page scope is genuinely harder to define.
WHAT THE TAG PRODUCES
A script inventory with justifications, a weekly header change record, runtime blocking, and an evidence pack for your assessor.
Short on time? Scope a multi-step booking flow by selector rule rather than by URL.
How payment-page scope is defined
Does airlines and transit need PCI DSS script monitoring?
Yes, if you operate any page where a cardholder enters, reviews or confirms card data, which includes pages that embed a payment iframe. A booking flow is long, multi-step, and carries more third-party code than almost any other checkout: seat maps, ancillaries, insurance, loyalty, currency and fare-comparison tags. Requirements 6.4.3 and 11.6.1 apply to those pages regardless of platform, and have done since 31 March 2025.
Where the exposure is
Payment is one step in a flow of many, so payment-page scope is genuinely harder to define
Ancillary and insurance partners inject their own scripts into the booking path
High ticket values make the traffic attractive and the fraud economics work at low volume
Legacy booking engines make any change to the payment step slow and expensive
What the inventory shows you
Every script across the booking path, with payment-page scope defined by selector rules
Partner and ancillary scripts reading fields they have no reason to touch
Changes to the payment step introduced by a partner rather than by your own release
Header changes on the payment step, including ones introduced by a CDN or edge rule
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
The two requirements, in this context
Frequently asked questions
Read the FAQ
With selector rules rather than a single URL. You define the patterns that constitute payment scope, including steps that render the card form dynamically, and the dashboard shows exactly which pages matched and why.
Often yes, through your tag manager or the booking engine's own script-injection mechanism. Worth confirming during setup, because it varies by engine.
Yes. Any script that executes in the booking path appears in the inventory regardless of who introduced it, which is usually the first useful thing teams see.
This is web only. The tag monitors scripts in a browser, so a native app checkout is outside what it can observe. If your app uses a web view for payment, that web view is in scope.
See the scripts on your own payment pages.
Free forever on 1,000 page views a month, no credit card. Unlimited domains on every plan.
Free forever plan. No credit card.