Que faire quand un mandat GoCardless est annulé

Sur GoCardless, chaque paiement dépend d’un mandat : l’autorisation du client de débiter son compte. Quand le mandat est annulé, plus rien ne fonctionne. Les paiements en attente s’arrêtent, les abonnements qui en dépendent prennent fin, et aucune relance ne peut aider. C’est l’événement le plus important à bien gérer dans une activité en prélèvement (Direct Debit), et aussi celui où un email automatique « merci de mettre à jour vos coordonnées » a le plus de chances d’être à côté de la plaque.

Ce guide explique pourquoi les mandats prennent fin, ce que deviennent les abonnements et les paiements qui en dépendent, comment lire la cause, et comment obtenir un nouveau mandat quand le client veut continuer à payer. Il s’en tient à la documentation de GoCardless : la référence des événements de mandat, la référence des événements d’abonnement, le guide développeur Responding to mandate events et l’article du centre d’aide sur les statuts de mandat (tous consultés en novembre 2026). Le site de documentation de GoCardless n’était pas accessible depuis notre environnement de recherche ; nous avons donc aussi vérifié les descriptions des champs et des endpoints dans les bibliothèques clientes officielles de l’API GoCardless (par exemple gocardless-pro-ruby), générées à partir du même schéma d’API. Pour la partie paiement de la récupération, voir comment récupérer les prélèvements échoués avec GoCardless.

Les statuts de mandat

GoCardless documente ces statuts de mandat :

Statut	Signification
pending_customer_approval	Pas encore signé par un second signataire
pending_submission	Pas encore soumis à la banque du client
submitted	Soumis, pas encore traité
active	Mis en place par la banque du client ; les paiements peuvent être prélevés
suspended_by_payer	Suspendu par le payeur
failed	N’a pas pu être créé
cancelled	Annulé
expired	Expiré pour inactivité
consumed	Utilisé et non réutilisable (seulement pour les schémas autorisés paiement par paiement)
blocked	Bloqué ; aucun paiement ne peut être créé

Seuls les mandats active peuvent être débités, et une relance manuelle de paiement exige un mandat actif. Chaque mandat a aussi une next_possible_charge_date, qui compte quand vous mettez en place un remplacement et voulez savoir quand vous pourrez encaisser.

Pourquoi un mandat est annulé

L’événement cancelled arrive avec details.cause, details.origin et, quand l’origine est la banque, details.reason_code. Utilisez cause pour votre logique. GoCardless prévient que reason_code est propre au schéma et peut être incohérent d’une banque à l’autre.

Le guide développeur de GoCardless liste plusieurs causes d’annulation de mandat, notamment :

• bank_account_closed : le compte bancaire du client a été fermé.
• invalid_bank_details : les coordonnées bancaires ne sont pas valides.
• mandate_cancelled : le mandat a été annulé.

Sur ce dernier point, les pages de GoCardless ne concordent pas entre elles. La référence API des événements de mandat décrit mandate_cancelled comme un mandat annulé par le client ou sa banque, tandis que l’ancien guide développeur l’utilise pour les annulations faites via le dashboard ou l’API et décrit autrement une annulation par le client côté banque. Ne comptez pas sur cause seul pour distinguer « le client a annulé auprès de sa banque » de « nous l’avons annulé » : lisez aussi origin (bank, api, gocardless, customer, etc.). Une origine api signifie que c’est votre propre système, ou une appli que vous avez connectée, qui l’a fait.

Un mandat expiré est différent : GoCardless fait expirer les mandats pour inactivité. Personne n’a décidé d’arrêter ; le mandat n’a simplement pas été utilisé.

Ce que deviennent les paiements et les abonnements

Un mandat annulé emporte d’autres choses avec lui :

• Les paiements en attente. La référence de l’API de GoCardless pour l’endpoint d’annulation indique qu’annuler un mandat annule tous les paiements associés encore annulables. Un paiement déjà soumis aux banques peut encore être encaissé ou échouer de lui-même.
• Les abonnements. La référence des événements d’abonnement de GoCardless montre des abonnements annulés parce que leur mandat l’a été, avec des causes comme mandate_cancelled, bank_account_closed et invalid_bank_details.
• Les paiements ultérieurs. Un paiement sur un mandat annulé échoue avec la cause mandate_cancelled. Il n’est pas possible de le relancer : les relances exigent un mandat actif.

