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

45.7 How does a double-entry ledger work?

3 min read+10 XP

a capture of ₹1,248 debits bank clearing and credits the merchant and fees, summing to zero; a refund is a new reversing transaction.

Figure: every transaction's lines add up to zero; history is never edited.

  • Every movement is a transaction of lines that sum to zero. Money doesn't appear or vanish; it moves between accounts. A ₹1,248 payment with a 2% fee: bank clearing +1,24,800, merchant −1,22,304 (we owe the merchant), fees −2,496 (our revenue). In the chapter's code, the ledger's total is zero after every step.
  • Unbalanced transactions are rejected outright; in the code, a 100 vs −90 posting raises an error.
  • Append-only: a refund is a new reversing transaction, never an edit. History stays complete for audits.
  • Balances are derived by summing lines (cached and periodically verified), so a wrong balance can always be traced to the entries that made it.
  • Integers only (paise), never floating point.
  • Accounts per merchant make payouts simple: the payout job pays the merchant's balance and posts the matching transaction.

Memory code: "Every rupee comes from somewhere and goes somewhere, and the lines always add to zero."