# Handling Subscription Payment Failures on PrestaShop

> A failed charge is almost never a customer acting in bad faith. Matching the sequence to the reason, preventing rather than chasing, and why a suspended state distinct from cancellation recovers the most subscribers.

- Page: <https://www.datafirefly.com/en/2026/10/08/subscription-payment-failures-prestashop/>
- Language: en
- Published: 2026-10-08
- Last updated: 2026-10-08
- Other languages: [fr](https://www.datafirefly.com/2026/10/08/echecs-paiement-abonnement-prestashop/index.md), [es](https://www.datafirefly.com/es/2026/10/08/fallos-pago-suscripcion-prestashop/index.md), [de](https://www.datafirefly.com/de/2026/10/08/fehlgeschlagene-abo-zahlungen-prestashop/index.md), [it](https://www.datafirefly.com/it/2026/10/08/pagamenti-falliti-abbonamento-prestashop/index.md), [pl](https://www.datafirefly.com/pl/2026/10/08/nieudane-platnosci-subskrypcji-prestashop/index.md), [nl](https://www.datafirefly.com/nl/2026/10/08/mislukte-betalingen-abonnement-prestashop/index.md), [pt](https://www.datafirefly.com/pt/2026/10/08/falhas-pagamento-subscricao-prestashop/index.md)
- Index: <https://www.datafirefly.com/en/2026/llms.txt>

On a subscription, a significant share of charges fails every month. This is not a problem of customers acting in bad faith: it is an expired card, a limit reached, a bank check triggered. The way you handle these failures determines how many subscribers you keep.

## The causes of failure, and what they imply

They do not call for the same response, and confusing them costs subscribers.

**The expired card.** The most frequent cause, entirely predictable and avoidable. It does not call for a retry but for anticipation.

**Insufficient balance or limit reached.** Often temporary, tied to the charge date. A new attempt a few days later frequently succeeds.

**The issuer decline** with no precise reason. It may come from an antifraud check, a temporary block, or a stop payment. The retry may or may not succeed.

**The lost, stolen or blocked card.** No retry will ever succeed. Only updating the payment method unblocks the situation.

Practical consequence: your sequence must take into account the **reason returned by the platform**, rather than applying the same dunning to everyone. Retrying fifteen times on a blocked card achieves nothing and can cost you fees.

## Preventing rather than chasing

Three measures that remove a large share of failures before they happen.

**The pre-expiry alert.** You know the card expiry date. A message thirty days before, with an update link, avoids the failure.

**Automatic card updating.** Card networks offer a mechanism by which a renewed card is reported to the merchant. Not every platform enables it by default, and it is worth checking.

**The upcoming charge notice.** A message a few days before the due date, recalling the amount and the date. It reduces disputes for unrecognised charges and it lets the customer plan ahead.

This last point is a legal obligation in several countries for automatically renewing subscriptions, and it is good practice in any case.

## The retry sequence

Four attempts spread over roughly two weeks cover most recoverable situations.

**Attempt 1: on the due date.** This is the normal charge.

**Attempt 2: three days later.** It recovers temporary shortfalls in balance.

**Attempt 3: seven days later.** Often timed after a payday, which improves the success rate.

**Attempt 4: fourteen days later.** Last chance before suspension.

Three complementary rules.

**Adapt to the reason.** On an expired or blocked card, do not retry: go straight to the update message.

**Space attempts out enough.** Retries too close together on a failing card can be read as suspicious behaviour by antifraud systems.

**Know when to stop.** Beyond four or five attempts the success rate becomes negligible, and each try can carry a cost.

## The message that goes with it

The technical retry is not enough. Every failure must trigger a message, and its content decides the outcome.

Five elements.

**The fact, without drama.** "Your subscription payment did not go through" rather than an alarming message.

**The likely cause**, if you know it. "Your card appears to have expired" points straight to the right action.

**The expected action**, with a direct link to updating the payment method. Not to the account area, to the exact screen.

**What happens next** and when. "We will retry on the 12th. Without payment by the 20th, your access will be suspended." The customer knows where they stand.

**A way to get in touch**, for the situations a form cannot settle.

A calibration point: two to three messages across the sequence, not one per attempt. Four messages in two weeks on the same subject produce a cancellation.

## The grace period

A commercial decision with a direct effect on retention.

Should access be cut off at the first failure? Almost never.

Three reasons. The failure is often **involuntary** and the customer acting in good faith. Cutting off immediately turns a technical incident into a **broken relationship**. And on a digital service, keeping access open for a few days costs you almost nothing.

A grace period of seven to fourteen days is a reasonable benchmark. It matches the length of your retry sequence.

On a physical product subscription the logic differs: the shipment is a real cost, and it should not leave before payment is collected. The grace period then applies to keeping the subscription alive, not to the delivery.

## Suspension, then cancellation

Three states to keep clearly distinct, and many implementations only handle two.

**Active with payment overdue.** Access is maintained, dunning is under way.

**Suspended.** Access is cut off, the subscription still exists, and the customer can reactivate it by settling up. This is the state most often missing, and it is the one that recovers the most subscribers.

**Cancelled.** The subscription is over. Resuming means signing up again.

The move from suspended to cancelled should happen after a long enough delay, thirty to sixty days, during which the customer can come back without losing anything.

An important point: keep the account history and data after cancellation. A former subscriber returning six months later should find what they had, which is a real argument for coming back.

## What you owe the customer

Three compliance points that frame this handling.

**Information on the due date and amount** before the charge, particularly on automatic renewals. Several European markets have made this explicit for consumer subscriptions.

**The ability to cancel**, which must stay reachable throughout the procedure. A customer in payment difficulty who wants to stop should be able to do so simply, without having to settle up first.

**Proportionate fees.** Charging dunning fees assumes they are contractually provided for, announced and proportionate. On a consumer subscription the practice is risky and the gain marginal.

## What sets a good sequence apart

One simple criterion: it must treat the failure as a technical problem to solve together, not as a failing on the customer's part.

In practice, three visible differences.

The **tone** stays neutral and helpful, including in the third message.

The **action** is made as easy as possible: one link, one screen, one field.

The **exit** stays open. A customer who would rather stop should be able to do so without obstacles, which preserves the chance that they come back.

## Measuring

Four indicators.

The **initial failure rate**, the share of charges that fail on the first attempt. A high rate can signal a configuration problem rather than a risky customer base.

The **recovery rate**, the share of failures eventually collected. This is the headline figure for your sequence.

The **breakdown by reason**, which tells you where to put the effort. If expired cards dominate, your project is the preventive alert, not the dunning.

The **reactivation rate after suspension**, which justifies the existence of that intermediate state.

The  handles this chain on PrestaShop 8 and 9: a retry sequence matched to the failure reason returned by the platform, a pre-expiry card alert, messages with a direct payment method update link, a suspended state distinct from cancellation and history retained after the subscription ends.