UPI：一笔支付交易的解剖

每天我们中的大多数人都会以同样的方式完成多次支付。你将手机对准一张打印的二维码，核对出现的姓名，输入金额，按下 PIN，然后一个绿色勾号表示交易完成。另一端，有人手机震动提示款项已到。从开始到结束，只需两到三秒。

这五个时刻——扫描、姓名与金额、PIN、勾号，以及另一端的震动——就是你所看见的全部支付过程。其余一切都被隐藏起来。在扫描与勾号之间，你的指令会经过一连串独立的机构，每一方检查一项内容并将结果传递给下一方，所有步骤在你抬头之前完成。你手机上的应用只是第一环，它从未触碰你的资金。

值得了解这安静交接背后承载的规模。仅在2026 年 6 月，UPI 就处理了超过2,272 亿笔支付，超过全球任何其他实时支付系统。5

本文将填补扫描与绿色勾号之间的空白。我们将沿着链路追踪一笔支付，一次经过一方：谁交给谁，每一方检查什么，以及哪里可能出错。在每个节点，我们也会审视该环节如何演变。下图展示全部参与方，我们从最上方开始，也就是你手中持有的部分。

应用

第一环是你已经熟悉的部分：应用。PhonePe、Google Pay、Paytm 或其他十几种应用。很容易将应用误认为支付系统本身，但它的实际职责很窄。在系统自身的语言中，它是第三方应用提供商（Third-Party Application Provider）：它收集你的意图——支付给此人、此金额——向你显示即将支付的对象，并通过一个它无法读取的安全键盘收集你的 PIN。随后它将指令传递出去。它从不看到你的 PIN，不持有你的资金，也没有银行牌照。1

这个薄薄的层级是 UPI 竞争最激烈的地方，而竞争极度不均衡。两款应用PhonePe和Google Pay合计占据约五分之四的 UPI 支付量；其余由其他应用瓜分。10 这种双寡头格局已持续多年。变化的是其下的排序。

观察多年来的排名。2024 年由 Flipkart 推出的新应用super.money，从前五十名之外在约一年内爬升至前五名，靠着保证返现吸引用户。810 顶部的两款应用几乎没有移动；它们下方的层级却从未停止重排。

尽管存在这些竞争，但有一件事这些应用都无法自行完成：接入支付网络。为此，它们必须依托于一家银行。

赞助方

由于应用没有牌照，也没有直接连接支付网络的线路，它必须从合作银行借用这两者，该银行被称为支付服务提供商（Payment Service Provider），即PSP，其赞助方。赞助方完成应用无法做到的事：连接中央系统，发行代表你的 UPI 地址，并在你设置 UPI 时首先将你的手机与银行账户绑定。1

这个地址比表面更具揭示性。UPI ID 后缀，即 @ 之后的部分，命名的是赞助银行，而非你使用的应用。结尾为@ybl的地址位于 Yes Bank；结尾为@okaxis的地址位于 Axis。PhonePe 的句柄运行于 Yes Bank、Axis 和 ICICI；Google Pay 的运行于 Axis、HDFC、ICICI 和 State Bank。7

如今大多数大型应用同时依托多家赞助银行而非一家，主要为了韧性：分散在多家银行中，单一银行的故障不会使整个应用离线，且没有单一赞助方需要承担全部应用量。7 赞助银行自身也能获得更安静的收益。当付款人与收款人恰好位于同一赞助方时，该银行可在自己的账簿中解析两个地址并跳过网络的中央目录——更快，且节省约一分钱的解析费用。7

因此，从你手机实际离开的不是资金，而是由应用组装并由你的赞助银行签名的请求。你看到的五个时刻中有三个发生在这里：扫描、姓名与金额，以及你的 PIN。姓名是网络确认持有你所扫描地址的人，这是你在资金移动前捕捉错误收款人的唯一机会。PIN 由手机上的认证组件捕获并加密；传递它的应用永远不会获知它。1

从这里开始，请求已完全离开你的手。此后的一切发生在银行与交换中心之间，并始于每笔支付都必须经过的唯一地点。

枢纽

无论从哪个应用或银行发起，每笔支付都会汇聚到一点：由NPCI运营的中央交换中心，该非营利机构负责运行 UPI；且只有这一家。它的首要任务是翻译。你要支付的地址属于收款人自己的赞助银行，因此交换中心将请求路由至该银行，该银行在资金移动前将句柄解析为真实账户。2

随后它转移资金，且顺序固定。交换中心首先要求你的银行借记你。你的银行是唯一能打开你手机上密封 PIN 的参与方，因此正是在这里，也只有在这里，你的 PIN 被检查：你的银行验证 PIN，确认余额，取出资金并回复。只有在借记确认后，交换中心才会要求收款人的银行贷记他们，并等待该确认。资金总是先离开，后到达，绝不反之。2

返回给你的结果并非由交换中心直接交付。NPCI 将结果返回给两家赞助银行，每家赞助银行再传递给其应用。你的赞助方向你的应用告知支付已完成，你看到绿色勾号；收款人的赞助方向收款人的应用告知，收款人手机显示款项已收到。2

交换中心本身几乎不公布自身工作的任何信息，因为没有可比较的对象。它只有一家。它的规模体现为它所承载的庞大总量。

然而，真正的资金移动发生在两端：借记付款人的银行和贷记收款人的银行。你可能会预期双方最繁忙的银行大致相同。

