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.8 How does reconciliation work?
3 min read+10 XP
Figure: unclear outcomes stay pending until proven; a daily comparison proves the rest.
Pending is a real state. If the bank times out, the customer may or may not have been debited. Marking it failed risks charging the customer with no order; marking it succeeded risks shipping unpaid. So: pending, then:
- Wait for the callback, and
- Run status checks against the bank or network on a schedule (UPI and card networks provide status-check APIs).
In the chapter's code, a timed-out payment stays pending while the bank doesn't know, and becomes succeeded when the signed callback arrives.
Reconciliation compares our ledger with each bank's daily settlement file, payment by payment:
- Match: done.
- Amount mismatch: investigate (in the code, ₹500 in our ledger vs ₹50 at the bank).
- Missing at the bank: we think it succeeded; they don't. Investigate, possibly reverse.
- Missing in our ledger: they took money we never recorded (a lost callback): record it or refund it.
Every break gets a ticket and an owner; the goal is zero unexplained breaks each day.
Memory code: "If you don't know, say pending; then prove every payment against the bank's books."