45. Design a Payment System (Stripe / UPI)
1
The interview prompt2
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 yourself14
Variations to practise15
Sources16
Code lab45. Design a Payment System (Stripe / UPI)
45.6 How does idempotency work end to end?
3 min read+10 XP
Step 5: Deep dives (10 minutes)
Chapter 24's double-charge problem, applied at every hop:
- Merchant → us: an
Idempotency-Keyper intended payment; the intents table has a unique constraint. In the chapter's code, a retried "pay ₹1,248 for order 881" returns the same intent, and there's still one. - Us → bank: every attempt carries our attempt reference; banks and networks de-duplicate on it, so our retry after a timeout doesn't debit twice.
- Bank → us: callbacks carry the bank's reference; we apply each once.
- Inside us: ledger transactions have deterministic IDs (
capture:pi_1,refund:pi_1), unique in the ledger, so recording the same event twice is a no-op. In the chapter's code, a second refund post returns "duplicate".
Memory code: "A key at every hop, and every effect recorded under a name that can't repeat."