---
title: "Payment Authorized/Captured but Booking Unknown/Failed"
description: "Diagnose payment-booking divergence when payment succeeds while booking remains unknown or fails, then choose safe recovery and compensation."
slug: "payment-booking-divergence-troubleshooting"
translationKey: "troubleshooting-payment-booking-divergence"
locale: "en"
type: "troubleshooting"
category: "troubleshooting"
tags: ["payment","booking","divergence","refund","compensation"]
publishedAt: "2026-09-27"
updatedAt: "2026-09-27"
reviewedAt: "2026-09-27"
technicalVerifiedAt: "2026-09-27"
codeExampleStatus: "illustrative"
---

Payment can be AUTHORIZED or CAPTURED while booking remains UNKNOWN or FAILED. This is a direct example of why **payment success is not booking success**.

## Symptom

A card shows authorization/capture while the reservation has no terminal confirmation, the provider booking cannot be found, or the traveler sees a charge without a booking.

## Possible causes

Authorization succeeded before booking failed, booking timed out, capture happened too early, provider confirmation was not persisted locally, or payment evidence arrived while booking webhook evidence did not.

## Diagnosis

Correlate payment transaction ID with bookingIntentId, lookup the booking at the provider, distinguish authorization from capture, inspect provider references, review void/refund/capture attempts and check for duplicate payment or booking attempts.

## Recovery

If the booking exists, repair local state. If booking is authoritatively FAILED, void an authorization or refund a capture according to policy. If booking is UNKNOWN, reconcile first rather than compensating blindly.

## Prevention

Keep payment and booking as separate state machines, make sequencing explicit, use operation-scoped idempotency, reconciliation queues and divergence alerts.

## Observability

Track authorized-without-booking, captured-without-confirmed-booking, divergence age, void/refund latency, manual intervention and duplicate-charge signals.