UPI支付交易结构解析

背景

UPI（Unified Payments Interface，统一支付接口）是印度国家支付公司（NPCI）运营的实时支付系统，自2016年推出以来迅速普及，已成为印度数字支付的基础设施。2026年6月，UPI单月处理超过227.2亿笔交易，超过全球任何其他实时支付系统。用户扫描二维码、输入金额和PIN码、看到绿色勾号确认支付成功，整个过程只需2-3秒。然而，这背后涉及七个参与方，用户只能看到其中一个——手机上的App。

核心内容

从扫描到勾号：一笔UPI支付的完整旅程

用户看到的支付流程只有五个瞬间：扫描二维码、确认姓名和金额、输入PIN码、出现绿色勾号、对方手机收到到账通知。其余所有环节都隐藏在屏幕之下。从扫描到勾号，用户的指令经过一系列独立组织，每个组织检查一件事情，然后将结果传递给下一个，所有这些都在用户移开视线之前完成。

第一站：App——支付入口，而非支付系统

用户使用的App（如PhonePe、Google Pay、Paytm等）在UPI体系中被称作“第三方应用提供商”（TPAP）。它的实际职责非常有限：收集用户意图（向谁支付、支付多少）、展示收款方姓名、通过安全键盘收集PIN码（App本身无法读取该PIN码），然后将指令传递下去。App从不接触用户的PIN码，不持有用户资金，也不持有银行牌照。

这正是UPI几乎所有竞争的战场，且竞争格局极不均衡。PhonePe和Google Pay两家App合计处理约80%的UPI交易，其余App瓜分剩下的20%。这一双寡头格局已持续多年，但排名下方的位置不断变动。例如，Flipkart在2024年推出的新App super.money，凭借保证返现，在约一年内从前50名之外攀升至前5名。

第二站：赞助银行——App的银行牌照与网络连接提供者

由于App没有银行牌照，也无法直接接入支付网络，它必须依靠一家合作银行作为“支付服务提供商”（PSP），即赞助银行。赞助银行负责连接到中央系统、为用户分配UPI地址，并在用户首次设置UPI时将手机与银行账户绑定。

UPI地址中的后缀（@之后的部分）揭示的是赞助银行，而非用户使用的App。例如，@ybl后缀代表Yes Bank，@okaxis代表Axis Bank。PhonePe的UPI地址运行在Yes Bank、Axis和ICICI上；Google Pay则运行在Axis、HDFC、ICICI和印度国家银行（SBI）上。

如今大多数大型App同时依赖多家赞助银行，主要是为了弹性：分散在多家银行，单一银行故障不会导致整个App离线，且没有一家赞助银行需要承担App的全部交易量。赞助银行自身也能获得一项隐性好处：当付款方和收款方恰好位于同一家赞助银行时，该银行可在自己的账簿内解析两个地址，跳过网络的中央目录，速度更快，同时节省约1派士（约0.01卢比）的解析费。

实际从用户手机离开的并不是资金，而是一个由App组装、由赞助银行签名的请求。用户看到的五个瞬间中有三个发生在此：扫描、姓名和金额、PIN码。姓名是网络确认所扫描地址的持有者，这是用户资金移动前捕捉错误收款方的唯一机会。PIN码由手机上的认证组件加密，App传递时永远不会得知其内容。

第三站：中央交换中心——NPCI的单一枢纽

每一笔支付，无论从哪个App或银行发起，都会汇聚到唯一的一个点：由NPCI运营的中央交换中心。NPCI是运营UPI的非营利组织。它的首要任务是翻译：用户支付的地址属于收款方的赞助银行，因此交换中心将请求路由到该银行，由该银行在资金移动前将手柄解析为真实账户。

然后交换中心移动资金，顺序是固定的：先要求付款方银行扣款。付款方银行是唯一能解封用户手机端加密PIN码的参与方，因此PIN码验证在此处进行——只有在付款方银行，PIN码才被检查。银行验证PIN码、确认余额、扣除资金并回复。只有当这笔扣款确认后，交换中心才要求收款方银行入账，并等待其确认。资金总是先离开再到达，顺序不可颠倒。

