Réduire le churn involontaire dans Maxio
Comment Maxio (ex-Chargify) gère les paiements échoués : calendriers de relance, tentatives, états past due et unpaid, mise à jour de carte et webhooks.
Par Florian
Le churn involontaire est la part du churn que personne n’a choisie : un renouvellement échoue, personne ne met à jour le moyen de paiement, et l’abonnement prend fin. Maxio Advanced Billing (anciennement Chargify) vous donne nativement la plupart des outils pour l’éviter : un calendrier de relance configurable, des nouvelles tentatives et des emails par étape, une action finale, un Billing Portal où les clients mettent à jour leur carte, et des webhooks pour chaque étape. Ce guide explique comment ces briques se comportent et comment bien les configurer.
Tout le comportement de Maxio décrit ici vient de sa documentation : comprendre le fonctionnement des relances, configurer les relances par carte, configurer les relances ACH, configurer les relances par prélèvement, mettre à jour le moyen de paiement d’un abonnement, paramètres des emails de relance et événements webhook (tous consultés en novembre 2026).
Ce qui se passe quand un renouvellement échoue dans Maxio
À la fin de la période d’un abonnement, Maxio tente de prélever le moyen de paiement enregistré. Si le prestataire refuse, l’abonnement passe en Past Due et Maxio commence à suivre votre calendrier de relance. À partir de là, trois issues sont possibles :
- Une nouvelle tentative réussit, ou le client met à jour son moyen de paiement et paie, et l’abonnement redevient Active.
- Le calendrier arrive à son terme et l’action finale s’applique : l’abonnement est soit Canceled (il cesse d’accumuler des montants dus), soit marqué Unpaid (il continue d’en accumuler).
- Vous intervenez à la main, par exemple en enregistrant un paiement.
Un abonnement Unpaid peut redevenir Active : la doc de Maxio décrit l’usage de Retry/Reactivate pour encaisser le paiement, ou de Reset to $0 pour annuler le solde.
Quelques cas se comportent différemment, d’après la présentation des relances :
- Les abonnements prépayés ne sont pas marqués past due. Ils restent actifs tant que le solde dure, puis sont suspendus.
- Les abonnements à durée déterminée dont le terme arrive pendant les relances expirent au lieu de rester past due, et ne sont pas annulés plus tard si les relances arrivent à leur terme.
- Les abonnements en paiement manuel (facturés sur facture) reçoivent des emails de rappel, mais les relances ne retentent pas les factures ouvertes.
- Les refus à haut risque ou pour fraude désactivent le profil de paiement au lieu de poursuivre les tentatives.
Le calendrier de relance
Les relances se trouvent dans Config, puis Retries & Dunning. Maxio les organise en réglages d’email, calendrier des tentatives et relances, et étape finale. Les emails de relance se configurent ici, séparément des autres emails de votre site.
Limites et règles par moyen de paiement
| Moyen de paiement | Règle selon la doc de Maxio |
|---|---|
| Carte bancaire | Jusqu’à 365 jours et/ou 30 étapes par calendrier |
| ACH | 2 nouvelles tentatives plus 1 action finale, selon les règles du réseau ACH |
| Prélèvement | Au moins 5 jours entre les tentatives ; l’action finale ne peut pas retenter |
| Paiement manuel | Emails de rappel seulement, pas de nouvelles tentatives |
Vous pouvez définir des stratégies pour tout le site par moyen de paiement, et des stratégies par produit ou famille de produits à côté, pour qu’une offre annuelle entreprise n’ait pas à partager un calendrier avec une offre mensuelle en libre-service.
Les étapes : tentative, email, ou les deux
Chaque étape du calendrier a un numéro de jour et deux interrupteurs :
- Retry Payment : tenter le prélèvement ce jour-là. Vous pouvez le désactiver pour envoyer un email sans retenter, sauf à l’étape du Day 1, qui retente toujours.
- Send Email : les modèles prédéfinis démarrent avec les emails désactivés, il faut donc activer chaque email voulu et modifier son objet et son texte.
Comment Maxio suit l’étape en cours
Maxio calcule l’étape en cours d’un abonnement à partir de la durée depuis laquelle il est past due et de votre calendrier actuel, plutôt que de stocker l’étape. La conséquence pratique, indiquée dans la doc : modifier le calendrier peut changer l’étape à laquelle un abonnement past due semble se trouver. Faites les changements de calendrier délibérément, et attendez-vous à ce que les abonnements déjà en relance suivent le nouveau calendrier.
À noter aussi : si un abonnement atteint sa date de renouvellement habituelle pendant les relances et qu’il n’y a pas d’étape de relance ce jour-là, le renouvellement a quand même lieu. S’il échoue, l’abonnement reste en relance et continue avec l’étape suivante.
Faire mettre à jour le moyen de paiement par le client
La plupart du revenu récupéré sur les refus définitifs et les cartes expirées vient du client qui saisit de nouvelles coordonnées. Maxio offre plusieurs façons de l’y amener, d’après sa doc sur la mise à jour du moyen de paiement et les paramètres des emails de relance :
- Dans les emails de relance : une variable
update_urldonne l’URL que le client peut utiliser pour mettre à jour son moyen de paiement. Si vous utilisez le Billing Portal, les modèles peuvent plutôt renvoyer vers la page de gestion du portail. - Depuis la page de l’abonnement : l’onglet Payment Details a une action pour envoyer au client par email un lien vers sa page en libre-service, et vous pouvez aussi copier l’URL de cette page pour l’envoyer vous-même.
- Dans le Billing Portal : les clients se connectent, choisissent l’abonnement, choisissent de mettre à jour le moyen de paiement, sélectionnent un moyen enregistré ou en ajoutent un nouveau, et enregistrent. Le portail a aussi un modèle d’URL directe vers la page de mise à jour du moyen de paiement d’un abonnement donné.
Deux limites à connaître :
- Tant qu’un paiement est encore en attente (par exemple un prélèvement non réglé), le moyen de paiement ne peut pas être changé, y compris depuis la page en libre-service.
- Les emails de relance ne sont envoyés que tant qu’un abonnement est past due ; ils ne sont pas traités pour les abonnements expirés ou annulés. Tout ce que vous voulez envoyer après l’action finale demande un autre canal.
Les webhooks à brancher dans votre appli
La référence des événements webhook de Maxio liste les événements dont vous avez besoin pour refléter l’état des relances dans votre produit :
| Événement | Ce qu’il vous dit | Que faire |
|---|---|---|
payment_failure |
Une tentative de paiement a échoué, y compris les nouvelles tentatives | Afficher une bannière dans l’appli, journaliser la tentative |
payment_success |
Un paiement a réussi, y compris les nouvelles tentatives | Retirer la bannière |
dunning_step_reached |
L’abonnement a atteint une étape de relance (le contenu inclut l’étape en cours et la suivante) | Caler vos propres rappels ou avis dans l’appli |
subscription_state_change |
L’état de l’abonnement a changé | Relire l’état, puis donner ou retirer l’accès |
Maxio précise qu’un paiement qui remet à jour un compte past due génère payment_success et subscription_state_change, mais pas renewal_success. Si votre appli n’écoute que les événements de renouvellement, elle manquera les récupérations. Maxio tente de livrer chaque webhook jusqu’à six fois (guide des webhooks) : rendez vos handlers idempotents.
Un plan de configuration
- Calez le calendrier sur la période de facturation. Pour les offres mensuelles, terminez les relances avant le renouvellement suivant pour ne pas empiler les périodes impayées. Les offres annuelles peuvent se permettre une fenêtre plus longue.
- Concentrez tentatives et emails au début. Retentez au jour 1, puis tous les quelques jours pendant les deux premières semaines, quand le client se souvient encore d’utiliser le produit.
- Activez les emails. Ils démarrent désactivés. Écrivez un premier email court avec le lien
update_url, deux ou trois rappels, et un dernier avis qui donne la date de fin de l’accès. - Séparez les stratégies par produit quand les publics diffèrent. Les clients entreprise ont souvent besoin d’une fenêtre plus longue et d’un contact humain, pas de plus d’emails automatiques.
- Choisissez l’action finale volontairement. Cancel arrête l’accumulation des montants dus ; Unpaid la poursuit, ce qui n’a de sens que si vous comptez encaisser le solde.
- Respectez les règles ACH et prélèvement. Ne concevez pas un calendrier de type carte pour les paiements bancaires ; Maxio impose les limites de toute façon.
- Reflétez l’état avec les webhooks, en vous appuyant sur
subscription_state_change, et affichez une bannière dans votre produit tant que l’abonnement est past due. - Passez en revue chaque mois les abonnements annulés pour non-paiement et cherchez des tendances : un produit, une passerelle, un type de carte.
Le faire avec NoChurn
Les relances de Maxio restent en place : nouvelles tentatives, facturation, taxes et prélèvement restent dans Maxio et votre passerelle. NoChurn se connecte avec une clé d’API Maxio, importe les clients et les abonnements, suit les webhooks de Maxio et ajoute des emails de récupération rédigés par l’IA, que vous relisez avant leur envoi, avec un lien pour mettre à jour le profil de paiement. En plus des relances, il ajoute des parcours d’annulation avec raisons, offres (un coupon ou un changement de produit sur l’abonnement Maxio) et un bouton d’annulation en un clic toujours visible, des emails de reconquête à J30, J60 et J90 selon la raison d’annulation, et un churn score de 0 à 100. Les litiges viennent de la passerelle derrière Maxio ; avec Stripe ou Braintree, NoChurn réunit les preuves et rédige une réponse que vous relisez. Voir NoChurn + Maxio.