PhonePe 商户接入指南：UPI 收款与自动扣款

PhonePe 商户接入指南：UPI 收款与自动扣款

把印度的支付接入想成"再接一个卡通道"，是这类项目最常见的起点，也是最容易返工的起点。印度的支付流量高度集中于 UPI（统一支付接口），而 UPI 的技术形态与卡几乎没有任何共同点：没有卡号，没有有效期，没有 CVV，收款依靠的是一串虚拟支付地址。你原来为卡设计的那套表单、校验与重试逻辑，在这里大部分都用不上。

这篇文章以 PhonePe 为主线，讲清 UPI 收款与自动扣款的接入取舍。PhonePe 是印度基于 UPI 的支付平台，同时提供商户收单服务。印度市场的整体结构可以先读 印度支付指南。

一、平台定位：基于 UPI 的支付平台与收单方，不是卡收单通道

1.1 没有卡号，收款标识是虚拟支付地址

UPI 的收款标识是虚拟支付地址（VPA），形如一个与手机号或账户绑定的别名。买家付款时不需要输入卡号，而是通过扫码、输入 VPA 或者在支付应用里选择收款方来完成。商户侧拿到的不是卡号，而是一个可以用于发起收款请求的标识。这意味着任何依赖卡号存储、卡 BIN 识别、卡类型判断的逻辑都必须重写。

VPA 的另一个特点是它与用户身份绑定得更直接，一个用户可能有多个 VPA，对应不同的银行账户。对账时你不能假设同一个用户在每次付款时使用的是同一个标识，这直接影响用户归因与退款定位。

对工程团队来说，最需要转变的观念是：UPI 收款的成功不取决于一次请求的返回，而取决于用户在其支付应用里的确认动作。这个动作可能立即发生，也可能延迟，还可能被用户放弃。

1.2 它不是什么

第一，它不是卡收单通道。没有卡号，没有授权请款两段式，拒付与举证的概念在这里不适用。

第二，它不是同步支付。除少数场景外，UPI 的结果需要用户在其支付应用内确认，结果通过回调与查询获得。

第三，它不是一套统一的用户体验。不同支付应用（包括 PhonePe 与其他 UPI 应用）在界面与交互细节上有差异，商户无法完全控制用户在确认环节看到什么。

第四，它不能替你做订阅设计。订阅依赖 e-mandate 授权，与卡基的存卡代扣是两套完全不同的机制。

二、准入与主体要求

2.1 商户主体、虚拟支付地址与业务说明

UPI 收单的准入，核心是商户主体与收款标识的配置。商户需要以自己的主体身份接入，绑定用于收款的账户，并在支付平台上完成商户资料与业务说明的提交。收款标识一侧，商户可以获得用于收款的 VPA 或商户标识，买家据此完成付款。

材料准备上，业务说明的重要性不低于主体文件。审核方需要判断你在卖什么、卖给谁、退款政策是否清楚。由于 UPI 场景下用户往往在支付应用内完成确认，商户页面对业务的说明清晰度会直接影响用户是否愿意继续付款。

另一个容易被忽略的点是收款账户与结算账户的关系。收款进入哪个账户、结算到哪个账户、两者是否需要一致，这些必须在接入前确认，并在账户变更时走流程，而不是直接改配置。

2.2 结算、税务与合规

印度的结算与合规有自己的节奏与要求。商户需要关注结算周期、结算报表的字段，以及税务与发票的义务。UPI 的交易凭据与卡不同，对账必须以支付平台提供的交易记录与结算报表为准。

对跨境团队来说，还需要关注主体与资金跨境的限制。收款成功之后的资金路径、是否可以跨境划转、需要哪些材料，这些问题的答案取决于你的主体结构与当地规则，必须以当前官方要求与合同为准。合规与许可的整体框架可以参考 支付合规与许可备案指南。

三、接入方式与账户结构

3.1 发起式与收集式两种流程

UPI 收款有两种典型流程。发起式是用户主动发起：用户扫码或者输入商户的 VPA，在自己的支付应用里确认金额并完成付款。收集式是商户主动发起：商户向用户的 VPA 发起一个收款请求，用户在其支付应用里看到这个请求并确认。

两者的差别不只是方向。发起式的用户心智是"我要付钱给这个商户"，主动权在用户；收集式的用户心智是"有人向我收款"，用户需要判断这个请求是否可信。这直接影响转化与失败率，也影响你在页面上如何引导。

工程实现上，收集式需要你先拿到用户的 VPA，这通常发生在用户首次填写或者授权之后；发起式则只需要展示商户的收款标识。选择哪种流程，取决于你的场景是网页结账、应用内支付还是线下扫码。

3.2 回调、状态机与两种流程的超时语义

服务端要处理的核心是状态机。UPI 的结果既可能通过回调抵达，也可能需要主动查询。发起式的超时通常意味着用户没有完成确认，订单应进入失败或可重试状态；收集式的超时语义不同，用户可能根本没有看到请求，或者看到了但没有处理，此时直接把订单判失败并不合适，需要区分"未送达"与"已送达未确认"。

因此状态机里至少要区分：已创建、已送达、待用户确认、成功、失败、超时、已取消。把这几个状态混成一个"处理中"，后续的客服、重试与对账都会失控。交易流程的整体设计可以参考 支付交易流程基础。

四、核心能力与覆盖市场

