Quels webhooks Stripe suivre pour le churn, et ce que veut dire chacun

Le Dashboard de Stripe vous montre les abonnements tels qu’ils sont maintenant. L’analyse du churn a besoin de l’histoire qui les y a menés : quand une résiliation a été demandée, quand elle a pris effet, si elle a suivi un paiement échoué, si le client s’était d’abord mis en pause. Cette histoire vit dans les événements webhook, et si vous ne les stockez pas à leur arrivée, vous ne pourrez pas la reconstruire plus tard avec beaucoup de confiance.

Ce guide liste les événements Stripe qui comptent pour le churn, ce que veut dire chacun et ce qu’il faut stocker. Il s’en tient au guide de Stripe using webhooks with subscriptions, à la présentation des webhooks, à la référence API cancel subscription, à la référence Early Fraud Warning et à l’article du support Stripe sur le card updater (tous consultés en novembre 2026).

La liste courte

Événement	Ce qu’il veut dire pour le churn
customer.subscription.created	Un abonnement a démarré. Ce n’est pas une preuve de paiement.
customer.subscription.updated	Quelque chose a changé : offre, coupon, renouvellement, résiliation programmée, pause d’encaissement
customer.subscription.deleted	L’abonnement a pris fin. C’est l’événement de churn.
customer.subscription.paused	Le statut est passé à paused
customer.subscription.resumed	Un abonnement en pause a repris
customer.subscription.trial_will_end	Un essai se termine bientôt
invoice.payment_failed	Une tentative de paiement a échoué
invoice.paid	Une facture a été payée, y compris après un échec
payment_method.automatically_updated	Le card updater a remplacé les données de la carte
charge.dispute.created	Un client a contesté un paiement
radar.early_fraud_warning.created	Une banque émettrice a signalé un paiement comme possible fraude

La suite de ce guide les passe en revue dans l’ordre où ils arrivent généralement.

Démarrer et changer

customer.subscription.created

Stripe l’envoie quand un abonnement est créé. C’est le point de départ de vos données de cohorte, mais ce n’est pas une preuve que le client a payé. Sur une première facture qui échoue, le guide des webhooks indique que l’abonnement reste incomplete. Stockez la date de création, mais ne comptez un client comme acquis qu’une fois la première facture payée.

customer.subscription.updated

Stripe décrit cet événement comme envoyé quand un abonnement démarre ou change : renouvellement, ajout d’un coupon, application d’une réduction, ajout d’une ligne de facture et changement d’offre le déclenchent tous. Pour le churn, trois changements à l’intérieur comptent le plus :

1. Une résiliation est programmée. Quand cancel_at_period_end passe à true, le client a décidé de partir, même si l’abonnement est toujours actif. Stockez cette date. C’est le moment de la décision, qui peut précéder de plusieurs semaines la fin de l’abonnement.
2. Une résiliation est retirée. Quand cancel_at_period_end repasse à false, vous avez gardé le client. Stockez-le aussi, sinon vos rétentions sont invisibles.
3. Une descente en gamme. Un changement d’offre vers un prix moins cher est une contraction, le cousin discret du churn.

Comme cet événement se déclenche pour de nombreuses raisons, comparez le nouvel objet avec previous_attributes dans l’événement pour voir ce qui a réellement changé.

Prendre fin

customer.subscription.deleted

Le guide des webhooks le dit simplement : envoyé quand l’abonnement d’un client prend fin. C’est votre événement de churn. Son horodatage marque l’arrêt du revenu.

Lisez cancellation_details sur l’abonnement, documenté dans la référence API cancel :

• reason vous dit pourquoi il a pris fin : cancellation_requested, payment_failed ou payment_disputed, entre autres. C’est ainsi que vous séparez le churn volontaire du churn involontaire sans deviner.
• feedback contient la raison choisie par le client, comme too_expensive, unused, missing_features ou switched_service.
• comment contient le texte libre écrit par le client.

Si vous ne retenez qu’une chose de ce guide : stockez reason et feedback au moment de la suppression. Pour les indicateurs construits dessus, voir comment calculer le taux de churn et le churn involontaire.

Mettre en pause

customer.subscription.paused et customer.subscription.resumed

Stripe envoie customer.subscription.paused quand le statut d’un abonnement passe à paused, y compris automatiquement quand un essai se termine sans moyen de paiement si vous l’avez configuré ainsi. Il envoie customer.subscription.resumed quand un abonnement en pause reprend, et le guide précise que cela ne s’applique pas quand seul l’encaissement reprend.

