System design interview guide
UPI System Design: How India's Payment Switch Works
UPI handled 24.51 billion payments in August 2026. That is about 791 million a day, worth ₹29.82 lakh crore in the month, across 752 banks (NPCI data). On average, that is about 9,000 payments every second. At the evening peak it is much more. Each payment moves real money between two banks that never talk to each other directly. Every payment goes through one central switch run by NPCI. And every payment must end in one of two states: paid, or not paid. This must hold even when a bank stops answering halfway through.
UPI is India's real-time payment system. You pay from an app like PhonePe or Google Pay. But the app never holds your money. Your money stays in your bank account. The app talks to a central switch run by NPCI, the National Payments Corporation of India. The switch finds the person you are paying from their UPI ID. It asks your bank to check your PIN and take the money out. Then it asks their bank to put the money in. The banks settle the real money between themselves later, in batches. Speed is not the hard part of this design. The hard part is staying correct when something times out in the middle. For example, your bank took the money, but the other bank never answered. The other hard part is protecting one central switch from its own users. In March and April 2025, UPI went down three times. NPCI found the cause: banks and apps asked 'did this payment go through?' far too often, and far too fast.
Where it shows up
A natural question for payments and fintech roles in India. Think of PhonePe, Paytm, Razorpay, CRED, Juspay and bank technology teams. It is also a common real-time payments question anywhere. It also comes in general forms. Design a payment switch. Design a bank-to-bank transfer system. Design a payment system that never loses money.
Why this question is asked
Most payment questions let you hide the hard part inside one company's database. UPI does not. The money lives in two different banks. The app in the middle holds none of it. A central switch sits between everyone. So you must talk about the things interviewers want to hear. A payment has two steps that can fail on their own. Retries must be safe across companies you do not control. A timeout does not mean the payment failed. Every day, all the records must be matched. And a shared system must protect itself from its own users.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- A user links a bank account to an app and gets a UPI ID, like name@bank
- Pay: the user sends money to a UPI ID, a phone number or a QR code
- The user approves every payment with a UPI PIN that only their bank can check
- The payer's bank takes the money out and the payee's bank puts it in, in real time
- Merchants can send a payment request, called a collect request, for the customer to approve
- Small payments can go through without a PIN, from a small balance on the phone (UPI Lite)
- Repeating payments (Autopay) for bills, loan payments and subscriptions
- Every payment ends in a clear final state, and a failed payment is returned automatically
Non-functional requirements
- Handle about 800 million payments a day, with a much higher evening peak
- A payment finishes in a few seconds for the user
- Never lose money and never move it twice, even when a bank times out
- The app the user types into can never see the PIN
- The switch stays up even when one bank or one app misbehaves
- Every payment can be matched between the switch and every bank, every day
- Follow the rules, including returning a failed payment by the next day
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Payments per month
24.51 billion (Aug 2026)
This is NPCI's figure for August 2026, the highest month so far. July was 23.66 billion. Volume grew about 22% in a year.
Average load
~9,000 payments/sec
791 million payments a day, divided by 86,400 seconds, is about 9,150 a second. That average includes quiet hours like 3 am. So plan for several times more at the evening peak. This is my estimate for design. NPCI itself treats 5 pm to 9:30 pm as peak hours.
Average payment size
~₹1,217
This is ₹29.82 lakh crore divided by 24.51 billion payments. The number is small, and it keeps falling. People now use UPI for tea and groceries, not just rent. So most traffic is many tiny payments. That is why cost and speed per payment matter so much.
Banks
752 banks live
NPCI reported 752 banks live in August 2026, up from 713 in April. Each bank is a separate system. Each has its own speed and its own ways to fail. The switch must work with the slowest of them.
Calls per payment
4 or more
One payment needs at least four calls. Find the payee's account. Take the money out. Put the money in. Tell both apps the result. Status checks add more calls when the result is unclear. At 800 million payments a day, one extra call per payment means 800 million extra calls.
App share
PhonePe 45.9%, Google Pay 32.4%
This is NPCI's data for August 2026. PhonePe had 45.9%, Google Pay 32.4%, Paytm 8.1% and Navi 4.4%. Two apps send over three quarters of all traffic. So one badly behaved app can be a big share of the load.
High-level architecture
Design UPI as a hub with spokes. The hub is a central switch. There are four kinds of parties. First, the payer's app, like PhonePe, which works through a sponsor bank. That bank is called a PSP, a payment service provider. Second, the central switch run by NPCI, which routes every message. Third, the payer's bank. It is the only party that can check the PIN and take money out. Fourth, the payee's bank, which puts the money in. A normal payment works like this. The app sends a pay request to the switch, through its PSP bank. The switch finds the payee's bank account from their UPI ID. It asks the payee's PSP for this. The payer types the UPI PIN into a secure part of the phone. The PIN is locked so only the payer's bank can read it. The switch asks the payer's bank to check the PIN and the balance, and take the money out. Then it asks the payee's bank to put the money in. The switch records the final state and tells both sides. No money moves between the banks at that moment. The switch keeps a record of who owes whom. The banks settle the totals later, in batches, through their accounts at the RBI. So there are two layers. Messages move in real time. Money between banks moves in batches. This is how UPI feels instant and still stays safe. The rest of the design is about one question: what happens when a step does not answer?
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
The app and its PSP bank
The app the user sees. It shows the linked bank accounts and scans QR codes. It never holds money and never sees the PIN. It reaches the switch only through its PSP bank, which is responsible for it. So a very large app can put heavy load on one bank.
Finding the payee (VPA lookup)
This turns a UPI ID like name@okbank into a name and a bank account. It works for phone numbers and QR codes too. The payee's PSP owns this list. The app shows the payee's real name before the payer types the PIN. This stops fraud. It is the moment a user notices they are paying the wrong person.
Safe PIN entry
The user types the PIN into a secure part of the phone, not into the app's own screen. The PIN is locked with a key that only the payer's bank has. The app and the switch carry the locked PIN but cannot read it. This is why hundreds of apps can exist without any of them learning your PIN.
The central switch
It routes every request between apps and banks. It gives each payment an ID and tracks it. It enforces time limits and records the state of every payment. It also makes the files used for settlement and matching. It must never be the reason money is lost. So it saves every state change safely before it replies.
Payer's bank (money out)
It checks the PIN, the balance and the limits. Then it takes the money out. It is the only party that decides whether money may leave the account. It must treat the same payment ID as the same payment. Then a repeated request never takes the money twice.
Payee's bank (money in)
It puts the money into the payee's account. This step is what makes timeouts dangerous. By now, the payer has already paid. If this bank does not answer in time, the payment is stuck between two banks. It stays stuck until someone finds out what happened.
Status checks and disputes
An app can ask 'what happened to this payment?' when no reply came. Banks can also raise and settle disputes. After the 2025 outages, NPCI limited this. The first check must wait 45 to 90 seconds after the payment. There can be at most three checks in two hours.
Settlement and matching
At the end of each settlement cycle, the switch works out what each bank owes every other bank. The totals are settled through the banks' accounts at the RBI. Then every bank matches its own records against the switch, payment by payment. Any mismatch shows a stuck payment or a needed refund.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
vpa_directoryvpa (PK)psp_idaccount_refverified_namestatusEach PSP owns the list for its own UPI IDs. The switch does not keep one central list. It asks the payee's PSP instead. So many apps can give out UPI IDs without one giant list of every user.
transactionstxn_id (PK)payer_vpapayee_vpaamount_paisetype (pay/collect)statecreated_atThe switch's record of every payment. The txn_id is made once, at the start. It travels through every step. Every party uses it to spot a repeated request. Amounts are whole paise, never decimals.
transaction_legstxn_idleg (debit/credit)bank_idstate (sent/success/failed/timeout)bank_refupdated_atEach payment has two steps that can fail on their own. Each step's state is stored separately. This makes the dangerous case easy to see: money out worked, but money in timed out. Refunds and matching start from these rows.
state_transitionstxn_idfrom_stateto_statereasonatA log of every change. Rows are only added, never edited. Disputes and regulators ask what the system knew, and when. This log answers that.
settlement_positionscycle_idbank_idnet_amount_paiseWhat each bank owes, or is owed, in one settlement cycle. It is worked out from the final state of every payment. Real money moves only on these totals, not on each payment.
reconciliation_breakstxn_idbank_idswitch_statebank_stateresolutionresolved_atEvery payment where a bank's record and the switch's record do not match. This is how a 'money left my account but did not arrive' problem gets fixed. Often it is fixed before the customer even calls.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Two steps, one payment: a timeout is not a failure
A UPI payment is really two operations at two banks. Take money out of one account. Put it into another. The switch asks for the money out, and gets a success. Then it asks for the money in, and the request times out. Now the switch does not know what happened. Maybe the payee's bank put the money in and the reply got lost. Maybe the request never arrived. If the switch calls it a failure and refunds the payer, the payee may have money nobody paid for. If it calls it a success, the payer may have lost money. So a timeout needs its own state: unknown. This is the most important rule in this design. A timeout means 'I do not know yet'. It never means 'it failed'. The payment stays pending. A status check or the daily matching finds the real answer. Only then is it marked final, or refunded.
Safe retries across banks you do not control
Networks retry. An app that hears nothing sends the same request again. The switch may do the same with a bank. If each retry counted as a new payment, one tap could take money twice. The fix is a payment ID. It is made once, at the very start. Every party treats it as the name of the payment. Suppose a bank gets a request to take money for an ID it already handled. It must return the old result, not take the money again. This needs one rule. The check and the money change must happen in one database statement, with the payment ID as a unique key. Then neither a crash nor two copies of one request can split them apart.
WITH d AS (
UPDATE accounts SET balance_paise = balance_paise - $3
WHERE account_id = $2 AND balance_paise >= $3
AND NOT EXISTS (SELECT 1 FROM debits WHERE txn_id = $1)
RETURNING account_id)
INSERT INTO debits (txn_id, account_id, amount_paise)
SELECT $1, account_id, $3 FROM d;
-- 0 rows: already debited, or not enough money.
-- A racing duplicate hits the txn_id primary key and
-- its whole statement, balance update included, rolls back.The 2025 outages: when the users take the system down
In March and April 2025, UPI went down three times. On 12 April, it was down for hours across the country. NPCI's finding was surprising. The switch was not too small for payments. The problem was a flood of 'check transaction status' calls from banks and apps. They came very fast, even for payments that were already done. Each app that got no quick answer asked again, and again. Each ask was a real request into the same central system. This is a retry storm. The slower the system gets, the more everyone asks. The more everyone asks, the slower it gets. NPCI fixed it with clear rules. Wait 45 to 90 seconds before the first status check. Make at most three checks in two hours. Do not retry on connection errors. NPCI also said it would add rate limits on some calls. In an interview, this is the moment to make a point. A central switch must protect itself. Limit each caller. Keep 'what happened?' calls apart from payments. Make callers wait longer between retries.
Keeping the PIN away from the app
Hundreds of apps can move money on UPI. None of them may know your PIN. You type the PIN into a secure part of the phone. It is locked with a key that only your bank can use. The app, its PSP bank and the switch all pass the locked PIN along. None of them can read it. Your bank opens it, checks it, and answers only yes or no. This is the same idea as end-to-end encryption in chat apps. The middle parties are trusted to carry the message, not to read it.
Messages in real time, money in batches
It feels as if money moves the moment you pay. Between banks, it does not. Each bank updates its own customers' balances in real time. What the banks owe each other is added up by the switch. It is settled later, in batches, through the banks' accounts at the RBI. This is on purpose. Moving real money between banks for every ₹20 payment would be slow and costly. So the switch adds everything up first. Say one bank's customers paid another bank's customers ₹1,000 crore today. And they got ₹950 crore back. Only the ₹50 crore difference moves. The cost is that the switch's records must be perfect. The money moves based on them. So every bank checks its records against the switch after every cycle.
Collect requests and fraud
UPI once had two ways to pay. In a push payment, the payer starts it. In a collect request, the payee asks, and the payer approves. Collect requests are useful for shops. A website asks you for ₹499, and you approve it in your app. Between two people, they became a tool for fraud. A stranger sends a request that looks like a refund or a prize. The victim approves it and types the PIN. These requests had a limit of ₹2,000 since 2019. From 1 October 2025, NPCI stopped them between people completely. Only merchants can still use them. The lesson is simple. A feature can work exactly as designed and still be the easiest way to cheat users. The safest payment is the one the payer starts.
Moving work away from the busy hours
From August 2025, NPCI added limits to actions that are not payments. Each user can check their balance at most 50 times a day in each app. Each user can ask for their linked accounts at most 25 times a day. Autopay runs only outside the busy hours. The busy hours are 10 am to 1 pm, and 5 pm to 9:30 pm. None of this stops anyone paying. It moves work that can wait out of the busiest hours. So at the peak, the capacity goes to payments. It is like running a big job at night. If you cannot make the peak smaller, move everything else away from it.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
One central switch versus banks connecting to each other directly
With hundreds of banks, direct links would mean tens of thousands of connections. Each would have its own format and rules. Every new app would need to reach every bank. With a central switch, every bank and app connects once. The cost is that the whole country depends on one system. That is why its uptime matters so much, and why it must protect itself from bad callers.
Treat a timeout as unknown versus failing fast
Failing fast gives the user a quick answer. But on the money-in step, a wrong 'failed' can move money that was never paid. Holding the payment as pending is slower, but it is correct. UPI chooses correct. A hard rule backs it up. A failed payment must be returned by the next day. If not, the bank pays the customer ₹100 for each day of delay.
Settle in batches versus moving money for each payment
Settling every payment between banks one by one would remove the need to trust the switch's records. But it would be far too slow and costly at this volume. Adding up and settling in batches makes each payment cheap and instant. The price is a daily check that must catch every mismatch.
Free status checks versus limited status checks
Free status checks feel friendly. An app can always find out what happened. But at this size, they became a storm that stopped payments in 2025. Now there are at most three checks, spread over two hours. Some users wait longer for an answer. But the switch stays up for everyone else.
Allow collect requests between people versus push only
Collect requests between people were handy. But they became a common way to trick users into paying. Removing them closes that door. The cost is small. One analysis reported by MediaNama found that 86% of payments between people were already above the old ₹2,000 limit. So people were mostly paying by push anyway.
A PIN for every payment versus a small balance with no PIN
A PIN on every payment is the safest option. But it adds a step and a bank call to a ₹10 payment. UPI Lite keeps a small balance on the phone, up to ₹5,000. It allows payments up to ₹1,000 each with no PIN. The risk stays small because the balance is small. And the huge number of tiny payments no longer hits the banks' main systems.
How UPI (Unified Payments Interface) actually does it
The numbers on this page are NPCI's figures for August 2026, as reported in the news. The rules come from NPCI circulars and an RBI circular. Each was checked against more than one report. NPCI does not publish how its switch is built. We do not know its databases, languages or exact capacity. So the design here fits UPI's public behaviour and rules. It is not a description of NPCI's code. Where a number is my own estimate, like the peak load, the page says so.
Sources
- MediaNama: UPI August 2026 data (NPCI figures)
- Inc42: UPI app market share, August 2026
- MediaNama: NPCI guidelines after the 2025 UPI outages
- MediaNama: NPCI ends P2P collect requests from 1 October 2025
- The Week: UPI API limits from 1 August 2025
- RBI: Harmonisation of turnaround time and customer compensation for failed transactions
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Idempotency Keys
intermediate / api design protocols
Distributed Transactions
advanced / distributed systems core
Saga Pattern
advanced / distributed systems core
Timeout Patterns
advanced / reliability resilience
Retry Patterns
advanced / reliability resilience
Rate Limiting for Resilience
advanced / reliability resilience
High Availability
advanced / reliability resilience
Related system design interview questions
Practice these next. They lean on the same core building blocks as UPI (Unified Payments Interface).