Une seule annulation produit donc plusieurs événements : le mandat, l’abonnement, et éventuellement des paiements. Regroupez-les par client avant d’envoyer le moindre email, sinon le client risque de recevoir trois messages pour une seule chose.

Décider de ce que signifie l’annulation

Avant d’écrire au client, classez l’annulation dans l’un de trois cas :

Cas	Signaux	Bonne réponse
Le client a changé de compte ou l’a fermé	bank_account_closed, ou une annulation suivie d’un message du client disant qu’il a changé de banque	Demander de nouvelles coordonnées via un nouveau mandat
Le client veut arrêter de payer	Annulé à la banque, souvent près d’un renouvellement ; pas de réponse	Le traiter comme une résiliation : la confirmer, demander pourquoi, mettre fin proprement à l’accès
C’est votre côté qui l’a annulé	origin vaut api ou le dashboard	Vérifier vos propres journaux avant de dire quoi que ce soit au client

Le guide développeur de GoCardless est clair sur un point : n’annulez un mandat vous-même que si le client l’a explicitement demandé.

Mettre en place un nouveau mandat

Quand le client veut continuer :

1. Écrivez une fois, simplement. Dites que le prélèvement a été annulé, qu’aucun autre paiement ne peut être prélevé dessus, et qu’il peut en mettre un nouveau en place en une minute s’il veut le garder. Le guide de GoCardless recommande de prévenir le client et de l’inviter à mettre en place un nouveau mandat si besoin.
2. Renvoyez vers un parcours hébergé. Sur GoCardless, les nouveaux mandats se recueillent avec une Billing Request et son Billing Request Flow hébergé. Envoyez ce lien ; ne demandez jamais de coordonnées bancaires par email.
3. Attendez active. Un nouveau mandat passe par pending_submission et submitted avant active. S’il échoue (par exemple parce que le nouveau compte n’accepte pas le prélèvement), vous recevez un événement failed ; demandez au client d’essayer un autre compte.
4. Recréez ce qui a été perdu. Créez un nouvel abonnement sur le nouveau mandat, et un paiement pour tout montant encore dû, à partir de la next_possible_charge_date du mandat.
5. Dites au client ce qui sera prélevé et quand, avant que cela arrive.

Et la réactivation ?

L’API de GoCardless a une action reinstate pour les mandats annulés ou expirés. Elle soumet de nouveau le mandat aux banques ; vous recevez ensuite resubmission_requested, submitted, puis reinstated ou failed jusqu’à deux jours ouvrés plus tard, et un mandat peut être soumis de nouveau jusqu’à 10 fois. Ne l’utilisez que lorsque vous savez que le mandat devrait encore être valable, par exemple après une erreur de votre côté. Quand le client a annulé auprès de sa banque, le réactiver sans son accord va contre sa décision et mène probablement à un échec ou à une réclamation.

Les mandats expirés

Un mandat expiré est le plus facile à récupérer, parce que personne ne s’y est opposé. Si vous prévoyez de débiter un client dont le mandat est resté inutilisé (une offre annuelle, ou un client qui a mis son abonnement en pause), vérifiez le statut du mandat avant la date de prélèvement. S’il a expiré, demandez au client de mettre en place un nouveau mandat à l’avance, plutôt que de le découvrir par un paiement échoué.

Une liste de contrôle

• Votre gestionnaire de webhooks traite les événements de mandat, pas seulement les événements de paiement.
• Les événements sont regroupés par client avant tout envoi d’email.
• cause et origin sont tous deux stockés et lus.
• Les annulations faites par votre propre système sont reconnues et ne sont pas présentées aux clients comme « votre banque a annulé ».
• L’email de nouveau mandat renvoie vers un Billing Request Flow hébergé.
• Les abonnements ne sont recréés qu’une fois le nouveau mandat actif.
• Les mandats sont vérifiés avant les prélèvements peu fréquents.

Le faire avec NoChurn

GoCardless garde les mandats, l’encaissement et les coordonnées bancaires. NoChurn importe clients, mandats, abonnements et paiements, suit les webhooks GoCardless et lit le statut des mandats (actif, annulé, expiré). Quand un mandat est annulé, l’email de récupération rédigé par l’IA de NoChurn, que vous relisez, renvoie le client vers la mise en place d’un nouveau mandat ; quand le client veut plutôt arrêter, le parcours d’annulation avec une résiliation en un clic toujours visible et les emails de reconquête à J30, J60 et J90 prennent le relais. Voir NoChurn + GoCardless.