East Africa is not one mobile-money integration
A regional merchant can sell the same subscription or membership in several East African markets while facing different currencies, wallet brands, operators and merchant-onboarding arrangements.
The reusable asset should be the billing model, not one provider integration.
Country snapshot
| Market | Currency | Prominent mobile-money wallets / merchant rails | What to verify |
|---|---|---|---|
| Kenya | KES | M-PESA; Airtel Money | Merchant approval, provider route, PayBill/Till or wallet collection product |
| Tanzania | TZS | Vodacom M-Pesa; Airtel Money | Country-specific merchant onboarding, provider semantics, settlement |
| Uganda | UGX | MTN MoMo; Airtel Money | Merchant KYC, merchant code/collection product, provider callbacks |
| Rwanda | RWF | MTN MoMo; Airtel Money | Merchant onboarding, payment method availability, settlement |
The table lists prominent local wallet examples, not an exhaustive provider catalogue or a guarantee that any particular merchant is approved for each rail.
What should stay the same across countries
- Customer/account identity.
- Plan or recurring obligation.
- Invoice and billing period.
- Payment-attempt history.
- Normalized payment states.
- Recovery policy framework.
- Reconciliation model.
What should be localized
- Currency and displayed price.
- Enabled wallets and payment methods.
- Provider route and merchant account.
- Customer authorization instructions.
- Settlement arrangement.
- Refund/reversal process.
The same wallet brand can still be a different integration
M-PESA in Kenya and M-Pesa in Tanzania do not mean the merchant can reuse one production merchant account or assume identical provider semantics. Country support, onboarding and settlement remain market-specific.
That is why capability should be scoped as market + currency + wallet + provider + merchant account, not “M-PESA enabled = true” for an entire company.
Absorb expansion into the operating model
A regional business should be able to add a new country by configuring a local route beneath the existing invoice and recovery model. The expansion should not require a second subscription product that happens to use different payment code.
Measure each market separately
- Paid-by-due-date rate.
- First-attempt completion.
- Recovery rate.
- Unknown-state rate.
- Payment-method mix.
- Manual reconciliation effort.
One regional architecture should not hide meaningful country differences.
A regional operating model still needs local ownership
Centralizing invoice and payment state does not mean every country should be operated identically. Assign an owner for merchant onboarding, settlement questions and provider incidents in each market so local exceptions do not disappear inside a regional dashboard.
The value of a shared billing model is that those local teams can work from the same commercial concepts while the payment routes remain country-specific.
Sources
- Safaricom Daraja (Kenya): https://developer.safaricom.co.ke/apis
- Airtel Africa Developer Portal, including Kenya, Tanzania, Uganda and Rwanda: https://developers.airtel.africa/
- MTN Uganda MoMo merchant services: https://www.mtn.co.ug/momo/merchant/
- Airtel Uganda merchant-payment description: https://www.airtel.co.ug/ug/about/driving_financial_inclusion_in_uganda
- Vodacom Tanzania M-Pesa merchant terms: https://myvodacom.vodacom.co.tz/assets/myvodacom/downloadFile/Schedule%205-M-Pesa%20Merchant%20Terms%20and%20Conditions-English%20Nov%202021-website.pdf
- Airtel Tanzania enterprise payment services: https://enterprise.airtel.co.tz/
- Airtel Rwanda: https://www.airtel.co.rw/
- MTN Rwanda MoMo / merchant payments: https://www.mtn.co.rw/momo/
