Art of Codeartofcode
Lesson 5 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.4 What do we store?

3 min read+10 XP
payment_intents id, merchant, amount, currency, method, state, idempotency_key (unique), created_at attempts intent_id, provider, provider_ref, state, request/response log ledger_txns txn_id (unique, e.g. "capture:pi_1"), created_at, description ledger_lines txn_id, account, amount (signed, integer) ← lines of a txn sum to zero accounts bank_clearing, merchant:{id}, revenue:fees, refunds_pending, ... outbox events to publish (webhooks, payouts) (Chapter 23)

Interviewer pushback:

  • "Where are the card numbers?" → In a separate, tightly controlled card vault (PCI DSS scope). Everything else uses tokens that are useless outside our system.

Memory code: "Intents for the story, a ledger for the money, a vault for the cards."