A booking screen has stopped responding and the customer is waiting. Clicking again feels like the quickest way to get an answer. Before anyone repeats the reservation, your team needs to establish what the first attempt actually did.

An interrupted response leaves a question to resolve. Expedia Group's Rapid booking guidance explicitly warns that a reservation may have been charged and confirmed even when the response never reaches the caller. It directs partners to retrieve the booking using the original references. For a travel agency, the practical lesson is to give an uncertain transaction its own controlled workflow.

Make one person responsible for the unresolved booking

Mark the case as awaiting verification in your working record and give it a named owner. Ask colleagues to route further action through that person while the outcome is being checked. This is especially useful when the customer is speaking to one adviser while another is watching the booking screen. Both need to know that a new attempt is a decision requiring evidence.

Record the time of the original attempt, the product and supplier, the intended traveller details and any reference already returned. Keep the error message or transaction identifier through your approved support process. A screenshot of a generic error may help explain what staff saw, but it isn't a substitute for the underlying transaction record. Avoid copying card details into a case note or support email.

Use plain wording with the customer. A suitable message might be: "We're checking the outcome of your booking request before taking any further action. I'll update you at the agreed time." Choose a review time your team can meet, then keep it even if the final outcome is still unresolved. Silence can tempt the customer to start the same booking elsewhere.

Retrieve the original result before creating another

Ask your technology provider which record is authoritative for the supplier outcome and how your team accesses it. The answer may be a retrieval function in the booking system, a supplier portal or an escalation to support. Follow the approved route for that connection. Don't improvise a universal recovery rule from the wording on one error screen.

Expedia's guidance explains that newly created itineraries can take time to become retrievable. It also specifies retaining the original affiliate reference for a permitted repeat of the same request. That is a documented behaviour of its API, with conditions and timing explained in its guidance. Your team should not assume another supplier accepts the same approach.

A missing result on the first check may therefore leave the case unresolved. Record what was checked and when the next check or escalation is due under the provider's procedure. If the system returns a reservation, compare its traveller, dates and product with the intended purchase. Finding a reference is useful, but the team still needs to confirm what it relates to.

Check payment and reservation status separately

The payment record answers a different question from the supplier reservation. Stripe's PaymentIntent documentation describes a payment moving through several statuses and recommends one PaymentIntent per order or customer session. Your staff need to know which payment reference belongs to the original attempt. That allows them to inspect the existing result through the tools your integration provides.

A payment marked as successful doesn't by itself prove that the hotel, flight or other travel service is reserved. Equally, a supplier confirmation doesn't establish that every payment task has finished. Reconcile the two records before sending a final customer message. If they disagree, keep the exception visible and assign the next action explicitly.

Our guide to reconciling travel payments covers the wider financial record. For this immediate incident, identify whether funds are authorised, captured or still unresolved using the provider's actual status. Avoid a fresh payment request until the person responsible has checked the first attempt and agreed the required next step. The customer's banking notification alone shouldn't decide the booking outcome.

Treat retry protection as a documented feature

Your developer may describe a request as idempotent, meaning that a supported repeat is designed to avoid performing the same operation again. Stripe documents this protection through an idempotency key and specific rules. It isn't a blanket promise that every retry in a travel transaction is harmless. A payment service and a reservation supplier can have different protections and limits.

Ask the provider to explain what identifies a repeated request, how long the protection applies and which actions are covered. Include the case where staff start again from a different screen or another device. The answer should be recorded in the operating procedure, without requiring an adviser to interpret API code during an incident. Never assume that typing the same customer name creates duplicate protection.

If the original attempt is confirmed as unsuccessful, follow the supplier's approved retry or new-booking process. Recheck the offer where required and obtain the customer's agreement to any changed details. If the outcome remains unknown, escalate with the evidence already collected. Urgency should influence the escalation route, not turn uncertainty into an assumed failure.

Reconcile the case before closing it

When a reservation is confirmed, connect the supplier reference to the agency record and relevant payment entry. Send the customer the correct confirmation and remove the unresolved status only after the required checks are complete. If two reservations exist, stop creating further ones and ask the supplier or support team to establish the available remedy. Don't cancel one casually without checking its conditions and the intended booking.

Keep the original attempt history even after the visible problem has gone away, following your records policy. Record the final outcome, the actions taken and any remaining payment work. A colleague taking over should be able to understand the case without reconstructing several conversations. That matters at the end of a shift as much as during a system-wide incident.

Use our booking-system outage guide for the wider recovery plan. Then rehearse this narrower scenario with a fictional booking in an approved test environment: no response, an uncertain payment and a customer asking to try again. Ask a colleague to locate the original references and follow the agreed escalation route. Fix any missing instruction before the next live timeout makes the decision for them.