Récupérer les prélèvements échoués avec GoCardless

Un prélèvement (Direct Debit) échoué n’est pas une carte refusée. Il n’y a pas de carte à mettre à jour, la banque répond des jours après votre demande d’encaissement, et le client peut parfois récupérer l’argent longtemps après qu’il a quitté son compte. La récupération sur GoCardless suit ses propres règles, et la plupart viennent des schémas bancaires (Bacs, SEPA, ACH et d’autres) plutôt que de GoCardless lui-même.

Ce guide explique pourquoi les paiements GoCardless échouent, comment fonctionnent les relances, que faire quand un mandat est annulé ou expiré, et comment sont gérés les charge-backs (indemnity claims). Il s’en tient à la documentation de GoCardless : la référence des événements de paiement, la référence des événements de mandat, le guide Success+, les articles du centre d’aide sur les échecs de paiement et sur les paiements échoués que Success+ peut relancer, et les descriptions des bibliothèques clientes officielles de l’API GoCardless (tous consultés en novembre 2026).

Le parcours d’un prélèvement

Un paiement GoCardless passe par une série de statuts. L’API documente ces valeurs de status :

Statut	Signification
pending_submission	Créé, pas encore soumis aux banques
submitted	Soumis aux banques
confirmed	Confirmé comme encaissé
paid_out	Inclus dans un versement à votre intention
failed	Le paiement n’a pas pu être traité
charged_back	Le paiement a fait l’objet d’un charge-back
cancelled	Le paiement a été annulé avant l’encaissement

Deux détails comptent pour la récupération :

1. Les échecs arrivent après la date de prélèvement. Le centre d’aide de GoCardless indique que les rapports d’échec arrivent en général un jour ouvré après la date de prélèvement. Vous l’apprenez un peu plus tard qu’avec les cartes, et vos relances doivent partir de l’événement d’échec, pas de la date de prélèvement.
2. Un paiement confirmé peut encore échouer. La référence de l’API précise que des paiements peuvent échouer après confirmation si la banque envoie le message d’échec en retard. Ne considérez pas confirmed comme définitif quand vous accordez ou retirez un accès.

Pourquoi les prélèvements échouent

Chaque échec s’accompagne d’un événement. Sur les événements de paiement, GoCardless envoie un objet details avec :

• cause : la clé simplifiée et prévisible de GoCardless pour ce qui s’est passé.
• origin : qui a déclenché l’événement, par exemple bank, gocardless, api ou customer.
• reason_code : quand l’origine est la banque, le code propre au schéma que la banque a renvoyé. GoCardless prévient qu’il peut être incohérent d’une banque à l’autre : construisez votre logique sur cause, et gardez reason_code pour enquêter.
• description : un texte lisible, qui selon GoCardless peut changer sans préavis.

Les causes listées dans la référence des événements de paiement comprennent insufficient_funds, refer_to_payer, mandate_cancelled, bank_account_closed, invalid_bank_details, direct_debit_not_enabled, bank_declined_payment, payment_stopped et account_blocked_for_any_financial_transaction. Elles se rangent en trois groupes :

Groupe	Causes	Que faire
Pas assez d’argent	insufficient_funds, refer_to_payer	Relancer, idéalement après le moment où le client a probablement été payé. GoCardless décrit refer_to_payer (un code Bacs) comme signifiant presque toujours des fonds insuffisants.
Mandat disparu	mandate_cancelled	Ne pas relancer. Le client a besoin d’un nouveau mandat.
Problème de compte	bank_account_closed, invalid_bank_details, direct_debit_not_enabled, account_blocked_for_any_financial_transaction	Ne pas relancer. Demander d’autres coordonnées bancaires ou un autre moyen de paiement.
Arrêté par le client ou la banque	payment_stopped, bank_declined_payment	Contacter le client avant de réessayer. Un paiement arrêté peut signaler qu’il veut partir.

Les relances avec Success+

Le produit de relance de GoCardless s’appelle Success+. D’après le guide Success+ et le centre d’aide :

• Il s’active dans le dashboard GoCardless par un administrateur, avec des réglages par schéma.
• Les intégrations par API doivent aussi inscrire chaque paiement en envoyant retry_if_possible: true à la création des paiements, des abonnements ou des échéanciers. La valeur par défaut est false.
• Par défaut, il relance jusqu’à 3 fois en 4 semaines. Vous pouvez définir votre propre fenêtre en jours calendaires, et les relances ont lieu les jours ouvrés à l’intérieur.
• Il ne relance que les échecs qu’il juge relançables, surtout les échecs pour manque de fonds. Les mandats annulés, les comptes fermés et les refus directs de la banque ne sont pas relancés. La liste des codes relançables est donnée par schéma.
• Pour Bacs, le payeur doit être informé de la date de relance avant que le paiement soit prélevé.
• Chaque relance est une nouvelle tentative de paiement pour la facturation : vérifiez votre tarification GoCardless.

Sur l’événement d’échec, le champ will_attempt_retry vous indique si Success+ va relancer. Quand il vaut false, not_retried_reason explique pourquoi : failure_filter_applied (GoCardless s’attend à ce que la relance échoue) ou other.

Le centre d’aide de GoCardless signale aussi que tous les partenaires logiciels ne prennent pas en charge Success+. Si votre facturation passe par une appli partenaire, vérifiez d’abord de ce côté.

Les relances manuelles via l’API

Sans Success+, ou pour un paiement qu’il ne relancera pas, vous pouvez relancer vous-même avec POST /payments/:id/actions/retry. L’API documente trois règles :

1. Le mandat sous-jacent doit être actif.
2. Un paiement peut être relancé jusqu’à 3 fois.
3. L’appel échoue avec retry_failed si le paiement n’a pas échoué.

