The Stripe analogy breaks after checkout

At the end of last year I sat down with Skift and made an argument I still believe: every other industry got its infrastructure layer, and travel did not. Payments got Stripe. Banking data got Plaid. Storefronts got Shopify. Compute got AWS. A developer in any of those categories can go from an idea to a live transaction in an afternoon, because someone else already absorbed the ugly parts.

Travel did not get that. It got the GDS, which is not the same thing. A GDS was built so a trained agent could work a terminal, and it is very good at that. It was never built so a product team at a neobank could ship a flight search in a sprint.

The interview is here. Eight months later I would not soften a word of it. What I would add is the reason travel has stayed unsolved while the other categories got fixed: it is a harder problem than the comparison makes it sound, and the difference shows up in one specific place.

The specifics still hold

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.

When Stripe takes a payment, the interesting part of that transaction is over in seconds. Authorisation, capture, settlement, done. There are refunds and disputes, and they matter, but they are exceptions running against a record that has stopped moving. The object is terminal.

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.

So the comparison holds perfectly right up to the moment of purchase, and then it inverts. In payments, checkout is the end of the hard part. In travel, checkout is where the hard part starts. That single difference is why travel needed this layer more than any of those categories did, and why it is the one that never got it.

This is why "we integrated a travel API" and "we run a travel business" are different sentences separated by about four months. 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.

None of that is exotic. It is just unglamorous, and it does not demo well, which is exactly why it stays unbuilt and why the fintech comparison is seductive. Stripe never had to keep a payment coherent for six weeks while three unrelated companies changed their minds about it.

What open actually has to mean

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.

Open is not an API with a public docs site. Every incumbent has one. Open means the switching cost is honest: you can get your order history out, you can put your own supplier contracts in, you can graduate to your own ticketing authority without a rewrite, and the platform does not sit between you and your customer relationship. A layer that makes it cheap to start and expensive to leave has not opened anything. It has moved the gate.

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 only thing I would add is scale of difficulty. Travel does not just need a Stripe for the transaction. It needs the thing nobody in payments ever had to build, which is a system that keeps a promise intact while the world underneath it moves. That is why this took longer to arrive here than it did anywhere else, and it is the reason the work is worth doing.

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