La distinction compte : une pause de l’encaissement (pause_collection) ne change pas le statut, vous ne la voyez donc qu’à travers customer.subscription.updated. Si vous proposez des pauses comme outil de rétention, suivez les deux types. Les détails sont dans comment mettre en pause un abonnement sur Stripe.

Un client en pause n’a pas churné. Suivez-le à part, et attribuez toute résiliation ultérieure à la raison d’origine.

Les essais

customer.subscription.trial_will_end

Stripe l’envoie trois jours avant la fin d’un essai, ou tout de suite si l’essai dure moins de trois jours. C’est votre dernier bon moment pour faire un rappel au client, vérifier qu’un moyen de paiement est enregistré, et vous assurer qu’il a atteint la partie du produit qui le fera rester. Le passage de l’essai au payant est un indicateur de churn à part entière ; voir la conversion de l’essai au payant.

Les paiements

invoice.payment_failed

Une tentative de paiement d’une facture a échoué. Sur les renouvellements, cela ouvre la fenêtre de relance. Stockez le numéro de tentative, le code de refus et l’advice code depuis le last_payment_error du PaymentIntent ; notre guide des codes de refus Stripe explique ce que veut dire chacun.

N’enregistrez pas de churn ici. Un paiement échoué est un risque, pas un départ. L’abonnement ne churne que quand il est supprimé, ou quand vos réglages de récupération le font passer dans un état où vous cessez de servir le client.

invoice.paid

La facture a été payée. Après un échec, c’est votre événement de récupération. Stockez la tentative qui a réussi et si le client a d’abord changé de carte. Avec le temps, cela vous dit si ce sont les nouvelles tentatives ou les emails qui font l’essentiel de la récupération.

payment_method.automatically_updated

L’article du support Stripe sur le card updater indique que Stripe crée cet événement quand le card updater modifie les données d’une carte. Il explique un renouvellement qui réussit sur une carte qui aurait sinon expiré. L’enregistrer vous permet de voir quelle part du churn involontaire le réseau évite pour vous ; plus de détails dans les cartes qui expirent.

Litiges et fraude

charge.dispute.created

Un client a contesté un paiement auprès de sa banque. Côté churn, un litige marque presque toujours la fin de la relation, et Stripe enregistre payment_disputed comme reason de résiliation quand un abonnement se termine pour cette cause. Suivez les litiges à part des résiliations : ils coûtent des frais, et ils demandent une réponse.

radar.early_fraud_warning.created

La référence Early Fraud Warning le décrit comme la banque émettrice qui notifie Stripe qu’un paiement pourrait être frauduleux. Ce n’est pas encore un litige. Si vous vendez des abonnements, décidez vite s’il faut rembourser et arrêter les prélèvements futurs. Nous traitons cette décision dans les alertes de fraude précoces Stripe.

Stocker les événements pour que les chiffres tiennent

La présentation des webhooks de Stripe documente quelques comportements qui déterminent la façon de stocker les événements :

1. Les événements peuvent arriver dans le désordre. Stripe ne garantit pas l’ordre de livraison. Utilisez l’heure created de l’événement et les champs de l’objet lui-même, pas l’ordre d’arrivée, pour construire l’historique.
2. Les événements peuvent arriver plusieurs fois. Dédoublonnez sur l’ID de l’événement avant d’écrire quoi que ce soit.
3. Renvoyez vite un 2xx. Stockez l’événement brut, accusez réception, et traitez-le dans une tâche en arrière-plan.
4. Vérifiez les signatures. Contrôlez l’en-tête Stripe-Signature avec le secret de votre endpoint avant de faire confiance à un payload.

Une table simple fonctionne bien : ID de l’événement, type, heure de création, ID client, ID d’abonnement, et le payload brut. Dérivez-en vos tables de churn. Quand une définition change, vous pouvez tout recalculer depuis les événements bruts au lieu de perdre l’historique.

Ce qu’il faut dériver

• Début de l’abonnement (première facture payée), résiliation demandée, résiliation retirée, fin.
• reason et feedback à la fin.
• Début et fin de pause.
• Chaque paiement échoué avec ses codes, et la récupération qui a suivi.
• Litiges et alertes de fraude précoces par client.

Faire tout cela avec NoChurn

NoChurn se connecte à Stripe en un clic et lit ces événements pour vous : vous n’avez pas à construire vous-même le stockage décrit ci-dessus. Il s’en sert pour les relances intelligentes, les emails de récupération que vous relisez, les réponses du parcours d’annulation, les emails de reconquête à J30, J60 et J90, et un score de churn de 0 à 100. Vous pouvez ajouter vos propres données clients par API. Stripe reste la source de vérité pour la facturation. Voir NoChurn + Stripe.