概要
支払いの試行が失敗すると、Dodo Payments は理由を示す標準化された失敗コードを返します。コードは支払い方法や決済処理業者にかかわらず同じなので、1 セットの処理ルールですべての失敗した支払いに対応できます。payment.failed webhook と payment object では、失敗した支払いについて次のフィールドを確認できます。
error_code: 下の表に記載されている標準化された失敗コード。error_message: あなた（merchant）向けに書かれた説明。error_codeが下記の標準化コードのいずれかである場合、これは見出しと推奨アクションであり、決済処理業者から返された生のテキストではありません。retry_attempt: 元の請求では0、スケジュールされたサブスクリプション更新の各再試行では1以上。サブスクリプション更新以外の支払いでは、値は0のままです。
マーチャント向けの文言と顧客向けの文言
各標準化された失敗コードには、あなた向けと顧客向けの 2 つのメッセージが対応します。Customer Portal は
error_message に顧客向けの文言を返し、merchant API は同じ支払いについて merchant 向けの文言を返します。error_code はどちらも同じです。Handle Payment Failures
webhook と API からこれらのコードを読み取り、顧客に表示し、再試行するタイミングを判断するための、開発者向けステップバイステップガイドです。
ソフトディクラインとハードディクライン
各失敗コードは、ソフトディクラインまたはハードディクラインのいずれかです。この種類によって、同じ支払い情報で後から再試行すれば成功する可能性があるか、または顧客が先に対応する必要があるかが分かります。
サブスクリプション更新では、Dodo Payments がこの分類を自動的に適用します。Subscription Payment Retries はソフトディクラインを再試行します。ハードディクラインが発生すると再試行チェーンは直ちに終了します。Subscription Dunning で回収してください。
取引の失敗理由
次の表には、すべての失敗コードについて、ディクラインの種類、顧客が解決できるかどうか、説明、推奨アクションを記載しています。User Error は、顧客がディクラインを解決できるかどうかを示します。
Yes は、正しいカード情報を入力するなど、顧客が問題を解決できることを意味します。No は、システムレベルの問題または銀行の制限が原因でディクラインが発生しており、顧客が直接解決できないことを意味します。発行銀行は、加盟店や取引の詳細に関係なく、独自のリスクエンジンによってカード保有者が高リスクと判定された場合にも、カードを拒否することがあります。このような拒否は通常、
DO_NOT_HONOR、GENERIC_DECLINE、CARD_DECLINED、TRANSACTION_NOT_APPROVED、または FRAUDULENT のような汎用コードとして表示されます。銀行は具体的な理由を共有しないため、Dodo Paymentsも加盟店もこの判断を覆すことはできません。問題のフラグを解消するために顧客から銀行へ連絡してもらうか、別のカードまたは支払い方法を使用してもらってください。プログラムでの失敗処理
payment.failed webhook または payment object から error_code を読み取り、表の推奨アクションに対応付けて、再試行するかどうかを判断します。サブスクリプション更新では、Dodo Payments がソフトディクラインを代わりに再試行します。Subscription Payment Retries を参照してください。
カードのディクラインではない API およびビジネスロジックのエラー（PAYMENT_NOT_SUCCEEDED や REFUND_WINDOW_EXPIRED など）については、Error Codes リファレンスを参照してください。
関連情報
Handle Payment Failures
失敗した決済の検出、表示、再試行をエンドツーエンドで解説するガイドです。
Error Codes
ディクライン以外の失敗に関する API およびビジネスロジックのエラーコードです。
Subscription Payment Retries
サブスクリプション更新時のソフトディクラインを回復する自動再試行です。
Subscription Dunning
決済手段の更新を促してハードディクラインを回復するメールシーケンスです。