Après l’appel, vous recevez un événement resubmission_requested, puis la même séquence que pour un nouveau paiement : submitted, suivi de confirmed ou failed. La relance a besoin d’une nouvelle date de prélèvement : choisissez-la délibérément. Pour un échec insufficient_funds, une date juste après un jour de paie courant dans le pays du client est un choix raisonnable. Relancer le lendemain, en général non.

Prévenir le client avant de relancer

Contrairement à une relance de carte, une relance de prélèvement est visible sur le relevé bancaire du client, et pour Bacs, GoCardless exige un préavis sur la date de relance. Un bon message :

1. Dit que le paiement n’est pas passé, avec le montant et l’offre.
2. Donne la date de la prochaine tentative.
3. Propose un moyen de changer de coordonnées bancaires ou de payer autrement si le compte ne sera pas approvisionné.
4. Est envoyé depuis une adresse qu’une personne lit.

Mandats annulés et expirés

Un paiement a besoin d’un mandat actif. L’API documente notamment ces statuts de mandat : active, suspended_by_payer, cancelled, expired (expiré pour inactivité), failed, consumed et blocked. Surveillez les événements de mandat (resource_type: mandates) d’aussi près que les événements de paiement : un mandat annulé signifie que tous les paiements futurs dessus échoueront.

Quand un mandat est annulé par le client auprès de sa banque, un paiement sur ce mandat échoue avec la cause mandate_cancelled. Ne relancez pas ; il vous faut un nouveau mandat. Les étapes :

1. Cherchez à savoir pourquoi. Un client qui annule son prélèvement auprès de sa banque a peut-être simplement changé de banque, ou veut peut-être arrêter de payer. L’email doit poser la question, pas présumer.
2. Envoyez un lien pour mettre en place un nouveau mandat. Sur GoCardless, un nouveau mandat se recueille via une Billing Request, en général avec un Billing Request Flow hébergé. Envoyez ce lien au client, pas un formulaire qui demande ses coordonnées bancaires par email.
3. Recréez le paiement sur le nouveau mandat une fois qu’il est actif.

L’API de GoCardless a aussi une action reinstate pour les mandats annulés ou expirés (jusqu’à 10 fois par mandat). Elle soumet de nouveau le mandat aux banques, et vous recevez ensuite submitted, suivi de reinstated ou failed, jusqu’à deux jours ouvrés plus tard. Ne l’utilisez que lorsque vous savez que le mandat devrait encore être valable. Quand le client a annulé volontairement, le réactiver sans lui demander n’est pas la bonne démarche.

Les charge-backs (indemnity claims)

Le prélèvement donne aux clients des droits de remboursement forts, et ils varient selon le schéma. Le centre d’aide et les guides de GoCardless les décrivent :

Schéma	Droit de réclamation du client
Bacs (Royaume-Uni)	Avec la Direct Debit Guarantee, GoCardless indique qu’il n’y a actuellement aucune limite de temps pour les indemnity claims.
SEPA Core	Remboursement sans justification dans les 8 semaines suivant le prélèvement ; jusqu’à 13 mois pour les paiements non autorisés.
SEPA B2B	Aucun remboursement pour les paiements autorisés ; réclamations pour paiements non autorisés jusqu’à 13 mois.

Un paiement réclamé passe à charged_back et le montant vous est repris. Contrairement aux litiges carte, il n’y a en général pas de procédure de preuves. GoCardless décrit une fonction de contestation des charge-backs dans son centre d’aide, sous conditions d’offre et de schéma ; vérifiez si elle s’applique à vous.

Ce que vous maîtrisez, c’est ce qui se passe avant la réclamation :

• Rendez la résiliation facile. Un client qui ne trouve pas comment résilier arrêtera le prélèvement à sa banque ou déposera une réclamation. Un bouton de résiliation clair de votre côté coûte moins cher.
• Envoyez des pré-notifications faciles à lire. Un client qui a oublié un renouvellement réclame plus volontiers.
• Traitez un charge-back comme un signal de résiliation. Arrêtez les paiements futurs sur ce mandat jusqu’à ce que vous ayez parlé au client.

Les webhooks à écouter

Une intégration de récupération minimale sur GoCardless suit ces événements :

Ressource	Action	Pourquoi
payments	failed	Lancer la récupération ; lire cause, will_attempt_retry
payments	resubmission_requested, submitted, confirmed	Suivre une relance
payments	charged_back	Indemnity claim ; suspendre et contacter le client
mandates	cancelled, expired	Demander un nouveau mandat avant le prochain paiement

Rappelez-vous qu’un seul échec peut produire plusieurs événements (par exemple un mandat annulé et ses paiements en attente annulés) : dédoublonnez sur l’ID d’événement et regroupez par client avant d’écrire à qui que ce soit.

Le faire avec NoChurn

NoChurn se connecte à votre compte GoCardless, importe clients, mandats, abonnements et paiements, et suit les webhooks GoCardless. Quand un paiement échoue, il envoie des emails de récupération rédigés par l’IA que vous relisez, calés sur le rythme du prélèvement, et quand un mandat est annulé, l’email renvoie le client vers la mise en place d’un nouveau mandat. L’encaissement, les relances et Success+ restent chez GoCardless, et les charge-backs apparaissent dans la chronologie du client, puisque les réclamations de prélèvement n’ont pas de preuves à envoyer. NoChurn ajoute aussi des parcours d’annulation avec une résiliation en un clic toujours visible, des emails de reconquête à J30, J60 et J90 selon la raison de la résiliation, et un score de churn. Voir NoChurn + GoCardless.