UPI:支付交易剖析
UPI: Anatomy of a Payment Transaction

原始链接: https://timeseriesofindia.com/economy/reads/upi-architecture/

UPI 支付虽然看似瞬间完成,但其熟悉的流程——扫码、输入金额、输入密码、勾选及振动提示——背后依赖着一个由七个不同实体组成的复杂且隐形的传输过程。 该流程始于**支付应用**(如 Google Pay、PhonePe),它作为前端界面,负责收集您的支付意向和加密后的密码。由于无法直接连接网络,它需要依靠**发起行**(即您的 UPI ID 对应的银行)来路由交易。 所有环节最终汇集在 **NPCI 的中央交换系统**,它充当了整个系统的枢纽。为了确保安全,它强制执行严格的“先扣款、后入账”顺序。资金从不由支付应用持有,而是直接在付款方和收款方的银行之间划转。 尽管该系统处理着数十亿笔交易,但错误仍分为“业务拒绝”(如密码错误、余额不足)和“技术拒绝”两类。系统的可靠性随时间推移已显著提高,目前技术性故障已十分罕见。即使支付状态显示为“处理中”,自动对账协议也能确保资金最终得到确认或退回,若银行未能及时解决延迟,将面临严格的监管处罚。

```Hacker News新 | 往期 | 评论 | 提问 | 展示 | 招聘 | 提交登录UPI:支付交易剖析 (timeseriesofindia.com)18点 由 prtk25 2小时前 | 隐藏 | 往期 | 收藏 | 3条评论 帮助 jesuswasjew 12分钟前 | 下一条 [–] 中心化、经过KYC实名认证的私有货币交易网络。这算好事吗?回复 pzmarzly 38分钟前 | 上一条 [–] 每年220亿笔交易意味着NPCI交换平台的平均每秒查询率(QPS)约为700。当然,流量并不均匀,峰值可能是这个数字的许多倍,但这听起来并不算太差——作为对比,我在谷歌上快速搜索了一下,纳斯达克TotalView ITCH数据源在开盘时的峰值超过10万QPS。回复 repeek 21分钟前 | 父评论 [–] 那是2026年6月单月的220亿笔,换算成年约为2640亿笔。回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 加入YC | 联系 搜索: ```
相关文章

原文
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

NPCIthe switch

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 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.

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.

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 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.

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

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

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.

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.

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.

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

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.

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

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

the relayappsponsorhubbanks
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.

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.
联系我们 contact @ memedata.com