Process out-of-order card events safely

Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.

Separate ingestion and application

Validate the incoming event and save a durable record before acknowledging receipt. Apply business effects in a worker with idempotency. If processing fails after acknowledgement, the durable queue makes recovery possible.

Do not rewind state

A late authorization event must not erase a settled transaction. Design transitions around event semantics, not a last-write-wins timestamp alone. If a refund arrives before its parent charge is known, hold it for reconciliation instead of inventing a parent.

Replay deliberately

Keep a replay tool scoped to safe event references and a defined time window. Replays should rebuild derived views without duplicating financial entries. Log the operator and reason, and compare before-and-after totals.

Illustrative implementation

if event_id_already_seen(event.id): return existing_result
persist(event)
apply_if_transition_is_valid(event)
# Unresolved dependencies enter reconciliation.

Acceptance check

Replay the same shuffled event set twice. The final ledger and customer-visible state should be identical after both runs.

Further reading

• Stripe webhook documentation (provider-specific example)

Read next

• Verify payment webhooks before trusting their contents
• Build a reconciliation queue for uncertain card operations