Razorpay 使用指南:印度市场的实体门槛与订阅实现
把印度市场当成"再接一个支付方式"来规划,是很多团队的第一反应,也是第一个错误。印度市场的准入问题本质上是实体问题:境外主体通常无法直接接本地收单平台,要么在当地设立实体,要么通过跨境聚合商间接接入。第二个难点藏在订阅里:印度的自动扣款渠道经历过多轮规则收紧,授权、首扣与重试三段的逻辑必须按渠道分别设计,照搬卡基订阅的实现方式几乎一定会出问题。这篇文章把这两件事拆开讲,并给出三条接入路径的对比与订阅实现的具体要点。
一、平台定位:印度本地收单
1.1 它解决的核心问题
印度市场的支付结构与成熟市场差别很大。UPI 在线上支付中占据主导位置,银行卡与网银仍然重要但已不是唯一入口,本地钱包在特定人群与场景里依然活跃。这意味着一个只接了国际卡组织的商户,在印度会丢掉相当一部分本来可以完成的订单。
本地收单平台的价值就建立在这里:它把 UPI、卡、网银与钱包这几类方式打包进同一套接口与账户结构,让商户不必分别对接。以印度市场为主战场的 Razorpay 就属于这一类,它覆盖上述主流方式,并提供订阅与拆单分账类的产品能力。
1.2 它不是什么
第一,它不是可以随意开户的通用网关。它的开户流程与主体要求是围绕印度本地主体设计的,这不是产品选择,而是当地准入结构的反映。
第二,它不是"UPI 等于一个按钮"的那种简化理解。UPI 的确认、失败原因、退款路径与卡完全不同,把它当成卡的变体处理,是接入后最先暴露的问题。
第三,它不是跨境收单平台。境外主体想在印度收款,往往需要走间接路径,这与直接用全球平台接卡是两种不同的组织方式。区域方式的整体格局可以先读 分地区本地支付方式指南。
二、准入与实体门槛
2.1 为什么境外主体接不进去
印度本地收单平台的准入,核心变量不是技术能力,而是主体。开户流程需要核验在当地注册的经营主体、本地银行账户、税务识别信息与业务实质材料。这套要求的目的很直接:确认收款方在当地是可追溯、可监管、可追责的。
境外主体在这个结构里处于错位位置。它可以证明自己是一家真实经营的公司,但很难证明自己在当地有可追溯的经营实质。这不是材料准备得够不够的问题,而是结构上不匹配。所以"能不能接进去"的答案,往往取决于"你有没有当地主体",而不是"你的网站做得好不好"。
这一点与拉美不同。拉美市场的本地收单方通常可以用自己的本地主体承接交易,让境外卖家间接参与;印度本地收单平台更多是服务于已经在当地落地的主体。两种结构的差别,直接决定了接入路径的选择。
2.2 三条接入路径的对比
既然直接接入通常要求本地实体,实际可选的路径就变成三条。下表把前置条件、适用团队与主要限制放在一起。
| 接入路径 | 前置条件 | 适用团队 | 主要限制 |
|---|---|---|---|
| 设立印度本地实体后直接接入 | 当地注册主体、本地银行账户、KYC 与税务识别材料 | 计划长期深耕印度市场、有稳定本地收入的团队 | 设立与维护周期长,合规与税务申报责任完全自持 |
| 通过跨境聚合商间接接入 | 境外主体通过聚合商的准入审核 | 市场验证阶段、印度量还不大的团队 | 本地方式覆盖可能不完整,结算路径更长,退款更慢 |
| 通过商户记录模式平台销售 | 通过平台侧审核,平台以自己名义销售 | 不愿承担本地开票与税务责任的团队 | 综合成本更高,定价控制更弱,用户关系被前置 |
| 与印度本地合作方联合运营 | 本地合作方主体与合作协议 | 有本地渠道或运营资源的团队 | 责任边界复杂,资金流与品牌分离,对账难度上升 |
这一列的取舍没有标准答案。判断依据应该是三件事:印度业务在你整体盘子里的权重、你能否承受主体维护的固定成本、以及你对定价与用户关系的控制要求。
主体与账户结构的通用设计方法可以参考 跨境卖家主体与账户结构指南,牌照与备案侧的合规要求可以参考 支付合规与牌照备案指南。
三、接入方式与账户结构
3.1 账户结构与 KYC
印度本地收单平台的账户结构,通常围绕一个已通过 KYC 的主体展开。子账户、多业务线、多门店的划分在平台内部实现,但底层主体只有一个。这对多业务线的团队意味着:不同产品线的交易会在同一主体下留痕,无法通过拆分子账户来隔离经营风险。
KYC 的深度也值得提前预期。除主体材料外,业务模式说明、产品页面、退款政策、客服渠道都会被核验。这些内容不是一次性的,主体信息、经营范围或业务模式发生实质变化时,通常需要重新提交。
所以接入前应该准备好两件事:一份能解释业务的材料包,以及一份"变化时谁负责更新"的内部约定。后者常被忽略,却是在跑起来之后最容易出问题的地方。
3.2 服务端要处理的三件事
不管接哪家收单服务商,服务端都要处理三件事:幂等、状态机与对账。
幂等意味着同一笔创建请求重复到达时不能产生两笔支付。UPI 类方式的回调可能重复投递,创建接口如果没有幂等键,很容易出现一单多付。设计方法可以参考 支付订单号与幂等设计指南。
状态机意味着创建、待支付、支付中、成功、失败、过期、退款中、已退款这些状态必须闭合。UPI 的确认速度通常较快,但失败原因分类比卡更细,状态机需要能承载这些细分原因,否则客服侧无法给出准确解释。
对账意味着订单记录要与结算报表逐笔对齐。印度场景下多了一层复杂度:订阅扣款与单笔支付会出现在同一张报表里,需要用统一标识区分,否则对账口径会一直混乱。
四、核心能力与覆盖市场
4.1 覆盖的方式类型
评估印度本地收单平台,不要问"支持多少种方式",而要问"在我目标客群实际用的方式里,支持了哪几种"。
UPI 是主力,覆盖它的深度决定了大部分订单能否完成。卡仍然重要,尤其在跨境客群与高客单场景;网银在特定人群与特定品类里份额可观;本地钱包在部分场景仍是有效补充。这几类方式的失败原因、退款路径与对账规则都不同,不能用同一套流程处理。
另外要留意成功率的结构差异。不同方式在不同客群上的表现差别很大,光看整体成功率会掩盖问题。成功率的分析方法可以参考 支付成功率优化指南。
4.2 订阅与自动扣款
订阅是印度市场最容易被低估的部分。很多团队以为"存了卡就能自动续费",实际完全不是这样。印度的自动扣款渠道经历过多轮规则收紧,规则变化影响的是授权、首扣与重试三个环节,而这三个环节的实现方式在不同渠道上并不一致。
所以订阅设计必须按渠道分别建模,而不是把卡基订阅的逻辑套一遍。下面这张表把关键要点、约束与设计建议拆开。
| 订阅实现要点 | 关键约束 | 设计建议 |
|---|---|---|
| 授权 | 自动扣款需要用户的显式授权,规则随渠道调整 | 授权与订单分开建模,单独记录授权状态、范围与有效期 |
| 首扣 | 部分渠道的首扣金额与授权金额规则不同 | 首扣单独设计校验环节,不要与后续重试共用逻辑 |
| 重试 | 失败原因分类不同,可重试与不可重试要区分 | 按渠道配置重试节奏与次数上限,超限后转人工处理 |
| 扣款前通知 | 部分渠道要求在扣款前向用户发送通知 | 把通知做成流程节点而非可选步骤,并记录发送结果 |
| 升降级与按比例计费 | 金额变化可能触发重新授权要求 | 变更前判断是否需要新授权,避免扣款被拒 |
| 对账与区分 | 订阅扣款与单笔支付出现在同一报表 | 用统一标识区分订阅扣款,避免对账口径混淆 |
订阅系统的方法论可以参考 订阅计费 API 集成指南,扣款失败后的挽回策略可以参考 订阅催收与挽回指南。
五、费用结构与真实成本
5.1 费用构成项
印度本地收单的费用是一组构成项,而不是一个数字。
| 费用构成项 | 说明 | 判断要点 |
|---|---|---|
| 交易处理费 | 按支付方式分别计价 | UPI、卡、网银与钱包的价格结构不同 |
| 订阅与自动扣款 | 与循环计费相关的处理 | 需与单笔交易分开核算 |
| 拆单分账 | 平台或市场类业务的分账处理 | 分账规则影响资金到账节奏 |
| 跨境与换汇 | 由结算币种与路径决定 | 境外主体走间接路径时更敏感 |
| 接入与维护 | 技术对接、对账与合规协同人力 | 常被低估但真实存在 |
具体费率与适用条件以官方当前报价与合同为准。任何文章里出现的百分比都会过期,用旧数字做预算是最常见的一类错误。
5.2 如何判断真实成本
横向比较费率数字是这一环节最容易犯的错。正确做法是构造一个与业务结构一致的交易组合:同样的方式占比、同样的客群、同样的金额区间,然后比较总成本与最终到账金额。
印度场景下有两个额外维度。
第一个是主体维护成本。如果选择设立本地实体,注册、记账、审计、税务申报与年度维护都是固定支出,这项成本不会体现在费率表里。第二个是订阅的隐性成本。授权失败、首扣失败与重试失败会直接变成流失,只看费率不看订阅留存率,结论一定是偏的。
如果走间接路径,还要把结算周期与汇率敞口纳入计算,因为路径变长意味着资金在途时间变长。这部分对现金流的影响往往比费率差异更大。
六、与其他方案的分工
6.1 与跨境聚合商的分工
跨境聚合商的价值是用一套接口覆盖多个新兴市场,适合市场验证阶段。在印度,它们的本地方式覆盖通常依赖合作通道,方式清单可能够用,但在成功率与退款体验上不一定比得上本地收单平台。
选择时应该问清楚:覆盖的是哪些方式、结算到哪里、退款怎么走、失败原因能否细分。这四件事决定了间接路径能不能真的跑起来。
6.2 与全球平台及本地同行的分工
全球收单平台的优势是接口成熟、文档完善、多币种支持标准化。它们更适合承接成熟市场的卡交易,在印度的本地方式深度通常不是强项。评估时可以同时看 Adyen 与 Stripe 的市场侧重与结算结构。
印度本地同行也各有侧重。如果业务涉及钱包或特定场景,可以看 Paytm、PhonePe 与 Payu 的产品定位。选择依据不是谁更大,而是谁在你目标客群的方式深度与结算路径更合适。
区域市场的整体格局可以参考 印度支付指南,它系统梳理了当地的主流方式与准入特点。
七、适合与不适合的团队
7.1 适合的团队
第一类:已经在印度落地主体、并计划长期经营的团队。这是本地收单平台最自然的服务对象,主体、银行账户与业务场景在同一法域内,接入路径最短。
第二类:订阅业务占比较高、需要按渠道精细化设计授权与重试的团队。本地平台在这类产品能力上的积累更深。
第三类:做平台或市场类业务、需要拆单分账能力的团队。分账规则与资金到账节奏紧密相关,本地化实现更贴合当地结算结构。
7.2 不适合的团队
第一类:没有印度主体、只是想做小规模市场验证的团队。直接接入通常走不通,应该先考虑间接路径或商户记录模式。
第二类:主要面向成熟市场销售、印度只是极小比例的团队。为极小比例的增量承担主体维护成本不划算。
第三类:对定价与用户关系有极强控制要求、又不愿承担本地税务与开票责任的团队。这两项要求在多数路径下是互斥的,需要先想清楚取哪一边。
第四类:把订阅理解成"存卡即可续费"的团队。在印度这条路径几乎一定失败,先补齐授权与重试的设计能力再谈上线。
八、落地要点与误解澄清
8.1 落地要点
| 落地要点 | 具体做法 |
|---|---|
| 先定路径再谈技术 | 主体路径决定接入方式,不要反过来 |
| 按渠道拆订阅逻辑 | 授权、首扣与重试分别建模,不共用一套流程 |
| 通知作为流程节点 | 扣款前通知要记录发送结果,而非可选步骤 |
| 对账区分订阅与单笔 | 用统一标识区分,避免口径混淆 |
| 支付层做薄 | 抽象订单、支付与退款状态,降低迁移成本 |
第一条最关键。很多团队先做技术选型,再回过头发现主体路径不成立,前面的设计全部要重做。路径问题必须在选型阶段解决。
8.2 常见误解澄清
第一个误解是以为可以像使用国际收单平台那样用境外主体直接接入。印度本地收单平台的准入是围绕本地主体设计的,境外主体在结构上不匹配,这不是材料问题。
第二个误解是以为订阅只要存卡就能自动续费。自动扣款渠道的规则变动频繁,授权、首扣与重试都需要按渠道单独设计。把卡基订阅的逻辑照搬过来,最常见的表现是首扣成功、第一次续费失败,然后大量流失。
第三个误解是以为拆单分账能替代资金合规架构。分账解决的是资金如何在不同主体之间分配,不解决谁有权收这笔钱、在哪个法域纳税的问题。
第四个误解是以为 UPI 只是一个支付按钮。UPI 的失败原因分类、退款路径与对账规则都与卡不同,把它当卡处理会让客服与财务同时陷入混乱。
| 常见误解 | 实际情况 |
|---|---|
| 境外主体可以直接接入本地收单平台 | 准入围绕本地主体设计,通常需要当地实体 |
| 存卡即可自动续费 | 授权、首扣与重试需按渠道分别设计与维护 |
| 拆单分账可替代合规架构 | 分账只解决资金分配,不解决资质与纳税 |
| UPI 只是另一个支付按钮 | 失败原因、退款与对账规则都与卡不同 |
更多收单与本地支付方案可以查看 支付 分类,按收单能力、本地方式与市场区域分别做了整理。
来源:16IDC 原创,文中涉及的产品能力、费率与准入要求以相关服务商官网文档及合同为准。