How to handle failed recurring payments with Mollie

Mollie makes recurring payments simple to start: one first payment creates a mandate, and subscriptions or on-demand charges run on that mandate. What happens when one of those charges fails is less obvious. Does Mollie retry? When does it cancel the subscription? What does your webhook actually receive? And how do you get a customer back onto a working payment method?

This guide answers those questions from Mollie’s own documentation: Recurring payments, Webhooks, Next-gen webhooks, Status reasons, the Chargebacks API, Update subscription and Mollie’s help center articles on failed SEPA Direct Debit payments and mandates after a reversal (all accessed November 2026).

How Mollie recurring payments work

Mollie’s model has three pieces, described in the recurring payments guide:

1. A first payment. You create a payment for a customer with sequenceType set to first. The customer completes it through the normal checkout.
2. A mandate. Once the first payment succeeds, Mollie stores a mandate for that customer and payment method. A mandate does not cap the amount or the number of charges.
3. Recurring charges. Either you create payments yourself with sequenceType set to recurring (this requires a mandate with status valid), or you create a subscription and Mollie charges on its interval. For subscriptions, the customer needs a mandate in status pending or valid.

The customer only goes through checkout once. That is the strength of the model, and also why recovery is different from card-on-file platforms: when a mandate stops working, there is no “update card” form on the mandate itself. The customer has to make a new first payment.

What happens when a subscription payment fails

Mollie does retry. According to the recurring payments guide:

• If a subscription payment fails, Mollie may attempt it again up to 5 times, once a day, depending on the failure reason.
• The retry behaviour may differ per payment method and failure reason.
• If a retry succeeds, the next charge date is updated based on the latest successful payment and your interval.
• Once all retries are exhausted, the subscription is cancelled.

Some failure reasons skip that pattern. The same page lists reasons that cancel the subscription immediately and others that cancel it after repeated occurrences:

Behaviour	Example SEPA reasons listed by Mollie
Cancel immediately	Invalid IBAN (AC01), closed account (AC04), deceased debtor (MD07)
Cancel after the same issue occurs repeatedly	No mandate (MD01), return requested by the customer (MD06), refusal by the debtor (MS02), reason not specified

If the subscription has a fixed mandate set (its mandateId field), cancelling it for these reasons also revokes the mandate.

One caution: an older Mollie help article gives a different threshold for SEPA subscriptions (cancellation after 2 failures, not applicable to insufficient funds). The developer documentation is the more recent reference, but test the behaviour for your own payment methods rather than assuming a number. For insufficient funds (AM04), Mollie’s help center suggests trying the direct debit again or contacting the customer.

Two practical consequences:

• You need to know when Mollie cancelled a subscription, because your app has to react. Cancelled subscriptions cannot be updated through the API, so recovery means creating a new subscription.
• Retries alone will not fix a closed account or a revoked mandate. Those customers need to pay again through checkout.

Webhooks that carry only an ID

Mollie’s classic webhooks are intentionally minimal. As the webhooks reference explains, Mollie calls your webhookUrl with a POST parameter id, the ID of the object that changed (for a payment, id=tr_...), and nothing else. Your handler must fetch the object from the API and read its current status.

Things to build around this:

1. Always fetch. Do not infer what happened from the fact that a call arrived. Read the payment, check its status, and for subscription payments check the subscription ID and the subscription’s own status.
2. Return HTTP 200 quickly. Mollie treats anything else, or a response slower than 15 seconds, as a failure and retries with increasing intervals, up to 10 attempts over about 26 hours. You cannot trigger a webhook call again manually from Mollie.
3. Make processing idempotent. The same payment can be reported more than once, and the status you read may have moved on since the call was sent.
4. Reconcile on a schedule. Since you cannot replay calls, a periodic job that lists recent payments and subscriptions catches anything a failed endpoint missed.

Mollie also offers next-gen webhooks, which are signed with an X-Mollie-Signature header computed with your webhook secret. If you use them, verify the signature before acting. Either way, treat your own API read as the source of truth.

Chargebacks

Customers can reverse payments, and Mollie exposes them through the Chargebacks API:

• GET /v2/chargebacks lists chargebacks across all your payments, newest first, paginated.
• The payment-level endpoints list or fetch the chargebacks for one payment.

For SEPA Direct Debit, a customer can reverse a payment within 8 weeks, and according to Mollie’s help center, Mollie revokes the mandate after a reversal. Any further charges need a new mandate, so a chargeback on a recurring payment is also a payment method problem, not just a lost amount. For card disputes, Mollie’s card chargeback article explains that, depending on the case, you may be able to respond with documentation within a limited number of days.

When a chargeback arrives on a subscription, decide explicitly: pause access, contact the customer, or end the subscription. Do not let the next scheduled charge discover that the mandate is gone.

Asking the customer to pay again

When retries have run out, the mandate is revoked or the account is closed, recovery means getting the customer back through checkout. The flow that follows Mollie’s documented model:

1. Detect the failure from your webhook handler after fetching the payment, and note the failure reason from the status reasons reference where available.
2. Email the customer the same day. Explain that the payment did not go through, without quoting bank codes, and include one link.
3. Point the link at a new first payment. Create a payment for the same customer with sequenceType first for the outstanding amount. Paying it settles what is owed and creates a new mandate in one step. Mollie’s payment links are another way to collect the amount, but check whether the method you use creates a mandate for future charges.
4. Restart the subscription on the new mandate once the payment is paid. If Mollie had already cancelled the old subscription, create a new one with a start date that fits the period the customer just paid for.
5. Send reminders if the link is not used: after a few days, then a final notice with the date access ends.
6. Offer another payment method in the reminder. A customer whose bank account was closed may prefer a card, and the first payment lets them choose.

A checklist

• Your webhook handler fetches every object and returns 200 fast.
• You store the subscription status and react when Mollie cancels it.
• Hard reasons (closed account, invalid IBAN, revoked mandate) go straight to a “pay again” email, without waiting.
• Insufficient funds get time: Mollie’s own retries, plus a reminder.
• Chargebacks are checked and mark the mandate as unusable in your app.
• A scheduled job reconciles payments and subscriptions in case webhook calls were missed.

Doing this with NoChurn

Payment processing, mandates, Mollie’s retries and the card and bank details all stay with Mollie. NoChurn connects to your Mollie account, imports customers, mandates and subscriptions, and, because Mollie webhooks only carry an ID, reads the payment again before acting. It adds AI-written recovery emails that you review before they go out, with a link to pay again and set up a new payment method. Chargebacks are shown read only on the customer’s timeline and count in the churn score from 0 to 100. NoChurn also adds cancel flows with reasons, offers and a one-click cancel that is always visible, and win-back emails at day 30, 60 and 90 based on the cancel reason. See NoChurn + Mollie.