Adding an African market is not adding another wallet logo
A recurring-revenue business entering Kenya, Uganda or Nigeria is not simply turning on another payment method.
The commercial obligation may remain familiar—a monthly SaaS plan, a school-fee installment, a membership or an annual digital-service renewal—but the payment environment underneath it can change dramatically.
- Kenya may require a merchant to support M-PESA and Airtel Money.
- Uganda may require MTN MoMo and Airtel Money.
- Nigeria may require a merchant to think about licensed mobile money operators such as OPay and PalmPay alongside the country's extensive instant account-transfer ecosystem.
The authorization journey, merchant approval, provider relationship, payment evidence and reconciliation data can all differ.
A good expansion strategy therefore preserves the recurring-revenue model while treating local payment behavior as a first-class design constraint.
Start with the same commercial questions in every country
Before choosing a PSP or wallet, define what the customer is buying.
For example:
- A professional-learning business sells a monthly plan.
- Kenya price: KES 3,500.
- Uganda price: UGX 95,000.
- Nigeria price: NGN-denominated according to the merchant's commercial policy.
The exact prices are merchant decisions. The operating model should answer the same questions everywhere:
- when does the invoice become due?
- what billing period does it cover?
- which entity is the seller?
- what happens after confirmed payment?
- what happens when the payment is late?
- when does access change?
- who handles disputes and refunds?
- which system is the source of truth for the invoice?
These questions should remain stable even if the payment route changes underneath them.
Kenya: design around M-PESA and Airtel Money, not card assumptions
Kenya is a strong example of why recurring mobile-money collection is its own operating problem.
Safaricom documents M-PESA merchant payments and merchant-initiated STK requests. In an STK Push flow, the customer receives a request on the phone, reviews the amount and enters an M-PESA PIN or cancels.
That is customer authorization at payment time.
Airtel Money is also relevant. Airtel Kenya documents merchant/paybill functionality and even permits Airtel Money customers to pay supported Lipa na M-PESA tills.
For a recurring-revenue merchant, this means the billing schedule can be automatic while the actual wallet payment may still need customer action.
The Kenya country package should therefore specify:
- whether M-PESA is enabled for this merchant;
- whether Airtel Money is enabled;
- how each attempt is initiated;
- what the customer sees;
- how long the merchant waits for final status;
- which provider references are returned;
- how a failed or expired attempt is recovered;
- how a confirmed payment maps back to the invoice;
- how provider reporting and settlement are reconciled.
Do not publish "M-PESA supported" as if it answers all of those questions.
Uganda: MTN MoMo has its own merchant-payment behavior
In Uganda, MTN MoMo is a major merchant-payment rail.
MTN Uganda's published MoMoPay instructions have customers provide a merchant code, amount and MoMo PIN to complete a merchant payment. MTN also describes payment processors and aggregators as participants that can integrate directly or indirectly with its Mobile Money payment system under relevant contracting and KYC requirements.
A merchant expanding from Kenya to Uganda should not simply rename an M-PESA screen "MTN MoMo."
The business needs to establish the actual approved route and customer interaction.
The Uganda country package should ask:
- Is MTN MoMo available for this merchant and provider setup?
- Is Airtel Money also required?
- How does customer authorization happen for the specific integration?
- What status states does the provider expose?
- What does an expiry or rejection look like?
- How are duplicate or late events handled?
- Which provider account receives the payment?
- What finance and settlement references are available?
The commercial invoice can remain provider-independent even while these details differ.
Nigeria: do not force an East African mobile-money model onto the market
Nigeria is an important counterexample to the idea that "African mobile money" is one uniform customer journey.
The Central Bank of Nigeria lists OPay and PalmPay among licensed Mobile Money Operators.
At the same time, Nigeria has a large instant-payment infrastructure connecting banks, fintechs and other participants through interoperable account-based transfers.
For a recurring-revenue merchant, the discovery question is therefore not "How do we copy our M-PESA flow into Nigeria?"
It is: Which local payment methods do our Nigerian customers already use for this kind of purchase, and what recurring operating model can preserve invoice, payment-attempt and reconciliation state across those methods?
A Nigerian collection route may involve a very different customer action from a Kenyan M-PESA STK request.
That is acceptable.
Consistency should live in the commercial lifecycle, not in pretending the rail is identical.
Separate "recurring billing" from "automatic debit"
This question must be answered for every market and every provider.
"Recurring payments" can mean:
- create a new invoice every month;
- send a new payment request each cycle;
- automatically charge a stored card;
- execute a standing instruction;
- use a reusable mandate supported by a particular rail;
- ask the customer to authorize each new wallet payment.
Those are different capabilities.
Before launching a mobile-money renewal flow, ask the provider:
- Does each cycle require fresh customer action?
- Is there a reusable mandate?
- What happens if the customer ignores the request?
- How long can the payment remain pending?
- Can a final status arrive late?
- Can the merchant query final status?
- How do retries work?
- How are duplicate payments prevented?
- Which mobile-money rails actually support the advertised "recurring" feature?
Never infer those answers from a marketing label.
Map the regulated payment relationship
Technical access is not commercial approval.
For every new African market, document:
- the legal entity selling the product;
- the PSP or regulated provider approving the merchant;
- the wallet or rail enabled for that merchant;
- customer currency;
- provider account;
- settlement destination;
- refunds and reversals;
- reserves or holds where applicable;
- provider reporting;
- support and escalation ownership.
A software layer can coordinate the recurring-revenue workflow, but the licensed provider remains responsible for the regulated payment execution and settlement responsibilities defined in its merchant arrangement.
This distinction matters when a business works with different PSPs in Kenya, Uganda and Nigeria.
Build a country capability package
Do not scatter local differences across code and support documents.
Maintain one explicit package per country.
For each market, capture:
- Currency — KES, UGX, NGN or other applicable local currency.
- Wallets and rails — Which methods are actually enabled, not merely technically known.
- Authorization semantics — Phone prompt, USSD, app authorization, transfer confirmation, mandate or another approved flow.
- Phone/account rules — Normalization, required identifiers and local validation.
- Attempt expiry — How long an initiated request remains actionable.
- Payment-state mapping — How provider states map into initiating, awaiting authorization, succeeded, failed, expired or unresolved.
- Refund capability — What the provider supports and who controls it.
- Merchant approval — KYB and route requirements.
- Reconciliation evidence — Transaction references, provider reports, fees and settlement records.
- Operational escalation — What support or engineering does when the route behaves unexpectedly.
The stable merchant-facing abstraction should survive the differences without hiding them.
Test failure before you call a market ready
A successful sandbox transaction proves very little.
Before launching recurring mobile-money collection, test:
- successful customer-authorized payment;
- customer rejection;
- expired prompt or request;
- unreachable phone or equivalent interruption;
- delayed provider response;
- unresolved status;
- late success;
- repeated callback or duplicate event;
- new attempt against the same unpaid invoice;
- refund;
- provider reconciliation;
- settlement reporting.
For a Kenya M-PESA route, test what happens if an STK prompt expires.
For Uganda, test the failure and status semantics of the actual MTN MoMo or Airtel Money integration you have contracted.
For Nigeria, test the real payment method and provider flow selected for the merchant instead of importing East African assumptions.
A new market is ready when the failure paths are understandable, not only when success is possible.
Decide where recurring-revenue truth lives
If each country's PSP becomes the source of truth for subscriptions, a regional merchant can slowly end up with several billing systems disguised as one product.
The merchant should be able to answer the same questions everywhere:
- What is due?
- Which attempts belong to the invoice?
- What is the latest verified payment result?
- Should the customer be contacted?
- Is service active?
- Has finance reconciled the payment?
- Is there an unresolved exception?
That operating state should remain coherent even when M-PESA, MTN MoMo, Airtel Money, OPay, PalmPay, instant transfer or another local route executes the payment.
Plan finance before launch
Do not add reconciliation after the checkout is finished.
Design this chain before going live:
invoice → payment attempt → provider transaction → provider fee or adjustment → reconciliation result → settlement evidence.
If the merchant cannot explain how a KES M-PESA payment, a UGX MoMo payment or a Nigerian transfer becomes a trusted commercial record, the market entry is incomplete.
The expansion checklist
Before adding an African country, wallet or PSP, answer:
- Who is the approved seller and merchant?
- Which regulated provider executes the payment?
- Which rails are actually enabled?
- How does the customer authorize each recurring payment?
- Which recurring billing state remains provider-independent?
- What happens after rejection, expiry or an unresolved result?
- How are duplicate and late-success scenarios handled?
- How does finance reconcile invoice, payment and settlement evidence?
- Who owns each operational exception?
- What evidence will tell you the market is ready to scale?
The operating principle
Multi-country recurring payments in Africa are not a logo-collection exercise.
Kenya, Uganda and Nigeria already demonstrate why.
The business model can remain stable while local payment behavior changes. Preserve the invoice and recurring-revenue state. Model customer authorization honestly. Keep provider capability explicit. Test the uncomfortable paths. Reconcile each local rail back to one commercial record.
RoamerWave's long-term thesis is built around that continuity: operate recurring revenue across African payment environments without rebuilding the billing operation for every PSP, wallet or country.