Order-Based Refund Orchestration: Preventing Double Refunds Across Payment and Settlement

The problem is not a single refund API

A customer requests a refund for a cancelled flight and unused seat. The seller sees one Order, but the financial result may involve multiple original payment allocations, a payment processor, an airline accounting ledger and a seller–airline clearance arrangement. A customer-facing “refund accepted” message does not prove money has been returned. Conversely, a payment-provider timeout does not prove the refund failed. Either assumption can cause duplicate payouts or misleading communications. A robust design separates entitlement calculation, refund instruction, payment execution and financial settlement, each with independent evidence. This is a practitioner architecture, not an IATA-prescribed state machine.

What IATA standards establish

IATA's ONE Order programme describes an integrated Order record supporting fulfilment, delivery and accounting, progressively replacing fragmented booking and document references. It does not imply that payment rails settle synchronously. The AIDM 25.1 Payment Status Code includes REFUNDED; that vocabulary alone does not establish bank posting or the customer's receipt of funds. IATA's Settlement with Orders Implementation Guide 19.2 includes a refund example involving a cancelled Order Item, a Refund Item and payment-processing information. That is a version-specific example rather than a universal instruction for all payment methods. IATA's Clearance and Settlement Standard describes interparty clearance requests, authorization tracking and net settlement. Customer payment refunds and seller–airline clearing must not be conflated. IATA Pay documentation separately describes refund API instructions and settlement reporting.

Five linked records, five different questions

Keep an immutable original allocation showing Order, Order Item, passenger, service, amount, currency and payment reference. Maintain an entitlement decision showing the applicable commercial rule, consumption evidence, approved amount, reviewer and decision timestamp. Record a refund instruction with immutable identity, destination payment allocation and provider reference. Record execution evidence from the payment provider, distinguishing accepted, pending, successful, rejected and indeterminate outcomes according to the provider's actual interface. Finally, reconcile accounting and settlement evidence against ledger postings, clearing claims, provider statements and bank movements. Link these records without collapsing them into one “refunded” flag. When a source is missing, show the gap rather than infer success.

Worked partial-refund example

Consider an illustrative Order for two passengers. Each has a flight item worth GBP 180; one passenger also has a GBP 24 seat and a GBP 30 baggage item. The Order total is GBP 414. A schedule change cancels only the first passenger's flight and seat while the second passenger's itinerary remains valid. Assume that the approved entitlement is GBP 204 and the baggage service remains usable under an applicable agreement. The engine must not simply refund half the Order total, GBP 207. It should identify the cancelled flight and seat allocations while preserving other obligations. If the original purchase used GBP 300 on a card and GBP 114 in vouchers, refund routing cannot be inferred from the affected items alone. Original funding allocations and applicable commercial policy determine eligible return methods. These numbers illustrate controls, not fare or tax rules.

Approve an entitlement before instructing payment

A proposed decision service reads the latest Order version and conditionally reserves the refundable balance. It verifies the affected services, checks previous refunds and disputes, and prevents the request exceeding the approved residual entitlement. It stores the rule version, reason, service status and original allocation. Distinguish voluntary cancellation, involuntary change, goodwill adjustment and payment correction, because authority and evidence may differ. An approval is permission to attempt a refund, not confirmation of a transfer. If another Order change alters the residual balance, reject the stale decision and recalculate. A decision should be reproducible from its saved inputs without depending on mutable pricing rules.

Idempotency must survive a network timeout

Create a stable refund-intent identifier before calling the payment provider. Enforce a uniqueness constraint across the intent and original payment allocation. Retries for the same intent must return the existing instruction and observed outcome. A new intent requires a documented business reason and a newly checked residual balance. Never create one automatically because the first call timed out. When supported, pass the same idempotency key to the provider within its documented retention window. When unsupported, reconcile by merchant reference or statement before sending another instruction. Provider idempotency is a useful second barrier, not a substitute for the internal refund ledger.

Illustrative internal contract

The following is invented application JSON, not an IATA schema. It separates commercial entitlement from payment execution.

{
  "refundIntentId": "RF-204-001",
  "orderId": "ORD-EXAMPLE-17",
  "orderVersion": 9,
  "affectedOrderItems": ["FLIGHT-P1", "SEAT-P1"],
  "currency": "GBP",
  "approvedAmountMinor": 20400,
  "originalPaymentAllocationId": "PAY-ALLOC-3",
  "reasonCode": "INVOLUNTARY_CHANGE",
  "execution": {
    "state": "OUTCOME_UNKNOWN",
    "providerReference": null,
    "idempotencyKey": "RF-204-001"
  }
}

