Gérer les paiements récurrents échoués avec Mollie

Mollie rend les paiements récurrents faciles à lancer : un premier paiement crée un mandat, et les abonnements ou prélèvements à la demande s’appuient sur ce mandat. Ce qui se passe quand l’un de ces prélèvements échoue est moins évident. Mollie fait-il une nouvelle tentative ? Quand annule-t-il l’abonnement ? Que reçoit réellement votre webhook ? Et comment remettre un client sur un moyen de paiement qui fonctionne ?

Ce guide répond à ces questions à partir de la documentation de Mollie : Recurring payments, Webhooks, Next-gen webhooks, Status reasons, l’API Chargebacks, Update subscription et les articles du centre d’aide de Mollie sur les prélèvements SEPA échoués et les mandats après un remboursement (tous consultés en novembre 2026).

Comment fonctionnent les paiements récurrents Mollie

Le modèle de Mollie compte trois éléments, décrits dans le guide des paiements récurrents :

1. Un premier paiement. Vous créez un paiement pour un client avec sequenceType à first. Le client le règle via le checkout habituel.
2. Un mandat. Une fois le premier paiement réussi, Mollie enregistre un mandat pour ce client et ce moyen de paiement. Un mandat ne plafonne ni le montant ni le nombre de prélèvements.
3. Des prélèvements récurrents. Soit vous créez vous-même des paiements avec sequenceType à recurring (il faut un mandat au statut valid), soit vous créez un abonnement et Mollie prélève à chaque échéance. Pour les abonnements, le client doit avoir un mandat au statut pending ou valid.

Le client ne passe qu’une fois par le checkout. C’est la force du modèle, et c’est aussi pourquoi la récupération diffère des plateformes à carte enregistrée : quand un mandat cesse de fonctionner, il n’existe pas de formulaire « mettre à jour la carte » sur le mandat lui-même. Le client doit faire un nouveau premier paiement.

Ce qui se passe quand un paiement d’abonnement échoue

Mollie fait bien de nouvelles tentatives. Selon le guide des paiements récurrents :

• Si un paiement d’abonnement échoue, Mollie peut le retenter jusqu’à 5 fois, une fois par jour, selon le motif de l’échec.
• Le comportement des nouvelles tentatives peut varier selon le moyen de paiement et le motif de l’échec.
• Si une tentative réussit, la date du prochain prélèvement est recalculée à partir du dernier paiement réussi et de votre intervalle.
• Une fois toutes les tentatives épuisées, l’abonnement est annulé.

Certains motifs échappent à ce schéma. La même page liste des motifs qui annulent l’abonnement immédiatement, et d’autres qui l’annulent après plusieurs occurrences :

Comportement	Exemples de motifs SEPA cités par Mollie
Annulation immédiate	IBAN invalide (AC01), compte clôturé (AC04), débiteur décédé (MD07)
Annulation après répétition du même problème	Pas de mandat (MD01), remboursement demandé par le client (MD06), refus du débiteur (MS02), motif non précisé

Si l’abonnement a un mandat fixe (son champ mandateId), son annulation pour ces motifs révoque aussi le mandat.

Une précaution : un article d’aide plus ancien de Mollie donne un autre seuil pour les abonnements SEPA (annulation après 2 échecs, hors provision insuffisante). La documentation développeur est la référence la plus récente, mais testez le comportement pour vos propres moyens de paiement plutôt que de supposer un chiffre. Pour une provision insuffisante (AM04), le centre d’aide de Mollie suggère de retenter le prélèvement ou de contacter le client.

Deux conséquences pratiques :

• Vous devez savoir quand Mollie a annulé un abonnement, car votre app doit réagir. Un abonnement annulé ne peut pas être modifié via l’API : la récupération passe donc par la création d’un nouvel abonnement.
• Les nouvelles tentatives seules ne règlent pas un compte clôturé ou un mandat révoqué. Ces clients doivent repayer via le checkout.

Des webhooks qui ne portent qu’un ID

Les webhooks classiques de Mollie sont volontairement minimalistes. Comme l’explique la référence des webhooks, Mollie appelle votre webhookUrl avec un paramètre POST id, l’ID de l’objet modifié (pour un paiement, id=tr_...), et rien d’autre. Votre handler doit récupérer l’objet via l’API et lire son statut actuel.

Ce qu’il faut construire autour :

