The failure is quiet, which is what makes it expensive. A hosting or SaaS customer signed up months ago, the first payment went through, and everything looked fine. Then a renewal invoice comes due, the gateway is supposed to charge the card on file automatically — and nothing happens. The invoice sits Unpaid, WHMCS starts sending overdue reminders, and a week later the service is suspended. You find out when the customer emails asking why their site is down.
This is the single most common WHMCS payment problem, and it is almost never a bug in WHMCS. It is a mismatch between how WHMCS bills and what your payment gateway is actually able to do.
What “recurring” really requires
There are two very different kinds of card payment:
- Customer-initiated — the customer is sitting at the checkout, entering (or confirming) their details. Every redirect-style gateway does this.
- Merchant-initiated (MIT) — you charge a stored card later, with no one present, using a payment token and a stored agreement created earlier.
WHMCS renewals are the second kind. When an invoice comes due, WHMCS’s cron tries to capture against a token the gateway stored at the first payment. If the gateway never stored a reusable token — or isn’t authorised for merchant-initiated charges — there is nothing to capture, and the renewal simply fails.
Why renewals break
Four causes account for almost all of it:
- The gateway doesn’t support tokenised/MIT payments at all. Many redirect or hosted-page gateways only ever take a customer-present payment. They work perfectly for the first invoice and cannot charge a renewal, because that requires a stored agreement they never created.
- The stored token expired or was never created. Some modules only tokenise when the customer ticks a box, or the provider’s agreement lapses. The renewal then has no valid token to charge.
- Every module handles it differently. WHMCS gateway modules each implement
capture(or don’t) in their own way. One gateway auto-charges cleanly; the next needs the customer to pay every invoice by hand — and you only discover which is which after renewals start failing. - Card updates and soft declines. Cards expire and get reissued. Without account-updater support or a retry path, a renewal that could succeed on a second attempt is written off as a hard failure.
The result is the same in every case: the invoice goes unpaid, WHMCS dunning kicks in, and otherwise-happy customers churn involuntarily — not because they wanted to leave, but because the payment silently didn’t go through.
How to diagnose it
Before changing anything, confirm this is what’s happening:
- Check the module log in Utilities → Logs → Module Log, filtered to your gateway, around a renewal date. A failed capture or a “no payment method” error is the tell.
- Look at whether the gateway is tokenised. In System Settings → Payment Gateways, tokenised gateways expose saved payment methods; redirect-only gateways don’t.
- Watch one renewal end to end. Let an invoice reach its due date and see whether the cron charges it or leaves it Unpaid.
If renewals only ever succeed when the customer pays manually, your gateway isn’t doing merchant-initiated payments — and no amount of dunning configuration will fix that.
How to fix recurring payments in WHMCS
The durable fix is to use a payment path that actually supports merchant-initiated renewals, so WHMCS can capture on the due date without the customer present. In practice that means a gateway (or an orchestration layer) that:
- Creates a reusable agreement at the first payment and stores a token WHMCS can charge later.
- Charges renewals automatically through the standard WHMCS callback, so the invoice is marked paid the moment the capture succeeds.
- Reports failures back to WHMCS cleanly, so its own retry and suspension rules can run — instead of the invoice hanging in limbo.
How PaymentHood handles WHMCS renewals
PaymentHood is a payment orchestration platform with a free WHMCS module, and recurring billing is built in rather than bolted on. When a customer pays with a method that supports agreements — such as PayPal, Stripe or Authorize.net — PaymentHood creates the subscription agreement at the provider. From then on, the renewal invoices WHMCS generates are charged automatically, with no customer action required.
Because it’s an orchestration layer, two more things follow. First, renewals, statuses and refunds flow back into WHMCS through the standard gateway callback, so your billing stays the source of truth. Second, if a provider has trouble, you can switch the active provider from a dashboard without reconfiguring WHMCS or asking customers to re-enter anything — the one thing you can never do on a redirect-only gateway mid-renewal-cycle.
Where PaymentHood fits
If your renewals are failing, the problem is almost always that your gateway can’t do merchant-initiated payments — and that’s exactly the gap PaymentHood closes. It connects WHMCS to 30+ providers through one free module, with tokenised recurring support, automatic failover, webhook verification and server-side confirmation handled for you. There’s no per-transaction fee from PaymentHood; you pay only your chosen provider’s processing fees.
Create a free PaymentHood account, see the WHMCS integration and its installation guide, or browse the full provider directory.