Skip to main content
Les réessais de paiement retentent automatiquement les paiements de renouvellement d’abonnement échoués selon un calendrier de temporisation progressive. Lorsqu’un réessai réussit, l’abonnement est automatiquement réactivé — aucune action du client ni aucun travail d’intégration requis.

Que sont les réessais de paiement ?

Lorsqu’un paiement de renouvellement d’abonnement échoue, l’abonnement est placé en attente. Lorsque les réessais de paiement sont activés, Dodo Payments débite automatiquement le moyen de paiement existant du client selon un calendrier intelligent, jusqu’à la réussite du paiement ou à la fermeture de la fenêtre de récupération. Cela permet de récupérer les revenus perdus à cause d’échecs temporaires — autorisations de carte expirées, fonds insuffisants renfloués par la suite, erreurs réseau transitoires — sans envoyer d’e-mail au client ni lui demander de mettre quoi que ce soit à jour.
Les réessais de paiement s’appliquent uniquement aux paiements de renouvellement d’abonnement. Les premiers paiements (configuration du mandat), les paiements ponctuels, les frais liés à un changement de plan et les frais à la demande ne font pas l’objet de réessais avec cette fonctionnalité.

Fonctionnement des réessais de paiement

1

Renewal fails

Un paiement de renouvellement d’abonnement échoue et l’abonnement passe à l’état on_hold.
2

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.) peuvent faire l’objet d’un réessai. Les refus définitifs mettent immédiatement fin à la chaîne de réessais, car un nouveau réessai ne modifierait pas le résultat.
3

Scheduled retry

Si le refus peut faire l’objet d’un réessai et que la fenêtre de récupération le permet, la tentative suivante est planifiée. Les réessais sont exécutés hors session avec le moyen de paiement existant du client, selon un calendrier de temporisation progressive.
4

Recovery

Dès le premier réessai réussi, l’abonnement revient à active et la prochaine date de facturation est avancée normalement. Si la fenêtre se ferme avant la réussite d’un réessai, les réessais s’arrêtent et l’abonnement reste en attente.

Configuration des réessais de paiement

Activez et configurez les réessais de paiement depuis Settings → Recovery dans votre tableau de bord.
Page Recovery Settings avec l'option Enable Payment Retries activée et le champ Recovery window (days) défini sur 13

Payment Retries settings under Settings → Recovery

La fenêtre de récupération est définie à partir du moment où la facture de renouvellement échouée a été créée. Les réessais sont planifiés uniquement tant que le délai cumulé de temporisation reste compris dans la fenêtre.

Calendrier des réessais

Les délais entre les réessais augmentent progressivement. Jusqu’à 8 tentatives sont effectuées, à condition que chacune d’elles soit comprise dans votre fenêtre de récupération :
Une fenêtre de récupération de 13 jours (la valeur par défaut) couvre les tentatives 1 à 5 (la tentative 5 est exécutée environ 10,5 jours après l’échec). Augmentez la fenêtre jusqu’au maximum de 30 jours si vous souhaitez exécuter les tentatives ultérieures et plus espacées (6 à 8).

Transitions d’état de l’abonnement

Si un abonnement est annulé alors que des réessais sont encore planifiés, la chaîne de réessais prend immédiatement fin et aucune autre tentative n’est effectuée. Les autres états non actifs (on_hold, expired, pending, failed) continuent de faire l’objet de réessais, car leurs factures de renouvellement ouvertes représentent une dette pour des périodes déjà consommées par le client.
Ces transitions génèrent les événements webhook d’abonnement standard. Vous pouvez donc piloter la logique des droits à partir de ces événements, sans gestion spéciale des réessais :

Subscription Webhook Payloads

Consultez les schémas complets des charges utiles webhook pour les événements du cycle de vie de l’abonnement.

Échecs pouvant ou non faire l’objet d’un réessai

Réessayer après un refus définitif ne modifiera pas le résultat : la chaîne de réessais s’arrête dès qu’un refus définitif est détecté. Associez les réessais de paiement à la relance d’abonnement pour inviter le client à mettre à jour son moyen de paiement dans ces situations.

Réessais de paiement et relance

Les réessais de paiement et la relance d’abonnement sont des outils de récupération complémentaires : L’activation des deux options vous offre la couverture de récupération la plus large : les réessais automatiques interceptent les échecs transitoires, tandis que la relance fait revenir les clients dont le moyen de paiement doit réellement être mis à jour.

Voir aussi

Subscription Dunning

Séquences d’e-mails invitant les clients à mettre à jour leur moyen de paiement.

Abandoned Cart Recovery

Récupérez les paiements ponctuels incomplets ou échoués grâce à des e-mails ciblés.

Subscriptions

Comprenez 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.
Dernière modification le 31 juillet 2026