Stripe は、サブスクリプション、請求書、支払いに変化があったときにイベントを発行します。これらのイベントを起点に役立つメールを送れますが、どのメッセージにも、明確な受信者と目的、そして今送るのが適切かどうかを判断するルールが必要です。

OAuthでの接続と Webhook の設定は、Brew の Stripe 連携が行います。このガイドでは、その先のメール施策をどう設計するかを説明します。請求ではなく製品イベントを起点にするフローについては、AIでメールを自動化するガイドをご覧ください。

1つのイベントに1つのメッセージを対応させる

目的	候補となるイベント	送信前に確認すること
購読者を歓迎する	customer.subscription.created	チェックアウトを起点にしたウェルカムメールと重複しないか
トライアルの終了を説明する	customer.subscription.trial_will_end	実際の期限と、請求が発生するかどうか
請求書の支払い失敗を知らせる	invoice.payment_failed	現在の請求書、請求ページへのリンク、Stripe が送る既存の通知
プランの変更を説明する	customer.subscription.updated	どのフィールドが変わったか、その変更が重要かどうか
解約を受け付けたことを伝える	customer.subscription.deleted	利用がいつ終わるか、顧客が何を求めたか
返金を説明する	refund.created	イベントで使える返金固有のフィールド

Stripe イベントリファレンスと、選択した Brew のトリガーのスキーマを参照してください。サブスクリプションの更新は、さまざまな種類の変更を表す可能性があります。データを確認せずに、更新のたびにプラン変更のメールを送るのはやめましょう。

接続と公開は慎重に

Brew の「連携サービス」ページで、Stripe へのアクセスを許可します。Brew が Webhook を登録し、対応するトリガーをプロビジョニングします。イベントごとに有効・無効を切り替えるスイッチはありません。実行されるのは、そのイベントに紐づいた稼働中のオートメーションだけです。

過去のコンタクトを取り込む必要がある場合は、「Stripe から顧客を同期」を使います。請求先のコンタクトをインポートしても、マーケティングメールへの同意を得たことにはなりません。イベントごとの「氏名を同期」の設定が制御するのは名前の更新であり、メールが送信されるかどうかではありません。

最初のオートメーションは下書きとして作成し、生成されたメールを確認して、公開する前に管理下にある受信者でテストしましょう。接続の詳細は、Stripe セットアップガイドに沿って進めてください。Brew が接続するのは本番の Stripe アカウントで、テストモードのイベントでは、オートメーションは開始されません。

古くなったリマインダーを送らずに、支払いの失敗に対応する

失敗をすぐに知らせる通知は、invoice.payment_failed を起点にできます。何が起きたかを説明し、自社の請求ページへのリンクを添えましょう。Brew が決済を再試行すると約束してはいけません。支払いの処理を担うのは Stripe です。

3日後にリマインダーを送るなら、請求書のステータスを確認する処理をアプリケーションで予約します。請求書が未払いのままで、顧客が引き続き対象となる場合に限り、リマインダー用の別の Brew イベントを送信します。支払いが回復していれば、イベントを送信せずに終了します。

「待機」のあとも、イベントのフィールドには元のペイロードが入ったままです。contact.stripe_subscription_status を使う条件は、そのノードの実行時点で Brew のコンタクトにあるフィールドの現在の値を読み取ります。Stripe に問い合わせるわけではなく、この請求書が支払われたことを証明するものでもありません。あとから届いた invoice.paid イベントによって、それ以前の実行が自動的にキャンセルされることもありません。また、支払い方法の更新も、支払いの証明にはなりません。

リマインダーのチェック前に支払いが回復したケース、請求書が未払いのままのケース、ジョブが再試行されたケースをテストしてください。同じ論理的なイベントには、ドキュメントに記載された再試行の期間内で、同じ冪等性キーを再利用します。

宣言されたフィールドでパーソナライズする

Brew は、サブスクリプションのステータスやプランなどの請求フィールドを、コンタクトに同期できます。イベントのペイロードとコンタクトのフィールドは、別々の情報源です。amount、currency、invoiceNumber、previousPlan、newPlan、failureMessage を使う前に、トリガーのスキーマを確認してください。どのイベントにも、これらのフィールドがすべて含まれるわけではありません。

Stripe オブジェクトのIDは、オートメーションのペイロードから除外されています。請求書やサブスクリプションのIDを推測して、カスタマーポータルのURLを組み立てるのはやめましょう。アプリケーションの認証付きの請求ページか、カスタムイベントで意図的に渡したリンクを使ってください。詳しくは差し込みタグのガイドをご覧ください。

各システムの役割を1つに絞る

Stripe の顧客向けメールの設定を確認しましょう。領収書、支払い失敗の通知、リマインダーを、どちらのシステムが送るかを決めます。Brew のオートメーションを有効にしても、Stripe のメールは止まりません。

メッセージの目的と許諾を確認していない限り、アカウントに関する通知に販促の内容を入れないでください。マーケティング目的のリマインダーには、それに見合った同意と配信停止の処理が必要です。

経路全体を確認する

イベントが Brew に表示されていること、紐づいたオートメーションが稼働中であること、その実行履歴に想定どおりの受信者と結果が記録されていることを確認します。そのうえで、受信したメールと請求ページへのリンクを確認しましょう。イベントは届いているのにメッセージが送信されていない場合は、Webhook の失敗を疑う前に、フィルター、配信除外、送信ドメインの準備状況を確認してください。

まずは、1つのイベントと、テスト済みのメール1通から始めましょう。後続のリマインダーを追加するのは、現在の状態のチェックと再試行時の挙動が、アプリケーションのテストでカバーされてからにしてください。