概述
每当支付尝试未成功时，Dodo Payments 都会返回详细的失败原因。这些原因在不同的支付方式和提供商之间是标准化的，因此您可以在应用程序中实现一致的处理逻辑。 当支付失败时，payment.failed webhook 和 payment object 会提供以下信息：
error_code— 下表中的标准化失败原因。error_message— 面向您（商户）编写的易读说明。当error_code是下列标准化代码之一时，这里显示的是标题加建议操作，而不是支付处理商返回的原始文本。retry_attempt— 对于原始扣款为0，对于每次计划中的订阅续费重试为1或更高。
商户文案与客户文案
每个标准化失败代码都对应两条不同的消息，以便向正确的受众展示适当详细程度的信息：Customer Portal 在
error_message 中返回面向客户的措辞，而 merchant API 会针对同一笔付款返回面向商户的措辞。两者中的 error_code 完全相同。Handle Payment Failures
一份分步开发者指南，介绍如何从 webhooks 和 API 中读取这些代码、将其展示给客户，以及决定何时重试。
软拒绝与硬拒绝
每个失败代码都属于两类之一。这一区分决定了您应重试相同的支付方式，还是要求客户更换支付方式。
对于订阅续费，Dodo Payments 会自动应用这一规则：软拒绝由 Subscription Payment Retries 重新尝试，而硬拒绝会立即结束重试链，最好通过 Subscription Dunning 进行处理。
交易失败原因
下表列出了每个失败代码、其拒绝类型、客户是否可以解决、描述以及建议操作。用户错误表示付款拒绝是否可以由客户解决。当
Yes 时，客户可以采取措施修复问题（例如输入正确的卡片详细信息）。当 No 时，拒绝源于系统级问题或银行限制，客户无法直接解决。当发卡银行自身的风险引擎将持卡人标记为高风险客户时，即使与商户或交易详细信息无关，卡片也可能被拒绝。这类拒绝通常会显示为通用代码，例如
DO_NOT_HONOR、GENERIC_DECLINE、CARD_DECLINED、TRANSACTION_NOT_APPROVED 或 FRAUDULENT。在这些情况下，银行不会分享具体原因，Dodo Payments 和商户也无法推翻该决定。请客户联系其银行解决这一标记，或使用其他卡片或支付方式。以编程方式处理失败
从payment.failed webhook 或 payment object 中读取 error_code，将其映射到上面的建议操作，并决定是否重试。对于订阅续费，软拒绝会自动为您重试——请参阅 Subscription Payment Retries。
对于 API 层和业务逻辑错误（例如 PAYMENT_NOT_SUCCEEDED 或 REFUND_WINDOW_EXPIRED），这些错误并非卡片拒绝，请参阅 错误代码 参考。
相关内容
Handle Payment Failures
检测、展示和重试失败付款的端到端指南。
Error Codes
适用于非拒绝类失败的 API 和业务逻辑错误代码。
Subscription Payment Retries
在订阅续费时自动重试并恢复软拒绝的机制。
Subscription Dunning
通过提示更新支付方式来恢复硬拒绝的邮件序列。