1. Récupérez toujours l’objet. Ne déduisez pas ce qui s’est passé du simple fait qu’un appel est arrivé. Lisez le paiement, vérifiez son statut et, pour un paiement d’abonnement, vérifiez l’ID de l’abonnement et son propre statut.
2. Renvoyez vite un HTTP 200. Mollie considère toute autre réponse, ou une réponse de plus de 15 secondes, comme un échec, et réessaie à intervalles croissants, jusqu’à 10 tentatives sur environ 26 heures. Vous ne pouvez pas redéclencher manuellement un appel de webhook depuis Mollie.
3. Rendez le traitement idempotent. Le même paiement peut être signalé plusieurs fois, et le statut que vous lisez a pu évoluer depuis l’envoi de l’appel.
4. Rapprochez à intervalles réguliers. Comme vous ne pouvez pas rejouer les appels, une tâche périodique qui liste les paiements et abonnements récents rattrape ce qu’un endpoint en panne a manqué.

Mollie propose aussi des next-gen webhooks, signés avec un en-tête X-Mollie-Signature calculé avec votre secret de webhook. Si vous les utilisez, vérifiez la signature avant d’agir. Dans tous les cas, considérez votre propre lecture via l’API comme la source de vérité.

Chargebacks

Les clients peuvent faire annuler des paiements, et Mollie les expose via l’API Chargebacks :

• GET /v2/chargebacks liste les chargebacks de tous vos paiements, du plus récent au plus ancien, avec pagination.
• Les endpoints au niveau du paiement listent ou récupèrent les chargebacks d’un paiement.

Pour le prélèvement SEPA, un client peut faire annuler un paiement dans les 8 semaines et, selon le centre d’aide de Mollie, Mollie révoque le mandat après un remboursement. Tout prélèvement ultérieur demande un nouveau mandat : un chargeback sur un paiement récurrent est donc aussi un problème de moyen de paiement, pas seulement un montant perdu. Pour les litiges carte, l’article de Mollie sur les chargebacks carte explique que, selon le cas, vous pouvez répondre avec des justificatifs dans un nombre de jours limité.

Quand un chargeback arrive sur un abonnement, décidez explicitement : suspendre l’accès, contacter le client ou mettre fin à l’abonnement. Ne laissez pas le prochain prélèvement prévu découvrir que le mandat a disparu.

Demander au client de payer à nouveau

Quand les tentatives sont épuisées, que le mandat est révoqué ou que le compte est clôturé, la récupération passe par un retour du client au checkout. Le parcours qui suit le modèle documenté par Mollie :

1. Détectez l’échec dans votre handler de webhook après avoir récupéré le paiement, et notez le motif d’échec à partir de la référence status reasons quand il est disponible.
2. Écrivez au client le jour même. Expliquez que le paiement n’est pas passé, sans citer de codes bancaires, et mettez un seul lien.
3. Faites pointer le lien vers un nouveau premier paiement. Créez un paiement pour le même client avec sequenceType first pour le montant dû. Le régler solde ce qui est dû et crée un nouveau mandat en une seule étape. Les liens de paiement de Mollie sont une autre façon d’encaisser le montant, mais vérifiez si la méthode utilisée crée un mandat pour les prélèvements futurs.
4. Relancez l’abonnement sur le nouveau mandat une fois le paiement réglé. Si Mollie avait déjà annulé l’ancien abonnement, créez-en un nouveau avec une date de début adaptée à la période que le client vient de payer.
5. Envoyez des rappels si le lien n’est pas utilisé : après quelques jours, puis un dernier avis avec la date de fin d’accès.
6. Proposez un autre moyen de paiement dans le rappel. Un client dont le compte bancaire a été clôturé préférera peut-être une carte, et le premier paiement lui laisse le choix.

Une checklist

• Votre handler de webhook récupère chaque objet et renvoie vite un 200.
• Vous stockez le statut de l’abonnement et réagissez quand Mollie l’annule.
• Les motifs définitifs (compte clôturé, IBAN invalide, mandat révoqué) déclenchent directement un email « payer à nouveau », sans attendre.
• La provision insuffisante a droit à du temps : les propres tentatives de Mollie, plus un rappel.
• Les chargebacks sont vérifiés et marquent le mandat comme inutilisable dans votre app.
• Une tâche planifiée rapproche paiements et abonnements au cas où des appels de webhook auraient été manqués.

Le faire avec NoChurn

Le traitement des paiements, les mandats, les nouvelles tentatives de Mollie et les coordonnées de carte et bancaires restent chez Mollie. NoChurn se connecte à votre compte Mollie, importe clients, mandats et abonnements et, comme les webhooks Mollie ne portent qu’un ID, relit le paiement avant d’agir. Il ajoute des emails de récupération rédigés par l’IA, que vous relisez avant envoi, avec un lien pour payer à nouveau et enregistrer un nouveau moyen de paiement. Les chargebacks s’affichent en lecture seule sur la chronologie du client et comptent dans le churn score de 0 à 100. NoChurn ajoute aussi des parcours d’annulation avec raisons, offres et un bouton d’annulation en un clic toujours visible, et des emails de reconquête à J30, J60 et J90 selon la raison de l’annulation. Voir NoChurn + Mollie.