M-Pesa Interoperability in East Africa: What It Means for Payment Operators

M-Pesa launched in Kenya in 2007 as a simple airtime-to-cash transfer product for Safaricom subscribers. Nineteen years later it operates across seven countries — Kenya, Tanzania, Mozambique, DRC, Lesotho, Ethiopia, and South Africa — with 62.3 million active users across the Safaricom Group as of September 2025 (Safaricom H1 FY26 results) and processes more transaction value in Kenya alone than the country’s banking system handles in deposits. The product that started as a closed-loop mobile wallet has become the dominant payment rail for consumer and SME payments across East and Central Africa.

For operators building payment acceptance or disbursement flows in Africa, M-Pesa is unavoidable in the markets where it operates. But M-Pesa is not one product — it is a brand operated by two distinct corporate entities with different technical standards, regulatory relationships, and API access models. Understanding the Safaricom/Vodacom split, the interoperability architecture that has emerged, and how aggregators fit into the picture is prerequisite to building reliable cross-market flows.

The Safaricom/Vodacom Split

M-Pesa’s brand is operated by two distinct corporate entities within the Vodafone Group ecosystem. Safaricom (Nairobi-listed; Vodacom holds ~35% and Vodafone Group holds ~14% directly) operates M-Pesa in Kenya and Ethiopia. Vodacom (JSE/Johannesburg-listed; 60% owned by Vodafone Group) operates M-Pesa in Tanzania, Mozambique, DRC, Lesotho, and South Africa. In practice, M-Pesa operates as two largely separate products:

Safaricom-operated markets: Kenya and Ethiopia. Safaricom holds a dominant position in Kenya — reaching 40 million monthly active M-Pesa customers in March 2026, up from 34 million in 2024 (Safaricom, March 2026), in a country of approximately 55 million people. Safaricom’s M-Pesa is the most technically advanced version: it includes M-Pesa API (the Daraja API, documented and publicly accessible), M-Pesa Business API for merchant payments, M-Pesa Global for international remittances, and M-Shwari (a savings and loan product integrated into the wallet). Kenya’s M-Pesa is often used as the reference implementation when people discuss “M-Pesa.”

Vodacom-operated markets: Tanzania, Mozambique, DRC, Lesotho, and South Africa (where M-Pesa relaunched in 2022 after a first attempt failed). Vodacom’s M-Pesa implementations are less feature-rich than Safaricom’s and have historically had more limited API access. Tanzania M-Pesa is the most significant Vodacom market by volume and has been the primary focus of Vodacom’s interoperability initiatives.

Why this matters for operators: A merchant integration built against Safaricom’s Daraja API in Kenya cannot be directly reused in Tanzania’s Vodacom M-Pesa. API endpoints, authentication methods, transaction initiation flows, and callback formats differ. Operators building multi-country coverage cannot treat M-Pesa as a single integration target.

The Interoperability Architecture

Tanzania became the proving ground for mobile money interoperability in Africa. The Bank of Tanzania (BOT) mandated interoperability between mobile money operators in 2014 — requiring M-Pesa (Vodacom), Airtel Money, and Tigo Pesa to allow cross-operator person-to-person transfers. Tanzania’s National Interoperability Framework enabled users to send money to any mobile number regardless of which operator held the recipient’s wallet.

The interoperability model in Tanzania uses a central switch mandated by the Bank of Tanzania — effectively a hub that routes transfers between mobile money operators’ platforms. When a Vodacom M-Pesa user sends to an Airtel Money user, the transaction routes through this interoperability layer, with net settlement between operators on a T+1 basis.

Kenya’s interoperability came later. The Central Bank of Kenya (CBK) mandated mobile money interoperability in 2018, and Safaricom implemented cross-operator transfers from M-Pesa to Airtel Money and Telkom Kenya wallets. However, the Kenyan interoperability implementation has faced adoption challenges — M-Pesa’s overwhelming market dominance (95%+ of mobile money transactions in Kenya) means most transactions are internal M-Pesa-to-M-Pesa.

The Africa Interop Layer: In 2022, Safaricom and Vodacom announced a joint initiative to create technical interoperability between their respective M-Pesa platforms across country borders — allowing, in principle, an M-Pesa user in Kenya to send to an M-Pesa user in Tanzania via a cross-border interoperability layer. Implementation progress has been incremental. As of 2025, cross-border M-Pesa transfers remain primarily handled through international remittance corridors (M-Pesa Global) rather than direct wallet-to-wallet cross-border transfers.

GSMA Mobile Money Interoperability Standards: The GSMA’s Mobile Money API standards and interoperability frameworks have provided the technical vocabulary for African mobile money interoperability. The GSMA’s Harmonized Industry Standard (HIS) for mobile money APIs is designed to reduce the per-country integration cost by standardizing API formats across operators. Adoption has been uneven — major operators have largely maintained proprietary APIs — but the GSMA standards are the foundation for aggregator abstraction layers.

API Access Models

For operators wanting direct M-Pesa integration (as opposed to working through an aggregator):

Kenya (Safaricom Daraja API): Safaricom’s Daraja API (daraja.safaricom.co.ke) is the most developer-friendly M-Pesa integration path. It supports:

• STK Push (Lipa na M-Pesa): Merchant-initiated payment request that sends a prompt to the customer’s phone — the primary in-app and online payment flow
• C2B (Customer to Business): Customer-initiated paybill and buy goods payments
• B2C (Business to Customer): Payouts from business wallet to customer M-Pesa accounts — used for disbursements, insurance claims, marketplace payouts
• B2B: Business-to-business M-Pesa transfers
• Account Balance Query and Transaction Status Query