银行

它们并非相同的银行。将付款方最繁忙的银行与收款方最繁忙的银行分别排名，然后将每家银行在两侧的排名对应起来：排序并不一致。

在付款侧，排序符合预期。State Bank of India 以较大优势领先，其他大型零售银行紧随其后，与其客户数量大致相符。在收款侧，排序则完全不同。一家私营银行Yes Bank遥遥领先，其收到的入账支付份额在付款侧无任何银行能及，且该份额在两年内大致翻倍。610 同一家 Yes Bank 在付款侧却只是陪跑者：它几乎不发起支付，却接收了最多资金。

原因可追溯至赞助层，且始于 UPI 的演变。大多数 UPI 支付已不再是个人对个人支付，而是个人对商户支付。两条曲线在 2022 年交叉，此后差距持续扩大。10

商户的 UPI 码由赞助银行发行，与你的句柄相同。对于最大的商户应用，赞助方压倒性地是 Yes Bank。7 因此，当你在商店扫描 PhonePe 码时，贷记首先到达 Yes Bank，即码背后的银行，随后商户从商户应用的池化账户中获得支付。6 此处的“受益人银行”并不指商户自己的银行，而是指赞助该码的银行。

故障之处

没有系统能在如此规模下始终正常运行，而 UPI 的独特之处在于它如何精确记录失败时刻。每笔被拒绝的支付都被归入两个类别之一。3

第一类是业务拒绝：错误的 PIN、余额不足、达到每日限额。你在发生时立即理解这些，因为应用会告诉你原因，且原因在你这一侧。第二类是技术拒绝：链路中某处，银行系统或交换中心本身，某一步骤无法完成。这类故障表现为关于银行服务器的消息，“银行服务器宕机”或“你的银行服务器未响应，请重试”，而你的侧没有任何解释。3

多年来的两类对比呈现出清晰的分化。最近约每 11 笔支付中就有 1 笔被拒绝，但因轨道本身失败的不到 1/400。差距还在扩大。技术拒绝逐年下降，从超过 1/100 降至不足 1/400，因为银行与交换中心已加强加固。业务拒绝并未下降，反而上升。10

因此，轨道变得更可靠，而失败的支付越来越多地因与轨道无关的原因失败。日常故障并非机器失灵，而是机器执行自身规则。

这与故障所暗示的情况相反。UPI 曾全国性宕机数小时，这些日子真实且被铭记。9 但它们罕见。在普通的一天，一笔支付几乎从不因系统故障而失败。它失败是因为达到限额、余额过低，或输入了错误的单个数字。

此外还有第三种情况，既非干净成功，也非干净拒绝：系统本身无法立即判定的支付。

安全网

请记住，资金总是先离开，后到达。几乎总是，到达在同一时刻被确认，你根本不知道曾有间隔。但偶尔，确认未能及时返回。收款人的银行可能已贷记账户但未报告，或根本未贷记，在短时间内网络确实无法判断。处于该状态的支付有自己的名称：deemed，即贷记未确认。2 这是你的应用停在绿色勾号之前、显示“支付处理中”的时刻。你的资金已离开，但无人能确定它是否已到达。

系统正是为此而建。你的应用不会坐等猜测。大约 90 秒后，它可以悄然向网络查询真实状态，且仅允许少量此类查询，因为过度查询此问题的应用曾导致 UPI 宕机。9 你无需做任何事；查询由系统代劳。

在其后，NPCI 运行自己的对账。它持续查询两家银行，直到获得明确答案，并给出两种裁决之一：贷记已发生，因此支付成立；或未发生，因此借记被冲回。9

若必须冲回，时间不会留给善意。转账资金必须在一天内返回给你，商户支付则为几天，若银行迟延，每日罚款 100 卢比。4 系统无法始终保证即时正确完成支付，因此规则承诺事后纠正。

以这种方式卡住的支付从未常见，围绕它们的对账机制自此也已收紧。

这让我们回到起点：扫描、姓名与金额、PIN、绿色勾号，以及另一端手机的震动。这五个时刻仍是你所看见的全部。在这短短几秒背后，是七家独立的公司和银行，将消息沿线路传递并返回，每一步都进行检查，并由规则包裹，以至于即使失败，也以有利于你的方式失败。下一次勾号出现时，你将知道它付出了什么。

来源

1. NPCI，PSP 与 TPAP 角色；PIN 处理与公共库。Razorpay；Google Pay / NPCI。
2. UPI 消息流（ReqPay 先借记后贷记；deemed 结果码；PSP 通知）。NPCI UPI Procedural Guidelines / Product Booklet。
3. 技术与业务拒绝，定义与目标。NPCI OC-149。
4. 失败交易自动冲回与罚款时间线。RBI TAT circular, 2019。
5. UPI 作为全球最大实时支付系统。PIB / IMF；ACI Worldwide。
6. 受益人银行集中度与商户托管。The Economic Times。
7. 赞助银行、@handle 后缀以及 on-us 效率。The Painted Stork。
8. super.money 的增长。Business Standard。
9. Deemed 交易、状态检查、UDIR 对账以及轮询驱动的宕机。Razorpay (UDIR)；Inc42 (NPCI outage guidance, 2025)。
10. 交易、应用、银行与拒绝数据。NPCI 生态系统统计，由 Time Series of India 处理。