SaaS 企業が決済の失敗の通知を n8n で受け、拒否の理由と契約の事情で分けて、督促と案内の下書きを作る

処理の起点を決める

起点は Stripe の invoice.payment_failed です。 Stripe の Smart Retries のページは、サブスクリプションの支払いの失敗と再試行の回数の更新をこの Webhook で受けるよう案内しています。再試行のたびに同じ請求書の通知が届くため、届いたらすぐ下書きを作るのではなく、請求書ごとに1回目の失敗と、型が変わったときだけ動かします。

Smart Retries は、決めた回数と期間で再試行し、推奨の既定は2週間以内に8回です。カスタムの規則にすると、前回から決めた日数を空けて最大3回の再試行になります。再試行で戻る失敗に、1回目から督促を送る必要はありません。 そこで型ごとに「すぐ連絡する」「再試行を何回か待つ」を決めておきます（第7章「AIに何をさせるのか」の表）。

Stripe の Webhook は、同じイベントを複数回届けることがあり、届く順も保証されません。 Stripe は処理したイベント ID を記録して二重に処理しないよう案内しています。n8n では受けた直後に Data Table「events」でイベント ID を引き、あれば止めます。受けたらすぐ成功を返すことも求められているので、重い処理は後ろに回します。

入力データを集める

質を決めるのは、下の3つです。 拒否コードは「何が起きたか」しか言いません。「この顧客に何をお願いするか」は、契約とやり取りを見て初めて決まります。 年額の更新で card_velocity_exceeded（利用限度額の超過）になった顧客と、月額の少額で同じコードになった顧客では、お願いすることが違います。

データの取得方法を決める

拒否の理由は、通知の中には直接入っていません。 請求書の payments は既定では返らず、expand で取ります。そこから支払い（PaymentIntent）を引き、PaymentIntent の latest_charge を展開して Charge の outcome を読みます。Stripe の公式ページは、拒否コードを outcome の reason に、次の対応を outcome の advice_code に示すとしています。

attempt_count には注意があります。 公式ページによると、再試行できない拒否コード（ハードデクライン）が返ると、新しい支払い方法が登録されるまで再試行は実行されませんが、予定は残り attempt_count は増え続けます。 回数が増えていても、実際には請求していないことがあります。回数だけを見て「何度も失敗している顧客」と扱わないでください。

HTTP Request ノードで Stripe API を呼ぶときは、n8n の Stripe の資格情報を使います。読むだけなので、制限付きのキーで請求書・支払い・Charge の読み取りに絞ります。

AIへ渡す前に整形する

1. 重複の除去 … イベント ID で引き、処理済みなら止める。同じ請求書の再試行の通知は、型が前回と同じなら止める
2. 型の先決め … outcome.reason を対応表に当てる。当たれば型が決まり、AIの分類に回さない
3. 理由を伝えない型の抜き出し … fraudulent・stolen_card・lost_card・merchant_blacklist は「理由を伝えない型」にし、拒否コードの文字をこの後のどのノードにも渡さない
4. 待つ回数の判定 … 型ごとの「待つ再試行の回数」に attempt_count が届いていなければ、記録だけして止める
5. 契約とやり取りの取得 … 顧客の ID で顧客管理のシステムを引き、過去90日のやり取りを件名と要点に絞る
6. 個人情報の削り … やり取りの本文から電話番号・カード番号らしき数字の並びを伏せる

3番目は、文面の段で気をつけるのでは足りません。 下書きを作るAIに fraudulent という文字が渡れば、どれだけ指示しても文面に出る可能性が残ります。渡さなければ、書かれようがありません。

AIに処理させる

させるのは2つです。 「理由は不明」の拒否を対応の型に分けること、型ごとの骨組みに沿って下書きを書くことです。まず、プログラムが決める型と、AIが分ける型を分けます。

AIが分けるのは、最後の行の4つの型です。

3つ目の型が、AIに分けさせる理由です。 解約を考えている顧客に督促のメールを先に送ると、解約の背中を押します。拒否コードには出てこない事情で、やり取りの文面を読まないと分かりません。 Text Classifier の「When No Clear Match」は既定で当てはまらない項目を捨てるので、「Output on Extra, 'Other' Branch」に変え、Other は人が見る型にします。

指示内容を固定する

Text Classifier の型の説明と、System Prompt Template に入れる指示です。

あなたは SaaS 企業の経理部で、カードの継続課金が失敗した顧客への連絡を準備する立場です。
カード発行会社が理由を示さずに拒否した決済について、顧客の契約と直近のやり取りだけを見て、
次の型のどれに当たるかを選んでください。

【型】
{categories}

【判断の材料】
- 契約の種類（月額・年額）と、今回の請求額と前月の請求額
- 直近90日のやり取りの件名と要点
- 担当者の交代の記録

【厳守事項】
- 材料に書かれていない事情を推測しないでください。
  やり取りに担当者の交代が書かれていなければ「支払い担当の交代」を選ばないでください。
- 「解約の気配」は、やり取りに解約・不満・他社への切替の言及がある場合だけ選んでください。
  請求額が増えたことだけを理由に選ばないでください。
