Payment System

A payment system moves money between customers, merchants, and external processors, and the bar is correctness rather than raw scale: no double charges, no lost payments, and books that always balance. The design revolves around idempotency, a durable state machine, a double-entry ledger, and reconciliation.

Clarify requirements

Functional

• Merchants (or our own e-commerce checkout) create payments: charge a customer's card/UPI/wallet via external payment service providers (PSPs).
• Payment lifecycle: created → authorized → captured → settled; refunds (full/partial).
• Record every money movement in a ledger; merchant balances and payouts.
• Webhooks/notifications to merchants on status changes.
• Out of scope: fraud models (integrate a risk service), currency conversion details, building a card network.

Non-functional

• 10M payments/day, peak 1,000 TPS (sales events).
• Exactly-once effect: never charge twice, never lose a successful charge.
• Strong consistency for ledger and payment state; full auditability (append-only).
• High availability, but correctness beats availability: better to fail a payment than to corrupt state.
• PCI DSS compliance: card data never stored in plain form.