4.1 UPI 两种流程的交互方式、超时语义与适用场景

把两种流程放在一张表里对比，是设计接入方案最有效的起点。差别体现在交互方式、超时与失败语义以及适用场景三个维度。

这张表的用法是，先确定你的场景属于主动支付还是被动收款，再决定状态机里需要哪些状态。不要用一套流程覆盖所有场景。分地区的本地方式差异可以对照 分地区本地支付方式指南。

4.2 订阅与 e-mandate 自动扣款

UPI 生态里的订阅依赖 e-mandate，也就是用户授权商户在未来按约定规则自动扣款。它的核心是一次授权、后续按规则扣款，与卡基的存卡代扣在授权对象、扣款触发方式与用户可见性上都不同。

这意味着订阅系统不能在卡基方案上简单改个参数。你需要处理授权建立、授权状态、每次扣款前的通知与用户可见性、扣款失败后的重试策略。授权被撤销或额度不足时的处理路径，也要与卡基订阅分开设计。订阅计费的接口设计可以参考 订阅计费接口集成指南，失败挽回的策略可以参考 订阅催收与失败挽回指南。

五、费用结构与真实成本

5.1 费用构成项

具体费率与适用条件以官方当前报价与监管规则为准。任何文章里出现的百分比都会过期，用旧数字做预算是最容易犯的一类错误。

5.2 真实成本与成功率的关系

UPI 场景下，真实成本与成功率的耦合比卡场景更紧。因为用户的确认动作发生在支付应用内，任何引导不当都会直接变成失败，而失败的成本不只是手续费，还包括客服成本、订单流失与重试带来的额外调用。

因此优化顺序应该是先成功率、后费率。成功率侧的常见抓手是：结账页清晰说明收款方与金额、收集式请求给出明确的确认指引、超时后提供合理的重试路径。成功率优化的整体方法可以参考 支付成功率优化指南。

六、与其他方案的分工

6.1 与印度收单平台的分工

在印度，很多团队会选择收单平台而不是直接对接单一支付应用，原因是收单平台能同时聚合多个 UPI 应用与卡通道，降低接入数量。以收单平台视角看 UPI 的接入方式，可以参考 Razorpay 与 Razorpay 使用指南，以及以钱包与 UPI 起家的 Paytm。

分工的判断依据是控制力与成本。直接对接支付应用，你能拿到更细的渠道数据与更直接的沟通；用收单平台，你能用更少的接口覆盖更多渠道，但多了一层。不要在同一个场景里同时接两套重叠方案，对账会立刻变成负担。

6.2 与卡收单和订阅计费方案的分工

卡在印度仍然有用，尤其是在跨境、企业采购与部分高客单场景。全球收单平台在卡通道与接口一致性上更成熟，例如 Adyen 与 Stripe。但它们的 UPI 深度通常依赖合作通道，方式清单够用，细节体验不一定比本地平台好。

订阅类业务需要单独评估：UPI 的 e-mandate 与卡的存卡代扣是两套机制，如果你的订阅系统已经围绕卡设计，接入 UPI 订阅相当于再做一套授权与扣款流程。更现实的做法是把订阅层抽象成统一接口，底层适配不同的授权机制。

七、适合与不适合的团队

7.1 适合的团队

第一类：印度是主要目标市场、买家以本地消费者为主、订单频次高的团队。UPI 覆盖几乎等于触达能力。

第二类：有订阅或复购业务、愿意投入 e-mandate 授权体系的团队。印度的订阅场景绕不开 UPI 授权。

第三类：愿意重写支付前端的团队。卡号表单的那套逻辑在 UPI 场景里基本作废，前端需要按 VPA 与二维码重新设计。

7.2 不适合的团队

第一类：印度只是试水市场、订单量很小、主要买家在境外的团队。直接对接的成本摊不薄，先用能聚合的方案跑一段时间更合理。

第二类：希望把卡基支付系统原样搬到印度的团队。UPI 的形态与卡差异太大，改造量通常被严重低估。

第三类：把订阅当成"改个参数"的团队。e-mandate 的授权、通知与扣款失败处理都需要独立设计。

第四类：完全没有服务端工程能力、只想配置上线的团队。UPI 的两种流程与状态机躲不掉。

八、落地要点与误解澄清

8.1 落地要点

8.2 常见误解澄清

第一个误解是把 UPI 收款当成扫码即到账。收集式有明确的超时与用户侧确认环节，用户没确认就不会成功，不是扫完就到账。

第二个误解是以为订阅可以照搬卡基存卡方案。e-mandate 是授权体系，与存卡代扣在授权对象、触发方式与用户可见性上都不同，需要重新设计。

第三个误解是把 VPA 当成用户唯一标识。一个用户可能有多个 VPA，用它做用户主键会在归因与退款时出错。

第四个误解是用卡的对账凭据去对 UPI 的账。两者的凭据、字段与粒度都不同，必须以支付平台提供的交易与结算记录为准。

如果你正在做印度市场的支付接入，可以把这篇文章当作一张检查表：先确定你的场景用发起式还是收集式，再确定状态机需要哪些状态，最后把订阅授权与退款流程单独设计一遍。区域层面的整体判断，可以回到 支付 分类页继续看。

来源：16IDC 原创，文中涉及的产品能力、费率与准入要求以相关服务商官网文档及合同为准。