Tanzania's mobile money interoperability means customers can send money between Vodacom M-Pesa, Tigo Pesa, and Airtel Money wallets. For developers, this is a user-level feature, not an API-level feature. Your payment integration still needs to accept payments from each provider separately (or through an aggregator that handles all three). Interoperability does not mean you can integrate one provider and accept payments from all three. It means the customer ecosystem is fluid, which increases the importance of supporting all three rails. Customers may fund their Tigo Pesa wallet from M-Pesa, but when they pay your business, they pay from whichever wallet they choose.
In 2014, Tanzania became the first country in Africa to achieve full mobile money interoperability. This means a Vodacom M-Pesa user can send money directly to a Tigo Pesa or Airtel Money user, and vice versa. The transfer happens across provider networks, just like how a Vodacom phone can call a Tigo phone.
Before interoperability, mobile money in Tanzania was siloed. An M-Pesa user could only send money to another M-Pesa user. Sending money to someone on Tigo Pesa meant withdrawing cash from an M-Pesa agent and depositing it at a Tigo Pesa agent. This was slow, expensive, and inconvenient.
The Bank of Tanzania pushed for interoperability, and the three telcos agreed to connect their systems. A technical switch facilitates the cross-network transactions. The result: Tanzania's mobile money ecosystem functions as a single, interconnected network at the user level.
This is a competitive advantage for Tanzania compared to most other African markets. In Kenya, mobile money is overwhelmingly M-Pesa, so interoperability is less relevant. In Uganda, MTN MoMo and Airtel Money have achieved some level of interoperability, but Tanzania got there first and most completely.
Here is the critical distinction: interoperability is a feature of the customer network, not a feature of the developer API.
What interoperability gives you as a developer:
What interoperability does NOT give you:
The practical implication: interoperability makes it less catastrophic to miss one provider (customers can work around it), but it does not make it okay. Adding friction to the payment process loses transactions. Support all three rails.
Get weekly developer tips
Join 25,000+ developers. Practical guides, job tips, and new content — straight to your inbox.
No spam. Unsubscribe anytime.
Tanzania's interoperability creates some interesting design considerations for payment systems:
A customer might pay with M-Pesa today and Tigo Pesa tomorrow. Your system should associate a customer with a customer ID, not a specific mobile money provider. Store the provider used for each transaction, but do not assume a customer always uses the same one.
If a customer pays with M-Pesa and later requests a refund, send the refund to their M-Pesa wallet (the same number that paid). Do not assume they want the refund on a different provider just because interoperability makes transfers possible. Always refund to the original payment method unless the customer explicitly requests otherwise.
Your reporting should break down transactions by provider. This data tells you which providers your customers prefer, which helps you prioritize if you ever need to troubleshoot provider-specific issues. It also helps with reconciliation, since each provider (or aggregator) has its own settlement schedule and fee structure.
With interoperability, the line between providers blurs for customers. In the future, number portability could mean a phone number's prefix no longer reliably indicates the provider. Design your systems so that provider detection is a helper, not a hard dependency. If auto-detection fails, let the customer choose their provider manually.
Tanzania's interoperability is not replicated everywhere. Here is how the major East African markets compare:
For developers building products across East Africa, Tanzania's interoperability means you face a genuinely multi-provider market. You cannot rely on one provider dominating. Your payment system must be designed for multiple rails from the start. This is harder than Kenya's single-provider reality, but it produces better-architected code. A payment system built for Tanzania's three rails can easily handle Kenya's single rail. The reverse is not always true.
If you are building a payment system for Tanzania:
The mobile money integration pattern is the same regardless of interoperability. McTaba's M-Pesa Integration for Developers course (KES 9,999 / ~TZS 200,000) teaches the architecture. Tanzania's interoperability adds multi-provider design considerations on top of that foundation.
Create a free McTaba Academy account. Access starter lessons, join the community, and explore at your own pace.
Create Free Account