Why travel bookings fail at confirmation and what to do

A booking confirmation failure happens when your website asks a supplier to confirm a flight, hotel or tour booking and does not get a clear success back. The supplier may reject the request, take too long to answer, or return an unclear status. The right response depends on which of these happened, and the worst response is to guess. With clear statuses, safe status checks and an operations queue, most failures can be resolved quickly and honestly.

Confirmation is the step where a supplier accepts the booking and gives you a reference. For flights, a ticket may still need to be issued afterwards. For hotels, confirmation usually follows a price check often called prebook. This guide explains the common causes of failure and how to handle each. If you are building a booking platform, our OTA platform service page explains how we approach these projects.

The most common causes of a booking confirmation failure

Failures fall into a few groups, and each needs a different response.

• Availability has gone. The fare or room was available at search or price check, but sold before the booking request arrived.
• The price or rules changed. The supplier will not confirm at the price or conditions your site sent.
• Invalid details. A name format, date of birth, document number or contact detail does not meet the supplier's rules.
• Duplicate booking protection. Some suppliers reject a booking that looks like one already made for the same passenger and itinerary.
• Technical errors. The supplier's system is slow, overloaded or temporarily unavailable, or returns an error your code does not recognise.
• Account or credit problems. Your agency's account with the supplier has reached a credit limit, or a deposit needs topping up.
• Timeouts. Your system stops waiting before the supplier answers, so you do not know the outcome.

The first five usually come with a clear answer from the supplier. Timeouts are different, because the booking may or may not exist.

For hotels, some of these problems can be caught earlier by the check described in our guide to the hotel prebook step.

Timeouts and the unknown booking status

A timeout means your system gave up waiting for the supplier's answer. The supplier may still have processed the request and created the booking. Treating a timeout as a failure is dangerous: if you tell the customer it failed and they book again, they may end up with two bookings.

1. Use a separate "unknown" status. Add a booking status such as "pending confirmation" or "unknown" for cases where you cannot be sure of the outcome.
2. Never retry the booking request automatically. A second request can create a duplicate booking or a second ticket. Retrying is only safe for calls that do not change anything, such as searches or status checks.
3. Keep every reference you have. Save any identifier sent or received, including your own booking reference passed to the supplier. It is often the key to finding the booking later.
4. Set sensible timeouts. Give booking calls enough time for the supplier to answer under normal conditions. Very short timeouts create more unknown statuses than necessary.
5. Show the customer a holding message. Explain that you are confirming the booking and will update them shortly, rather than showing an error.

When the customer has paid but the booking failed

This is the situation customers fear most, and the one that most needs a clear process.

1. Keep payment and booking as separate records. Each should have its own status. The payment may be authorised or captured while the booking is failed or unknown.
2. Reserve money before capturing where possible. If your payment gateway supports it, authorise the payment first and capture it only after the booking is confirmed. A failed booking then means releasing the authorisation rather than issuing a refund.
3. Release or refund quickly when failure is certain. If the supplier clearly rejected the booking, release the authorisation or refund at once and tell the customer.
4. Do not refund an unknown booking too early. If the status is unclear, check with the supplier first. Refunding a booking that actually exists leaves you paying the supplier for a trip the customer has not paid for.
5. Offer alternatives. If availability has gone, offer to search again with the same details, or have your team contact the customer with options.
6. Tell the customer exactly where things stand. Say whether they have been charged, what happens next and when they will hear from you. Follow up by email with the same information.

Checking status with the supplier safely

Most suppliers offer a way to retrieve or look up a booking. This is the safe way to resolve an unknown status.

1. Check in the background. Run the status check as a queued background task, so the customer is not left waiting on a loading page.
2. Search by the references you saved. Use the supplier's booking reference if you received one, or your own reference if the supplier supports looking bookings up that way.
3. Retry status checks, not bookings. Status checks do not change anything, so they can be repeated a few times with a delay between attempts.
4. Update the booking from the answer. If the booking exists, mark it confirmed and continue with ticketing or vouchers. If it clearly does not exist, mark it failed and release the payment.
5. Escalate when checks cannot decide. If automated checks still cannot confirm the outcome, send the booking to a person.
6. Log every check. Record each request and response, linked to the booking, with sensitive data masked.

Some suppliers also send notifications when a booking status changes. Where available, they are a useful extra signal, but keep your own status checks as a backup.

Building an operations queue for failed bookings

Even with good automation, some bookings need human attention. An operations queue in your admin panel makes sure none are forgotten.

1. List every booking that needs action. Include unknown statuses, failures after payment and tickets or vouchers that were not issued.
2. Show everything needed to decide. Customer and passenger details, payment status, supplier references, and the logs of every call made for the booking.
3. Provide clear actions. Buttons to re-run a status check, mark a booking confirmed or failed with a reason, release a payment, issue a refund or contact the customer.
4. Record who did what. Every action should be logged with the staff member and time, for accountability and later review.
5. Set alerts and targets. Notify the team when a booking enters the queue, and agree how quickly each type should be resolved.
6. Review patterns. Look regularly at why bookings fail. Frequent failures with one supplier or route point to problems worth fixing in the flow or the integration.

Failures that happen before the booking step, such as a price change at revalidation, need different handling. Our guide to why flight prices change between search and booking covers those, and our guide on how to design a flight booking flow customers finish shows how the confirmation page should present each outcome.

Summary

• Confirmation fails for clear reasons, such as lost availability or invalid details, or unclear ones such as timeouts.
• Use an "unknown" status for timeouts and never retry a booking request automatically.
• Keep payment and booking separate, release or refund quickly when failure is certain, and check before refunding an unknown booking.
• Resolve unknown statuses with background status checks, logged and linked to the booking.
• Give your team an operations queue with full context, clear actions and alerts.

Confirmation failures cannot be avoided entirely, but they can be handled so customers are never left guessing. If you're building or improving a booking platform, you can tell us about it here.