为什么印度的支付方式很重要
UPI Dominance
UPI 每月处理超过 200 亿笔交易,而且许多印度客户没有国际银行卡。
Low-Value Payments
UPI 接受最低 ₹5 的付款,适合高交易量、低金额的交易。
Subscription Support
与大多数替代支付方式不同,UPI 和印度发行的银行卡(包括 Visa、Mastercard 和 RuPay)可通过 RBI 授权指令支持定期付款。
支持的方式
下表列出了每种方式、是否支持订阅以及最低金额:
*订阅需要符合 RBI 要求的 mandates,并遵循特殊的处理规则。48 小时处理延迟适用于所有印度发行的银行卡和 UPI 的 recurring charges。
以 INR 计费的付款,无论是一次性付款还是订阅,金额都必须至少为 ₹5。
配置
API Method Types
在allowed_payment_method_types 中传入以下值:
示例:面向印度的 Checkout
此 session 向一位位于印度、以 INR 计费的客户提供 UPI 和银行卡:UPI 的要求
仅当以下所有条件均满足时,UPI 才会显示在 Checkout 中:- billing country 为印度(
IN)。 - billing currency 为 INR。
- 对于印度境外 merchant 的订阅,已启用 Adaptive Currency。如果产品以 INR 定价,一次性 Checkout 不需要启用该功能。
使用 RBI Mandates 的订阅
使用 UPI 或印度发行的银行卡支付的订阅基于 RBI(Reserve Bank of India)mandates,这些 mandates 会增加其他支付方式没有的规则。RBI Mandates 的工作方式
客户订阅时会授权一个 mandate。之后,每次续订扣款都会在预扣款通知后等待 48 小时,银行才会扣除资金:Mandate 类型
Mandate 类型取决于订阅金额与 mandate floor 的比较结果:
在客户银行登记的金额为
max(mandate_floor, billing_amount)。当计费金额低于该 floor 时,floor 就会成为面向客户的 authorization ceiling。
**Plan changes:**如果升级产生的扣款超过现有 mandate limit,扣款会失败,客户必须重新授权。
可配置的 Mandate Floor
使用mandate_min_amount_inr_paise 字段设置 INR e-mandates 的 mandate floor,单位为 INR paise(₹1 = 100 paise)。
你可以在以下三个级别覆盖系统默认值 ₹15,000:
Dodo Payments 使用第一个已设置的值:先使用 per-request override,然后是 merchant setting,最后是 system default。
要设置 floor,请在创建 Checkout session时,在 request body 中传入
mandate_min_amount_inr_paise。已弃用的 Create Subscription endpoint 也接受相同字段。
更高的 floor 允许你之后进行更大金额的一次性扣款,例如计划升级或基于用量的超额扣款,而无需客户重新授权。较低的 floor 会使客户的授权金额更接近实际计费金额,但也会减少未来可变扣款的空间。
48 小时处理延迟
印度银行卡或 UPI 的续订扣款会在续订日期约 48 小时后完成。这是它与国际银行卡付款最重要的区别:1
Charge Initiated (Day 0)
在预定的续订日期,Dodo Payments 会向银行发起扣款。
2
Pre-Debit Notification
客户的银行会通知客户即将发生扣款。
3
48-Hour Window
在此期间,客户可以在银行 app 中取消 mandate。
4
Debit Completed (~48-51 Hours)
48 小时后,银行还可能需要最多 3 小时进行处理,之后才会扣除资金。
5
Webhook Sent
Dodo Payments 会在实际扣款后,而不是在发起扣款时,发送
payment.succeeded webhook。处理 48 小时窗口
根据 payment webhook(而不是续订日期)授予访问权限:印度订阅的 Webhook 事件
为使用 UPI 或印度发行的银行卡支付的订阅处理以下事件:测试
UPI 测试 ID
在 test mode 中输入以下 UPI ID,以模拟各类结果:印度银行卡测试号码
使用以下印度发行的测试银行卡:最佳实践
Plan for the 48-hour delay
Plan for the 48-hour delay
构建应用时,应处理扣款发起与实际付款之间的时间差。请考虑:
- 订阅访问权限的宽限期
- 清晰地向客户说明处理时间
- 由 webhook 驱动的履约,而不是由日期驱动的履约
Handle mandate cancellations
Handle mandate cancellations
客户可以随时在银行 app 中取消 mandates。监控
subscription.on_hold webhooks,并提示客户重新订阅或更新 payment method。Set appropriate mandate amounts
Set appropriate mandate amounts
对于基于用量计费等可变定价,请检查 mandate floor 上的 on-demand mandate(默认为 ₹15,000)是否足以覆盖最大扣款。如果扣款金额可能超过该值,请通过
mandate_min_amount_inr_paise 提高 floor。否则,客户必须授权新的 mandate。Offer UPI prominently
Offer UPI prominently
对于印度客户,请将 UPI 设为主要支付选项。许多客户更偏好 UPI 而不是银行卡,因为他们更熟悉这种方式,操作阻力也更小。
故障排查
UPI not appearing at checkout
UPI not appearing at checkout
检查:
- billing country 是否设置为
IN? - billing currency 是否设置为
INR? - 如果你是印度境外的 merchant,是否已启用 Adaptive Currency?
upi_intent是否包含在allowed_payment_method_types中?
country: "IN",并设置 billing_currency: "INR"。如果已禁用 Adaptive Currency,API 会忽略 billing_currency,因此请改为使用 INR 为产品定价。Subscription charge failed after upgrade
Subscription charge failed after upgrade
**原因:**新的扣款金额超过了现有 mandate limit:即 mandate floor(默认为 ₹15,000),或订阅金额(如果订阅金额更高)。**解决方案:**客户必须更新 payment method,以使用正确的限额设置新的 mandate。
Subscription on hold but customer claims they didn't cancel
Subscription on hold but customer claims they didn't cancel
**原因:**客户可能在 48 小时窗口内取消了 mandate,或者其银行拒绝了扣款。**解决方案:**客户需要再次授权 mandate,或更新 payment method。
Payment deduction delayed beyond 48 hours
Payment deduction delayed beyond 48 hours
**原因:**银行 API 延迟可能使处理时间延长 2–3 小时。**解决方案:**这是预期行为。请构建系统以处理总计约 51 小时的延迟。
Mandate cancelled but subscription still active
Mandate cancelled but subscription still active
**原因:**RBI regulations 中存在一种边界情况:在处理窗口内取消 mandate 不会立即取消订阅。**解决方案:**下一次扣款会失败,订阅会变为
on_hold。监控 payment.failed webhooks。相关页面
Payment Methods Overview
查看所有支持的支付方式。
Subscriptions
完整的订阅文档,包括 RBI mandates。
Webhooks
支付事件的 webhook 处理。
Testing Process
所有测试数据,包括 UPI ID 和印度银行卡。