UPI is not a payment gateway. It is a four-party switch moving money directly between bank accounts in under a second, at a scale no card network operates at. The design questions it raises — idempotency, deemed acceptance, reversal — are different from the ones a checkout flow raises.
UPI processes well over a thousand crore transactions a month and is still growing. Individual payments are small — a chai at a roadside stall, a split dinner bill — so the system is defined by transaction count rather than value, and by a latency budget the user measures in the time it takes to lift a phone away from a QR code.
name@bank) and link it to a bank account.Primary takeaway: the hard part is not throughput. It is that money moves between two independent banks over an unreliable network, and the system must still be able to say afterwards, with certainty, whether it moved.
This is what makes UPI structurally different from a card payment or a wallet. There is no merchant acquirer holding funds and no intermediate balance. A central switch coordinates a debit at one bank and a credit at another, and four parties are involved in every payment.
Payer PSP app → the app the user opens
Payer bank → holds the account being debited
Central switch → routes, sequences and settles
Payee bank → holds the account being credited
The payer never sees an account number. A VPA is resolved through the switch into the payee's bank and masked account details. That indirection is why a user can change banks without reprinting every QR code, and why account numbers are not scattered across apps.
Money does not rest anywhere in between. Contrast a wallet, which takes custody and can settle later at leisure — here the debit and the credit belong to one logical operation across two institutions that share no database.
1. App builds the request, assigns a unique transaction id
2. UPI PIN captured inside a bank-owned secure component
3. Switch resolves payee VPA → payee bank
4. Switch asks payer bank to debit
5. On debit success, switch asks payee bank to credit
6. Both legs confirmed → SUCCESS to the app
The UPI PIN is captured by a library the bank controls, encrypted against the bank's key, and passed through opaquely. The PSP app — and therefore whoever built it — never sees it. Being able to say this matters in interviews: it explains why any app can be a PSP without every app becoming a credential risk.
Steps 4 and 5 are two calls to two independent institutions. Either can time out without telling you whether it applied. This is the heart of the question, and a candidate who describes only the happy path has not answered it.
The money has left one account and not arrived in the other. The switch must issue a reversal to the payer bank. Until it completes, the user's balance is genuinely wrong — which is why reversal is a first-class flow with its own guarantees, not error handling.
A bank that does not answer has not necessarily failed. The switch cannot assume either way, so the transaction sits in a deemed state and is resolved by an explicit status check against the bank, retried on a schedule until the bank gives a definite answer.
Every retry carries the original transaction id. A bank receiving a debit it has already applied must return the prior result rather than debit again. Without this, the retry machinery above would itself become the bug — double debits are the most common failure in a naive design.
At end of day every party exchanges its ledger and the switch matches them leg by leg. Anything unmatched is auto-reversed or escalated. Real-time correctness is best-effort; reconciliation is what makes it eventually certain.
Interview angle: this is a distributed transaction across parties that cannot run two-phase commit — no bank will let an external switch hold a lock on its ledger. The answer is a saga: forward legs with compensating reversals, made safe by idempotency keys and settled by reconciliation.
Partition ledger state by account so a debit touches one shard. The switch itself is stateless per transaction and scales horizontally; the transaction log is append-only and partitioned by id.
Bank reliability varies enormously. A circuit breaker per bank stops one slow institution consuming every worker thread, and lets the switch decline fast with an honest error instead of hanging the user.
When a bank is struggling the right behaviour is to fail the transaction quickly and clearly — a user who is told it did not go through will simply try again, while a user left on a spinner will retry blindly, re-scan, or pay twice by another route. Fast honest failure reduces total load; optimistic hanging multiplies it.
Largely. Design UPI, design PhonePe, design Google Pay, design a UPI payment system and “how does UPI work” are the same interview question. The apps are PSPs sitting on the same rails; what differs is whether the interviewer wants the switch and the inter-bank protocol, or the app-side concerns of onboarding, QR handling and notifications. Ask which, early.
It is a different question from designing a generic payment gateway. A gateway sits between a merchant and card networks and can take custody of funds; UPI moves money directly between two banks with no float. If you answer one with the other, the follow-up about what happens when the credit leg fails will show it.