Stripe Smart Retries は、リトライ実行レイヤーとして海外で広く採用された成熟ツールです。本稿の目的は、その強みを正しく理解したうえで、Smart Retries が構造上カバーしない「後段」に何が残るのか、そしてその後段をどう扱うべきかを整理することです。
結論を先に書きます。Smart Retries は強力です。だからこそ、その後ろに残る決済エラーは「Smart Retries で取り切れなかった、より対応難度の高い取引」になります。後段を放置すると、本来は再開可能な取引まで自然解約として静かに失われていきます。
Stripe Smart Retries が担うレイヤー
Stripe Smart Retries は、サブスクリプションや継続課金で発生した決済エラーに対して、リトライのタイミングと回数を機械学習ベースで最適化する仕組みです。Stripe ネットワーク全体の膨大な決済データを学習データに用い、どの条件下でリトライを再投入すれば成功確率が高いかを動的に判断します。
同種の領域では、Recurly Recover、Chargebee Dunning なども「リトライ実行とリマインダー配信」を最適化するツールとして長く運用されてきました。これらはいずれも、決済エラーが発生した直後の「もう一度通す」レイヤーを担う前段ツールです。Recovery Monitor はこれらと競合する立ち位置ではありません。むしろ、これらの後段に残る取引をどう扱うかという、別レイヤーの課題（リトライ実行と対応分類の分業構造）に向き合うサービスです。
Smart Retries の限界は、性能ではなく設計範囲
Smart Retries の限界を語るとき、精度の話をするのは適切ではありません。Smart Retries は精度の高いツールです。むしろ重要なのは、Smart Retries が設計上カバーする範囲と、そもそも別レイヤーとして切り出されている範囲を区別することです。
具体的には、以下のような領域が Smart Retries の設計範囲外、もしくは別途運用者側で対応する前提になっています。
1. Stripe ネットワーク外の決済データを統合しない
Smart Retries が参照するのは Stripe 上で発生した取引データです。複数の決済代行会社を併用している事業者の場合、Stripe 以外で発生した決済エラーは Smart Retries の対象外になります。複数決済代行会社をまたいだ「全体としての決済エラー残量」を把握する役割は、別のレイヤーで担う必要があります。
2. 「次に誰に何をすべきか」のリスト化はしない
Smart Retries はリトライ実行に最適化されています。一方、リトライ後に残った取引について「次にどの顧客に、どの順番で、どのアクションを取るべきか」を経営者やオペレーターが読めるリスト形式に変換する機能は、設計範囲外です。リトライが終わった先に残るリストを誰がどう扱うかは、別の役割になります。
3. 経営者向けの集約ビューは持たない
Smart Retries はトランザクション単位の最適化ツールです。「先月リトライ後に残った決済エラーの総額」「再開候補とそうでないものの内訳」「ハードディクライン比率」といった、経営者が月次で読むための集約ビューは、本来別レイヤーの仕事です。
4. 顧客対応文面のドラフト機能は範囲外
残ったエラー取引に対して、顧客に状況を案内する文面の下書きを生成する機能は、決済処理レイヤーの責務ではありません。リトライエンジンの後段にある、対応プロセスを誰が支援するかという課題が別にあります。
5. 国際カードブランド側の期限切れリストは別途抽出が必要
国際カードブランドの有効期限切れに起因する取引は、リトライしても通らないことが多く、別途リストとして抽出し、顧客側で更新してもらうフローが必要になります。Smart Retries はこの「カード期限切れ専用リスト」を切り出す機能を持たないため、運用者側で対応することになります。
後段に何が残るか
Smart Retries が走り切ったあと、典型的に残るのは以下のような取引です。
- ハードディクライン: カード側から明確に拒否された取引。再試行しても通らない可能性が高い
- 不正フラッグが付いた取引（リトライ非推奨候補）: リスク判定で止まった取引。リトライではなく顧客確認や別ルートが必要
- 国際カードブランドの有効期限切れ: カード更新が前提のため、リトライ単独では解決しない
- 残高不足の長期化: 数回のリトライで通らなかった取引。給料日サイクルを含む長期的なタイミング判断が必要
- 顧客連絡先が古い取引: メールアドレスや電話番号が古く、自動リマインダーが届かない取引
これらは Smart Retries が「対象外」と判断した取引ではなく、Smart Retries が走った結果として「より対応難度が高い、後段に送られる取引」です。本来、人間の判断と手を動かすコストをかける価値がある取引が、判断材料なく並んでいる状態になります。
多くの現場で、この後段の取引は「自然解約」として黙って処理されています。海外では決済エラー後のリカバリーで再開できる比率を 20〜40%（参考値）とする調査もあります。後段を放置した分の解約は、本来は再開できたはずの収益が静かに失われている状態です。
Recovery Monitor の位置づけ
Recovery Monitor は、Stripe Smart Retries やそれに類するリトライ実行レイヤーの「後段」にあたる領域を、「決済エラー管理（Payment Error Management）」というカテゴリとして日本市場で最初に体系化したサービスです。
役割分担を整理すると以下のようになります。
- 前段（Smart Retries / Recurly Recover / Chargebee Dunning など）: リトライ実行とリマインダー配信の最適化
- 後段（Recovery Monitor）: リトライ後に残った決済エラーの分類、再開候補リスト化、顧客対応文面ドラフト、経営者向け月次レポート
Recovery Monitor は決済処理を行いません。リトライエンジンと競合する位置ではなく、リトライエンジンが走った後に残る取引をどう扱うかという、別レイヤーの課題に向き合うサービスです。Stripe Smart Retries を導入している事業者にとっては、その後段の見落としを防ぐ補完レイヤーとして併用される設計になっています。
後段に残っている取引量を把握する
自社で Stripe Smart Retries を稼働させている事業者の場合、後段に残っている取引量を把握することは比較的容易です。リトライ完了後に未回収のまま残っている取引を、月次で集計するだけで概況がつかめます。そこで初めて、「自然解約として処理していたが、再開候補として扱える可能性があった取引」がどれだけあったかが見えます。
Recovery Monitor の試算ツールでは、決済代行会社のエクスポートから「Smart Retries 後に残る取引量」と「Recovery Monitor で再開候補として扱える比率」の参考値を確認できます。複数決済代行会社を併用している場合、それぞれの後段を統合して読むビューも提供します。