SaaSの未払いを自動回収するには、決済失敗を検知し、再請求・通知・支払い方法の更新・利用制限までをあらかじめ自動化します。特に、クレジットカードの有効期限切れや残高不足などの「一時的な決済失敗」と、支払う意思が確認できない「長期滞納」は、分けて対応することが重要です。
ただし、自動回収は未払いを必ず回収できる仕組みではありません。利用規約、契約内容、決済会社のルールに沿って、通知や利用停止の条件を設定する必要があります。
SaaSの未払いを自動回収する基本的な方法
基本的な流れは、決済失敗の検知、再請求、顧客への通知、支払い方法の更新依頼、利用制限、手動対応です。
- 決済会社から決済失敗の通知を受け取る
- 失敗理由に応じて、一定期間を空けて自動で再請求する
- 顧客にメールや管理画面で支払い失敗を通知する
- 支払い方法を更新できるページを案内する
- 未払い期間に応じて機能制限や利用停止を行う
- 一定期間を過ぎた案件を担当者へ引き継ぐ
この仕組みは、一般に「リトライ」「督促」「ダニング」と呼ばれます。すべてを自社開発する方法のほか、継続課金に対応した決済サービスや請求管理サービスの機能を利用する方法もあります。
未払いの原因ごとに回収方法を変える
決済失敗の原因によって、適切な対応は異なります。原因を区別せず、同じ間隔で何度も請求するだけでは、回収できる未払いを逃したり、顧客に不必要な負担をかけたりするおそれがあります。
| 主な原因 | 自動対応の例 | 確認したいこと |
|---|---|---|
| カードの有効期限切れ | カード情報の更新依頼、更新後の再請求 | 決済サービスがカード情報の更新機能に対応しているか |
| 残高不足や利用限度額超過 | 一定期間を空けた再請求、失敗通知 | 再請求の回数や間隔が決済会社の仕様に合っているか |
| カードの利用停止・解約 | 別の支払い方法への変更依頼 | 顧客が更新ページを利用できるか |
| 口座振替の残高不足 | 再振替の案内、別の支払い方法の提示 | 金融機関や収納代行会社の再振替条件 |
| 請求先情報の誤り | 請求先情報の修正依頼、請求書の再送 | 法人名、住所、担当者、請求先メールアドレス |
| 支払い意思が確認できない長期滞納 | 最終通知、利用停止、担当者対応 | 契約や利用規約に定めた期限と手続き |
決済失敗の理由を取得できる範囲は、利用する決済サービスによって異なります。自動処理を設計する前に、取得できるエラー情報、再請求の可否、顧客への通知機能を確認してください。
自動回収の具体的な運用フロー
1. 決済失敗をリアルタイムで検知する
決済サービスから送られるWebhookや管理画面の通知を使い、決済成功・決済失敗・返金・サブスクリプション停止などの状態をSaaS側に反映します。
決済結果を受け取ったら、顧客ID、契約プラン、請求額、請求日、失敗理由、次回請求日を記録します。状態を記録しないままメールだけを送ると、再請求の重複や対応漏れが起きやすくなります。
2. 一時的な失敗には自動リトライを設定する
残高不足など、一時的な原因が考えられる場合は、一定期間を空けて再請求します。再請求の回数や間隔は、決済サービスの仕様、顧客への通知タイミング、サービスの利用形態を踏まえて設定します。
同じ日に繰り返し請求するのではなく、請求結果を確認してから次の処理へ進む仕組みにします。再請求で成功した場合は、未払い状態を自動的に解除し、顧客へ支払い完了を通知します。
3. 支払い方法を更新できる画面を用意する
メールに「支払い方法を更新してください」と書くだけでなく、顧客がログイン後に安全にカード情報や口座情報を更新できる画面を用意します。
カード番号などの決済情報を自社システムで直接保存すると、セキュリティや決済業界の基準への対応が必要になります。決済サービスが提供する入力画面やトークン化機能を利用し、自社側では必要最小限の情報だけを管理する設計が一般的です。
4. 状態に応じて通知を自動送信する
通知は、決済失敗直後、再請求前、利用制限前、利用停止後など、顧客が次に取るべき行動が変わるタイミングで送ります。
- 決済に失敗したこと
- 失敗した請求の金額と対象期間
- 支払い方法を更新する手順
- 次回の再請求予定
- 利用制限や契約停止が始まる条件
- 問い合わせ先
メール内のリンク先は、ログインが必要な顧客専用ページにするなど、請求情報が第三者に見られないようにします。請求額や顧客情報を、推測されやすいURLにそのまま含める設計は避けます。
5. 未払い期間に応じて利用を制限する
未払いが続いた場合の対応は、契約や利用規約にあらかじめ定め、その内容を顧客に分かるように示します。いきなり全機能を停止するのではなく、サービスの性質に応じて段階的に制限する方法があります。
- 新規データの登録や一部機能を制限する
- 管理者だけに支払い案内を表示する
- 読み取り専用に変更する
- 一定期間後にログインや利用を停止する
データを削除する場合は、保存期間、復旧方法、解約後の取り扱いを明確にします。重要なデータを扱うサービスでは、利用停止とデータ削除を同じ処理にしないほうが安全です。
クレジットカード決済で自動回収する場合のポイント
クレジットカード決済では、カードの有効期限切れや再発行による情報変更に対応できるかが重要です。決済サービスによっては、カード情報の更新を支援する機能や、顧客が更新しやすい請求ポータルを提供しています。
決済サービスを比較するときは、次の項目を確認します。
- 継続課金に対応しているか
- 決済失敗をWebhookなどで通知できるか
- 決済失敗後の自動リトライに対応しているか
- カード情報の更新機能があるか
- 請求書や領収書を発行できるか
- 返金やプラン変更を管理できるか
- 失敗理由をどの程度取得できるか
- 利用停止やサブスクリプション解約と連携できるか
カード情報の自動更新に対応している場合でも、すべてのカードや決済失敗が自動で解決するとは限りません。更新後も決済に失敗するケースを想定し、顧客への通知と別の支払い方法への変更手段を用意します。
請求書払いのSaaSで自動回収する方法
法人向けSaaSで請求書払いを採用する場合は、決済の再試行よりも、請求書の送付・入金確認・督促の自動化が中心になります。
- 契約開始時に請求先情報と支払条件を登録する
- 請求日に請求書を自動発行する
- 送付日時と送付先を記録する
- 入金情報を取り込み、請求と消し込む
- 支払期日を過ぎた請求を自動抽出する
- 未入金の通知を送る
- 一定期間後に担当者へ引き継ぐ
請求書払いでは、入金名義が会社名と一致しない、振込手数料が差し引かれる、複数の請求をまとめて振り込まれるといった理由で、入金消込が自動で完了しないことがあります。自動処理の対象外となった請求を一覧で確認できるようにしておくと、対応漏れを減らせます。
自動回収のタイミングを設定する考え方
具体的な日数は、契約条件、決済サービスの仕様、顧客への通知内容を確認して決めます。重要なのは、請求失敗から利用停止までの流れを一貫させ、顧客がいつ何をすべきか分かる状態にすることです。
| 段階 | 自動処理の例 | 目的 |
|---|---|---|
| 決済失敗直後 | 失敗通知、更新ページの案内 | 単純な入力ミスや情報更新漏れを解消する |
| 再請求の段階 | 決済結果の確認、再請求 | 一時的な残高不足などに対応する |
| 未払い継続 | 再通知、管理画面への警告表示 | 支払いが必要な状態を明確に伝える |
| 利用制限前 | 期限と制限内容を通知する | 突然のサービス停止を避ける |
| 長期滞納 | 利用停止、担当者への引き継ぎ | 自動処理だけで解決しない案件を管理する |
一律のルールではなく、月額制か年額制か、個人向けか法人向けか、保存データの重要性はどの程度かによって調整します。
自動回収を導入するときの注意点
利用規約と契約内容を先に整える
決済失敗時の再請求、支払い方法の変更、利用制限、契約解除、データの保存と削除について、契約や利用規約に記載します。実際の運用が規約の内容と異なると、顧客とのトラブルにつながる可能性があります。
未払いを理由に利用を停止できるか、停止前に通知が必要か、解約後も料金が発生する条件があるかは、契約形態やサービス内容によって変わります。法律上の扱いが問題になる場合は、専門家への確認が必要です。
重複請求を防止する
Webhookの再送や通信障害が起きても、同じ請求を二重に処理しない仕組みが必要です。請求IDや決済IDを使って処理済みか確認し、再請求の前に現在の決済状態を照合します。
成功した支払いで利用制限を解除する
再請求に成功したのに、SaaS側の未払い状態が解除されないと、正しく支払った顧客が利用できなくなります。決済成功の通知を受け取った後に、請求状態、契約状態、利用制限状態が一致しているか確認します。
担当者が対応する案件を残す
自動回収だけで解決できない案件もあります。法人契約、金額が大きい請求、契約更新時の未払い、請求先変更、解約を希望する顧客などは、担当者が確認できるようにします。
自社開発と決済サービス利用の選び方
自社開発は、契約状態や利用制限を細かく連携できる一方、決済仕様、セキュリティ、例外処理、通知管理まで設計する必要があります。独自の請求ルールや複雑な契約管理が必要な場合に向いています。
決済サービスの機能を利用する方法は、継続課金やカード情報の更新、決済失敗通知を短期間で導入しやすい点がメリットです。一方で、再請求のルールや通知文面、利用停止との連携がサービスの仕様に制限されることがあります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 決済サービスの機能を利用 | 標準的な月額課金を早く導入したい | 対応できる決済方法や自動処理の範囲を確認する |
| 自社システムとAPI連携 | 契約や利用制限と細かく連動させたい | 状態同期、エラー処理、重複防止が必要 |
| 請求管理サービスを利用 | 請求書発行や入金消込をまとめて管理したい | 会計システムや銀行データとの連携条件を確認する |
| 担当者による手動対応を併用 | 法人契約や例外的な請求が多い | 自動処理から手動対応へ移す基準を決める |
SaaSの未払い自動回収で最初に決めること
導入時は、次の順番で決めると設計しやすくなります。
- 決済方法ごとに、失敗理由として取得できる情報を確認する
- 再請求できる条件と回数を決める
- 顧客へ送る通知の内容と送信タイミングを決める
- 支払い方法を更新する画面を用意する
- 未払い期間ごとの機能制限を決める
- 利用規約や契約書へ反映する
- 重複請求や状態不一致をテストする
- 自動処理から担当者対応へ切り替える条件を決める
まずは「決済失敗を記録する」「支払い方法の更新を案内する」「再請求の結果をSaaSの契約状態へ反映する」の3点から始めると、未払い対応の土台を作れます。そのうえで、通知、利用制限、請求書の入金消込を追加すると、手動作業を段階的に減らせます。







