sydepsystem design atlas

Payment Processing Platform

Route, authorize and reconcile payments with idempotency and ledgering.

AdvancedCommerceFintech
ClientClientPayment APINetworkingPayment RouterComputeIdempotency StoreStoragePayment ProcessorClientLedgerStorageReconciliation JobCompute

Payment requests are idempotency-keyed and routed to the right processor/rail, with every state transition recorded in an append-only ledger so money movement is fully auditable and reconcilable against processor statements.

When to use it

  • Payments must never be double-charged even under client retries or network failures
  • Every movement of money needs a durable, auditable trail for reconciliation and disputes

Trade-offs

  • Idempotency keys, ledger entries and reconciliation jobs add real implementation weight beyond a naive charge call
  • Multi-processor routing needs a fallback strategy for when a preferred rail is degraded

Components used

Web AppAPI GatewayManaged App ServiceCacheThird-party ClientRelational DatabaseBatch / Scheduled Job

How it works

  • Every payment attempt carries a client-supplied idempotency key, so retries return the original result instead of charging again.
  • Authorization and capture are separate steps: authorization reserves funds, capture actually moves them, which is why a refund and a void are different operations.
  • A double-entry ledger records every movement as balanced debits and credits, and reconciliation compares that ledger against the processor's settlement reports.

Used in the wild

  • Marketplaces splitting funds between platform and sellers.
  • Subscription billing with retries and dunning.
  • Any system where the finance team needs to explain a discrepancy to the penny.

Good to know

  • Never store money as a floating-point number. Use minor units as integers or an exact decimal type — 0.1 + 0.2 is famously not 0.3 in binary floating point, and that error compounds across millions of rows.
  • The ledger should be append-only. Correcting a mistake means writing a reversing entry, not updating the original, because auditors need to see that the mistake happened.