Art of Codeartofcode
Lesson 10 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.9 How do callbacks and webhooks work?

3 min read+10 XP

Two directions, same rules (Chapter 24):

  • Incoming callbacks from banks: verify the signature and timestamp, de-duplicate by event ID, and apply idempotently. In the chapter's code, the same success callback delivered twice captures the payment once, and a forged signature gets 400.
  • Outgoing webhooks to merchants: sign them (HMAC), retry with backoff for days, let merchants see delivery logs and replay events, and include an event ID so they can de-duplicate.
  • Never trust the client's redirect ("payment successful" in the browser URL) as proof of payment: only the server-to-server callback or a status check counts.
  • Order isn't guaranteed: "refund succeeded" might arrive before "payment succeeded"; the state machine and ledger IDs handle any order.

Memory code: "Check the signature, apply once, and believe the server, not the browser."