サブスクリプションや月額課金を運営している事業者の方に、ひとつだけ確認させてください。

先月、自社の決済は何件エラーになりましたか。そのうち、何件が「対応すれば回収できた」ものだったか、即答できますか。

この問いに数字で答えられる事業者は、業界経験上ごくわずかです。決済代行会社の管理画面にエラー件数自体は表示されているはずなのに、月次レビューで議題に上がらない。担当チームの月初の議題は新規獲得・LTV・解約率に集中し、決済エラーは「決済代行会社側で処理されている前提」として、意思決定の射程の外に置かれがちです。その結果、毎月静かに売上が消えていく——という構造が、サブスク事業の現場では常態化しています。

業界参考値:決済エラー率は3〜15%

業種別の参考値として、サブスクリプション・継続課金における決済エラー率はおおよそ 3〜15% のレンジに収まると言われています(参考値)。SaaS や定期通販、デジタルコンテンツ、月額メンバーシップなど、対象とする顧客層・国際カードブランドの構成・決済単価・課金日の集中度によって幅が出ます。

仮に月間 1,000 件 の決済がある事業者で、エラー率を中央値の 9% と置くと、エラー件数は月 約 90 件。平均単価が ¥5,000 であれば、月 ¥450,000、年間で 約 540 万円 がエラーの背後に滞留している計算になります。月間 5,000 件の事業者であれば、年間 2,700 万円規模が同じレイヤーに沈んでいる、ということになります。

これは「諦めるしかない金額」ではありません。性質を分けて見れば、相当割合が回収可能な性質を持ったエラーです。問題は、その分解作業が現場で行われていないこと——ほぼそれに尽きます。

見えていない損失の正体

多くの事業者から共通して聞こえてくる声があります。

  • 「決済代行会社のダッシュボードでエラー件数は見ているが、何をすべきか分からない」
  • 「リトライ機能はオンにしているが、実際の回収率は把握していない」
  • 「解約として処理されているものの中に、本来は回収できたケースがあるはずだが、特定する方法がない」
  • 「カスタマーサクセスと経理で見えている数字が違い、月次の数字合わせに時間がかかる」

これらは個別の運用ミスではなく、決済エラーを「一覧で見る」ことはできても「分類して打ち手を出す」レイヤーが存在しないという構造的な問題です。LTV・チャーン率は KPI として整備されている一方で、その手前にある「決済エラー由来の解約候補（受動的チャーン）」は、未分解のまま流れていきます。

Hard Decline と Soft Decline の構造的な違い

決済エラーには大きく2種類あります。専門用語を避けて言い換えると、次のようになります。

恒久的なエラー(Hard Decline):カード番号が無効、不正検知、紛失・盗難扱い、発行銀行による永続的な拒否など。これは何度リトライしても通りません。むしろ短期間に再試行を繰り返すと、国際カードブランド側でリスクスコアが悪化し、健全な決済まで影響を受けることがあります。このカテゴリでは、再試行ではなく「顧客にカード情報の更新を依頼する」ことが正解です。

一方で一時的なエラー(Soft Decline):残高不足、利用限度額超過、銀行の一時的な拒否、3-D セキュアのタイムアウトなど。タイミングを変えて再試行すれば通る可能性が高い性質のものです。給与日後の再試行、72時間以内の限度額リセット狙いなど、定石が存在します。

この2つを区別せずに「決済エラー = 解約予備軍」として処理してしまうと、本来は継続できた顧客まで失うことになります。逆に、すべてを延々と再試行してしまうと、リスクスコアの悪化と顧客体験の毀損(通知メールの過剰送信など)を同時に招きます。分類してから打ち手を変える——この一段が抜けていることが、現場の本質的な課題です。

整った状態:数字が読め、リストが出る

では、決済エラー周りが整理されている事業者の現場は、どう見えるのか。

月次レビューの冒頭で、「今月の決済エラーは ◯件、金額換算で ¥◯万円、うち再試行候補が ◯件、カード更新依頼候補が ◯件、顧客対応候補が ◯件」と、5分以内に把握できる状態になっています。前月比・前年同月比でのトレンドも一目で見え、季節性(新年度・ボーナス時期など)による変動も切り分けて読めます。

