Welche Stripe-Webhooks Sie für Churn-Tracking brauchen, und was jeder bedeutet

Stripes Dashboard zeigt Ihnen Abos, wie sie jetzt sind. Eine Churn-Analyse braucht die Geschichte, wie sie dorthin gekommen sind: wann eine Kündigung beantragt wurde, wann sie wirksam wurde, ob sie auf eine fehlgeschlagene Zahlung folgte, ob der Kunde zuerst pausiert hat. Diese Geschichte steckt in Webhook-Events, und wenn Sie sie nicht beim Eintreffen speichern, können Sie sie später kaum zuverlässig rekonstruieren.

Dieser Ratgeber listet die Stripe-Events, die für Churn zählen, was jedes bedeutet und was Sie speichern sollten. Er hält sich an Stripes Leitfaden Webhooks mit Abos nutzen, die Webhook-Übersicht, die API-Referenz zum Kündigen von Abos, die Referenz zu Early Fraud Warnings und Stripes Support-Artikel zum Card Updater (alle abgerufen im November 2026).

Die kurze Liste

Event	Was es für Churn bedeutet
customer.subscription.created	Ein Abo hat begonnen. Kein Zahlungsnachweis.
customer.subscription.updated	Etwas hat sich geändert: Plan, Gutschein, Verlängerung, eine geplante Kündigung, eine Pause des Einzugs
customer.subscription.deleted	Das Abo ist beendet. Das ist das Churn-Event.
customer.subscription.paused	Der Status wechselte zu paused
customer.subscription.resumed	Ein pausiertes Abo ist zurück
customer.subscription.trial_will_end	Eine Testphase endet bald
invoice.payment_failed	Ein Zahlungsversuch ist fehlgeschlagen
invoice.paid	Eine Rechnung wurde bezahlt, auch nach einem Fehlschlag
payment_method.automatically_updated	Der Card Updater hat Kartendaten ersetzt
charge.dispute.created	Ein Kunde hat eine Belastung beanstandet
radar.early_fraud_warning.created	Eine Bank hat eine Belastung als möglichen Betrug markiert

Der Rest dieses Ratgebers geht sie in der Reihenfolge durch, in der sie meist auftreten.

Beginn und Änderungen

customer.subscription.created

Stripe sendet dies, wenn ein Abo erstellt wird. Es ist der Anfang Ihrer Kohortendaten, aber kein Nachweis, dass der Kunde bezahlt hat. Bei einer ersten Rechnung, die fehlschlägt, bleibt das Abo laut Leitfaden zu Webhooks incomplete. Speichern Sie das Erstellungsdatum, aber zählen Sie einen Kunden erst als gewonnen, wenn die erste Rechnung bezahlt ist.

customer.subscription.updated

Stripe beschreibt dieses Event als gesendet, wenn ein Abo beginnt oder sich ändert: Verlängern, einen Gutschein hinzufügen, einen Rabatt anwenden, einen Rechnungsposten hinzufügen und den Plan wechseln lösen es alle aus. Für Churn zählen drei Änderungen darin am meisten:

1. Eine Kündigung wird geplant. Wenn cancel_at_period_end auf true wechselt, hat der Kunde entschieden zu gehen, auch wenn das Abo noch aktiv ist. Speichern Sie dieses Datum. Es ist der Zeitpunkt der Entscheidung, der Wochen vor dem Ende des Abos liegen kann.
2. Eine Kündigung wird zurückgenommen. Wenn cancel_at_period_end wieder auf false geht, haben Sie den Kunden gehalten. Speichern Sie auch das, sonst sind Ihre Rettungen unsichtbar.
3. Ein Downgrade. Ein Planwechsel auf einen günstigeren Preis ist Kontraktion, der stille Verwandte des Churns.

Da dieses Event aus vielen Gründen ausgelöst wird, vergleichen Sie das neue Objekt mit previous_attributes im Event, um zu sehen, was sich tatsächlich geändert hat.

Ende

customer.subscription.deleted

Der Leitfaden zu Webhooks sagt es klar: gesendet, wenn das Abo eines Kunden endet. Das ist Ihr Churn-Event. Sein Zeitstempel ist der Moment, in dem der Umsatz aufhörte.

Lesen Sie cancellation_details auf dem Abo, dokumentiert in der Referenz der Cancel-API:

• reason sagt Ihnen, warum es endete: unter anderem cancellation_requested, payment_failed oder payment_disputed. So trennen Sie freiwilligen von unfreiwilligem Churn, ohne zu raten.
• feedback enthält den vom Kunden gewählten Grund, etwa too_expensive, unused, missing_features oder switched_service.
• comment enthält den Freitext, den der Kunde geschrieben hat.

Wenn Sie sich eine Sache aus diesem Ratgeber merken, dann diese: Speichern Sie reason und feedback im Moment der Löschung. Zu den darauf aufbauenden Kennzahlen siehe So berechnen Sie die Churn-Rate und unfreiwilliger Churn.

Pausieren

customer.subscription.paused und customer.subscription.resumed

Stripe sendet customer.subscription.paused, wenn der Status eines Abos zu paused wechselt, auch automatisch, wenn eine Testphase ohne Zahlungsmethode endet und Sie das so konfiguriert haben. Es sendet customer.subscription.resumed, wenn ein pausiertes Abo fortgesetzt wird, und der Leitfaden weist darauf hin, dass es nicht gilt, wenn nur der Zahlungseinzug wieder aufgenommen wird.

Diese Unterscheidung zählt: Eine Pause des Zahlungseinzugs (pause_collection) ändert den Status nicht, Sie sehen sie also nur über customer.subscription.updated. Wenn Sie Pausen als Werkzeug zur Kundenbindung anbieten, verfolgen Sie beide Arten. Details finden Sie in So pausieren Sie ein Abo bei Stripe.