- どれにも当てはまると言い切れないときは、無理に選ばないでください。
- 型の名前だけを返してください。理由の説明は要りません。

Basic LLM Chain に渡す、下書きの指示です。

あなたは SaaS 企業のカスタマーサポートで、決済の失敗を顧客にお知らせするメールの下書きを書きます。
下の【型】の骨組みに沿って、件名と本文を書いてください。

【厳守事項】
- カードが拒否された理由を、骨組みに書かれている以上に説明しないでください。
  「不正」「紛失」「盗難」「残高不足」などの言葉は、骨組みに無ければ使わないでください。
- 金額・請求書番号・利用停止の予定日は【請求の情報】の値をそのまま写してください。
  日付を計算したり、言い換えたりしないでください。値が空なら「（要確認）」と書いてください。
- 支払い方法を直す場所として【支払いの画面の URL】を1回だけ入れてください。
  カード番号やセキュリティコードをメールで送るよう頼まないでください。
- 利用停止や解約を予告する言葉は、骨組みにある一文だけにしてください。
- 宛名は【請求先の担当者】の値を使ってください。空なら「ご担当者様」としてください。

【型】{route}
【骨組み】{template}
【請求の情報】{invoice_summary}
【支払いの画面の URL】{hosted_invoice_url}
【請求先の担当者】{billing_contact}

「骨組みに無い言葉を使わない」を、具体的な言葉を挙げて書くのが要点です。 「理由を詳しく書かない」だけだと、AIは親切のつもりで「残高不足の可能性があります」と補います。理由を伝えない型をAIに渡していなくても、他の型の文面で同じことが起きます。

出力形式を固定する

Text Classifier は型ごとの出口に項目を流します。 型の名前を出口から受けるので、AIが自由な文字列を返して後段が迷うことはありません。下書きは次の JSON で受けます。

{
  "invoice_id": "in_...",
  "customer_id": "cus_...",
  "route": "card_update | authentication | balance_limit | wait_retry | do_not_disclose | high_amount | contact_change | churn_risk | ask_issuer | other",
  "route_source": "rule | classifier",
  "decline_code_group": "known | unknown | do_not_disclose",
  "attempt_count": 1,
  "draft": {
    "subject": "",
    "body": "",
    "missing_fields": []
  },
  "needs_review_by": "staff | manager"
}

1つ目の理由は、route_source で「誰が型を決めたか」を残せることです。 対応表で決まった型と、AIが分けた型を後で別々に数えられます。AIの分類を見直すとき、対象を classifier だけに絞れます。

2つ目は、decline_code_group に拒否コードそのものを入れないことです。 ログにも下書きにも fraudulent の文字を残さず、do_not_disclose という群だけを書きます。拒否コードは Stripe 側に残っているので、必要なら経理の責任者がそちらで見ます。

3つ目は、missing_fields で埋められなかった値が分かることです。 利用停止の予定日が顧客管理のシステムに無ければ、下書きには「（要確認）」と入り、この欄に名前が出ます。担当者は本文を読む前に、確かめる項目が分かります。

システムへ連携する

Stripe には書き込みません。 再試行の予定を変えたり、サブスクリプションを止めたりはこの構成の外です。下書きの段で止めているので、型を取り違えても顧客には何も届きません。

Gmail の Draft の Create は、To・件名・本文に加えて Thread ID を指定でき、過去のやり取りのスレッドに下書きを付けられます。同じ顧客とのやり取りが続いているときは、新しいメールより返信の形のほうが読まれます。

人が確認する

1. 担当者が毎朝、一覧を型の順に開く … 「カードの更新のお願い」「認証のお願い」は件名と宛先だけ確かめて送る
2. AIが分けた型は本文まで読む … route_source が classifier のものは、やり取りの要点と型が合っているかを確かめる
3. 「解約の気配」は督促を出さない … カスタマーサポートの担当が先に電話かメールで事情を聞く
4. 「理由を伝えない型」と Other は経理の責任者が見る … 文面は人が書く。拒否の理由には触れず、別の支払い方法の登録をお願いする
5. 型を直したら記録する … どの型からどの型に直したかを Data Table に残す

4番目を省かないでください。 事情を書けない以上、何を伝えるかは人が決めます。

目標は、240件をならして1件5分です。 対応表で決まる型は1〜2分で送れ、AIが分けた型と人が見る型は数分から10分かかります。

例外に対処する

上から3行目と4行目は、正常に起きます。 エラーとして扱うと、毎朝の一覧が赤い行で埋まります。

記録を残す

• 受けたイベント ID、請求書の ID、顧客、attempt_count、受けた時刻
• 型と route_source、decline_code_group（拒否コードそのものは残さない）
• Text Classifier に渡したやり取りの要点（伏せ字にした後のもの）
• 下書きの件名・本文と、担当者が送った版の差分
• 人が型を直した記録 … どの型からどの型へ、誰が
• 送った後に支払いが戻ったか（invoice.paid の有無と日付）

最後の行が、型の対応表を直す材料になります。 「残高・枠の確認のお願い」を2回待ってから送っている型で、待つ間に戻る割合が高ければ、待つ回数を増やせます。逆に、送った後もほとんど戻らない型は、文面よりお願いの中身を見直します。