A regional product can support M-PESA or Airtel Money in one market and still need a separate commercial and technical setup in the next.
Wallet brand is not a global capability flag.
M-PESA in Kenya is not the same merchant setup as M-PESA in Tanzania
In Kenya, Safaricom exposes Daraja APIs for M-PESA business integrations. In Tanzania, M-PESA merchant services are operated by M-Pesa Limited within the Vodacom Tanzania ecosystem, with its own merchant terms, business numbers and onboarding.
A product that has working Kenya credentials cannot assume those credentials, identifiers or settlement arrangements carry into Tanzania.
Airtel Money is also organized by operating company
Airtel Africa's developer portal now asks developers to select the country operating company before proceeding, and applications are managed per Op-Co.
That is a useful architectural signal: configuration should be country-scoped even when the customer sees the same Airtel Money brand.
What can change by country
- Legal merchant entity or onboarding eligibility.
- Currency.
- Merchant or wallet identifiers.
- API product availability.
- Customer authorization flow.
- Provider/PSP route.
- Settlement account and timing.
- Refund or reversal process.
- Transaction limits and compliance requirements.
Model capability as merchant + country + currency + provider + wallet
Avoid a configuration such as mpesa_enabled = true.
A safer model records the merchant account, market, currency, wallet brand, provider route and exact capability that has been enabled.
Do not let regional expansion fork the billing model
The recurring commercial objects should remain stable: customer, invoice, attempt, payment state, recovery and reconciliation.
Country-specific adapters and merchant configurations should absorb the differences underneath.
Use country-scoped configuration, not brand-scoped configuration
A regional application should be able to answer: which merchant account, currency, operator/PSP route and wallet capability apply in this country? That configuration belongs beside the provider adapter, not inside the commercial invoice.
The same customer-facing label can therefore map to different credentials and settlement relationships by country while the merchant API remains stable.
What to re-test in every market
-
merchant onboarding and production approval;
-
customer authorization flow;
-
callback and status-verification behavior;
-
limits, reversals and refunds;
-
settlement currency and bank-account requirements;
- provider statement fields used by finance.
Regional expansion is therefore partly an integration exercise and partly a merchant-operations exercise. Reusing code does not remove the need to validate the local commercial setup.
Sources
Safaricom Daraja API catalogue (Kenya): https://developer.safaricom.co.ke/apis
Vodacom Tanzania M-PESA merchant service: https://vodacom.co.tz/lipa-kwa-simu
Airtel Africa Developer Portal: https://developers.airtel.africa/