Recover unknown outcomes without paying twice

Imagine the provider commits a credit but loses its HTTP response. The orchestration service observes a timeout. Retrying with a new identifier could create a second economic event. Instead mark the instruction OUTCOME_UNKNOWN, preserve its identity and query the provider's refund lookup or event stream. If no reliable lookup exists, queue statement-based reconciliation and manual review. A delayed webhook must match the original instruction, currency and amount. Do not accept a generic success event without checking its transaction reference. Retry a failed instruction only after establishing that the provider did not execute it. Communicate a pending status while the outcome is unresolved.

Partial refunds, reversals and disputes

Track approved ceilings and amounts reserved, instructed, executed and reversed separately. A provider reversal does not automatically extinguish the customer's commercial entitlement. Chargebacks and disputes may overlap refunds, so check dispute records and establish case ownership. If the original instrument is unavailable, use documented alternative-refund procedures and applicable legal requirements rather than sending funds to an arbitrary account. Currency conversion, fees and tax treatment require explicit policies and precision rules. Never infer a refundable amount from the original sale value when a contractual calculation or consumption record is missing. Refunds across multiple Order Items must preserve the retained services and remaining balances.

Accounting and settlement confirmations

Provider acceptance, an accounting journal, a settlement statement and the customer's receipt of funds can occur at different times. Record separate timestamps and statuses. Post liabilities or credits according to the organization's accounting policy, then reconcile the payout against provider and bank evidence. For agency sales, separately reconcile seller–airline clearance adjustments under the relevant agreement. IATA's Clearance and Settlement Standard concerns interparty settlement; it does not guarantee instantaneous customer refunds. A useful reconciliation report links Order, payment allocation, refund decision, provider transaction, ledger journal, any clearing adjustment and the outstanding variance. Do not close a case solely because one downstream amount matches.

State ownership and customer communication

A suggested lifecycle is REQUESTED, ELIGIBILITY_PENDING, APPROVED, SUBMITTED, OUTCOME_UNKNOWN, EXECUTED, RECONCILED and CLOSED, with REJECTED and MANUAL_REVIEW branches. These are internal recommendations, not mandatory IATA status codes. Every transition should have one accountable owner and immutable evidence. Servicing owns entitlement and explanations. Payment orchestration owns provider execution and lookup. Finance owns posting and settlement exceptions. Customer service needs an evidence-backed view distinguishing approved, sent to provider and confirmed executed. Acknowledge receipt promptly, but do not promise payout dates unsupported by the payment method.

Exception queues and operational measures

Prioritize duplicate provider references, amounts exceeding residual entitlement, missing original-payment mappings, timeouts without lookup, currency mismatch, refund–dispute overlap and aged unreconciled payouts. Monitor counts and value of approved-but-unsubmitted refunds, unknown provider outcomes, executed-but-unreconciled refunds and cases older than agreed service objectives. Segment by payment rail and market without exposing personal data. Measure retry deduplication effectiveness rather than API success alone. Escalate financially material variances to named owners with a documented remediation path. Reconciliation without ownership merely relocates the problem to a dashboard.

Acceptance tests and release gates

Submit the same intent twice: only one provider instruction should exist. Simulate timeout after provider execution: recovery must retrieve the original result, not pay again. Race two partial refunds exceeding the residual entitlement: no over-refund should occur. Deliver a late success webhook after an apparent failure: do not reissue money. Introduce a chargeback between approval and execution: hold or review the refund. Test split-tender routing against original allocations. Reverse a previously executed refund: reopen accounting reconciliation. Quarantine a callback with mismatched currency or amount. Remove a settlement statement: show executed but unreconciled. Replay all refund events: financial balances and instruction counts must remain unchanged. A release should fail if unknown outcomes can trigger automatic second payouts.

Delivery sequence

First map Order Item, payment and accounting identifiers and document the authoritative source for each status. Introduce an immutable refund-intent store and residual-balance reservation before adding new payment rails. Next implement provider lookup, statement reconciliation, an exception queue and customer-facing status mapping. Pilot low-risk scenarios and compare new records against established finance reports. Require security review for payment data, access control for overrides and evidence retention policies. These are suggested engineering controls, not IATA certification criteria. The goal is to prove at-most-once economic execution despite at-least-once messages and unreliable network responses.