Give the next renewal a clear path
Amina has joined Letu Plus for KES 890 a month. When the next month arrives, she should know what is due and how to keep watching. Letu should know whether she has paid and when a follow-up would help.
The payment steps depend on the provider and the authorization available for that route. Some routes require the customer to approve each payment; others can support recurring collection under an appropriate mandate. The journey below uses a customer-approved wallet payment.
In Kenya, for example, an M-PESA payment initiated by a business can result in an STK prompt on the customer's phone. The customer reviews the request and enters an M-PESA PIN to approve it. Airtel Money transactions similarly rely on the customer's wallet and PIN-controlled authorization. In Uganda, MTN MoMo merchant payments are also completed from the customer's mobile-money account with a PIN.
That difference changes what "renewal" means operationally.
A monthly invoice can be created automatically. A reminder can be scheduled automatically. A checkout link can be generated automatically. But the actual wallet payment may still depend on the customer seeing, understanding and authorising a payment request.
For Letu collecting KES 890 each month for Plus, the renewal problem is therefore not simply "charge the customer again." It is: make the next payment moment clear enough that the customer can complete it, and keep the business's invoice state accurate when they do not.
Start with a clear mobile-money renewal request
Amina’s next Letu Plus subscription payment is due on 12 September.
A useful renewal message should tell them:
- which business is requesting payment;
- what the KES 890 charge is for;
- which billing period it covers;
- when it is due;
- whether M-PESA, Airtel Money or another route is actually available;
- what they should expect on their phone after choosing a wallet.
This is more important than it sounds. Mobile-money customers are used to acting on phone prompts, USSD menus, wallet apps and SMS confirmations. A payment request that arrives without enough context can look suspicious, especially if the prompt itself is initiated by a provider rather than displayed inside the merchant's website.
The merchant should therefore connect the message, checkout and provider-controlled authorization into one understandable sequence.
For example:
"Your September Letu Plus subscription of KES 890 is due. Choose M-PESA or Airtel Money to continue. After you choose a wallet, follow the authorization instructions on your phone."
The customer should never need to guess why a wallet prompt appeared.
Do not treat every unpaid mobile-money invoice the same way
The biggest mistake in recurring mobile-money recovery is to reduce every unpaid invoice to one label: failed.
Several different things may have happened.
- The customer may not have opened the payment link.
- They may have opened checkout but not selected a wallet.
- An M-PESA STK prompt may have expired before authorization.
- The customer may have rejected the request.
- The provider may have acknowledged the attempt while the final result is still unresolved.
- Or the customer may already have paid while the merchant's own system has not yet matched the provider evidence back to the invoice.
Those situations require different next actions.
A renewal workflow should distinguish at least:
- Due, no attempt yet — The customer still needs a useful reminder or payment path.
- Awaiting customer authorization — The wallet flow has started. Do not behave as if the payment has already failed.
- Failed or expired — There is enough evidence to offer a fresh customer-authorized attempt.
- Unknown or unresolved — Do not immediately ask the customer to pay again. Verify the earlier attempt first.
- Confirmed — Stop collection communication and update the invoice.
- Paid but not reconciled — Finance may still have work to do, but the customer should not be chased again.
This is where recurring mobile-money billing differs sharply from a simplistic "retry the card" playbook.
Keep one invoice even when the wallet attempt changes
The commercial obligation and the payment attempt should not be the same object.
Suppose the September invoice is KES 890.
Amina first chooses M-PESA. The prompt expires. The invoice is still KES 890. Nothing about the amount owed has changed.
Later, Amina returns and chooses Airtel Money, assuming Airtel Money is enabled for that merchant and payment route. That should create a new payment attempt against the same unpaid invoice, not a second invoice and not an overwritten history.
This structure matters because a late provider response can otherwise create duplicate-payment risk. If the first M-PESA attempt later resolves successfully after a second payment has already been requested, the merchant needs enough history to investigate what happened.
One obligation. Multiple traceable attempts when necessary. One final paid state.
That is a safer model for M-PESA recurring payments, Airtel Money subscriptions and other customer-authorized mobile-money renewals.
Use reminders to reduce uncertainty, not to increase pressure
A mobile-money dunning sequence should be based on payment state, not only on time.
For a Kenyan monthly subscription, a respectful pattern might be:
- Two days before due date — Explain the upcoming KES invoice and available wallet options.
- Due date — Present the invoice and payment link.
- Attempt expired or failed — Explain that the invoice remains unpaid and offer a new payment action.
- Attempt unresolved — Tell the customer that the previous payment is still being checked and they do not need to pay again yet.
- Payment confirmed — Stop all renewal reminders.
- Grace period exceeded — Apply the merchant's agreed service or support policy.
The exact timing will differ between an online school in Kenya, a professional membership in Uganda and a regional SaaS business. The principle is the same: the message should correspond to what the system actually knows.
Country context matters
A recurring-revenue business expanding across Africa should not assume that the same mobile-money journey exists everywhere.
In Kenya, M-PESA is an obvious customer expectation and Airtel Money is an important second wallet. Safaricom's merchant-initiated STK flow requires the customer to confirm the amount and enter a PIN, and the same PIN-controlled, customer-authorized pattern applies to Airtel Money. In Uganda, MTN MoMo and Airtel Money are the relevant merchant rails, with MoMoPay completing from the customer's wallet. In Nigeria, licensed mobile money operators such as OPay and PalmPay sit alongside a large instant account-transfer ecosystem, so a copied Kenyan checkout with a different currency label would be the wrong approach.
The recurring billing model can stay stable across all of these. What changes is the local payment experience, and the renewal design should follow the market's actual behavior rather than the other way around.
Measure whether the renewal operation is actually improving
For recurring mobile-money payments, useful growth metrics go beyond successful transactions.
Track:
- percentage of invoices paid by due date;
- time from invoice creation to confirmed wallet payment;
- M-PESA, Airtel Money or other wallet completion by enabled route;
- number of reminders before payment;
- recovery after an incomplete first attempt;
- unresolved payment incidents;
- duplicate-payment incidents;
- customer support contacts about payment status;
- manual staff touches per invoice;
- time from confirmed payment to reconciled invoice.
These measures help a business see whether it is making mobile-money renewals easier, or merely generating more prompts.
The renewal operating model
Recurring mobile-money collection needs a different operating model from card-on-file subscriptions, and it can be stated in three rules.
First, separate the schedule from the authorization: automate invoices, reminders and links, but never assume the wallet payment is automatic. Second, keep the invoice stable while attempts change — a customer can try M-PESA, let the prompt expire and later authorize Airtel Money against the same obligation, with every attempt traceable. Third, let the message match the evidence: treat failed and unresolved differently, name each wallet only where it is genuinely enabled, and stop recovery the moment payment is verified.
That is the recurring-revenue problem RoamerWave is focused on: the commercial state, customer-authorized wallet attempts, recovery and reconciliation work that sits around the licensed providers executing the actual mobile-money payment.