Mobile Money Interoperability in Tanzania: What Developers Need to Know

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:

• Customers can fund any wallet from any other wallet. A customer with money in M-Pesa can transfer to their Tigo Pesa wallet and then pay your Tigo Pesa integration. This means you do not need to worry about customers being "locked in" to one provider.
• The total addressable market is the entire mobile money user base, not just subscribers of the providers you support. Even if you only integrate M-Pesa and Tigo Pesa, an Airtel Money user could transfer money to their M-Pesa wallet and pay you. (But this adds friction, and you lose the transaction if they decide it is not worth the effort.)

What interoperability does NOT give you:

• A single API endpoint that accepts payments from all three providers. You still need separate integrations (or an aggregator that handles all three).
• Automatic cross-provider payment acceptance. If your integration is with Vodacom M-Pesa only, a Tigo Pesa user cannot pay you directly from their Tigo Pesa wallet. They would have to transfer to M-Pesa first.
• Simplified development. Your code still needs to handle whichever providers you choose to support.

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.

Tanzania's interoperability creates some interesting design considerations for payment systems:

Wallet-agnostic customer records

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.

Refund routing

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.

Transaction reporting

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.

Number portability awareness

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:

• Tanzania: Full interoperability since 2014. Three providers (M-Pesa, Tigo Pesa, Airtel Money) connected through a central switch. Customers transfer freely between all three.
• Kenya: M-Pesa dominates with over 90% market share. Some interoperability exists (M-Pesa to Airtel Money transfers are possible), but it is less relevant because the market is effectively single-provider for most purposes.
• Uganda: MTN MoMo and Airtel Money have some interoperability. The two-provider market is more balanced than Kenya's but less evenly split than Tanzania's three-provider market.
• Rwanda: MTN MoMo dominates. Airtel Money and Tigo (now merged into Airtel) have smaller shares. Interoperability exists but the market dynamics are different from Tanzania's.

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:

1. Support all three providers from launch. Use an aggregator (Selcom, Azampay, ClickPesa, or Pesapal) to handle all three through one API. This is the simplest path and ensures you do not lose customers from any provider.
2. Design your data model for multi-provider. Store the provider alongside every transaction. Do not assume customers use one provider consistently. Allow the same customer to pay with different providers on different transactions.
3. Build a provider abstraction layer. Whether you use an aggregator or direct integration, abstract the provider-specific details behind a common interface. This makes adding or changing providers a configuration change, not a rewrite.
4. Track provider distribution. Know what percentage of your transactions come from M-Pesa, Tigo Pesa, and Airtel Money. This data informs debugging priority, fee optimization, and aggregator negotiations.
5. Test cross-provider edge cases. What happens if a customer with multiple wallets pays from one and requests a refund to another? What if auto-detection picks the wrong provider? Build and test these scenarios.

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.