De-bunking "Insufficient Funds"

If you run subscriptions, e-commerce, or any kind of recurring billing, "insufficient funds" is one of the most common reasons your payments fail. It's also one of the most misunderstood payment errors. The label sounds final (the customer didn't have the money), but on card rails it often isn't true. And the failures that aren't really about money are exactly the ones a well structured recovery strategy can claw back.

The leadership instinct

When company leadership sees that decline reason, the instinct is operational: the customer has insufficient funds, let's retry or start the arrears process. Sometimes that's true, sometimes it isn't, and the difference matters for the recovery line on the P&L.

Industry voices estimate that around 40% of total subscription churn is involuntary: customers who didn't actively cancel, but whose payment failed and who never re-engaged.¹ A meaningful share of that is recoverable: The customers said yes, they intend to keep paying, they just can't be charged at this exact moment, on this exact path.

What “insufficient funds” could actually be

"Insufficient funds" is a single response code that has to absorb several distinct realities that range in complexity:

• The bank account is genuinely empty.
• The account does have the funds, but a hold from a hotel pre-auth or gas-pump auth is encumbering the available balance. These holds last up to 8 days on debit and 30 days on credit.²
• The issuer's risk system flagged a pattern (fraud score, merchant-category restriction) and dressed the decision in a balance code.
• A velocity rule fired (too many attempts in a window, threshold breached).
• The card is geo-blocked for that merchant category, or the issuer's policy engine flagged it for any of a dozen reasons that have nothing to do with the customer's balance.

One label. Five different things going on underneath. Each has a different fix, or no fix at all.

Same card, same minute, different PSP

Here's the part most teams don't realise. Same card, same amount, same minute. Declined on Payment Service Provider (PSP) A, approved on PSP B. If the customer were genuinely broke, this could not happen.

A different PSP means a different combination of inputs to the issuer's risk model:

• The authentication context (3DS step-up vs frictionless).
• Whether the card runs as a network token or as a raw card-on-file.
• The BIN and merchant category code on the auth message.
• Whether partial-authorisation signaling is on or off.
• The risk-engine reputation between the merchant and the issuer.

Different inputs, different decision. The customer's balance was never the deciding factor, so swapping the path of the payment changes the outcome where swapping the day would not.

This is also why top-of-market merchants (Booking, Uber, Amazon, Shopify) all run multiple PSPs as standard.³ It isn't a performance trick, it's how merchants stop trusting a label that's often wrong.

Why payday timing matters, but isn't enough

Payday-aware billing means timing both the first attempt and the retries to the customer's payday. One operator reports recovering ~42% of "insufficient funds" cancellations using exactly this approach.⁴

But payday is only one of the realities behind the label. If the decline was a risk-system decision or a path issue, payday changes nothing. The same path produces the same answer.

A well structured recovery stack does both, in order: first route to the path that gives you a more honest answer, then retry within that path on the right day for the cases that genuinely are about timing.

Wallet rails: a more honest signal

On African mobile-money rails such as M-Pesa, MoMo, and Airtel Money, the failure mode is structurally different. The wallet is the account; there's no upstream bank to authorise against. The ledger is online and authoritative. So when a wallet returns "insufficient funds," it's much closer to actually meaning what it says.⁵

This applies in wallet-dominant markets (Kenya, Uganda, Ghana, parts of West and East Africa) more than South Africa, where card payments dominate. For merchants operating across African corridors, the implication is uneven: wallet-rail declines you can take closer to face value, card-rail declines you cannot. In South Africa specifically, where the merchant flow is mostly cards, a single-PSP stack puts you at risk of writing off sales that a different route could have saved.

The takeaway

On a single PSP, one path's verdict is the whole story. Everything it declines becomes a "bad customer." The recoverable revenue sits in two places: retries timed to the customer, and the path you didn't try. Retry gets you one. Routing gets you both.

References:

¹ Industry estimate via Philip Pages / Recurly. ~40% of subscription churn is involuntary.

² Visa, Partial Authorization Service. Hold durations vary by debit (~8 days) vs credit (~30 days).

³ Multi-acquirer standard observed across top-market merchants (Booking, Uber, Amazon, Shopify).

⁴ Philip Pages, LinkedIn (2026). 18,270 of 43,891 cancellations recovered via payday-aware retry. Operator claim, not independently audited.

⁵ Wallet-rail recovery model, NjiaPay internal.