Travel Event Reconciliation Architecture

Design deterministic reconciliation across booking, payment, cancellation and supplier events with explicit authority and audit rules.

Editorial information
Advertisement

Booking, payment, webhook and supplier-report systems can describe the same transaction at different times and with different identifiers. Reconciliation exists to prove which state is authoritative and resolve divergence in a traceable way.

Production scenario

A booking create call times out. The provider later sends CONFIRMED, payment is captured, the internal record remains UNKNOWN and the overnight supplier report contains the booking again.

Architecture flow

text
API Response / Webhook / Payment / Supplier Report
 -> Normalize Event
 -> Correlation Keys
 -> Deduplication
 -> Event Ordering
 -> State Comparison
 -> Reconciliation Rule
 -> Corrective Action
 -> Audit Record

Correlation keys

Prefer internal booking ID, attempt ID, provider reference, idempotency key and payment transaction ID. Traveler/product/date composite keys are useful only as weaker fallback evidence.

Source authority

Define which source is authoritative for each fact. Provider booking references may decide booking existence; PSP state may decide payment state; matured supplier reports may decide settlement.

Trade-offs

Real-time reconciliation reduces inconsistency windows but increases complexity. Batch reconciliation is simpler but slower.

A hybrid model often works well: near-real-time for critical operational mismatches and scheduled reconciliation for finance.

Failure modes

Expect duplicates, missing webhooks, delayed provider reports, out-of-order cancellations, payment/booking divergence and duplicate provider references.

Idempotency and replay

Reconciliation must be rerunnable. The same evidence set should produce the same corrective outcome.

Observability

Track unreconciled records, reconciliation latency, auto-fix rate, manual review, booking/payment divergence and duplicate-reference incidents.

Alternatives

Daily SQL can be enough for low-volume systems. Multi-provider products with payment flows benefit from an explicit event/reconciliation service.

Production checklist

Define source authority, stable correlation keys, idempotent rules, replay, audit trails, manual review and separate operational versus financial reconciliation.

Technical advisory

Let’s review your architecture.

We can assess your travel distribution and metasearch architecture for scalability, failure modes and operations.

Discuss your project →

Related content