PAY.JP は日本の SaaS / EC で広く採用されている決済代行会社です。シンプルな API、Webhook を中心とした柔軟な設計、そして国内事業者向けの導入のしやすさで、サブスクリプション課金や継続課金を運用する多くの企業が利用しています。

一方で、PAY.JP には海外の Stripe Smart Retries / Recurly Recover / Chargebee Dunning のような「自動リトライ + 一定の判断材料を一体で提供する」機能は標準搭載されていません。これは PAY.JP の設計上の選択であり、加盟店事業者様にとっては運用設計の自由度と引き換えに、リトライ運用の責任を自社側で負う構図になっています。

本稿では、PAY.JP の設計思想を尊重したうえで、加盟店事業者様が決済エラー発生後にどのような運用フローを組むべきかを整理します。

PAY.JP が提供している決済エラー周辺の機能

PAY.JP は、決済エラーが発生した際に Webhook を通じて加盟店側へ通知を送ります。charge.failed や subscription.payment_failed 等のイベントを購読することで、加盟店事業者様は自社システム上でエラー発生を即時に検知できます。

Webhook の payload にはエラー理由コード、カード種別、課金方式、決済金額、顧客 ID などの情報が含まれます。これらを受け取った後の処理 — 再試行のタイミング、回数、メール通知、顧客への連絡、再試行を諦める判断 — は、すべて加盟店事業者様の設計に委ねられています。

柔軟性が高い反面、運用設計の負荷は加盟店側に集中する

この設計は、加盟店事業者様の業態・顧客層・商品特性に応じた柔軟な運用を可能にします。一方で、決済の知識とエンジニアリングリソースを併せ持つチームでなければ、Webhook を受けた後の処理を体系的に組み立てるのは難しいのが実態です。

海外の決済代行会社との設計思想の違い

海外では、Stripe Smart Retries、Recurly Recover、Chargebee Dunning などが、決済エラー発生後の自動リトライと、リトライ結果に応じた判断材料の提示を一体で提供しています。リトライのタイミングはエラー理由や顧客の支払い履歴を踏まえて調整され、リトライ後の対応 — カード更新依頼、顧客連絡、リトライ非推奨判定 — も一定の枠組みが用意されています。

これは英語圏でサブスクリプション課金が早くから一般化し、決済エラー後の Revenue Recovery が市場として確立されたためです。PAY.JP は日本市場の特性 — 業態の多様性、加盟店ごとの独自要件、エンジニアリングリソースのばらつき — を踏まえ、機能を限定せず Webhook を中心とした柔軟な設計を採用しています。どちらが優れているという話ではなく、市場特性に応じた設計選択の違いです。

多くの PAY.JP 加盟店事業者様が直面している現実

PAY.JP の Webhook を購読している加盟店事業者様の中でも、エラー通知を受けた後の運用フローが十分に整っていないケースは少なくありません。具体的には次のような状態が見られます（参考値）。

  • Webhook を受けてエラーメールを社内に通知するだけで、後段の対応分類が体系化されていない
  • リトライ実行は手動で、担当者の判断に依存している
  • カード期限切れによるエラーと一時的な認証エラーを区別せず、同じ対応をしている
  • リトライ可能なエラーと、リトライ非推奨のエラー（盗難・不正利用フラグ等）が混在している
  • 見落としを防ぐ仕組みがなく、月末の集計時に対応すべき件数が表面化する

この状態を放置すると、本来であればカード更新依頼で回収できた売上、認証確認で復旧できた決済が、エラー通知の山に埋もれて見落とされていきます。

PAY.JP 加盟店事業者様が取れる選択肢

選択肢 1：自前で自動リトライ機構を内製する

PAY.JP の Webhook を受けて、エラー理由コード別の分岐、リトライタイミングの調整、回数制限、例外処理、顧客連絡のオーケストレーションをすべて自社実装する方法です。

柔軟性は最も高い一方、決済ドメイン知識を持つエンジニアの工数、運用保守コスト、エラー理由コードの仕様変更への追従コストが継続的に発生します。中堅以上の SaaS 事業者でも、本業から離れたこの領域に専任リソースを割くのは現実的ではないことが多いです。

選択肢 2：第三者ツールでリトライ実行を補完する

海外には決済エラー後のリトライ実行を肩代わりするツールが複数存在します。日本市場では選択肢が限られ、国内の決済代行会社・国際カードブランドの要件、日本語顧客対応、契約形態への対応に課題が残るケースがあります。

選択肢 3：PAY.JP の Webhook + Recovery Monitor で対応分類を整える

PAY.JP が提供する Webhook 通知を活かしつつ、リトライ実行ではなく「リトライ後・エラー発生後の対応分類」レイヤーを外部に委ねる選択肢です。AI Orchestra の Payment Intelligence > Recovery Monitor は、この後者のレイヤーを担います。

Recovery Monitor の位置づけ — リトライ実行ではなく対応分類

Recovery Monitor は、PAY.JP の決済データを読み取り専用で受け取り、発生した決済エラーを以下のカテゴリーに分類して提示します。

  • 再試行候補 — 一時的な認証エラー、ネットワーク起因など、再試行で復旧する可能性が高いエラー
  • カード更新候補 — カード期限切れ、カード変更が必要なケース
  • 顧客対応候補 — 顧客側の状況確認・連絡が必要なケース
  • 認証確認候補 — 3D セキュア等の追加認証が必要なケース
  • リトライ非推奨 — 盗難・不正利用フラグ等、再試行すべきでないエラー

Recovery Monitor は決済を実行しません。リトライ実行は PAY.JP 側、または加盟店事業者様の既存の仕組みに残したまま、その後段にある「どのエラーを、誰が、いつ対応すべきか」を整理して提示します。これは日本市場で最初に体系化された「決済エラー管理（Payment Error Management）」カテゴリーです。

顧客対応文面のドラフトは生成、送信は人間判断

Recovery Monitor は、カード更新依頼や顧客への連絡が必要なケースについて、文面のドラフトを生成します。ただし送信は行わず、{お客様名} 等のプレースホルダのまま提示し、最終確認と送信は加盟店事業者様の担当者が行う設計です。これは「顧客連絡の送信は人間判断で行う」「人間の判断を介在させる」という方針に基づいています。

PAY.JP の設計を活かす運用フローの全体像

PAY.JP 加盟店事業者様にとって、決済エラー後の運用フローは以下のように整理できます。

このフローでは、PAY.JP の柔軟性を活かしながら、加盟店事業者様が「Webhook を受けて何もしていない」状態から抜け出すための実用的な枠組みが整います。

まずは自社の決済エラー損失を試算してみる

PAY.JP を利用していて決済エラー後の対応フローが整っていないと感じられる加盟店事業者様は、まず自社で発生している決済エラー損失額を試算することから始めるのが現実的です。月間の決済件数とエラー率を入れるだけで、見落としで失われている可能性のある売上が概算で出ます（参考値）。

決済エラー損失計算機で試算する

そのうえで実際の決済データに対して Recovery Monitor がどのような分類を提示するかを試したい加盟店事業者様向けに、30 日間の無料トライアルを用意しています。Stripe Checkout 経由でカード登録のうえお試しいただけます（30 日後に Starter ¥19,800/月 自動課金。トライアル中の解約は無料）。

料金プランの詳細は料金プラン、実際の出力イメージはサンプルレポートからご確認いただけます。

PAY.JP は加盟店事業者様の運用設計に自由度を与える成熟した決済代行会社です。その自由度を活かす対応分類レイヤーとして、Recovery Monitor をご検討ください。