Les paiements échoués sur Paddle Billing, et ce que vous pouvez ajouter

Quand un renouvellement échoue sur Paddle Billing, beaucoup de choses se passent sans vous : Paddle est le marchand officiel (merchant of record), il retente le paiement et peut écrire au client. C’est un vrai avantage par rapport à des relances construites vous-même. Cela veut aussi dire que vous devez savoir exactement ce que fait Paddle, pour ne pas le dupliquer ni laisser de trous.

Ce guide explique comment Paddle Billing gère un paiement d’abonnement échoué, ce que Paddle Retain ajoute, comment les clients mettent à jour leurs informations de paiement, et ce que vous pouvez améliorer vous-même. Il s’en tient à la documentation de Paddle : le changelog des relances par défaut, configurer Payment Recovery et les relances, Payment Recovery, mettre à jour les informations de paiement et l’article d’aide de Paddle sur le rythme des nouvelles tentatives de Retain (tous consultés en novembre 2026).

Ce qui se passe quand un renouvellement échoue

Pour un abonnement prélevé automatiquement, le guide des relances de Paddle décrit la séquence :

1. Le paiement de la transaction de renouvellement échoue.
2. Le statut de l’abonnement passe à past_due.
3. Paddle envoie transaction.payment_failed pour la tentative, puis transaction.past_due et subscription.past_due quand la transaction et l’abonnement passent en impayé.
4. Paddle retente le paiement.
5. Si une tentative réussit, l’abonnement repasse à active et n’est plus en impayé.

Les nouvelles tentatives par défaut, avec ou sans Retain

Le changelog 2025 de Paddle a ouvert les nouvelles tentatives automatiques après un échec de paiement à tous les utilisateurs de Paddle Billing. Les paiements échoués des abonnements prélevés automatiquement sont retentés jusqu’à sept fois sur 30 jours, même si vous n’avez pas activé Paddle Retain.

Deux limites à connaître :

• Comptes live uniquement. Paddle indique que les nouvelles tentatives automatiques ne tournent que sur les comptes live. Aucune n’a lieu en sandbox : vous ne pouvez donc pas y tester le calendrier complet.
• Prélèvement automatique uniquement. Pour les abonnements prélevés manuellement (payés sur facture), Paddle Retain ne fait rien quand ils sont en impayé. Paddle a fait passer ces abonnements en past_due en 2024, mais les relancer est à votre charge.

Ce qui se passe à la fin de la fenêtre

Selon l’article d’aide de Paddle sur le rythme des nouvelles tentatives, vous choisissez ce qui arrive à un abonnement à la fin de la fenêtre de récupération : le résilier, le mettre en pause ou le laisser en impayé. Par défaut, il est résilié au bout de 30 jours, et la fenêtre se règle depuis le dashboard Paddle.

Choisissez en connaissance de cause. Résilier est propre pour les rapports. Mettre en pause garde l’abonnement, pour que le client puisse revenir sans nouveau checkout. Laisser en impayé garde la porte ouverte mais peut laisser à des clients un accès qu’ils ne paient pas, sauf si votre app vérifie le statut.

Ce que Paddle Retain ajoute

Payment Recovery fait partie de Paddle Retain. En plus des nouvelles tentatives par défaut, la documentation de Paddle décrit :

Fonctionnalité	Ce qu’elle fait selon Paddle
Tactical Retries	Retente les paiements échoués à des moments choisis selon le type de moyen de paiement, la localisation du client et d’autres informations
Emails de récupération	Jusqu’à quatre emails de récupération de paiement
Autres canaux	Rappels de paiement dans l’app et par SMS
Fin des relances	Peut mettre en pause ou résilier automatiquement les abonnements quand toutes les tentatives sont épuisées

Par défaut, les relances de Retain s’étalent sur 30 jours. Vérifiez dans votre dashboard Paddle si Payment Recovery est activé sur votre compte avant de supposer que tout cela s’applique.

Si vous utilisez Retain, laissez-lui les nouvelles tentatives et les emails. Faire tourner un second calendrier de tentatives sur la même carte ajoute des essais sans ajouter d’information, et deux séquences de relance dans la même boîte mail ressemblent à du spam.

