Gateway timeout_

Gateway timeouts on a busy departure day, mid-campaign or during a flash sale can leave deposits in limbo — booked from the customer view but unrecorded from the merchant view. Resolving them by hand is operationally expensive and can lead to either duplicate charges or lost bookings.

A single gateway timeout on a £4,000 deposit is not a technical anomaly — it is a customer who is now uncertain whether they have booked a holiday. Without idempotent capture and reliable reconciliation against the acquirer record, the resolution often involves either charging the customer twice or losing the booking entirely, and either outcome usually surfaces as a complaint.

The travel businesses that survive their busiest day are the ones that designed the gateway-timeout case into the system from the start. Idempotency keys, retries, automatic reconciliation against acquirer state and clean customer messaging turn the case into an exception that resolves itself. Without those mechanics, a flash sale can produce more refunds than bookings.

felloh handles timeout cases automatically with idempotent capture, retries and reconciliation against acquirer state, so the booking either settles cleanly or surfaces as a single, actionable exception.

The pay checkout treats authorisation calls as idempotent so a timeout never produces a duplicate charge or a lost booking. Reconciliation against acquirer state runs continuously, surfacing any cases where the gateway response differed from the acquirer’s record as actionable exceptions in the Transactions view.

For travel businesses running flash sales or busy departure days where gateway timeouts are inevitable, the customer experience stays intact and finance never sees a "did this go through" backlog. The exception count is small, specific and resolvable rather than a queue someone has to chase.