Why travel infrastructure has to work after checkout

Travel infrastructure has to keep working after the customer pays. An airline can move a flight, a traveller can cancel part of a trip, and a supplier refund can arrive after the customer expects it.

In my Skift interview, I argued that travel needs the infrastructure layer that made other industries easier to build on. The comparison with Stripe helps explain the opportunity. It also leaves out how much of the travel job happens after checkout.

The infrastructure must keep the booking, the supplier action and the money connected as the trip changes. A simple search-and-pay integration does not cover that responsibility.

What payment infrastructure gets right

The numbers I gave Skift were not rhetorical. They are the reasons a good team quits, and none of them have moved.

NDC adoption in the United States sits at roughly a fifth of the market. So a new entrant does not integrate the future of airline retailing, they integrate the future and the present and the long tail, and then normalise across the three.

Look-to-book ratios cap how many searches you may run against how many bookings you produce. Read that again as a founder. The supply side enforces a limit on experimentation. You cannot A/B a merchandising idea if the cost of looking is rationed by a partner who benefits from you not looking.

And integrations that should take under a month take several, not for technical reasons but for procedural ones: accreditation, certification queues, sandbox access, commercial sign-off. The engineering is rarely the bottleneck. The waiting is.

Those three facts are enough to explain why travel has so few new entrants relative to fintech. I would repeat all of it word for word today.

Why travel is the harder version

Here is what makes this problem heavier than the one fintech solved.

Payment infrastructure coordinates authorisation, capture and settlement, followed by refunds or disputes where needed. These are distinct states with their own timing. A successful checkout does not mean the financial work is finished.

A travel order is not terminal. It is a set of promises made by third parties about a Tuesday six weeks from now, and every one of those parties can change their mind. The airline moves the departure. The hotel resells the room. The operator cancels the transfer for weather. None of them ask you first, and all of them are still your problem, because the customer bought from you.

The comparison is useful, but incomplete. Travel infrastructure must manage the financial lifecycle and changes to the journey itself. A confirmed payment cannot tell you whether a new flight time works for the traveller or whether a hotel amendment is available.

This is why connecting a booking API is only part of running a travel product. The first is search and checkout. The second is the day an airline reschedules two hundred of your customers overnight and someone has to decide, per booking, what to offer, what it costs and who tells the traveller.

What an infrastructure layer has to include in travel

If the object stays alive, then the layer underneath it cannot stop at supply access. Access is the commodity part. Anyone can resell a connection.

The parts that are hard to buy, and therefore worth buying, are these.

One order that survives its suppliers. A record where a flight, a room and a transfer bought in one basket remain a single thing you can reason about after one of them changes. Most integrations hand you three references and wish you luck. What that record has to look like is the whole of checkout is the midpoint.

Servicing as an API, not a phone number. Changes, cancellations, involuntary reaccommodation, refunds that trace back to the original components. If the answer to a schedule change is a support queue, you have bought a demo, not infrastructure.

Money that inherits the shape of the trip. One customer payment, several supplier settlements in several currencies, refunds that unwind partially and asymmetrically. This is the part finance discovers in month five.

A commercial posture that does not punish looking. If a platform passes its own look-to-book anxiety on to you, it has recreated the constraint it claims to solve.

Payments also have a lifecycle: settlement, refunds and disputes continue after checkout. Travel adds another set of moving parts: supplier confirmations, changing itineraries and service decisions. Those changes have to stay connected to the financial record.

Keep control of your suppliers and customer experience

I used the word open in that interview and I want to be harder about it now, because it is the easiest word in this industry to say and the least often true.

An open integration should give your team practical choices. You should be able to export order history, bring existing supplier contracts and understand how to change ticketing arrangements. Check the wind-down terms too: bookings already sold still need support after a migration.

That standard is uncomfortable to hold yourself to, which is the reason to say it publicly.

Eight months on

The argument I made to Skift is the argument I would make today: travel's real barrier is not demand or capital, it is that the cost of entering is set by people who benefit from you not entering, and an infrastructure layer is how that changes.

The challenge is keeping the itinerary and the payment history aligned as plans change. A supplier may move a flight, a traveller may cancel one room, and a refund may arrive later. The platform needs to show what happened and who handles the next step.

We connect 517+ carriers including 140+ low-cost carriers, and two million properties deduplicated to one identity. That is the part that gets quoted. The part I would rather be judged on is what happens on day nine, when the airline moves the departure and nobody has emailed the customer yet.

If you want the argument for whether travel belongs in your product at all, it is in adding travel is easy, owning it is the decision.

Source

• Q&A: Why Travel Needs a New Platform Built for an Open Ecosystem, Skift, 29 December 2025