Visa and eTA checks are now a booking-flow requirement, not an afterthought.
For most of the industry's history, a visa or entry requirement was the traveller's problem, solved somewhere upstream of the airline and quietly verified, if at all, by a check-in agent running a lookup a few hours before departure. That model survived as long as it did because it matched the reality it was built for: most travel required nothing beyond a passport, the exceptions were rare enough to check manually, and catching a problem at the gate, while bad, was rare enough to treat as an edge case rather than a design requirement.
That assumption is breaking, country by country, as governments convert what used to be visa-free entry into a pre-approved authorization a traveller has to obtain before departure, not on arrival. The United States has run this model since 2009. The United Kingdom now runs a version of it for most visa-exempt visitors. The European Union is moving through the final stages of a long-delayed rollout of the same idea across the entire Schengen area. None of this is a footnote anymore, and a booking flow that still treats entry eligibility as something to mention in a confirmation email, rather than something to verify before the card is charged, is building on an assumption that is now actively wrong for a growing share of its own bookings.
Why entry requirements stopped being a formality
The US ESTA program has been around long enough that most of the industry has stopped thinking of it as a meaningful example of anything: apply online, pay a small fee, get approved in minutes, board as normal. It became the template most people picture when they hear "electronic travel authorization," which is exactly why the newer versions of the same idea have been so easy to underestimate. The UK's ETA scheme now covers most visa-exempt visitors who previously travelled on nothing but a passport, and the EU's ETIAS is set to do the same across the entire Schengen area once its long-delayed rollout finishes landing. Together, these are not three isolated schemes. They are a pattern: three of the largest inbound travel markets in the world converting frictionless entry into a pre-approved one, in the same decade.
The reason this matters more than it used to is not the authorization itself, which is usually cheap and usually fast. It is what a missing one now means for a carrier. Airlines have carried liability for boarding passengers without correct entry documentation for decades, under carrier-sanction rules that predate any of this digitization: a carrier that boards someone who gets turned away at the border can be fined, and is typically on the hook for flying that passenger home. IATA's Timatic database exists specifically to manage that exposure, giving check-in staff a single place to verify document requirements before a passenger reaches the gate. Timatic was built for a world where that check happened once, close to departure, for a small minority of passengers. It was never designed to be the only place the check happens for a rapidly growing majority.
What changed is not that the rule got stricter. It is that the rule now applies to enough passengers, on enough routes, that a check-in-time lookup is too late to matter. A missing visa used to be rare enough that catching it at the airport was an acceptable, if painful, last line of defence. A missing eTA is now common enough, on the right routes, that the airport is the worst possible place to discover it, for the traveller, the carrier, and whichever platform sold the ticket.
From gate-side lookup to booking-flow requirement
The structural problem with a gate-side check is timing, not accuracy. Timatic, run correctly, tells an agent the truth about what a passenger needs. It just tells them at the one moment in the entire journey when a missing requirement can no longer be fixed without losing the trip. An eTA or ETIAS authorization typically has to exist before departure, sometimes days before, which means a check that only happens at check-in is not really a check at all for that requirement. It is a very late, very expensive way of confirming that the booking is about to fail.
Moving the check earlier, into the booking flow itself, changes what a failure actually costs. A traveller who discovers at the point of purchase that a destination now requires a pre-travel authorization has options: apply immediately, choose a different date that allows processing time, or decide not to book at all before any money has changed hands non-refundably. A traveller who discovers the same requirement at the airport has none of those options left. The booking has already converted, the trip is already priced in against non-refundable inventory in most cases, and the only remaining question is how badly the failure gets handled from there.
This is the same argument this desk has made about the post-booking servicing gap generally, applied to a specific and rapidly growing failure mode: the industry has spent two decades optimising the moment of purchase and treating everything that could go wrong afterward as somebody else's problem to absorb. Entry-requirement checking used to be a reasonable exception, because it affected few enough bookings to live outside the checkout flow without much consequence. It is no longer a reasonable exception. It is now exactly the kind of failure a well-built checkout flow exists to catch before it becomes a servicing problem at all.
What happens when the check happens too late
A denied boarding over entry documentation is one of the few failure modes in travel that is almost entirely uncompensated for the traveller. It is not a schedule change, it is not the airline's fault under most fare rules, and it typically falls into the same category as a passenger simply not showing up: the fare is forfeited, and whatever downstream bookings, hotels, tours, transfers, were tied to that arrival date are usually forfeited along with it. The traveller absorbs the largest part of the cost, but they are rarely the only ones who do.
The carrier absorbs the regulatory exposure. Carrier-sanction rules exist precisely because governments have decided that airlines, not just travellers, are responsible for verifying entry documentation before departure, and a pattern of boarding passengers without valid authorization draws exactly the kind of regulatory attention no airline wants. The platform that sold the booking, OTA, tour operator, or loyalty program redemption engine, absorbs a different kind of cost: a traveller who was never warned rarely accepts that the failure was their own oversight, and the chargeback, the public complaint, and the customer who never returns all land on the seller, not on the government that changed the rule.
What a real entry-requirement check actually has to do
A genuinely useful check starts with a live requirement database rather than a rules table someone updated by hand at the start of the quarter. Entry requirements change with little warning, a scheme launches, a reciprocity agreement shifts, a country adds a transit exemption, and a booking engine that treats this as static reference data will eventually sell a trip against a rule that no longer exists. IATA's Timatic API is one of the few products built specifically so a seller can pull this data programmatically into its own flow rather than relying on an agent looking it up separately, which is closer to what a modern travel commerce integration actually needs than a static compliance page ever was.
The second requirement is nationality and route matching that accounts for more than the final destination. Transit rules are their own category of edge case: a passport that needs no visa for the destination can still need a transit authorization for the country the layover happens in, and dual citizenship, minor travellers on a parent's itinerary, and connecting itineraries across multiple visa regimes all multiply the number of cases a naive "destination equals requirement" lookup will get wrong.
The third is an in-flow application path, not just a warning. Telling a traveller they need an authorization and leaving them to find the correct government website on their own recreates the exact gap this piece is about, just one step earlier. The fourth is pre-departure re-validation: an authorization approved at booking time can still be revoked, expire, or turn out to have been entered incorrectly, and a system that checks once at purchase and never again is trusting a snapshot that may be stale by the time the passenger actually travels.
Who is liable when it gets skipped
Formal liability, the fines and sanctions written into immigration law, has always sat mainly with the carrier, and that has not fundamentally changed. What has changed is how much informal, commercial liability now sits with whoever sold the booking, regardless of whether that seller was ever the legally designated party for verifying documentation. A traveller does not distinguish between the airline's regulatory obligation and the OTA's product experience when a trip falls apart at the airport. They remember who took their money and never mentioned the requirement that just cost them the trip.
A visa problem caught at checkout is customer service. The same problem caught at the gate is a cancelled trip with someone else's name on the receipt.
That commercial exposure is compounding as digitization spreads. Every government that converts a visa-free relationship into a pre-travel authorization adds one more route where a seller's silence at the point of sale looks less like an oversight and more like a pattern. A platform that has never surfaced an entry requirement to a single customer has, in most cases, simply not sold enough bookings to the newly affected routes yet, not solved the problem. The rollout of ETIAS alone is set to bring an entire continent's worth of previously frictionless corridors into this category at once, which makes this a considerably worse year to discover the gap for the first time than it would have been five years ago.
Four questions before your booking flow ships without this
First, does your booking flow check entry-authorization requirements before payment is captured, or does the traveller only find out afterward, in a confirmation email nobody reads carefully before departure day.
Second, is that check running against a live, regularly updated source, or a rules table someone on your team last touched when the feature originally shipped. If the honest answer involves the phrase "we should probably update that," treat it as already out of date.
Third, when a traveller needs an eTA or visa, does your flow help them get it, ideally in the same session, or does it simply tell them they need one and send them off to find a government website on their own. The second version solves almost nothing.
Fourth, do you re-check status any time before departure, or only once, at the moment of booking. An approval granted months before a trip is not a guarantee it will still be valid when the passenger actually travels.
What this looks like in practice
A multi-country tour operator came to us after a run of cancellations that had nothing to do with its itineraries or its pricing: travellers arriving at departure airports without a valid electronic travel authorization for a stop on their route, discovering the requirement from a check-in agent instead of from the operator that sold them the trip. Support tickets after the fact followed an identical pattern, a traveller asking why nobody had told them, and a support team with no good answer beyond apologising for a gap in the product.
We integrated a live requirement check into the booking flow itself, run against every leg of a multi-country itinerary rather than just the final destination, with layover and transit requirements matched separately from the main entry rule. Where a traveller needed an authorization, the flow linked directly to the application step inside the same session, and the system re-checked status automatically in the weeks before departure, flagging any authorization that had lapsed or been affected by a rule change since booking.
Airport-side denied-boarding incidents tied to missing authorizations dropped to a small fraction of their prior rate within two travel seasons, and the support tickets that used to open with "why didn't anyone tell me" mostly stopped appearing at all, replaced by travellers who had already handled the requirement before the confirmation email even arrived. Nothing about the itineraries changed. The moment the gap got caught moved earlier, which turned out to be the entire fix.
We build the entry-requirement checks, live document APIs, and pre-departure re-validation that keep a booking flow honest about what a trip actually requires. If your platform still finds out about a missing visa the same way a check-in agent does, that is where we start.