7.8
深览指数
科技Bestblogs·Hacker News··AI 生成
UPI：一笔交易的剖析
本文以一笔支付从扫码到入账的完整流程为线索，逐层拆解了背后七个参与方的角色与交互机制。核心发现包括：支付应用极度集中于PhonePe和Google Pay；因商户发起机制，收款银行（Yes Bank）与付款银行（SBI）呈显著不对称；技术性拒付率已降至极低，但业务性拒付（如PIN错误、余额不足）占比上升，成为失败主因。文章引用了大量NPCI文档、央行通知和交易数据，适合对金融基础设施或支付系统设计感兴趣的读者，尤其适合产品经理和金融科技从业者。原文 ↗
核心观点
- ▍一笔UPI交易涉及七个不同参与方，但用户只看到应用界面；资金从不经由应用流转，真正的清算由发起银行、NPCI和收款方银行完成。
- ▍UPI支付流程遵循“先扣款、后入账”的顺序，NPCI交换机先确认从付款银行扣款成功，再贷记受益人银行，这保证了交易的最终性，但也产生了待处理交易的风险。
- 01支付应用高度集中，PhonePe和Google Pay合计占据UPI交易量的绝大部分份额。
- 02最大的收款银行是Yes Bank，而非最大的付款银行SBI，这是因为商户发起制度下，Yes Bank为大型聚合商生成了大部分商户UPI码。
- 03技术性拒付率已大幅下降至低于1/400，但业务性拒付率（如PIN错误、余额不足、达到限额）上升，目前约占1/11的付款失败。
- 04系统内置了安全网：通过状态查询接口和NPCI后台自动对账，处理“待处理”交易；若资金无法送达，系统会在一天内逆转交易并对延迟处以罚款。
- 05UPI的交易模式正在从个人对个人（P2P）向商户支付（P2M）转变，这改变了参与方的角色和风险分布。
反方 / 局限
- — 尽管系统设计有对账和安全网，但“待处理”交易的存在意味着支付瞬间的成功率并非100%，用户仍可能面临资金短暂冻结的不确定性。
- — 文章主要聚焦于技术流程和交易数据，对UPI系统的监管风险、数据隐私争议以及支付宝/微信支付等非UPI体系的对比分析较少涉及。
3 分钟 · 4 卡片 · 9 资料
读原文 →