Art of Codeartofcode
Lesson 15 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)

Sources

3 min read+10 XP

Source notes

  • UPI volume: more than 20 billion transactions in August 2025, the first month above that mark, per NPCI data as reported in the press; checked 2026-10-08.
  • Idempotent requests and signed webhooks: Stripe documentation (see Chapter 24's source notes).
  • Card data handling and tokenisation: PCI DSS (Payment Card Industry Data Security Standard).
  • Double-entry bookkeeping as the basis of payment ledgers: standard accounting practice; payment companies have described ledger designs on these lines in engineering posts.
  • Payment volumes, fees, ledger line sizes and retention are interview assumptions agreed in Step 1, not figures for any real company. Arithmetic computed 2026-10-08.
  • Idempotent intents, balanced ledger with reversing refunds, pending resolution by callback, signed and de-duplicated callbacks, and reconciliation breaks: tested 2026-10-08 (code/ch45_payments.py, all checks pass).