Adding a hotel supplier is not adding a data source

This week TRVL, the online travel agency I run, connected its third source of hotels: Emerging Travel Group. Overnight the site went from a catalogue built mostly around Greece to 8,773 new properties in 111 countries and 1,511 cities. That is the sentence for the press release. This is the other one: importing those hotels was the quickest and least interesting part of the work.

The easy mistake is to treat a new supplier as a new data source. You map their fields onto yours, write the hotels into the same table, and the rest of the system carries on as before. It looks finished. It is not, because a hotel supplier does not sell you data. It sells you promises: this room exists, at this price, on these dates, under these cancellation terms. Every one of those promises can change between the moment a guest reads it and the moment they pay.

So the first decision was structural. Every place in the code that used to say "if it is not one of ours, it must be the old supplier" became an explicit branch per supplier. An "else" is a guess about the future, and the future had just arrived. Where both suppliers sell the same hotel, the one we already know keeps it, because a duplicate listing at two prices is worse than either price.

The second was about speed. A supplier's API has limits, and the call that returns full room-by-room availability is the slowest and most rationed of all. If every hotel page asks for it, the limit is reached by ordinary browsing, and the guest sees "no availability" for a hotel that has plenty. The page now prices itself from the search call, which is fast and generous, and the expensive call is made once, when someone actually starts to book.

The third is the one that matters most: the price on the page is a quote, not a contract. Between reading it and paying, the supplier may reprice the room. We decided in advance what happens, so nobody improvises at checkout. If the price falls or rises by up to three per cent, the guest pays what they saw. If it rises by more, they are shown the new price before they pay. If the room is gone, no payment is taken, and if a change is only discovered after payment, the refund is automatic and in full.

Then there is absence, which is not the same as failure. About two thousand of the new hotels returned no rates at all, across four sets of dates months apart. The API answered correctly each time; it simply had nothing to sell. The tempting reaction is to call that a bug and hide the hotels, or to call it fine and move on. We did neither. We measured it, sent the list to the supplier, and kept the decision about what guests see for when we have their answer.

Some of the work is invisible on purpose. A supplier has its own email system, and a guest who booked with us should never receive a message from a company they have never heard of, so every message comes from TRVL. The mobile apps already installed on people's phones could not understand the new hotels, so the server only shows them to versions that say they can. None of this appears in a demo. All of it appears the first time it is missing.

Before any of it went live, the whole path was tested with real bookings on a test property: search, price check, payment, confirmation, cancellation, refund. Until we switched it on, a guard in the code allowed bookings on that one hotel and nowhere else. Testing a booking engine with fake data proves that your code agrees with itself. Testing it with the supplier proves that the supplier agrees with you, which is the only agreement the guest will ever notice.

That is what adding a supplier really means. Not more rows in a table, but a second set of rules about time, price and trust that has to hold at the exact moment money moves. The hotels are what the guest sees. The rules are what they are actually buying.