Laisser les clients mettre à jour leurs informations de paiement

La plupart des refus définitifs ne se récupèrent que si le client vous donne une nouvelle carte. Le guide mettre à jour les informations de paiement de Paddle liste les options :

1. Portail client. Le portail de Paddle est activé par défaut et permet aux clients de mettre à jour leur moyen de paiement sans aucun écran de votre côté.
2. Session du portail client. Vous pouvez créer un lien profond authentifié qui mène directement à la page de mise à jour du moyen de paiement pour un abonnement donné, pour que le client n’ait pas à se connecter.
3. URL de gestion de l’abonnement. Paddle renvoie pour chaque abonnement un lien update_subscription_payment_method que vous pouvez afficher dans votre app.
4. Transaction de mise à jour du moyen de paiement. Appelez GET /subscriptions/:id/update-payment-method-transaction. Si l’abonnement est past_due, il renvoie la transaction impayée la plus récente. Ouvrez son checkout.url, ou passez l’ID de transaction à Paddle.js. Cela ne fonctionne que si collection_mode vaut automatic.

Une étape de configuration piège souvent : le lien de paiement par défaut doit être défini dans votre compte Paddle et approuvé avant que les clients puissent mettre à jour leurs informations de paiement. Paddle l’utilise aussi dans ses emails de relance.

Quand un abonnement impayé est réglé après une mise à jour, Paddle envoie subscription.activated et le statut redevient active.

Une configuration pratique

Que vous utilisiez Retain ou non, ces étapes comblent les trous habituels.

1. Définissez le lien de paiement par défaut et vérifiez qu’il est approuvé. Sans lui, les liens de mise à jour ne fonctionnent pas.
2. Choisissez le résultat en fin de fenêtre (résiliation, pause ou impayé) selon la façon dont votre app gère l’accès.
3. Conditionnez l’accès au statut. Gérez subscription.past_due, subscription.activated et subscription.canceled dans votre app. Décidez quel accès garde un client en impayé, et dites-le.
4. Montrez le problème dans votre app. Une bannière pour les clients en impayé avec le lien de gestion de l’abonnement touche ceux qui n’ouvrent jamais les emails de relance.
5. N’envoyez pas d’emails en double. Si Paddle ou Retain envoie des emails de récupération, vos propres messages doivent être dans l’app, ou clairement différents (par exemple venant du responsable du compte, pour les gros comptes B2B).
6. Relancez vous-même les factures manuelles. Retain n’agit pas sur les abonnements prélevés manuellement. Construisez une séquence de rappels pour eux.
7. Enregistrez chaque échec. Stockez chaque transaction.payment_failed avec l’abonnement, le montant et le résultat. Au bout de quelques mois, vous saurez quels clients se récupèrent par une nouvelle tentative et lesquels seulement par une nouvelle carte.

Ce que vous pouvez ajouter

Paddle couvre bien l’essentiel : nouvelles tentatives, page de mise à jour hébergée, emails et modèle de statuts. Ce qui reste, c’est surtout le contexte.

• Sachez quels clients sont à risque. Un échec sur un compte ancien et actif n’est pas un échec sur un compte où personne ne s’est connecté depuis deux mois.
• Reliez les échecs à ce que vous savez du client. L’offre, l’usage, l’historique de support et le type de moyen de paiement changent tous ce que doit dire un bon message de récupération.
• Mesurez. Comptez les paiements récupérés et perdus par mois et par cause. Voir le churn involontaire pour les définitions et les modèles d’emails de relance si vous rédigez vos propres textes dans l’app.

Le faire avec NoChurn

Avec Paddle, l’encaissement, les nouvelles tentatives et les emails de Paddle restent chez Paddle, en tant que marchand officiel. NoChurn lit vos abonnements et transactions Paddle, donne à chaque client un churn score de 0 à 100 à partir de vos données perso envoyées par API, et ajoute un parcours d’annulation et des emails de reconquête à J30, J60 et J90. Là où les réglages de Paddle laissent de la place, il peut envoyer des messages de récupération rédigés par l’IA, que vous relisez avant envoi. Voir NoChurn + Paddle.