Recurring billing people do not have to fight to escape

Recurring revenue is the most attractive shape a business can have, which is why so many companies pursue it to the point of making their customers resent them.

There are two failures worth designing against, and they pull in opposite directions.

The first failure: giving up too early

A renewal fails. The balance was short that morning. The subscription is cancelled, access stops, and a customer who fully intended to keep paying is gone.

Most failed renewals are not decisions. They are a Tuesday.

Dunning is the fix: a failed collection is retried on a published schedule rather than abandoned on the first attempt. Spread across days, most of those payments simply succeed, and the customer never knows there was a problem.

It is unglamorous and it is the single highest-return thing in recurring billing.

The second failure: not letting go

The opposite temptation, and far more damaging: making cancellation difficult.

Hide the button. Require a phone call. Only during office hours. Offer three retention screens before the real one.

This works, in the sense that it buys one more month. It also produces a customer who tells everybody, and who will never come back — and increasingly, a regulator who takes an interest.

Cancellation here stops the next collection, from the customer’s own side. No call, no retention maze, no support ticket.

A business that only retains customers who cannot find the exit does not have recurring revenue. It has a countdown.

A mandate, not a stored card

Collection rests on a mandate the customer confirmed — an explicit agreement to be charged on a schedule.

That is a different thing from keeping a card number on file and hoping it still works. The customer agreed to the arrangement, can see it, and can end it.

Events, so your system knows

Created, cancelled, invoice paid, payment failed — all published as events.

Your product can suspend access when dunning finally fails, and restore it the moment a retry succeeds, without anybody polling anything.

Metered plans

Usage can be recorded against a subscription, so a plan that charges for what was used invoices for what was used.

What it costs

The ordinary rate on the payments collected. There is no charge for the schedule itself.

What you can check

These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.

• Collection rests on a mandate the customer confirmed, not on a card number kept on file.
• A failed collection is retried on a published dunning schedule rather than being abandoned on the first failure.
• Subscription lifecycle events — created, cancelled, invoice paid, payment failed — are published, so your system knows without polling.
• Usage can be recorded against a subscription where a plan is metered rather than flat.

What it costs

Subscriptions carry the ordinary rate on the payments they collect. There is no separate charge for the schedule.

Is it switched on?

Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Subscriptions and recurring billing on the features page.

Read next

• Payment links — Get paid by sending a message.
• Signed webhooks — Your software finds out before your customer does.
• The gateway API — Three calls and a webhook.