Payment System Design — Interactive Simulation

Money must never be inconsistent

Unlike a dropped search query or a missing feed post, a dropped payment is catastrophic. The user was charged but received nothing — or worse, charged twice. Every design decision in a payment system prioritises correctness over speed.

Three failure classes

(1) Duplicate charges — client retries after a network timeout but the first request already succeeded. (2) Lost payments — request arrived but the system crashed before persisting. (3) Phantom charges — charge recorded but downstream fulfilment never triggered.

What we'll build

A system that handles all three failure classes using Idempotency, Webhook Handler, an immutable Ledger Service, and a nightly Reconciliation Service.