E-Mail-Integrationen für Stripe im Vergleich: Events, synchronisierte Abrechnungsdaten, Einrichtung, Erinnerungsbedingungen. Brew, Sequenzy, Loops, Customer.io.
Dieser Vergleich stammt von Brew. Wir haben die verlinkte Produktdokumentation am 28. September 2026 geprüft. Es ist ein Vergleich der Dokumentation, kein Praxistest jeder einzelnen Plattform. Prüfe die aktuellen Limits der Pläne auf der Preisseite des jeweiligen Anbieters.
Bei der Verlängerung schlägt die Kartenzahlung eines Kunden fehl, und Stripe sendet invoice.payment_failed (die Rechnung bleibt offen). Dein E-Mail-Tool startet seinen Flow mit Zahlungserinnerungen. Am nächsten Morgen aktualisiert der Kunde seine Karte, und am Nachmittag geht trotzdem die zweite Erinnerung raus.
Viele E-Mail-Plattformen haben eine „Stripe-Integration“ im Angebot. Was hinter diesem Etikett steckt, funktioniert aber ganz unterschiedlich. Ein Tool empfängt die rohen Stripe-Webhooks und synchronisiert Plan und Abo-Status eines Kunden. Ein anderes übersetzt Abrechnungsaktivität in eigene Event-Namen. Ein drittes gibt dir eine Anleitung, mit der du die Webhooks selbst anbindest.
Diese Unterschiede entscheiden darüber, ob eine Erinnerung zur Testphase den Status der Testphase prüfen kann und ob ein Follow-up zu einer fehlgeschlagenen Zahlung aufhört, sobald die Karte wieder funktioniert. Dieser Leitfaden vergleicht vier Plattformen genau in diesen Punkten.
saas.purchase und saas.payment_failed um.Wir haben am 28. September 2026 die Stripe-Dokumentation jedes Anbieters geprüft und Folgendes verglichen:
| Tool | Verbindung | Events | Abrechnungsdaten am Kontakt | Flow stoppen |
|---|---|---|---|---|
| Brew | OAuth; Brew registriert den Webhook für dich | 22 Stripe-Events zu Checkout, Kunde, Abo, Rechnung, Angebot und Zahlung | stripe_subscription_status, stripe_subscription_plan, stripe_plan_amount_cents, stripe_trial_end, stripe_renews_at, stripe_delinquent |
Explizite Bedingungen auf synchronisierten Kontaktfeldern; Prüfung einer bestimmten unbezahlten Rechnung in deiner Anwendung |
| Sequenzy | OAuth | Aus Stripe abgeleitete SaaS-Lifecycle-Events | MRR, LTV und Tags wie trial, past-due, churned |
Eine Abbruchbedingung pro Sequenz, zum Beispiel bei saas.purchase |
| Loops | „Connect to Stripe“ in den Einstellungen | Über 20 Stripe-Events, darunter Zahlungsanfechtungen | E-Mail-Adresse, Vor- und Nachname | Verzweigungen im Workflow |
| Customer.io | Eine Anleitung für Kampagnen, die per Webhook ausgelöst werden | Die Events, die du sendest | Alles, was du zuordnest | Bedingungen in der Kampagne |
Brew verbindet sich per OAuth über Stripe Apps und sieht deine API-Keys deshalb nie. Danach registriert Brew den Webhook selbst und abonniert 22 Event-Typen:
checkout.session.completed sowie die Events für erfolgreiche und fehlgeschlagene asynchrone Zahlungen.trial_will_end, gelöscht.payment_failed, bevorstehend.charge.refunded, refund.created, payment_intent.payment_failed.Jedes verifizierte Event startet alle Automatisierungen mit dem Status „Live“, die es nutzen. Kunden- und Abo-Events legen den Stripe-Kunden außerdem in deiner Zielgruppe an oder aktualisieren ihn, samt Feldern stripe_*, nach denen du filtern kannst. Über den Button „Kunden aus Stripe synchronisieren“ übernimmst du bestehende Stripe-Kunden nachträglich im Hintergrund; wird der Import unterbrochen, lässt er sich fortsetzen.
In der E-Mail selbst kannst du Merge-Tags wie amount, currency, invoiceNumber, previousPlan und newPlan, failureMessage und declineCode verwenden. IDs von Stripe-Objekten lassen die Payloads bewusst weg, du kannst sie also weder als Merge-Tags noch als Filter verwenden.
Brew empfängt Events; es kann keine Zahlung erneut einziehen, keine Rückerstattung auslösen und kein Abo ändern. Nach einem Schritt „Warten“ liest eine Bedingung mit contact.stripe_subscription_status den aktuellen Wert des Kontaktfelds in Brew, während die Event-Felder die ursprüngliche Payload behalten. Das Lesen des Kontaktfelds fragt Stripe nicht ab und beweist nicht, dass eine bestimmte Rechnung bezahlt wurde. Prüf diese Rechnung in deiner Anwendung, bevor du ein späteres Event für eine Zahlungserinnerung auslöst. Kontaktaktualisierungen und neue Events brechen laufende Ausführungen nicht automatisch ab. Mehr dazu im Leitfaden zu Automatisierungen.
Brew gestaltet und versendet die E-Mails auch. E-Mails zu Zahlungen und Testphasen nutzen das Designsystem deiner Marke und gehen von deiner verifizierten Domain raus. Ein separates Vorlagen-Tool brauchst du also nicht.
Die Stripe-Integration von Sequenzy verbindet sich per OAuth. Vor der ersten Synchronisierung wählst du, welche Produkte einbezogen und welche Metadaten übernommen werden. Danach übersetzt Sequenzy Abrechnungsaktivität in SaaS-Lifecycle-Events, darunter Käufe, Beginn und Ende der Testphase, Kündigung, Churn, fehlgeschlagene Zahlung, Upgrade, Downgrade und Rückerstattung.
Kontakte erhalten MRR und LTV als numerische Attribute sowie Status-Tags wie customer, trial, past-due und churned. Jede Sequenz hat eine Abbruchbedingung, die vor jedem Schritt geprüft wird. So kann eine Sequenz für die Testphase ohne zusätzliche Filter bei saas.purchase enden.
Sequenzy ordnet Kontakte nur über die E-Mail-Adresse zu. Gast-Checkout-Sitzungen ohne Stripe-Kunden lässt es bei der Umsatzsynchronisierung außen vor.
Sequenzy passt zu SaaS-Teams, die fertige Lifecycle-Status für Abos wollen und die rohen Event-Namen von Stripe nicht brauchen.
In Loops verbindest du Stripe in den Einstellungen über „Connect to Stripe“. Synchronisiert werden E-Mail-Adresse, Vor- und Nachname. Ist die E-Mail-Adresse neu, legt Loops einen Kontakt an, und bei customer.deleted kann es Kontakte abmelden oder löschen. Mehr als zwanzig Events können Workflows starten, darunter Kunden-, Abo-, Rechnungs-, Checkout- und Angebots-Events sowie charge.dispute.created und charge.dispute.closed. Im April 2026 hat Loops weitere Abo-Events ergänzt.
Loops verarbeitet nur Events, die eine E-Mail-Adresse enthalten. Plan oder Status führt die Dokumentation nicht unter den synchronisierten Eigenschaften auf. Für Bedingungen zum Abrechnungsstatus brauchst du also Daten aus einer anderen Quelle.
Customer.io dokumentiert Stripe als Muster, das du selbst baust. Du richtest die Webhooks von Stripe auf eine Kampagne, die per Webhook ausgelöst wird, findest die Person über ihre E-Mail-Adresse und setzt ihre ID auf die Stripe-Kunden-ID. Danach kannst du beliebige Abrechnungsdaten abbilden und für E-Mail, SMS und Push nutzen. Das kostet mehr Einrichtung als bei den anderen drei, gibt dir aber mehr Kontrolle über das Datenmodell.
Stripe Billing kann Kunden selbst E-Mails schicken: einen Hinweis nach jeder fehlgeschlagenen Kartenzahlung, eine Erinnerung sieben Tage vor dem Ende einer kostenlosen Testphase, Erinnerungen vor der Verlängerung und eine Warnung einen Monat, bevor die Standardkarte abläuft. Diese E-Mails verlinken auf eine Seite, auf der der Kunde seine Zahlungsmethode aktualisieren kann.
Wenn du sie aktivierst und zusätzlich in Brew oder Loops einen Flow auf invoice.payment_failed baust, bekommen Kunden zwei E-Mails zu einem einzigen Fehlschlag. Leg fest, welches System welche Nachricht versendet. Eine mögliche Aufteilung: Den Link zum Aktualisieren der Zahlungsdaten überlässt du Stripe, und deine E-Mail-Plattform übernimmt Erklärung und Follow-up. Prüf, ob der Link, den du in deine eigenen E-Mails setzt, noch gültig ist.
| Du suchst … | Infrage kommt |
|---|---|
| rohe Stripe-Events, synchronisierte Abrechnungsfelder sowie Gestaltung und Versand der E-Mails in einem Produkt | Brew |
| SaaS-Lifecycle-Events und eingebaute Abbruchbedingungen | Sequenzy |
| eine einfache E-Mail-Plattform für SaaS, die viele Stripe-Events abdeckt | Loops |
| volle Kontrolle über das Datenmodell, über mehrere Kanäle hinweg | Customer.io |
Bei Abos: customer.subscription.trial_will_end, invoice.payment_failed, invoice.paid, customer.subscription.updated und customer.subscription.deleted. Stripe sendet trial_will_end drei Tage vor dem Ende einer Testphase oder sofort, wenn die Testphase verkürzt wird.
Sie versenden die E-Mails. Erneute Zahlungsversuche und Kartenaktualisierungen passieren in Stripe. Laut seiner Dokumentation kann Brew keine Belastungen erstellen und keine Abos ändern.
Für Marketing-E-Mails ja. Laut der Stripe-Dokumentation von Brew ist das Synchronisieren von Kontaktdaten keine Erlaubnis, diese Kontakte anzuschreiben. Belege und Zahlungshinweise zu einem bestehenden Abo sind eine andere Kategorie. Mehr dazu unter Transaktions-E-Mails.
Nicht im Stripe-Testmodus: Brew verbindet Live-Konten von Stripe, und Events aus dem Testmodus synchronisieren keine Kontakte und starten keine Automatisierungen. Lass die Automatisierung im Status „Entwurf“ und teste sie mit Empfängern, die du kontrollierst. Die Dokumentation von Loops schlägt vor, Testkunden anzulegen oder Events mit dem Befehl trigger der Stripe-CLI auszulösen.
Alle Details zu Brew findest du auf der Seite zur Stripe-Integration. Bau danach einen Flow als Entwurf und teste ihn mit Empfängern, die du kontrollierst, bevor du ihn veröffentlichst.
