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.3 What are the doors?
3 min read+10 XP
Step 3: API and data model (10 minutes)
POST /v1/payment_intents Idempotency-Key: order-881
body: { "amount": 124800, "currency": "INR", "merchant": "m_bookstore",
"method": "upi" | "card_token" }
returns: 201 { "id": "pi_1", "status": "requires_action" | "processing" | "succeeded" | "failed" }
POST /v1/refunds Idempotency-Key: refund-881-1 { "payment_intent": "pi_1", "amount": 124800 }
GET /v1/payment_intents/{id} → current status (merchants can poll; webhooks are preferred)
(webhook to merchant) POST https://merchant…/webhooks signed: payment_intent.succeeded, .failed, refund.succeeded
(callback from bank) POST /internal/bank/callback signed by the bank or network
Amounts are integers in the smallest unit (paise), never floats.