Ein pausierter Kunde hat nicht gekündigt. Weisen Sie ihn getrennt aus und ordnen Sie eine spätere Kündigung dem ursprünglichen Grund zu.

Testphasen

customer.subscription.trial_will_end

Stripe sendet dies drei Tage vor Ende einer Testphase oder sofort, wenn die Testphase kürzer als drei Tage ist. Es ist Ihr letzter guter Moment, um den Kunden zu erinnern, zu prüfen, dass eine Zahlungsmethode hinterlegt ist, und sicherzustellen, dass er den Teil des Produkts erreicht hat, der ihn bleiben lässt. Die Umwandlung von Testphasen in zahlende Kunden ist eine eigene Churn-Kennzahl; siehe Umwandlung von Testphasen in zahlende Kunden.

Zahlungen

invoice.payment_failed

Ein Zahlungsversuch auf einer Rechnung ist fehlgeschlagen. Bei Verlängerungen beginnt damit das Zeitfenster des Mahnwesens. Speichern Sie die Nummer des Versuchs, den Ablehnungscode und den Advice Code aus last_payment_error des PaymentIntent; unser Ratgeber zu Stripe-Ablehnungscodes erklärt, was jeder bedeutet.

Erfassen Sie hier keinen Churn. Eine fehlgeschlagene Zahlung ist ein Risiko, kein Abgang. Das Abo gilt erst als gekündigt, wenn es gelöscht wird oder wenn Ihre Rückgewinnungseinstellungen es in einen Zustand versetzen, in dem Sie den Kunden nicht mehr bedienen.

invoice.paid

Die Rechnung wurde bezahlt. Nach einem Fehlschlag ist das Ihr Rückgewinnungs-Event. Speichern Sie, welcher Versuch erfolgreich war und ob der Kunde vorher seine Karte gewechselt hat. Mit der Zeit sagt Ihnen das, ob Wiederholungen oder E-Mails den Großteil der Rückgewinnung leisten.

payment_method.automatically_updated

Stripes Support-Artikel zum Card Updater sagt, dass Stripe dieses Event erstellt, wenn der Card Updater die Daten einer Karte ändert. Es erklärt eine Verlängerung, die auf einer Karte gelingt, die sonst abgelaufen wäre. Wenn Sie es protokollieren, sehen Sie, wie viel unfreiwilligen Churn das Netzwerk für Sie verhindert; mehr dazu in ablaufende Karten.

Streitfälle und Betrug

charge.dispute.created

Ein Kunde hat eine Belastung bei seiner Bank beanstandet. Für Churn ist ein Streitfall fast immer das Ende der Beziehung, und Stripe speichert payment_disputed als reason der Kündigung, wenn ein Abo aus diesem Grund endet. Erfassen Sie Streitfälle getrennt von Kündigungen: Sie kosten Gebühren und brauchen eine Antwort.

radar.early_fraud_warning.created

Die Referenz zu Early Fraud Warnings beschreibt es als Mitteilung der Bank an Stripe, dass eine Belastung betrügerisch sein könnte. Es ist noch kein Streitfall. Wenn Sie Abos verkaufen, entscheiden Sie schnell, ob Sie erstatten und künftige Belastungen stoppen. Diese Entscheidung behandeln wir in Stripe Early Fraud Warnings.

Events so speichern, dass die Zahlen halten

Stripes Webhook-Übersicht dokumentiert einige Verhaltensweisen, die bestimmen, wie Sie Events speichern:

1. Events können in falscher Reihenfolge eintreffen. Stripe garantiert keine Zustellreihenfolge. Nutzen Sie die created-Zeit des Events und die eigenen Felder des Objekts, nicht die Reihenfolge des Eintreffens, um die Historie aufzubauen.
2. Events können mehr als einmal eintreffen. Deduplizieren Sie anhand der Event-ID, bevor Sie etwas schreiben.
3. Geben Sie schnell einen 2xx zurück. Speichern Sie das Rohevent, bestätigen Sie es und verarbeiten Sie es in einem Hintergrundjob.
4. Prüfen Sie Signaturen. Prüfen Sie den Header Stripe-Signature mit Ihrem Endpoint-Secret, bevor Sie einer Payload vertrauen.

Eine einfache Tabelle funktioniert gut: Event-ID, Typ, Erstellungszeit, Kunden-ID, Abo-ID und die Roh-Payload. Leiten Sie Ihre Churn-Tabellen daraus ab. Wenn sich eine Definition ändert, können Sie aus den Rohevents neu berechnen, statt Historie zu verlieren.

Was Sie ableiten

• Abo-Beginn (erste bezahlte Rechnung), Kündigung beantragt, Kündigung zurückgenommen, beendet.
• reason und feedback am Ende.
• Beginn und Ende von Pausen.
• Jede fehlgeschlagene Zahlung mit Codes und die darauf folgende Rückgewinnung.
• Streitfälle und Early Fraud Warnings nach Kunde.

Das mit NoChurn umsetzen

NoChurn verbindet sich mit einem Klick mit Stripe und liest diese Events für Sie, sodass Sie die oben beschriebene Speicherung nicht selbst bauen müssen. Es nutzt sie für Smart Retries, Mahnmails, die Sie prüfen, Antworten im Kündigungsflow, Win-back-Mails an Tag 30, 60 und 90 und einen Churn-Score von 0 bis 100. Sie können Ihre eigenen Kundendaten per API ergänzen. Stripe bleibt die maßgebliche Quelle für die Abrechnung. Siehe NoChurn + Stripe.