Brew、Sequenzy、Loops、Customer.io の Stripe 連携を、対応イベント、同期される請求データ、セットアップ、リマインダーの対象条件で比較します。
この比較は Brew が公開しているものです。2026年9月28日に、リンク先の各社の製品ドキュメントを確認しました。これはドキュメントに基づく比較であり、すべてのプラットフォームを実際に試したと主張するものではありません。最新のプランの上限は、各ベンダーの料金ページで確認してください。
更新のタイミングで顧客のカード決済が失敗し、Stripe は invoice.payment_failed を送信します（請求書は未払いのまま残ります）。メールツールは、支払いのリマインダーのフローを開始します。顧客は翌朝カードを更新しましたが、その日の午後には、2通目のリマインダーがそのまま送られてしまいます。
多くのメール配信プラットフォームが「Stripe 連携」を掲げていますが、その裏の仕組みはさまざまです。Stripe の Webhook をそのまま受け取り、顧客のプランとサブスクリプションのステータスを同期するツールもあれば、請求のアクティビティを独自のイベント名に変換するツールもあります。Webhook を自分でつなぐためのガイドを用意しているだけのツールもあります。
こうした違いによって、トライアルのリマインダーがトライアルの状態を確認できるか、カードが使えるようになった時点で支払い失敗のフォローアップが止まるかが決まります。このガイドでは、4つのプラットフォームをこれらの観点で比較します。
saas.purchase や saas.payment_failed のようなSaaS向けのイベントに変換します。2026年9月28日に各ベンダーの Stripe 関連のドキュメントを確認し、次の点を比較しました。
| ツール | 接続 | イベント | コンタクトに保存される請求データ | フローの停止 |
|---|---|---|---|---|
| Brew | OAuth。Webhook は Brew が登録 | チェックアウト、顧客、サブスクリプション、請求書、見積書、支払いにわたる22種類の Stripe イベント | stripe_subscription_status、stripe_subscription_plan、stripe_plan_amount_cents、stripe_trial_end、stripe_renews_at、stripe_delinquent |
同期したコンタクトフィールドに明示的な条件を設定。特定の未払いの請求書は、アプリケーション側でチェック |
| Sequenzy | OAuth | Stripe のデータから生成されるSaaSのライフサイクルイベント | MRR、LTV、trial、past-due、churned などのタグ |
シーケンスごとに停止条件を1つ（例：saas.purchase） |
| Loops | 設定画面の「Connect to Stripe」から接続 | 不審請求（dispute）を含む20種類以上の Stripe イベント | メールアドレス、名、姓 | ワークフローの分岐 |
| Customer.io | Webhook トリガー型のキャンペーンを作るためのガイド | 自分で送信したイベント | 自分でマッピングしたデータすべて | キャンペーンの条件 |
Brew は Stripe Apps のOAuthフローで接続するため、APIキーを目にすることはありません。そのうえで Brew が自ら Webhook を登録し、22種類のイベントを受信します。
checkout.session.completed に加えて、遅延決済の成功と失敗のイベント。trial_will_end、削除。payment_failed、次回の請求予定。charge.refunded、refund.created、payment_intent.payment_failed。検証済みのイベントは、それを使う稼働中のオートメーションをすべて開始します。顧客とサブスクリプションのイベントでは、Stripe の顧客がオーディエンスに作成または更新され、フィルターに使える stripe_* フィールドも付与されます。「Stripe から顧客を同期」ボタンを使うと、既存の Stripe 顧客をバックグラウンドで取り込めます。処理が中断されても再開できます。
メール本文では、amount、currency、invoiceNumber、previousPlan と newPlan、failureMessage、declineCode などの差し込みタグを使えます。ペイロードからは Stripe オブジェクトのIDが意図的に除外されているため、IDを差し込みタグやフィルターに使うことはできません。
Brew はイベントを受け取る側であり、決済の再試行、返金、サブスクリプションの変更はできません。「待機」のあと、contact.stripe_subscription_status を使う条件は Brew のコンタクトフィールドの現在の値を読み取りますが、イベントのフィールドには元のペイロードが残ったままです。コンタクトの値を読んでも Stripe に問い合わせるわけではなく、特定の請求書が支払われたことの証明にもなりません。後続の支払いリマインダーのイベントを送信する前に、アプリケーション側でその請求書を確認してください。コンタクトの更新や新しいイベントによって、進行中の実行が自動的にキャンセルされることはありません。詳しくはオートメーションのガイドをご覧ください。
Brew は、メールのデザインと送信も行います。支払いやトライアルのメールはブランドのデザインシステムをもとに作られ、認証済みのドメインから送信されるので、別のテンプレートツールは必要ありません。
Sequenzy の Stripe 連携は、OAuthで接続します。最初の同期の前に、対象に含める商品と、引き継ぐメタデータを選びます。そのうえで、請求のアクティビティをSaaSのライフサイクルイベントに変換します。購入、トライアルの開始と終了、解約、チャーン、支払いの失敗、アップグレード、ダウングレード、返金などです。
コンタクトには、数値の属性としてMRRとLTVが、さらに customer、trial、past-due、churned のようなステータスタグが付与されます。各シーケンスには停止条件が1つあり、各ステップの前に毎回チェックされます。そのため、トライアルのシーケンスは、フィルターを追加しなくても saas.purchase で終了できます。
Sequenzy は、コンタクトをメールアドレスだけで照合します。顧客に紐付いていないゲストの Checkout セッションは、売上の同期の対象外です。
Sequenzy は、Stripe の生のイベント名は必要なく、すぐに使えるサブスクリプションのライフサイクルの状態がほしいSaaSチームに向いています。
Loops は、設定画面の Connect to Stripe から接続します。同期されるのは、メールアドレス、名、姓です。新しいメールアドレスならコンタクトを作成し、customer.deleted を受け取ると、コンタクトを配信停止にするか削除できます。顧客、サブスクリプション、請求書、チェックアウト、見積書のイベントに加えて、charge.dispute.created と charge.dispute.closed など、20種類以上のイベントでワークフローを開始できます。Loops は2026年4月に、サブスクリプションのイベントを追加しました。
Loops が処理するのは、メールアドレスを含むイベントだけです。ドキュメントには、同期されるプロパティとしてプランやステータスが挙げられていないため、請求の状態を条件に使うには、別のソースからデータを取り込む必要があります。
Customer.io のドキュメントでは、Stripe との連携を自分で組み立てるパターンとして説明しています。Stripe の Webhook の送信先を Webhook トリガー型のキャンペーンに設定し、メールアドレスでユーザーを特定して、そのIDを Stripe の顧客IDに設定します。そこからは、請求に関するどんなデータも自由にモデル化して、メール、SMS、プッシュ通知で使えます。ほかの3つより設定の手間はかかりますが、データモデルをより細かく制御できます。
Stripe Billing は、顧客に直接メールを送ることができます。カード決済が失敗するたびの通知、無料トライアル終了の7日前のリマインダー、更新のリマインダー、デフォルトのカードの有効期限が切れる1か月前の警告を送れます。これらのメールには、顧客が支払い方法を更新できるページへのリンクが含まれています。
これらを有効にしたうえで、Brew や Loops でも invoice.payment_failed を起点にフローを作ると、1回の失敗について顧客に2通のメールが届きます。それぞれのメッセージをどちらのシステムが送るかを決めましょう。たとえば、支払い方法を更新するリンクは Stripe に任せ、事情の説明とフォローアップはメール配信プラットフォームで行う、という分担があります。自社のメールに入れたリンクが今も有効かどうかも確認してください。
| 求めるもの | 検討すべきツール |
|---|---|
| Stripe の生のイベント、同期される請求フィールド、そしてメールのデザインと送信をひとつの製品で | Brew |
| SaaSのライフサイクルイベントと、組み込みの停止条件 | Sequenzy |
| Stripe イベントに幅広く対応した、シンプルなSaaS向けメール配信プラットフォーム | Loops |
| 複数のチャネルにまたがるデータモデルを完全に制御すること | Customer.io |
サブスクリプションなら、customer.subscription.trial_will_end、invoice.payment_failed、invoice.paid、customer.subscription.updated、customer.subscription.deleted です。Stripe は trial_will_end をトライアル終了の3日前に送信します。トライアルが短縮された場合は、すぐに送信します。
これらのツールが行うのは、メールの送信です。支払いの再試行やカードの更新は Stripe で行われます。Brew のドキュメントにも、決済の作成やサブスクリプションの変更はできないと明記されています。
マーケティングメールなら、必要です。Brew の Stripe のドキュメントでは、コンタクトのデータを同期しても、そのコンタクトにメールを送る許諾にはならないとしています。既存のサブスクリプションに関する領収書や支払いの通知は、別のカテゴリーです。トランザクションメールの記事をご覧ください。
Stripe のテストモードではできません。Brew が接続するのは本番の Stripe アカウントで、テストモードのイベントでは、コンタクトの同期やオートメーションの開始は行われません。オートメーションは下書きのままにして、管理下にある受信者でテストしてください。Loops のドキュメントでは、テスト用の顧客を作成するか、Stripe CLIの trigger コマンドでイベントを発生させる方法が紹介されています。
Brew 側の詳細は、Stripe 連携のページをご覧ください。そのうえで、フローを1つ下書きとして作り、公開する前に、管理下にある受信者でテストしてみましょう。
