Payments Core Architecture Deep-Dive

The unglamorous core of a payments system is exactly where outages and lost money hide. This written companion to our deep-dive recording covers designing for correctness under concurrency, with the failure stories that shaped each decision.

Start with an immutable ledger

Every balance is a derived view over an append-only log of events. You never update a row in place; you append the next truth. It sounds expensive until you realize it is the only model where reconciliation is trivial and audits are free.

• Append-only events, balances computed on read or materialized async.
• Idempotency keys on every write so retries are safe.
• Double-entry enforced at the database layer, not in application code.
• A reconciliation job that compares rails and pages on drift.

Orchestrate the rails, do not couple to them

Each payment rail fails differently and at different speeds. Put a thin orchestration layer in front that speaks one internal language and translates per rail, with timeouts and fallbacks you can change without a release. The day a processor has an incident, this layer is the only reason your customers do not feel it.

In payments, the boring decisions are the load-bearing ones. Idempotency is not a feature; it is the floor you stand on.