Booking Timeout & Duplicate Prevention Playbook

When a booking-create call times out, the most dangerous response is to submit the same transaction again without proving the original outcome. The supplier may have created the reservation even though the client never received the response.

Trigger / symptom

A create-order/create-booking request times out, the connection drops or a 5xx occurs and the local system has no confirmed booking reference.

Objective

Avoid a second create operation until the system has evidence about whether the first transaction completed.

Evidence needed

Collect internal booking-attempt ID, idempotency key, supplier request ID, traveler identity, itinerary/property and dates, amount/currency, request timestamp and payment authorization state.

Ordered response

1. Move the attempt to UNKNOWN, not FAILED.
2. Do not perform an immediate blind retry.
3. If supplier idempotency is supported, follow the documented retry behavior with the same key.
4. Use booking lookup/retrieve APIs with request ID, traveler and itinerary where available.
5. Check payment authorization/capture state.
6. If the supplier booking exists, reconcile it into the local record.
7. If no booking exists and safe-retry conditions are proven, retry in a controlled manner.
8. If evidence remains inconclusive, move to manual review/escalation.

Duplicate detection

Traveler + product + close timestamp can be a useful investigation key but is not definitive. Supplier booking reference, idempotency key and payment transaction ID are stronger evidence.

Stop conditions

Every attempt should end as CONFIRMED, definitively NOT_CREATED or MANUAL_REVIEW. UNKNOWN should not become a permanent state.

Escalation criteria

Escalate when payment is captured but no booking is found, or when more than one supplier booking reference exists.

Metrics proving resolution

Track unknown-booking age, duplicate rate, idempotency hits, reconciliation latency and manual-review volume.

Prevention

Assign a stable attempt ID to every booking create operation. Use provider idempotency where supported and keep auditable request/response evidence with appropriate PII minimization.