The day before Diwali, Mrs. Rao orders ₹1,000 of groceries from Annapurna Stores' website. She taps Pay. The page spins. Her mobile data drops for a second, the page shows an error, and she taps Pay again. (Mrs. Rao, Annapurna Stores, PaySetu, Farida and every number here are made up for teaching.)
Behind the shop's checkout sits PaySetu, a payment service that sits between shops and outside payment providers. Farida is its architect. She explains her two rules with a school canteen:
Every request carries a number. You hand over a coupon, and the cashier writes it in a book and gives you a receipt with a number. If a friend bumps you and you hold out the same coupon again, a careful cashier doesn't charge twice. They look up the number, see it's already done, and hand back the same receipt.
Every movement of money is written in two places that must balance. The cashier's book has two columns, so a mistake shows up.
Those two rules, plus an honest "I don't know yet," are the whole design. This guide designs a payment service in the spirit of Stripe, Razorpay or PayPal. It is an original interview design, not the internal architecture of any named company, and it doesn't build a card network or a bank. Where concrete behaviour is described, such as how retries and webhooks work, it comes from Stripe's public documentation, and the text says so. The ideas apply to any provider. Related problems appear in the hotel reservation, BookMyShow and ATM guides.
What happens to Mrs. Rao's ₹1,000
Idea it forces
"She tapped Pay twice"
Idempotency keys
"The provider timed out. Did the money move?"
A payment state machine with an honest unknown
"The confirmation arrived twice, and out of order"
Webhooks, processed safely
"Where exactly is the ₹1,000 now?"
A double-entry ledger
"Finance says the books are ₹40,000 off"
Daily reconciliation
"Card numbers, Indian data rules, a region outage"
Security, compliance, failover
"We can't build all of this on day one"
Growing the design in stages
In 30 seconds, as an architect would frame it: "A payment platform has one job that can't fail silently: move money exactly once, and prove it. I'd use a provider's hosted card fields, so card data never touches our systems. Every request carries an idempotency key. A timeout is treated as unknown, not failed. Signed webhooks confirm the result, money is recorded in an append-only double-entry ledger, and a daily job reconciles the ledger with the provider's settlement file. Then I'd cover the constraints (PCI scope, data residency, recovery targets) and how the design grows from one provider to two, with a disaster-recovery region."
The five-minute whiteboard sketch
Before any detail, this is the picture to draw in the first five minutes of an interview. It has seven components and one numbered path. If you only have time for one drawing, draw this one.
Seven components and six numbered steps. Draw this first, say the two rules out loud (every request has a key, every money movement balances), then ask which part the interviewer wants to go deeper on.
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
