I worked on scaling UPI a few years ago. Real-time Payments is vastly more complex as it is much more distributed - each transaction involves the two banks holding funds, two end-user apps (and their banks), and the network (npci) – for the payment to complete end to end, multiple message exchanges need to happen between these parties while the user at both ends are waiting. So, if you measure the scale in messages/sec it would 10-25x higher.
Real-time payment rails that works 24/7 365 days a year from any bank to any bank (domestic, no exceptions) for free is truly a game-changer. Compare that to US payment rails which is slow and expensive. Apart from UPI, India has 3 more payment rails – NEFT (similar to ACH – batch settlement), IMPS (similar to UPI, instantaneous - but different user experience), RTGS (real-time, intermediated by the central bank RBI, but only for high-value transactions) – all are 24/7/365 and free. Then, there's credit card rails – apart from Visa and Mastercard, India also has RuPay which has much lower interchange rate.
scan
name & amount
PIN
the part you never see
payment sent
received
The five moments of a UPI payment as you experience them. Everything between your PIN and the result happens out of sight.
Several times a day, most of us pay the same way. You hold your phone up to a printed code, check the name that appears, enter the amount, key in a PIN, and a green tick says it is done. On the other side, someone’s phone buzzes to say the money has arrived. Start to finish, two or three seconds.
Those five moments, the scan, the name and amount, the PIN, the tick, and the buzz on the other side, are the whole payment as you ever see it. Everything else is hidden. Between the scan and the tick your instruction runs through a short chain of separate organisations, each checking one thing and handing the result to the next, all of it finishing before you have looked up from the screen. The app on your phone is only the first link, and it never touches your money.
It is worth knowing how much rides on this quiet handover. In June 2026 alone UPI carried more than 2,272 crore payments, more than any other real-time payment system in the world.5
This piece fills in the gap between the scan and the green tick. We follow a single payment down the chain, one party at a time: who hands it to whom, what each one checks, and where it can fail. At every stop we also look at how that part has changed. The diagram below is the whole cast, and we begin at the top, with the part you are holding.
Your appPhonePe, GPay
Your PSPissues your @handle
Your bankmoney out ⊖
NPCIthe switch
Payee bankmoney in ⊕
Payee PSPowns payee @handle
Payee appshows received
Every actor in one payment. NPCI sits in the middle and trades request-and-reply messages with all four legs. The receiver’s side mirrors yours.
The first part is the one you already know: the app. PhonePe, Google Pay, Paytm, or one of a dozen others. It is easy to take the app for the payment system itself, but its actual job is narrow. In the system’s own language it is a Third-Party Application Provider: it gathers your intent — pay this person, this amount — shows you who you are about to pay, and collects your PIN through a secure pad it cannot read into. Then it hands the instruction on. It never sees your PIN, holds none of your money, and carries no banking licence.1
This thin layer is where almost all of UPI’s competition is fought, and the contest is lopsided. Two apps, PhonePe and Google Pay, between them carry about four-fifths of every UPI payment; everyone else divides the rest.10 That duopoly has held for years. What moves is the order beneath it.
Watch the ranking over the years. A newcomer, super.money, launched by Flipkart in 2024, climbs from outside the top fifty into the top five in about a year, pulling users in with guaranteed cashback.810 The two apps at the top barely shift; the floor below them never stops rearranging.
Rank of the leading UPI apps by yearly transaction volume. Source: NPCI app statistics.10
For all that competition, there is one thing none of these apps can do on their own: reach the payment network. For that, each of them has to stand behind a bank.
Because the app holds no licence and no direct line to the payment network, it has to borrow both from a partner bank called a Payment Service Provider, or PSP, its sponsor. The sponsor does the things the app cannot: it connects to the central system, it issues the UPI address that stands for you, and it is the party that first tied your phone to your bank account when you set UPI up.1
That address is more revealing than it looks. The suffix on a UPI ID, the part after the @, names the sponsor bank, not the app you are using. An address ending in @ybl sits on Yes Bank; one ending in @okaxis sits on Axis. PhonePe’s handles run on Yes Bank, Axis and ICICI; Google Pay’s on Axis, HDFC, ICICI and State Bank.7
Most of the big apps now sit on several sponsor banks at once rather than one, mainly for resilience: spread across banks, a single bank’s outage cannot take the whole app offline, and no one sponsor has to carry all of the app’s volume.7 The sponsor banks get a quieter benefit of their own. When a payer and a payee happen to sit on the same sponsor, that bank resolves both addresses in its own books and skips the network’s central directory — faster, and it saves the resolution fee of about a paisa.7
So what actually leaves your phone is not money. It is a request assembled by the app and signed by your sponsor bank. Three of the five moments you see live here: the scan, the name and amount, and your PIN. The name is the network confirming who holds the address you scanned, your one chance to catch a wrong payee before any money moves. The PIN is captured and encrypted by a certified component on your phone; the app passing it along never learns it.1
Your appTPAP
Your PSPsponsor
NPCIswitch
From a QR scan to a signed pay request. The verified payee name comes back before you pay; your PIN is encrypted inside the common library (Creds type=“MPIN”), never seen by the app. Source: NPCI UPI API specification.2
From here the request has left your hands entirely. Everything after this happens among the banks and the switch, and it begins at the one place every payment must pass through.
Every payment, whatever app or bank it starts from, converges on a single point: the central switch run by NPCI, the non-profit that operates UPI; there is only one. Its first task is translation. The address you are paying belongs to the recipient’s own sponsor bank, so the switch routes the request there and that bank resolves the handle into a real account before any money moves.2
Then it moves the money, and the order is fixed. The switch asks your bank to debit you first. Your bank is the only party that can open the sealed PIN from your phone, so it is here, and only here, that your PIN is checked: your bank verifies it, confirms the balance, takes the money, and replies. Only once that debit is confirmed does the switch ask the payee’s bank to credit them, and wait for that confirmation in turn. The money always leaves before it arrives, never the other way round.2
Your bankremitter
NPCIswitch
Payee bankbeneficiary
Inside the switch. NPCI debits your bank first and waits for confirmation before asking the payee’s bank to credit; the money always leaves before it arrives. Source: NPCI UPI API specification.2
What comes back to you is not handed over by the switch directly. NPCI returns the outcome to the two sponsor banks, and each sponsor passes it on to its app. Your sponsor tells your app the payment went through and you see the green tick; the payee’s sponsor tells the payee’s app and their phone shows the money received.2
Your appyou
Your PSPsponsor
NPCIswitch
Payee PSPsponsor
Payee apppayee
The result comes home through the sponsors, not straight from the switch: your PSP shows payment sent on your screen, the payee’s PSP raises their received. Source: NPCI UPI API specification.2
The switch itself publishes almost nothing about its own work, because there is nothing to compare it against. There is only one of it. Its scale shows up instead as the sheer total it carries.
2,272 crore UPI payments in June 2026, up from a few million a month at launch in 2016
The real money-moving, though, happens at the two ends: the bank that debits the payer and the bank that credits the payee. You would expect the busiest banks on each side to be much the same.
They are not the same banks. Rank the busiest banks on the paying side and the busiest on the receiving side, then join each bank to itself across the two: the orders do not line up.
Each bank’s rank when paying vs when receiving, latest 12 months. Source: NPCI member-bank data.10
On the paying side the order is the one you would guess. State Bank of India leads by a wide margin, the other large consumer banks behind it, much as their customer numbers would suggest. On the receiving side the order falls apart. One private bank, Yes Bank, sits far out in front, taking a share of incoming payments that no bank comes near on the paying side, and a share that has roughly doubled in two years.610 The same Yes Bank is an also-ran at paying: it barely originates payments, yet it receives more than anyone.
The reason runs back to the sponsor layer, and it starts with what UPI has become. Most UPI payments are no longer people paying people; they are people paying shops. The two lines crossed in 2022 and have moved apart ever since.10
Share of UPI payments by count: merchant vs person-to-person, monthly. Merchants passed people in August 2022. Source: NPCI.10
A shop’s UPI code is issued by a sponsor bank just as your handle is. For the largest merchant apps that sponsor is, overwhelmingly, Yes Bank.7 So when you scan a PhonePe code at a store, the credit lands first at Yes Bank, the bank behind the code, and the shopkeeper is paid out afterwards from the merchant app’s pooled account.6 “Beneficiary bank” here does not mean the shopkeeper’s own bank. It means the bank that sponsors the code.
No system running at this size works every time, and what sets UPI apart is how precisely it records the times it does not. Every declined payment is filed under one of two headings.3
The first is a business decline: a wrong PIN, a short balance, a daily limit reached. You understand these the instant they happen, because the app tells you why and the cause sits on your side of the screen. The second is a technical decline: somewhere in the chain, a bank’s systems or the switch itself, a step could not be completed. This is the failure that surfaces as a message about the bank’s server, “Bank server down” or “your bank’s server didn’t respond, please try again”, with nothing on your side to explain it.3
Set the two against each other over the years and a clear divergence appears. Lately about one payment in eleven is declined, but fewer than one in four hundred fails because of the rail itself. And the gap is widening. Technical declines have fallen year after year, from more than one in a hundred to fewer than one in four hundred, as the banks and the switch were hardened. Business declines have not fallen; they have risen.10
Remitter-side decline rate, technical vs business, by year. Source: NPCI member-bank data.10
So the rail grows more reliable even as the payments that fail increasingly fail for reasons that have nothing to do with it. The everyday breakdown is not the machine giving way; it is the machine enforcing one of its own rules.
This runs against what the outages suggest. UPI has gone dark across the country for hours at a time, and those days are real and remembered.9 But they are rare. On an ordinary day a payment almost never fails because the system broke. It fails because of a limit reached, a balance too low, or a single wrong digit.
And then there is a third case, neither a clean success nor a clean decline: the payment the system itself cannot immediately call.
Remember that the money always leaves before it arrives. Almost always the arrival is confirmed in the same moment, and you never know there was a gap at all. But every so often the confirmation does not come back in time. The payee’s bank may have credited the account and failed to report it, or it may not have credited at all, and for a short while the network genuinely cannot tell which. A payment caught in that state has its own name: it is deemed, meaning the credit is unconfirmed.2 This is the moment your app stops short of the green tick and says, instead, that the payment is processing. Your money has left, and no one can yet say whether it landed.
The system is built for exactly this. Your app does not sit and guess. After about ninety seconds it can quietly ask the network for the true status, and it is allowed only a few such checks, because apps that hammered this one question have themselves brought UPI down.9 You are not asked to do anything; the asking happens for you.
Behind that, NPCI runs its own reconciliation. It keeps querying both banks until it has a definite answer, and posts one of two verdicts: the credit did happen, so the payment stands, or it did not, so the debit is reversed.9
Your appyou
Your bankremitter
NPCIswitch
Payee bankbeneficiary
When a payment is left pending, your app quietly checks the status and NPCI auto-reconciles, ending with the money either confirmed or reversed to you, guaranteed within a day. Sources: NPCI UPI API spec, UDIR (OC-98), RBI TAT circular.94
And if it must be reversed, the timing is not left to goodwill. The money has to return to you within a day for a transfer, a few days for a merchant payment, with a hundred-rupee daily penalty on the bank if it is late.4 The system cannot always promise to get a payment right in the moment, so the rules promise to make it right afterwards.
Payments stuck this way were never common, and the reconciliation machinery around them has only tightened since.
scan
name & amount
PIN
the relayapp›sponsor›hub›banks
payment sent
received
The same five moments, with the gap filled in: the hidden relay spans app, sponsor, hub, and banks.
Which returns us to where we began: the scan, the name and amount, the PIN, the green tick, and a phone buzzing on the other side. Those five moments are still all you see. Behind those few seconds are seven separate companies and banks, passing a message down a line and back, checking it at every step, wrapped in rules written so that even when it fails, it fails in your favour. The next time the tick appears, you will know what it took.