结果并非由交换中心直接返回给用户。NPCI将结果返回给两家赞助银行，每家赞助银行再传递给各自的App。用户方的赞助银行通知App支付成功，用户看到绿色勾号；收款方的赞助银行通知收款方App，其手机显示资金已到账。

交换中心几乎不公布自身的任何工作细节，因为它是唯一的，没有比较对象。其规模体现在它承载的绝对交易总量上。

第四站：银行——扣款方与入账方并非同一批银行

真正的资金移动发生在两端：扣款的付款方银行和入账的收款方银行。令人意外的是，忙碌的银行在两端并不相同。

在付款方一侧，银行排名符合预期：印度国家银行（SBI）遥遥领先，其他大型零售银行紧随其后，与它们的客户数量相匹配。但在收款方一侧，排名完全打乱：一家私有银行——Yes Bank——远远领先，其接收的付款份额是任何银行在付款侧无法接近的，而且该份额在两年内大约翻了一番。同样的Yes Bank在付款侧几乎不发起支付，却接收最多。

原因要追溯到赞助银行层面，且与UPI的演变有关。如今大多数UPI支付已不再是个人对个人（P2P），而是个人对商户（P2M）。这两条曲线在2022年交叉，此后差距不断扩大。

商户的UPI二维码由赞助银行发行，就像用户的UPI地址一样。对于最大的商户应用（如PhonePe的商户码），其赞助银行绝大多数是Yes Bank。因此，当用户在商店扫描PhonePe二维码时，资金首先进入Yes Bank（二维码背后的银行），然后商户从商户应用的池化账户中获得付款。“收款行”在此处并非指商户自身的银行，而是指赞助该二维码的银行。

哪里会出错

没有系统能在如此规模下每次都完美运行。UPI独特之处在于它精确记录了失败的次数。每笔被拒绝的支付都归入两个类别之一（原文未完整展开，但暗示了分类记录失败原因的方式）。

关键要点

• 用户可见的支付流程仅有五个瞬间：扫描、确认姓名金额、输入PIN、出现勾号、对方收到通知。其余所有环节（涉及七方）均隐蔽在后台。
• 手机App（TPAP）的职责仅限于收集用户意图并传递指令，它无法读取PIN码、不持有资金、不持有银行牌照。
• UPI竞争集中于App层，但存在牢固的双寡头格局：PhonePe和Google Pay合计占约80%交易量；排名下方的App持续重组，新玩家可通过返现策略快速上升。
• 赞助银行（PSP）是App与支付网络之间的桥梁：它们提供银行牌照、网络连接和UPI地址发行。UPI地址的@后缀揭示了赞助银行，而非用户使用的App。
• 大型App通常同时使用多家赞助银行以提升弹性，避免单一银行故障导致全App离线。
• 如果付款方和收款方位于同一赞助银行，该银行可在内部解析地址，跳过NPCI中央目录，速度更快且节省解析费。
• NPCI中央交换中心是所有支付流量的单一枢纽：它负责地址翻译、强制先扣款后入账的顺序（资金先离开再到达）。
• PIN码验证只发生在付款方银行，该银行是唯一能解封加密PIN码的参与方。
• 付款侧最忙碌的银行是印度国家银行（SBI）；收款侧最忙碌的银行是Yes Bank。这种错位源于大多数UPI支付已变为商户支付，而最大商户二维码的赞助银行主要是Yes Bank。
• UPI精确记录每一笔失败支付，并归入两类（原文未详述具体分类）。

意义与影响

• 支付基础设施的透明度与可理解性：UPI的架构清晰划分了App层、赞助银行层、中央交换层和结算银行层，每一层职责明确。解剖一笔交易有助于用户、开发者、企业理解自身在系统中的位置和风险。
• 竞争格局与垄断风险：App层的双寡头格局（PhonePe与Google Pay联合垄断