Why Hosting Payments Fail: A Taxonomy

"Payment failed" is not a reason, it is a category. Underneath it sit half a dozen genuinely different events with different causes, different recovery rates and different correct responses — and treating them as one thing is why most hosting dunning sequences underperform.

Here is the taxonomy, and what each one should actually trigger.

The failures, and what they mean

Expired card. The card is fine, the number is stale. This is not a credit problem and the customer is not in difficulty — they simply have a new piece of plastic and have not told you. Highly recoverable, and it is predictable: you knew the expiry date when you stored the card. Any recovery effort spent here has the best return of anything on this list, because the fix is a form, not a decision.

Insufficient funds. A timing problem more often than a solvency one. Retrying on the same day repeatedly is pointless; retrying a few days later, or around a typical payday, is not.

Do not honour / generic decline. The issuer declined without saying why, which is deliberate on their part. Sometimes fraud heuristics, sometimes a limit, sometimes nothing meaningful. Retry once or twice, then ask the customer to use a different method — you cannot diagnose it and neither can your processor.

Authentication required. The transaction needs the cardholder present to authenticate. Unattended retries will fail forever. This one must route the customer to a page where they can complete it, and a dunning sequence that just retries is guaranteed to lose the customer.

Lost, stolen or blocked card. Do not retry. Repeated attempts against a blocked card is a pattern issuers notice, and it will not succeed.

Mandate cancelled. For direct debit, the customer revoked the mandate at their bank. That is a cancellation signal by another route, and treating it as a failed payment misreads it entirely.

Gateway or network error. Nothing to do with the customer. Retry promptly, and do not send a dunning email — telling a customer their payment failed when your processor had an outage is an unforced credibility loss.

The distinction that reframes dunning

Split the list in two and the strategy falls out.

Non-decisions — expired cards, timing, authentication, technical errors. The customer has not chosen to stop paying. They want the service and something mechanical is in the way. Your job is to remove the obstacle with as little friction as possible.

Decisions — blocked cards, cancelled mandates, sustained insufficient funds. Something has changed on the customer's side. Your job is to find out what and offer an option, not to retry harder.

Most involuntary churn in hosting sits in the first group, and most dunning sequences are written for the second. That mismatch is the gap worth closing: a sequence that treats an expired card like a delinquency loses a customer who never intended to leave.

Prevention beats recovery

Expired cards are the only common billing failure you can see coming, which makes them the one place prevention actually works. You hold the expiry date. A reminder a few weeks ahead, with a one-click update link, converts a future failure into a non-event — and it is the highest-return automation in billing because it costs one email and prevents an entire dunning cycle.

Two more preventive measures worth the effort: an account-updater service through your processor where available, which refreshes stored card details automatically; and offering a second payment method to customers on annual plans, where a single failure is a whole year of revenue — see annual versus monthly billing.

Why most platforms cannot do this

The processor returns a specific decline reason. A great many billing systems then throw it away and record "payment failed", because that is all the generic gateway interface was designed to carry.

Once that information is discarded it cannot be recovered, and every downstream decision degrades to a guess. You cannot retry differently for an expired card than for a blocked one, you cannot route an authentication failure to an authentication page, and you cannot report on why payments fail — which means you cannot tell whether your recovery is working or whether your customer base is deteriorating.

When evaluating a platform, ask specifically: does the failure reason from the processor reach the service record and the dunning logic, or does it stop at the gateway integration? It is a narrow question and it determines whether anything else in this post is implementable.

A sequence shaped by reason

• Expired: immediate email with an update link. No dunning tone. Retry once the method is updated, not on a schedule.
• Insufficient funds: retry after a few days, then again a week later. Two or three attempts, spaced, then a human-shaped email.
• Authentication required: stop retrying. Send the customer to complete authentication.
• Generic decline: one or two retries, then ask for a different method.
• Blocked / mandate cancelled: no retries. Contact directly.
• Technical error: retry quickly, notify nobody.

Underneath all of them sits the suspension timeline, which should be generous enough that a recoverable failure never reaches it — see the suspension and termination timeline.

How FluxBilling fits

Every FluxBilling payment gateway plugin forwards the processor's own decline and failure reason back into the platform rather than collapsing it into a generic error, so the reason is available to dunning logic and to reporting instead of being discarded at the integration boundary. Gateway webhook deliveries are logged durably, so an asynchronous failure or reversal leaves a record rather than disappearing into a request that returned 200.

Automatic payment runs in the daily lifecycle pass after renewals are generated and before suspension checks, so a service is not suspended in the same run that would have charged it successfully. Invoice reminders and renewal reminders run in the same pass.

See the gateway catalogue and dunning management.

Closing thoughts

Pull last quarter's failed payments and group them by the reason your processor gave. If your platform cannot produce that breakdown, that is the finding. If it can, the shape will tell you where the money is — and for most hosting providers, an uncomfortable share of it is sitting in expired cards that nobody was ever asked to update.