Bookings confirm on your site and the supplier has no record

The confirmation your customer received was written by the script's checkout, not by a supplier. In a booking flow that works, the commit step calls the supplier over its API, waits for a response carrying a supplier-side reference, stores that reference, and only then emails the customer. In the flow you have, at least one of those 4 steps is missing, so checkout reaches its success page whether or not anybody upstream agreed to hold a room.

That narrows the investigation before you open a support ticket. Five things produce this symptom, and the check that separates them takes about an hour. Do not open with the script vendor: their first answer is that the supplier declined, and you cannot argue with that until you know whether a supplier call happened at all.

The check that settles it: a timed three-way comparison

Compare 3 things at one moment: what the script shows, what the supplier extranet shows, and what your database stores after a booking. Same property, date, occupancy and rate plan — anything looser and both sides can be honestly different.

1. Pick 1 property you sell often and 1 arrival date 30 to 45 days out — close enough that inventory is moving, far enough that you are not testing a sold-out night.
2. Load availability in the supplier extranet for that exact property, date and occupancy. Note the time to the minute, in UTC if the two systems disagree about timezone.
3. Within 60 seconds, run the same search through your own site as a customer would, and record what it shows: sellable or not, and at what price.
4. Repeat both on a date the supplier has closed. This is the informative half — a script serving a cached copy will sell you a night the supplier stopped selling hours ago.
5. Take 1 real booking on a refundable line, then read the row your database wrote. Find the field meant to hold the supplier reference and read its value.
6. Check the supplier extranet for that booking. Present, absent, or present with a non-confirmed status are 3 different diagnoses.
7. Write down 4 facts: search agreed or not, closed-date behaviour, reference stored or empty, supplier-side record present or not. Those 4 identify the cause.

Five causes, in the order they usually turn out to be the one

Only the last row leaves a booking the supplier knows about. The other 4 end with a PDF voucher for a trip nobody upstream agreed to run.

Cached availability with nothing rechecking it at commit

Caching is not the defect. Every serious booking system caches, because search traffic runs 1 or 2 orders of magnitude above booking traffic. The defect is caching with no mandatory live recheck between the customer choosing and the money moving.

The arithmetic is unforgiving. With a TTL of 30 minutes, a room that sells out at minute 2 stays on sale for the following 28. Stretch the TTL to 6 hours to keep supplier load down and your shop is on average 3 hours out of date on the one fact that matters. The defensible range is a decision rather than a default, worked through in how long a cached availability answer stays true.

• Look for the recheck. Between basket and charge there should be exactly 1 call that re-prices and re-verifies the selection, as in putting a price recheck between basket and charge. If it is not in a log, it does not exist.
• Look for the token. Most supplier APIs return an opaque key with the availability response that must be presented at booking and expires in minutes — see the rate key as an opaque token with a countdown.
• Check the stale-token path. An expired key should produce a visible re-quote rather than a silent success, which is the failure traced in booking fails on an expired token mid-checkout.
• Check invalidation. A cache with a timer but nothing invalidating it on your own bookings will resell your last room.

A test credential that was never swapped for a live one

This one is common and has a signature you cannot miss: everything is available. Every property, every date, every occupancy, including dates a real supplier closed months ago. Test environments exist to return sellable results so integrators can exercise a flow, so a portal pointed at one behaves like a shop with infinite stock.

• Read the configuration, not the admin screen. A white-label build usually has 1 environment flag, and the panel shows a friendly label rather than the credential in use.
• Establish whose account it sits in. If the credential belongs to the script vendor, your commercial terms and your ability to leave belong to them too — see whose name the supplier credentials sit in.
• Expect live to behave nothing like test, as in it passed in test and live returns nothing sellable.

The mapping table points at something the supplier retired

Between your product and the supplier's sits a translation table: your identifier for a property or room type against theirs. Suppliers change their side — properties get renamed, rebranded, re-contracted under a new code — and nobody notifies you, because from their side nothing broke.

The tell is asymmetric: search works, commit fails, or commit succeeds against the wrong room type. Search commonly runs against a static content file refreshed on its own schedule while booking runs against live product codes, so the 2 halves of one integration drift apart unnoticed. A single property routinely carries several identifiers across supplier, content provider, mapping layer and your own database, which is the subject of hotel mapping and the five ids one property has. Fixing 1 row without fixing the reconciliation job buys you a week.

The booking write that was never wired at all

Some readymade portals ship a complete search and checkout experience over a booking step left as an exercise. The customer journey is real; the commit is a database insert and an email template. One query finds it: count bookings where the supplier reference is empty. If that equals every booking you have taken, you have a shop front, not an integration.

A near neighbour is worse because it looks like it works. Where the commit call is made but the response is discarded, or an HTTP timeout is treated as a failure and retried, you end up holding 2 supplier reservations for one customer or none for another — the outcomes traced in the book call timed out and nobody knows the outcome. Underneath all of it is the question of which system is permitted to declare a booking confirmed, and on a white-label script the honest answer is often that none of them holds that authority. That is defined in the reservation system of record, and it has to be settled before any repair means anything.

A booking is not confirmed because your database says so. It is confirmed because a supplier issued a reference and you stored it.

Patch, wrap or replace

Work down this list and stop at the first branch that matches. The question underneath all of them is whether you can reach the supplier account on credentials you own, because that fact decides how much of the script you still need.

1. Sandbox credentials, or a mapping row pointing at a retired code, and the supplier account is yours. Patch: swap the credential, rebuild the mapping table, add a nightly reconciliation against the supplier's product list.
2. Search and pricing are broadly right, the commit path is untrustworthy, and you can reach the supplier directly. Wrap: keep the script as a shop front and move the recheck and the booking write into a small service you own. That shape is most of our internal tools and operations work, and it is the cheapest honest fix.
3. The credential belongs to the vendor and they will not transfer it. Replace the connection first, deciding direct or intermediary with aggregator versus direct connections to supply.
4. The commit was never wired and the vendor cannot show you a booking log. Replace: there is nothing to repair, and every further month of selling is another month of confirmations you cannot honour.
5. You are replacing with departures already on the books. Stage it against the booking curve rather than a calendar date, as in cutting over between seasons without losing departures, and model what you hold first, the way a DMC's eleven spreadsheets get sorted into one system.

Whichever branch you land on, add 1 instrument this week: a daily count of bookings taken against bookings carrying a supplier reference. When those diverge you know within a day, not when a traveller arrives at a property that has never heard of them. The silo sits under build, buy or replatform; the wider view is in our travel and tourism work.

• booking engines
• supplier connectivity
• availability caching
• diagnostics