Recurring payments are a billing problem as much as a payment problem
A recurring business has a simple commercial pattern: value becomes due again. That can be a SaaS subscription, gym membership, school installment, rent, a retainer, association dues or another repeat obligation. The payment rail moves money. The billing operation keeps track of what is due, whether it was paid, what happens when a payment does not complete and how the result reaches finance.
That distinction matters in Kenya because mobile money is part of everyday financial life. The 2024 FinAccess Household Survey reported that 82.3% of Kenyan adults used mobile money, compared with 52.5% who used banks, and the Communications Authority reported 53.4 million mobile-money subscriptions at the end of March 2026. These measure different things (our Kenya mobile-money statistics guide explains how), but both lead to the same conclusion: a Kenyan billing strategy should make a deliberate decision about mobile money rather than treat it as an edge case.
What actually recurs?
The cleanest starting point is the amount that becomes due, not the wallet. A recurring billing record should know:
- who owes the amount;
- what the payment is for;
- the billing period;
- the amount and currency;
- the due date;
- whether the obligation is still due, paid, adjusted or cancelled.
Each payment attempt is then linked to that record. One monthly invoice can have more than one attempt: a customer might ignore the first payment request and pay two days later from a reminder link. The business still has one invoice for the month, with two attempts recorded against it.
Why mobile money changes recurring billing
Many card subscription systems assume that a stored card authorization can support later background charges. Mobile-money flows often work differently.
Safaricom's Daraja platform exposes payment APIs such as M-PESA Express (the STK Push prompt), Customer to Business (C2B), M-PESA Express Query and Transaction Status. M-PESA Express lets a business send a payment request for a PayBill or Till to the customer's phone. The customer still approves the payment with their M-PESA PIN.
Recurring billing can therefore be highly automated without claiming that every renewal is an invisible automatic debit. A business can automate:
- invoice creation and due-date scheduling;
- payment reminders and contextual payment links;
- payment-attempt creation;
- processing provider callbacks and checking results that arrive late;
- recovery rules;
- reconciliation;
- service or membership updates.
How the customer authorizes each payment still depends on the payment method and the merchant's provider setup.
What the customer should experience
The customer should not need to understand provider APIs or billing architecture. They should know which business is asking for payment, what it is for, how much is due, which payment methods are available, what to do next and whether the payment has been confirmed.
A useful renewal message might say: "Your November membership of KES 3,500 is due. Choose an available payment method to complete it."
The point is context. The customer should not have to rebuild the payment from an old PayBill poster, a remembered account number and a separate WhatsApp conversation. A clearer payer experience also helps the merchant, because it reduces wrong references, payment-status questions and manual confirmation.
Payment state is where recurring operations become real
Creating a payment request does not mean money has been received. A recurring-payment workflow needs to tell these states apart:
- Due: the commercial obligation exists.
- Awaiting customer: the customer still needs to approve the payment.
- Pending: the provider is processing the payment.
- Unknown: the result cannot yet be confirmed safely.
- Failed or expired: the attempt ended without payment.
- Paid: the obligation has been satisfied.
- Reconciled: finance has matched the payment evidence to the business record.
These distinctions have direct consequences. If an unresolved payment is treated as failed, the customer may be asked to pay again and end up paying twice. If a successful payment is not matched to the right invoice, staff may keep chasing someone who has already paid.
The two main merchant problems in Kenya
Recurring-payment businesses usually arrive from one of two directions.
Operations-led merchants
These businesses already accept mobile money: gyms, schools, associations, property managers and local service providers. Their problem is rarely access to M-PESA. It is everything around the payment:
- knowing who is due;
- matching payments to customers;
- stopping reminders once someone has paid;
- handling failed or unresolved attempts;
- updating access or account state;
- reconciling finance records.
For them, recurring-payment software is an operations tool.
Access-and-expansion-led merchants
These businesses often already run mature card billing. A SaaS company entering Kenya may manage plans, invoices, account state and card renewals well, but some Kenyan customers prefer to pay with a local wallet. The job is to add local payment access without building a separate billing engine for every wallet or country. The billing model should stay stable while the payment route changes. Our guide for SaaS product teams covers that implementation in detail.
Choosing a system
The useful buying question is not "Does it support M-PESA?" but which parts of the recurring operation will still be manual after you adopt it. Our buyer's guide to recurring payment software in Kenya turns that into a checklist and a set of demo scenarios to test.
Not every merchant needs a recurring-payment platform. A PayBill or a payment link can be enough when payments are infrequent, the customer base is small and staff can reconcile comfortably. The case for recurring software grows as repeat obligations create repeat administrative work.
Where RoamerWave fits
RoamerWave is for merchants that need a recurring operating layer across local payment methods. The merchant's licensed PSP or payment provider continues to process and settle each transaction. RoamerWave focuses on the commercial workflow around it: obligations, payment attempts, payment state, recovery and reconciliation.
That makes it relevant both to merchants that already accept mobile money and need better operations, and to merchants with mature billing that need local-wallet access.
A renewal in practice: one obligation, several operational states
Consider an illustrative November membership invoice for KES 3,500. These are invented teaching records, not RoamerWave transaction data or typical provider timings.
| Event | What the business records | What staff should do |
|---|---|---|
| November invoice becomes due | One KES 3,500 obligation | Send a clear invoice or renewal notice |
| Customer begins an M-PESA request | Attempt A linked to that invoice | Show "awaiting approval", not "paid" |
| Provider result is delayed | Attempt A becomes unknown; invoice still due | Pause new collection attempts and check provider evidence |
| Provider confirms success | Payment confirmed; invoice satisfied once | Stop reminders and update service according to policy |
| Finance matches the provider record | Reconciled, with the payment reference retained | Investigate any mismatched items separately |
| PSP settlement is reported | Settlement recorded independently | Match settlement evidence and fees without asking the customer to pay again |
The distinction between payment confirmation and settlement protects both customer experience and finance. A merchant's own policy decides when access changes; a delayed callback alone is not evidence that the customer refused to pay.
What to measure before buying software
For one billing cycle, capture how many invoices became due, how many payment attempts were unresolved, how many successful payments required manual matching, how many unnecessary reminders were sent and how long staff spent resolving exceptions. Keep the sample customer references anonymous. These are operational baselines for your business, not industry benchmarks.
If a PayBill and disciplined receivables ledger handle the volume well, additional software may not yet pay for itself. If the same invoice repeatedly generates manual investigation, measure that work before choosing a platform. Compare collection methods and review the Kenya software buying questions.