担当者が抽出すべき顧客リストは、ダッシュボード上で自動的に分類されており、「このリストには給与日後にメール、こちらにはカード更新ページのリンク送付、こちらは認証エラーなのでサポートからフォロー」と、打ち手まで紐付いた状態で出てきます。

結果として、解約処理されていたはずの顧客が継続し、新規獲得のための広告費(CAC)を二重にかけずに済む——という当たり前の経済性が成立します。CAC が ¥30,000 のサービスで月10件の継続を取り戻せれば、それだけで月 ¥30 万円の取得コストが浮く構造です。

Recovery Monitor の位置づけ:決済エラー管理レイヤー

海外の SaaS / サブスク市場では、決済エラーへの対応は「リトライ実行レイヤー」として既に整備されています。Stripe Recovery、Recurly Recover、Chargebee Dunning などがこの層に該当し、ルールベースで自動的にリトライ・通知を行う仕組みが標準です。日本市場でも、決済代行会社各社が同等のリトライ機能を提供しはじめています。

ただし、これらのツールが扱うのは「いつ・どう再試行するか」までで、その後段——「結果として何が起きたのか、次月に何をすべきか、どの顧客に人間が対応すべきか」を経営の言語で整理するレイヤーは、長らく空白でした。リトライは実行されているが、その結果が経営の意思決定に紐付かない、という構造です。

Recovery Monitor は、この後段を 決済エラー管理(Payment Error Management) という名称で体系化し、日本市場で最初に提供しているサービスです。決済代行会社のデータを読み取り(read-only、決済処理は一切行いません)、エラーを次の5カテゴリに分類します。

  • 再試行候補:タイミングを変えれば通る可能性が高いもの
  • カード更新候補:期限切れ・無効カードで、顧客にカード更新を依頼すべきもの
  • 顧客対応候補:メール送付や個別連絡で復帰見込みがあるもの
  • 認証確認候補:3-D セキュア等の認証フローで止まっているもの
  • リトライ非推奨:不正検知・恒久エラーで、これ以上の再試行が逆効果になるもの

分類は決定論的なルールベースで行い、AI は 顧客対応文面のドラフトや月次サマリの要約など、判断支援の範囲でのみ使用します。自動リトライや自動メール送信は行いません。打ち手の最終判断は事業者側の人間が行う設計に統一しています。これは「自動化の不足」ではなく、カード情報や顧客対応という、機械任せにすべきでない領域を意図的に人間に残している設計上の選択です。

次のアクション:まず自社の数字を見る

提案は2つだけです。

第一に、自社の月間決済件数と平均単価から、エラー件数・損失額の概算を可視化してください。推定損失額の試算ページに数値を入れれば、業界参考値に基づくレンジが1分で出ます。これは Recovery Monitor を契約しなくても無料で使えます。経営会議の議題に「決済エラー」を入れる第一歩として、この数字を持ち込むだけで会話が変わります（MRR / LTV / CAC への影響を経営判断に組み込む方法は経営者が見るべき決済エラー KPI ダッシュボードで詳述しています）。

第二に、概算を見たうえで「実データで分解する価値がある」と判断された場合は、30日間無料トライアルで Recovery Monitor の分類結果を実際の決済データで確認してください。Stripe Checkout 経由でカード登録のうえお試しいただけます（30 日間は無料・期間中の解約で課金は発生せず、31 日目から Starter ¥19,800/月が自動課金）。決済代行会社の読み取り権限のみで開始でき、カード番号・CVC は分析対象として一切扱いません。30日間、自社の決済データで5カテゴリの分類が現実的に機能するかを検証してから、継続を判断する流れです。料金プランの詳細は料金プラン、サンプルレポートはサンプルレポートからご確認いただけます。

月間1,000件の決済の背後にある数字を、次の月次レビューまでに自分の言葉で説明できる状態にする——出発点はここです。