Why recurring billing is harder here than abroad
Subscription businesses elsewhere assume a saved card that charges itself every month. In Kenya, where M-Pesa dominates, that assumption breaks - and it is the single biggest reason local subscription products struggle to collect.
The issue is consent. M-Pesa is built so the customer authorises each payment with their PIN. That is great for security and terrible for silent monthly billing. So building subscriptions in Kenya is less about writing a charge loop and more about designing around how customers can and will authorise repeated payments.
Cards: the easy case
Where your customers have cards, recurring billing works the familiar way. The first payment tokenizes the card - you store a token, never the number - and each cycle your system charges that token automatically, no customer action needed.
The work that remains is handling the edges: cards expire, banks decline, and some charges trigger a 3D Secure step. A solid card subscription system detects an expiring card and prompts the customer to update it before it lapses, and retries soft declines intelligently. But the core - charge automatically each month - is genuinely easy on cards. If your audience is card-holding (corporate, diaspora, higher-end consumer), lead with cards for recurring.
M-Pesa: the honest picture
On M-Pesa there is no equivalent of a silently charged saved card. A standard STK Push always asks the customer for their PIN, so you cannot debit them in the background. Pretending otherwise leads to billing systems that simply do not collect.
There are two realistic paths. One is M-Pesa's recurring payments / standing-order facilities - M-Pesa Ratiba - where the customer sets up an authorised recurring debit, closer to a true mandate. The other is to schedule an STK Push each cycle and prompt the customer to approve it, treating billing as a nudge-and-confirm flow rather than a silent debit. Both are legitimate; both require designing the customer experience around authorisation, not hiding it.
Failed payments are normal - plan for them
In Kenyan recurring billing, a meaningful share of charges will fail on the first try, and almost none of those failures mean the customer wants to leave.
- An M-Pesa prompt arrives when the customer is busy and goes unanswered.
- The wallet or account is momentarily short of funds - common right before payday.
- A card has expired or the issuer soft-declines a legitimate charge.
- A network timeout leaves a charge in limbo, neither clearly paid nor failed.
- The customer simply misses the notification the first time.
Retries and dunning: where subscriptions are saved
Because failures are mechanical, recovery is largely mechanical too. This is dunning: a structured sequence of retries and reminders that turns a failed charge back into a paid one.
Good dunning re-attempts on a sensible schedule - not five times in an hour, but spaced across days, ideally timed around when customers have funds. It reminds the customer through their preferred channel, with a one-tap way to complete the payment. It escalates gently: reminder, retry, grace period, then suspension only as a last step. Businesses that do this recover a large share of would-be lost subscribers; businesses that treat the first failure as a cancellation bleed revenue they never had to lose.
Model subscription state, not just payment status
The hidden complexity of subscriptions is state. A subscriber is not simply paid or unpaid. They are active, or past-due but in a grace period, or suspended pending payment, or cancelled, or paused. They upgrade mid-cycle and expect proration; they downgrade and expect credit.
A billing system that only knows 'paid this month: yes/no' cannot handle grace periods, retries, or fair proration, and it will either cut off good customers too early or let non-payers keep using the service for free. Getting this state model right - and driving access, invoices and dunning off it - is what makes subscription billing dependable rather than a monthly scramble.
How Upeosoft builds subscription billing
We build recurring billing designed for Kenyan reality: card tokenization where customers have cards, M-Pesa recurring or scheduled-STK flows built around real customer consent, and a proper subscription state model with grace periods, proration and clean records. On top of that we add retries and dunning that actually recover failed payments, and reconciliation so every collection lands in your books.
If your subscription product struggles to collect, or you are launching one, talk to Upeosoft and we will build billing that keeps revenue from leaking.
