UPI: Anatomy of a Payment Transaction

How it works · The rails · 13 min read · data through June 2026

UPI: Anatomy of a Transaction

You pay in seconds. Seven parties make it happen, and you see only one of them. We follow one payment from the scan to the green tick: at each stop, how that layer works, and what the data shows about how it has changed, including the days it fails.

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.

The app

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.

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.

The sponsor

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

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.

The hub

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

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

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.

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.

The banks

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.

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

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.

Where it breaks

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

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.

The safety net

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

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.

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.

Sources

1. NPCI, PSP and TPAP roles; PIN handling and common library. Razorpay; Google Pay / NPCI.
2. UPI message flow (ReqPay debit then credit; deemed result code; PSP notification). NPCI UPI Procedural Guidelines / Product Booklet.
3. Technical vs business decline, definitions and targets. NPCI OC-149.
4. Failed-transaction auto-reversal and penalty timeline. RBI TAT circular, 2019.
5. UPI as the world’s largest real-time payment system. PIB / IMF; ACI Worldwide.
6. Beneficiary-bank concentration and merchant escrow. The Economic Times.
7. Sponsor banks, @handle suffixes, and the on-us efficiency. The Painted Stork.
8. super.money’s growth. Business Standard.
9. Deemed transactions, status checks, UDIR reconciliation, and polling-driven outages. Razorpay (UDIR); Inc42 (NPCI outage guidance, 2025).
10. Transaction, app, bank and decline figures. NPCI ecosystem statistics, processed by Time Series of India.