Daraja API access requires a Safaricom developer account, an M-Pesa business shortcode (paybill number), and KYC documentation for the business. The sandbox environment is publicly accessible; production access requires Safaricom approval. API rate limits and transaction limits apply — operators with high volume should negotiate volume limits directly with Safaricom.

Tanzania (Vodacom M-Pesa API): Vodacom Tanzania’s API access is available but less standardized than Daraja. Third-party access typically requires working through a licensed Payment Service Provider (PSP) in Tanzania rather than direct API access to Vodacom’s systems. The Tanzanian regulatory environment (BOT licensing for payment services) shapes the access model.

DRC and other Vodacom markets: API access in DRC and Mozambique is even more restricted, typically requiring either an aggregator or a direct commercial agreement with Vodacom in each country.

Aggregator Access: Flutterwave and Cellulant

For most operators building multi-country Africa coverage, the practical access path is through a regional payment aggregator that has pre-negotiated access to M-Pesa (both Safaricom and Vodacom) and other local mobile money operators.

Flutterwave (Nigerian-founded, operating across 34 African countries as of 2025, per Flutterwave H1 2025 Report) provides unified API access to M-Pesa in Kenya and Tanzania, plus Airtel Money, MTN Mobile Money, Vodacom Money, and other operators across West and East Africa. Flutterwave’s API abstracts the per-operator differences — a single integration provides mobile money collection and payouts across markets. Settlement can be in local currency or USD. Flutterwave holds payment licenses in Nigeria, Kenya, Ghana, Tanzania, Rwanda, Zambia, and other markets.

Cellulant (Kenyan-founded, operating in 18 African markets) specializes in the African market with particularly deep relationships with local mobile operators, including direct Safaricom and Vodacom integrations. Cellulant’s Tingg platform provides unified collection and disbursement across mobile money, bank transfer, and card payment methods. Cellulant is often the access path for enterprise operators (banks, multinationals) that require SLA-backed integrations with contractual guarantees.

Other aggregators with M-Pesa coverage: Pesapal (East Africa focus), Peach Payments (East/Southern Africa), and DPO Group (acquired by Network International) provide alternative access paths.

Aggregator economics: Typical aggregator MDR for M-Pesa transactions is 1.5–3.5% depending on market, transaction type, and volume. Direct Safaricom Daraja integration for merchant payments costs approximately 1% MDR for STK Push — cheaper than most aggregators but with all the integration and compliance overhead of a direct relationship.

Building Payment Flows Across the M-Pesa Footprint

For operators building acceptance flows that work across Kenya, Tanzania, and potentially DRC:

Collection (accepting payments):

• Kenya: Safaricom Daraja STK Push is the standard for online/in-app payments. Customer receives a prompt on their phone, enters M-Pesa PIN, payment confirmed. Works for e-commerce, subscription initiation, marketplace purchases.
• Tanzania: M-Pesa USSD payment or aggregator-mediated collection. Tanzania has lower smartphone penetration than Kenya, making USSD-based flows more important.
• Diaspora payments: M-Pesa Global allows international remittances from the UK, EU, and other markets to M-Pesa wallets in Kenya — relevant for operators in remittance corridors.

Disbursement (paying out to recipients):

• Daraja B2C API in Kenya handles payouts to individual M-Pesa numbers — standard for gig platforms, insurance payouts, marketplace seller settlements.
• Transaction limits apply: B2C per-transaction limit is KES 150,000 (~$1,160 USD). For larger disbursements, B2B channel or multiple transactions.
• Tanzania disbursements via aggregator or direct Vodacom API relationship.

Reconciliation considerations:

• M-Pesa transactions include a unique transaction ID (e.g., “QHK22TBMX8”) that serves as the reconciliation reference.
• Callback delays: Safaricom’s Daraja callbacks are generally reliable but can have seconds-to-minutes delays. Build idempotent callback handlers that correctly handle duplicate callbacks for the same transaction.
• Failed transactions: M-Pesa STK Push timeouts (when the customer doesn’t respond within the prompt window) require explicit status polling — don’t rely on callback alone for final state.

What This Means for Operators

M-Pesa’s dominance in Kenya is near-total — any operator targeting Kenyan consumers or SMEs without M-Pesa acceptance is excluding the primary payment method of the market. The Daraja API makes Kenya integration relatively accessible.

The cross-market picture is more complicated. Safaricom-operated Kenya and Vodacom-operated Tanzania are effectively different products despite sharing a brand. There is no turnkey multi-country M-Pesa integration — operators need either country-by-country direct API relationships or an aggregator that has done that work.

For operators entering East Africa in 2026, the recommended starting point is Kenya via Daraja API (or an aggregator if Kenya-only is insufficient to justify direct integration), with Tanzania covered via an aggregator like Flutterwave or Cellulant. The Africa interoperability layer between Safaricom and Vodacom markets is developing but not yet reliable enough to replace per-country integration for production payment flows.

The medium-term infrastructure development to watch: the potential expansion of Kenya’s real-time interbank rails (which M-Pesa increasingly connects to, allowing M-Pesa-to-bank and bank-to-M-Pesa flows) and whether the GSMA’s API standardization efforts accelerate to reduce per-country integration cost. For now, East Africa payments remains a market where infrastructure investment is proportional to the revenue opportunity, country by country.