当付款失败时,Dodo Payments 会通过标准化的
error_code 和人类可读的 error_message 告诉您失败原因。此指南展示如何读取这些字段、决定是否值得重试,并在不向客户暴露敏感信息的情况下恢复付款。Dodo Payments 如何报告失败
每个失败的支付——无论是一次性结账还是订阅续订——都会在支付对象上携带相同的失败字段:error_code 和 error_message 在付款实际失败之前是 null。始终先检查 status,然后读取错误字段。payment.failed Webhook
检测失败的最可靠方法是 payment.failed webhook。事件在 data 中封装完整的支付对象:
payment.failed payload
error_code 并基于它进行路由:
决定是否重试:软拒绝 vs. 硬拒绝
error_code 告诉您重试相同的支付方式是否值得。
Transaction Failures 参考列出了每个
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
模拟拒绝和续订失败的测试卡。