Failed Payments

Payments fail routinely — expired cards, insufficient funds, fraud blocks. What happens next is something you build, not something that is configured.

Where to find it

Architect Panel → Automation:

Workflow Builder — the rules that react to a failure
Journeys — a multi-step recovery sequence

Architect Panel → Subscriptions:

Subscribers — who is affected

How you find out

Stripe sends a webhook. It is verified, logged, and fires the platform’s rules with the event type as the trigger. Everything after that is yours to define.

There is no built-in dunning schedule waiting to be switched on — which is worth knowing, because assuming one exists means nobody is chasing anything.

Stripe retries on its own

Configured in the Stripe dashboard, not here. Set the retry schedule there and the recovery process here, and be careful not to build a second retry cycle that conflicts with Stripe’s.

A workable process

First failure — record it against the subscriber, e-mail the customer. Do not restrict anything.
Continued failure — a second message, more direct, with a way to update the card.
Final notice — say plainly what will happen and when.
Restrict — reduce access rather than deleting anything.
Cancel — and keep the record.

Build it as a journey rather than as separate rules, so the sequence is visible in one place and somebody can see where a customer has reached.

Failures are usually not deliberate

Most are an expired card. The tone of the first message should assume that, because treating an ordinary card expiry as a debt-collection matter loses customers who fully intended to pay.

Restrict, do not delete

A customer who resolves the payment should get their access back intact. Deleting data over a failed payment turns a recoverable situation into a lost customer, and occasionally into a data-protection complaint.

Give somebody the list

Automation handles the routine cases; the ones that need a person need a person. A view of subscribers in failure, checked weekly, catches the customer who has been quietly failing for a month because their e-mail address is also wrong.

Watch the recovery rate

If most failures recover after the first message, your process works. If they do not, the problem is usually that the messages are not reaching people — check what address they go to and whether it bounces.

Worked example

A subscription business runs a five-step journey from first failure to cancellation over three weeks, restricting rather than deleting at day fourteen. A weekly view of accounts in failure is reviewed by one person. Most recover at the first e-mail; the review catches the handful whose contact address is stale.

Recommendations

Build the process — there is no default one.
Set retries in Stripe, recovery here, and do not duplicate.
Assume an expired card in the first message.
Restrict rather than delete.
Review the failure list weekly with a person.