Les Retries de Paiement réessaient automatiquement les paiements de renouvellement d’abonnement échoués sur un calendrier de recul progressif. Lorsqu’un retry réussit, l’abonnement est réactivé automatiquement — aucune action du client ni intégration n’est requise.
Que Sont les Retries de Paiement?
Lorsqu’un paiement de renouvellement d’abonnement échoue, l’abonnement est mis en attente. Avec les Retries de Paiement activés, Dodo Payments recharge automatiquement le moyen de paiement existant du client sur un calendrier intelligent jusqu’à ce que le paiement réussisse ou que la fenêtre de récupération se ferme. Cela récupère des revenus perdus à cause d’échecs temporaires — cartes expirées, fonds insuffisants qui sont rechargés, erreurs de réseau transitoires — sans envoyer d’email au client ou lui demander de mettre à jour quoi que ce soit.Les Retries de Paiement ne s’appliquent qu’aux paiements de renouvellement d’abonnement. Les premiers paiements (mise en place de mandat), paiements uniques, frais de changement de plan, et frais à la demande ne sont pas réessayés par cette fonctionnalité.
Comment Fonctionnent les Retries de Paiement
Renewal fails
Un paiement de renouvellement d’abonnement échoue et l’abonnement passe à l’état
on_hold.Retryability check
Le code d’erreur de l’échec est vérifié. Les refus temporaires (fonds insuffisants, refus générique, erreurs de traitement ou de réseau, etc.) sont réessayables. Les refus définitifs mettent fin à la chaîne de retry immédiatement, car réessayer ne changera pas le résultat.
Scheduled retry
Si le refus est réessayerable et que la fenêtre de récupération le permet, la prochaine tentative est planifiée. Les retries s’exécutent hors session contre le moyen de paiement existant du client sur un calendrier de recul progressif.
Configuration des Retries de Paiement
Activez et configurez les Retries de Paiement depuis Paramètres → Récupération dans votre tableau de bord.
| Réglage | Description | Par défaut |
|---|---|---|
| Activer les Retries de Paiement | Relance automatiquement les paiements de renouvellement d’abonnement échoués pour récupérer des revenus. | Désactivé (opt-in) |
| Fenêtre de récupération (jours) | Durée pendant laquelle réessayer un paiement échoué avant d’abandonner. Doit être entre 1 et 30. | 13 |
Calendrier des Retries
Les retries s’échelonnent progressivement. Jusqu’à 8 tentatives sont effectuées, tant que chacune s’adapte à votre fenêtre de récupération :| Tentative | Délai après la tentative précédente | Temps approximatif depuis l’échec |
|---|---|---|
| 1 | 12 heures | 12 heures |
| 2 | 24 heures | 36 heures |
| 3 | 48 heures | ~3,5 jours |
| 4 | 72 heures | ~6,5 jours |
| 5 | 96 heures | ~10,5 jours |
| 6 | 120 heures | ~15,5 jours |
| 7 | 7 jours | ~22,5 jours |
| 8 | 7 jours | ~29,5 jours |
Transitions de Statut d’Abonnement
| Événement | Statut de l’abonnement |
|---|---|
| Échec du paiement de renouvellement | active → on_hold |
| Échec de la tentative de retry | reste on_hold (prochain retry planifié si la fenêtre le permet) |
| Réussite de la tentative de retry | on_hold → active, prochaine date de facturation avancée |
| Fenêtre de récupération épuisée | reste on_hold |
| Événement | Se déclenche quand |
|---|---|
subscription.on_hold | Un renouvellement échoue et l’abonnement est mis en attente |
subscription.active | Un retry réussit et l’abonnement est réactivé |
Subscription Webhook Payloads
Voir les schémas de charge utile complets des webhooks pour les événements du cycle de vie de l’abonnement.
Échecs Réessayerables vs Non-Réessayerables
| Type d’échec | Exemples | Réeessayé? |
|---|---|---|
| Déclin temporaire | Fonds insuffisants, refus générique, vitesse de carte dépassée, erreur de traitement, erreur réseau/timeout, réessayer plus tard | Oui |
| Déclin définitif | Carte volée/perdue, carte invalide, ne pas honorer, compte fermé, et autres déclins terminaux | Non — chaîne se termine immédiatement |
Réessayer un déclin définitif ne change pas le résultat, donc la chaîne de retry se termine dès qu’un déclin définitif est observé. Associez les Retries de Paiement avec le Recouvrement des Abonnements pour inciter le client à mettre à jour son moyen de paiement dans ces cas.
Retries de Paiement vs Relance
Les Retries de Paiement et le Recouvrement des Abonnements sont des outils de récupération complémentaires :| Retries de Paiement | Recouvrement des Abonnements | |
|---|---|---|
| Mécanisme | Recharge silencieusement le moyen de paiement existant | Envoie un email au client pour mettre à jour son moyen de paiement |
| Action du client | Aucune requise | Le client met à jour le moyen de paiement dans le portail |
| Meilleur pour | Déclins temporaires/résolution automatique | Cartes expirées ou invalides nécessitant un remplacement |
Connexe
Subscription Dunning
Séquences d’emails incitant les clients à mettre à jour leur moyen de paiement.
Abandoned Cart Recovery
Récupérer des paiements uniques incomplets ou échoués avec des emails ciblés.
Subscriptions
Comprendre les états d’abonnement impliqués dans les flux de récupération.
Subscription Webhooks
Réagissez aux événements
subscription.on_hold et subscription.active.