同じ「決済エラー」に見えても、対応がほぼ真逆になる 2 種類があるという事実は、国内ではまだ十分に共有されていません。
具体的には、ソフトディクライン（Soft Decline / 一時的なエラー） と ハードディクライン（Hard Decline / 永続的なエラー） の 2 つです。両者は同じ「Card Declined」というラベルで管理画面に並ぶことも多く、レスポンスコードを読み解かない限り見分けがつきません。本稿では、この 2 種類の違いと、Recovery Monitor の「決済エラー管理（Payment Error Management）」カテゴリでどのように扱うのかを整理します。
一律リトライ・一律通知が招く機会損失
多くの事業者様で、決済エラー後の運用は次のどちらかになりがちです。
- パターン A: 一律リトライ — エラー種別を問わず、決済代行会社のリトライ機能に任せて数回再課金する
- パターン B: 一律通知 — エラーが出たら「カード情報をご確認ください」というテンプレートメールを一斉送信する
どちらも一見すると合理的に見えますが、ハード/ソフトの区別がついていないと、次のような機会損失が同時に発生します。
- ソフトを捨ててしまう: 数日待てば通ったはずの取引を、早すぎる再課金で「永久にダメだったもの」として処理してしまう
- ハードを叩き続ける: 期限切れカードや無効カードに繰り返し再課金を試み、決済代行会社のリスクスコアを下げ、本来通るはずの取引にまで影響が及ぶ
- 顧客体験の劣化: 通る見込みのない取引に対して「カードをご確認ください」を何度も送り、関係性を消耗する
言い換えると、ハード/ソフトを仕分けないままの運用は、取り戻せる顧客様を取り逃がし、取り戻せない顧客様に労力を集中させてしまう 構造になっています。
ソフトディクラインの定義と主要原因
ソフトディクラインは、その瞬間の事情で課金が通らなかったが、状況が変われば通る可能性がある 一時的なエラーを指します。「再試行する価値がある」ことが本質です。
主要原因
- 残高不足・限度額の一時超過: 月初・年初・大型支出が重なる時期に多く、数日後には解消していることが珍しくありません。給料日サイクルとの相性も大きい領域です。
- ネットワーク一時障害: 国際カードブランドの認証ネットワークや、発行会社のオーソリ系統で短時間の障害が起きると、その時間帯の課金だけが通らないことがあります。
- 認証タイムアウト: 3D セキュア等の本人認証フローで、顧客様がパスワード入力を間に合わせられなかった、通信が切れた、といった事情で通らないケース。再案内で完了することが多い領域です。
- 与信枠の一時的な逼迫: ホテル予約・レンタカー予約などで保留金（オーソリ）が残っており、その期間だけ与信枠が一時的に逼迫しているケース。保留解除後には通ります。
- 不正検知ルールの一時ヒット: 普段と異なる IP、海外渡航中、深夜帯の課金など、リスクスコアが一時的に高めに出てブロックされるケース。状況が落ち着けば通ります。
ソフトディクラインの取引は、適切な時間差で再試行する か、顧客様に状況確認を案内して再認証してもらう ことで、相当な比率が回復します。海外調査では、リカバリー運用次第で 55〜70%（参考値） が再開可能とする報告もあります。
ハードディクラインの定義と主要原因
ハードディクラインは、カードや口座そのものの状態に起因し、再課金しても通らない見込みが高い 永続的なエラーを指します。「リトライではなく、別アクションが必要」というのが本質です。
主要原因
- 有効期限切れ: 登録カードの月年が過ぎているケース。新しいカード情報の登録なしでは、何度再課金しても通りません。海外調査ではエラー全体の 35〜40%（参考値） を占めるとも言われる最大要因です。
- 無効カード（Invalid Card Number / Lost / Stolen）: カード番号自体が無効、紛失届・盗難届が出されているケース。再課金は不可で、別カードの登録が必要です。
- 不正フラッグ恒久化: 国際カードブランド・発行会社・決済代行会社のいずれかで「このカードと加盟店の組み合わせはブロック」と恒久的に判定されたケース。再課金は逆効果になり得ます。
- 口座閉鎖（Closed Account）: カードに紐づく銀行口座やカード自体が閉鎖されているケース。リトライは無意味で、顧客様への連絡か、サービス停止判断が必要です。
- 発行会社による恒久拒否（Do Not Honor 恒久化を含む）: 発行会社側の判断で、明示的に「以後拒否」が出ているケース。理由は共有されないことが多く、原因特定は困難です。
ハードディクラインの取引に対して一律で再課金を続けると、決済代行会社のリスクスコアを下げる結果になり、本来通るはずの新規取引まで通りにくくなる副作用があります。「叩かない」判断こそが、ハードディクラインへの正しい対応です（「触ってはいけないエラー」の見分け方はリトライしてはいけない取引の見分け方で詳述）。
国際カードブランドのレスポンスコード体系
ハード/ソフトの判別は、決済代行会社のエクスポートに含まれる レスポンスコード から行うのが基本です。国際カードブランドの体系では、主に次のような区分が使われます。
- Insufficient Funds 系: 残高不足や限度額超過に該当。ソフト寄り。
- Do Not Honor 系: 発行会社の判断による拒否。理由は共有されない曖昧コードで、ソフトともハードとも取れるため、繰り返しの頻度で実質判定するケースが多い。
- Expired Card 系: 有効期限切れ。ハード確定。
- Invalid Card Number / Lost Card / Stolen Card 系: 無効・紛失・盗難。ハード確定。
- Pickup Card / Restricted Card 系: 回収指示・利用制限。ハード寄り。
- Authentication Required 系: 本人認証が必要。ソフト寄り（再案内で通る可能性）。
- Try Again Later 系: 一時的な障害・タイミング起因。ソフト確定。
同じ「Card Declined」というラベルでも、これらのレスポンスコード次第で対応が完全に分かれます。コードを読まずに一律対応すると、ソフトを捨て、ハードを叩く運用 になりやすい構造です。
「同じ Card Declined でも対応は真逆」
たとえば、同じ画面で「Card Declined」と表示されている 2 件があったとして、片方が insufficient_funds（残高不足、ソフト）、もう片方が expired_card（期限切れ、ハード）だった場合、推奨される対応は次のように真逆になります。
- insufficient_funds（ソフト）: 数日後に再試行を 1〜2 回試みる。早すぎる再課金はリスクスコアに影響するため、給料日サイクルなどを考慮する。
- expired_card（ハード）: 再課金は試みず、顧客様にカード再登録の案内を送る。決済代行会社の「カード更新サービス（Account Updater 等）」が走っているかも併せて確認する。
この区別ができていないと、本来取り戻せた残高不足を捨て、取り戻せない期限切れに労力を費やす、という運用が発生します。
あるべき状態 — ソフト/ハードが自動で仕分けられ、それぞれに最適な対応が走る
本来あるべき決済エラー管理の状態を整理すると、次のようになります。
- レスポンスコードが取得された時点で、ソフト/ハードの一次判定 が走る
- ソフトに分類された取引は、適切な時間差での再試行候補としてリスト化される
- ハードに分類された取引は、再課金対象から外され、顧客様への連絡候補・カード更新案内候補として別リストに振り分けられる
- 判別が曖昧なコード（Do Not Honor 等）は、繰り返し回数や顧客様属性から実質判定される
- 経営者の月次レビューでは、ソフト/ハードの比率がそのまま読める形で集約される
この状態が実現できれば、「取り戻せる顧客様だけにエネルギーを集中させる」運用 が成立します。能動的チャーン対策と並んで、受動的チャーン対策の中核になる領域です。
Recovery Monitor の 5 つの対応カテゴリは Hard/Soft を内包する
Recovery Monitor は、リトライ実行レイヤー（Stripe Recovery / Recurly Recover / Chargebee Dunning 等）の 後段 に立つサービスで、リトライ後に残った決済エラーを、次の 5 つの対応カテゴリに整理して提示します。
- 再試行候補（Soft 寄り）: 時間差で復活する可能性が高い取引。残高不足、一時的な認証タイムアウト、ネットワーク一時障害などが該当します。
- カード更新候補（Hard 寄り）: 有効期限切れや発行会社側の更新が必要な取引。再課金ではなく、顧客様にカード再登録を案内する設計です。
- 顧客対応候補（Hard/Soft 混在）: 個別に状況確認が必要な取引。Do Not Honor の繰り返し、無効カードなどが該当します。
- 認証確認候補（Soft 寄り）: 3D セキュア等の認証フローを再度案内すべき取引。再案内で通る見込みのあるケースです。
- リトライ非推奨（Hard 確定）: これ以上の再課金が逆効果になりうる取引。紛失・盗難・口座閉鎖・不正フラッグ恒久化などが該当します。
これらは「Hard/Soft の二分類を、運用に直接落とせる粒度まで分解した形」だと考えていただくと整理しやすいかと思います。AI は分類補助と月次レポートの下書きを担当し、顧客様への連絡判断・カード更新案内の送信は事業者様が行います（Rule-first, AI-assisted）。
まず自社のエラー内訳を試算する
「自社のエラーは、ソフトとハードのどちらが多いのか」を可視化するだけでも、運用の方向性が大きく変わります。決済代行会社のエクスポートに含まれるレスポンスコードをベースに、ソフト/ハードの比率を試算するところから始められます。
Recovery Monitor では、自社の決済エラー内訳を簡易に試算できる試算ツールと、実データで 5 つの対応カテゴリへの分類フローを試せる 30 日間無料トライアルをご用意しています。
「同じ Card Declined でも、コード次第で対応は真逆になる」 — この前提を一度持ち込んで、自社の決済エラー運用を見直すきっかけにしていただければ幸いです。