Art of Codeartofcode
Lesson 14 of 16

45. Design a Payment System (Stripe / UPI)

1
The interview prompt
2
45.1 What do you ask first?
3
45.2 How big is this, really?
4
45.3 What are the doors?
5
45.4 What do we store?
6
45.5 What does the whole system look like?
7
45.6 How does idempotency work end to end?
8
45.7 How does a double-entry ledger work?
9
45.8 How does reconciliation work?
10
45.9 How do callbacks and webhooks work?
11
45.10 How do you keep it consistent?
12
45.11 What would you say in the last five minutes?
13
Score yourself
14
Variations to practise
15
Sources
16
Code lab
45. Design a Payment System (Stripe / UPI)

Variations to practise

3 min read+10 XP

Chapters used

Approach (1), Estimation (2), SQL vs NoSQL (8), Replication (14), Sharding (15), Consistency (16), Transactions and sagas (17), Message queues (22), Outbox (23), APIs, idempotency and webhooks (24), Rate limiting (25), Failures and circuit breakers (29), Observability (30), Checkout (42).

Try these variations

Each is a common follow-up. Answer in two minutes, then check the sketch.

  1. "Pay merchants every day." → A payout job reads each merchant's ledger balance, sends a bank transfer with an idempotency key, and posts a balanced payout transaction; failed payouts reverse it.
  2. "Handle chargebacks." → A dispute creates a hold transaction moving funds from the merchant to a disputes account; the outcome either releases or confirms it.
  3. "Multi-currency." → Ledger accounts per currency; conversions are transactions through FX accounts at a recorded rate; never mix currencies in one line.
  4. "10× payment volume." → More shards by merchant, bucketed hot accounts, more bank adapter capacity, and reconciliation run in parallel per bank and per day.