当付款失败时,Dodo Payments 会通过标准化的
error_code 和人类可读的 error_message 告诉您失败原因。此指南展示如何读取这些字段、决定是否值得重试,并在不向客户暴露敏感信息的情况下恢复付款。Dodo Payments 如何报告失败
每个失败的支付——无论是一次性结账还是订阅续订——都会在支付对象上携带相同的失败字段:| 字段 | 类型 | 描述 |
|---|---|---|
status | string | 用于失败支付的 failed。其他非成功状态包括 cancelled、requires_customer_action 和 requires_payment_method。 |
error_code | string | null | 标准化的失败原因,例如 INSUFFICIENT_FUNDS 或 PROCESSING_ERROR。请参阅 Transaction Failures 参考获取完整列表。 |
error_message | string | null | 人类可读的失败解释。 |
retry_attempt | integer | 原始收费的 0。1 或更高标识计划的订阅续订重试。 |
error_code 和 error_message 在付款实际失败之前是 null。始终先检查 status,然后读取错误字段。payment.failed Webhook
检测失败的最可靠方法是 payment.failed webhook。事件在 data 中封装完整的支付对象:
payment.failed payload
error_code 并基于它进行路由:
决定是否重试:软拒绝 vs. 硬拒绝
error_code 告诉您重试相同的支付方式是否值得。
| 拒绝类型 | 意味着什么 | 该怎么办 |
|---|---|---|
| 软拒绝 | 临时或可纠正的(例如 INSUFFICIENT_FUNDS、PROCESSING_ERROR、NETWORK_ERROR、TRY_AGAIN_LATER)。 | 重试——延迟后,或客户修复输入后——可以成功。 |
| 硬拒绝 | 终端(例如 STOLEN_CARD、LOST_CARD、DO_NOT_HONOR、FRAUDULENT)。 | 不要重试同一张卡。请客户提供不同的支付方式。 |
error_code 的拒绝类型和建议操作。
处理结账与续订失败
您的恢复方式取决于客户是否在场。- At checkout (customer present)
- On subscription renewal (customer not present)
客户正在积极结账。显示清晰的消息并让他们立即重试或使用其他卡。
requires_payment_method— 客户未提供支付方式:他们未输入卡片详情,或受到提示未采取行动。这通常是结账放弃,而不是拒绝——重新接触客户完成付款(参见 Abandoned Cart Recovery)。requires_customer_action— 需要额外验证(如 3DS);让客户完成验证。参见 3D Secure handling。
重试失败的付款
- 订阅: 启用 Subscription Payment Retries 来恢复软拒绝,且无需集成工作。您还可以通过让客户通过 Update Payment Method API 更新他们的支付方式来触发恢复,该方法将收取所有未缴款项。
- 一次性付款: 重新发送结账或
payment_link,以便客户可以使用不同的方法重试。对于一次性付款,没有自动重试。
安全地向客户展示错误
向客户显示友好的消息——永远不要显示原始error_code。
Customer-facing messaging
相关
Transaction Failures
每个拒绝代码、其类型和建议的操作。
Error Codes
不是卡片拒绝的 API 和业务逻辑错误。
Subscription Payment Retries
订阅续订时软拒绝的自动恢复。
Subscription Dunning
恢复硬拒绝的电子邮件序列。
Payment Webhooks
支付事件的完整负载模式。
Testing Failures
模拟拒绝和续订失败的测试卡。