Smart Retries de Stripe : ce qu'ils font bien et où ils s'arrêtent
Si tu utilises Stripe Billing, les Smart Retries sont probablement déjà activés. C'est un bon réglage par défaut et tu devrais le garder. Mais une nouvelle tentative n'est jamais qu'un nouvel essai sur la même carte, et beaucoup de paiements échoués ne se règlent pas ainsi. Savoir exactement où s'arrêtent les nouvelles tentatives indique où porter le reste de l'effort de récupération.
Ce que sont les Smart Retries
Quand un paiement d'abonnement échoue, Stripe peut le retenter automatiquement. Avec les Smart Retries, Stripe choisit le moment de ces tentatives d'après des signaux observés sur l'ensemble de son réseau, plutôt que selon un calendrier fixe. Tu choisis le nombre de tentatives autorisées et la durée de la fenêtre dans tes réglages de facturation, dans la section consacrée aux paiements échoués et à la récupération du revenu.
À la fin de la fenêtre, l'abonnement suit la règle que tu as fixée : annulé, marqué impayé ou laissé en retard. La facture ouverte peut aussi être marquée irrécouvrable.
Ce qu'ils font bien
- Les refus temporaires : une erreur de traitement à la banque, un plafond qui se réinitialise, un solde qui revient. Une tentative plus tard, à un meilleur moment, réussit souvent sans que personne n'intervienne.
- Un calendrier impossible à deviner seul : Stripe voit des tendances sur un très grand nombre de paiements, qu'aucune entreprise ne peut observer à son échelle.
- Zéro entretien : rien à construire, et les tentatives s'arrêtent quand la facture est payée.
Pour beaucoup d'entreprises, cela suffit à ramener une part non négligeable des paiements échoués. Cette part est ta référence : tout ce que tu ajoutes doit être jugé par rapport à elle, pas par rapport à zéro.
Où s'arrêtent les nouvelles tentatives
Une nouvelle tentative débite à nouveau le même moyen de paiement. Chaque fois que la solution passe par le client, retenter ne sert à rien, quel que soit le moment choisi.
| Situation | Une nouvelle tentative peut-elle régler le cas ? | Ce qu'il faut |
|---|---|---|
| Carte expirée | Non, sauf si le réseau de cartes transmet une mise à jour | Une nouvelle carte du client |
| Carte perdue ou volée | Non | Un nouveau moyen de paiement |
| Confirmation 3-D Secure demandée | Non | Le client qui confirme le paiement auprès de sa banque |
| Fonds insuffisants | Souvent, au bon moment | Du temps, et parfois un rappel |
| Refus générique de la banque | Parfois | Une nouvelle tentative, puis une autre carte ou un appel à la banque |
| Carte d'entreprise d'un employé parti | Non | Joindre la personne qui gère désormais la facturation |
Dans chaque ligne « non », le résultat dépend entièrement d'une chose : le client apprend-il qu'il y a un problème, le comprend-il, et peut-il le régler vite ?
Les emails qui accompagnent les nouvelles tentatives
Stripe peut aussi envoyer un email au client quand un paiement échoue, avec un lien pour mettre à jour son moyen de paiement, et peut envoyer un lien quand un paiement demande une authentification. Ces emails sont utiles et tu devrais les activer si tu ne fais rien d'autre. Leurs limites tiennent surtout au contrôle : le texte est générique, le moment suit les réglages de Stripe plutôt que la raison du refus, et le message semble venir d'un prestataire de paiement plutôt que de l'entreprise que le client a choisie.
On compare les deux approches dans relances à ton nom ou emails de Stripe.
Ce qu'on peut ajouter, sans contrarier les nouvelles tentatives
- Ne fais pas tourner un second moteur de tentatives. Débiter la même carte depuis deux systèmes crée des tentatives en double, que les banques et les réseaux de cartes n'aiment pas, et rend les résultats illisibles.
- Ajoute de la communication, pas des tentatives. La pièce manquante est presque toujours un message clair au client, adapté au refus : nouvelle carte, authentification, ou simple information.
- Cale les messages sur les tentatives. Un email court juste après le premier échec, un rappel avant une date de tentative probable, un dernier avis avant la fin de la fenêtre.
- Arrête tout dès que la facture est payée, quel que soit le chemin qui l'a payée.
Les questions à poser sur tes réglages actuels
- Combien de tentatives sont autorisées, et sur combien de jours ? Une fenêtre trop courte abandonne des clients qui allaient payer ; une fenêtre trop longue garde des comptes impayés en vie pendant des semaines.
- Que se passe-t-il à la fin : l'abonnement est-il annulé, marqué impayé ou laissé en retard ? Chaque choix change tes chiffres de revenu et ce que vit le client.
- Les emails de paiement échoué sont-ils activés, et dans quelle langue arrivent-ils chez tes clients ?
- Le lien de confirmation 3-D Secure est-il activé ? Sans lui, les échecs d'authentification ne peuvent pas du tout être récupérés par de nouvelles tentatives.
- Qui, dans ton équipe, regarde les factures encore ouvertes au bout d'une semaine ? Souvent, personne.
Note les réponses. Elles décrivent ce qui arrive aujourd'hui à chaque paiement échoué, et c'est le point de départ de toute amélioration.
Savoir ce que les nouvelles tentatives récupèrent déjà
Avant de juger quoi que ce soit, mesure ta référence : la part des montants échoués que Stripe récupère seul dans une fenêtre fixe, par exemple 30 jours après le premier échec. Fais-le par devise, parce que des montants dans des devises différentes ne s'additionnent pas.
Ensuite, quand tu ajoutes des relances, garde un groupe de factures échouées tirées au hasard qui n'en reçoivent aucune. La différence entre les deux groupes, c'est ce que tes relances apportent. Tout le reste mélange leur effet avec celui des nouvelles tentatives. La méthode est décrite dans mesurer la récupération avec un groupe témoin.
C'est exactement ainsi que Reclaiva est conçu : Stripe continue de retenter, Reclaiva se contente de lire le compte et d'envoyer les messages, et son relevé montre le revenu récupéré en plus de ce que les nouvelles tentatives ont ramené seules.