Payments, AI Commerce, and Why Retail Went First: A Conversation with Stripe at ITB Berlin
Stripe's James Lemon discusses payment infrastructure challenges in hotels and why AI booking technology is more complex for travel than retail.
At ITB Berlin, Simone Puorto spoke with James Lemon, Hospitality, Travel and Leisure Global Lead at Stripe, about the state of payments infrastructure in hotels, why AI booking is harder to build for travel than retail, and what the next generation of commerce actually looks like. The conversation was one of the more technical of the week, and one of the more grounding ones too.
The payments problem nobody is talking about
The industry conversation at ITB was dominated by AI. James brought it back to something more immediate: most hotels have not modernised their payments infrastructure, and that matters before anything else does.
Legacy payment checkouts are still common across hotel groups and PMS platforms. Missing local payment methods, unsupported currencies, no buy-now-pay-later options. Every missing feature is a conversion loss at the most critical moment in the booking journey, after a guest has already decided they want to stay. Some travel websites see payment failure rates that would be considered catastrophic in any other retail context. Building an AI booking experience on top of that infrastructure is not going to work.
James's point was straightforward: fix the direct booking experience first. Build a strong payments foundation. Then the skills, the tech team and the learnings are already in place when AI commerce matures.
Why retail went first
The major LLMs have been open about starting AI commerce with retail rather than travel, and James explained why. Retail has a simple product catalog. A fixed number of items at fixed prices, uploadable in a standard format. Travel does not work that way. Prices change constantly, inventory sells out, a single hotel can have a hundred room types with different rates, restrictions and conditions. Add in loyalty programmes, preferential rates, the gap between booking date and stay date, and the question of who is actually the merchant of record, and the complexity multiplies fast.
Stripe has spent 15 years working through complicated payment structures in hotels, and is actively working with PMS providers, booking engines and LLMs to build something that actually fits how travel transactions work.
The shared payment token
The most concrete thing James described was a new piece of technology Stripe has developed called the shared payment token. The idea is to solve the friction that metasearch never fully resolved. Metasearch unified discovery and comparison, but payment still required the guest to click off to a final merchant to complete the transaction, breaking the experience at its most delicate point.
The shared payment token works differently. To the guest, it looks like a standard checkout happening inside a chatbot or AI travel concierge. Behind the scenes, the token is a portable package of payment data that can be passed to any travel supplier, hotel, airline, OTA, tour operator, without requiring a separate checkout flow. The hotel or supplier remains the merchant of record. The technology is open source.
Five layers of commerce, and where we are now
Stripe's founder John Collison recently outlined five layers of AI commerce in their annual letter. James placed the industry at layers one and two right now: human in the loop, able to explore options, but often still completing transactions on a separate site. Layer five is fully automated, agents shopping on your behalf, reading your calendar, booking your recurring Edinburgh trip without you having to ask.
James's view was that both ends of this spectrum will coexist. Business travel and simple repeat trips are natural candidates for full automation. A honeymoon is not. The richness of travel as an experience means the range of AI booking types will be much broader than in retail, and the industry should build for that range rather than assuming one model fits everyone.
Comments
Comments for this content
0 comments available