Tigo Pesa API Integration in Tanzania: Developer Guide

Tanzania has three mobile money providers: Vodacom M-Pesa, Tigo Pesa, and Airtel Money. Tigo Pesa is operated by MIC Tanzania (the Tigo brand). It is the second-largest mobile money platform in the country and has a significant user base, especially outside Dar es Salaam.

For developers, ignoring Tigo Pesa means turning away a large chunk of potential customers. Unlike Kenya, where M-Pesa dominates with over 90% market share, Tanzania's mobile money market is split across three providers. A checkout page that only supports one rail loses transactions from the other two.

The good news: Tigo Pesa's API follows the same fundamental pattern as Vodacom M-Pesa and Airtel Money. If you have integrated one, the others are a matter of adjusting endpoints, authentication, and payload formats. The architecture is identical.

Since 2014, Tanzania has had full mobile money interoperability. Customers can send money from Tigo Pesa to M-Pesa or Airtel Money and back. But interoperability is a user feature, not a developer feature. Your code still needs to handle Tigo Pesa transactions through either the Tigo API or an aggregator that routes to it.

The Tigo Pesa API provides endpoints for the standard mobile money operations:

• C2B (Customer to Business): Collecting payments from Tigo Pesa users. You send a request with the customer's phone number and amount. Tigo sends a USSD push to the customer's phone. They enter their PIN. You receive a callback with the result.
• B2C (Business to Customer): Sending money to Tigo Pesa users. Used for refunds, disbursements, and payouts.
• B2B (Business to Business): Transfers between business accounts.

The authentication mechanism involves API credentials provided during the registration process. Like Vodacom's Open API, the exact implementation has its own quirks, but the general flow is: authenticate, get a token or session, make requests with that token, handle callbacks.

The request-callback pattern deserves emphasis because it is the single most important concept in East African payment integration:

1. Your server sends a payment request to the Tigo API.
2. Tigo pushes a prompt to the customer's phone.
3. The customer enters their PIN (or declines).
4. Tigo sends a POST request to your callback URL with the transaction result.
5. Your server processes the callback, updates the order/transaction status, and returns a response.

This is the same flow for Vodacom M-Pesa, Safaricom Daraja, Airtel Money, and MTN MoMo. Learn it once, use it everywhere.

Here is the part that most guides skip: getting direct Tigo Pesa API access is difficult.

Unlike Safaricom's Daraja, which lets any developer sign up and start testing in minutes, Tigo's developer onboarding process involves business verification, commercial agreements, and approval timelines that can stretch to weeks or months. For a solo developer or an early-stage startup, this process can stall a project indefinitely.

This is not unique to Tigo. All three Tanzanian telcos have more restrictive API access than Kenya's Safaricom. It is a market-wide reality.

The practical workaround is aggregators. Services like Selcom, Azampay, ClickPesa, and Pesapal have already established direct connections with all three telcos. They expose a single API that routes to Tigo Pesa, M-Pesa, and Airtel Money. You integrate once, and the aggregator handles the telco-specific details.

For a detailed comparison of the aggregator options, see our Selcom vs ClickPesa vs Pesapal vs Direct API article.

The decision is straightforward: if you have existing business relationships with Tigo or you are processing high enough volume to justify the setup effort, pursue direct integration. For everyone else, use an aggregator and focus your development time on the product, not on telco paperwork.

Since you will likely need to support Tigo Pesa alongside M-Pesa and Airtel Money, your payment layer should be designed for abstraction from the start.

The pattern that works:

• A payment service interface. Define a common interface with methods like initiatePayment(), handleCallback(), and checkStatus(). Each provider (or aggregator) implements this interface.
• Provider-specific adapters. Each adapter handles the authentication, endpoint URLs, and payload formatting for one provider. The rest of your application talks to the interface, not the adapter.
• A callback router. If you are using direct integration with multiple providers, each one sends callbacks to a different endpoint or with different formats. A central callback router normalizes the data before passing it to your business logic.

If you are using an aggregator, they handle the multi-provider abstraction for you. Your code talks to one API and receives normalized callbacks. This is the main reason aggregators save development time.

Whether you go direct or through an aggregator, store the provider name (tigo_pesa, mpesa, airtel_money) and the raw callback payload alongside each transaction in your database. When something goes wrong (and it will), having the raw data makes debugging possible.

There is no widely available Tigo Pesa integration course as of mid-2026. The documentation is limited, developer community resources are sparse, and most Tanzanian developers learn through aggregator documentation rather than direct Tigo API docs.

Here is the practical learning path:

1. Learn the pattern on a well-documented API. Safaricom's Daraja has the best developer documentation, the most active community, and an instant sandbox. McTaba's M-Pesa Integration for Developers course (KES 9,999 / ~TZS 200,000) teaches the full request-callback pattern, webhook handling, and error management using Daraja.
2. Apply the pattern through an aggregator. Sign up for Selcom or Azampay's sandbox. Integrate their API to handle Tigo Pesa payments. The request-callback architecture you learned with Daraja applies directly.
3. Scale to direct integration if needed. Once your volume justifies it, pursue direct Tigo API access. By this point, you understand the architecture. The adaptation is credentials, endpoints, and payload formats.

This path is honest about a market reality: the best sandbox experience and learning materials are on Daraja. Using that as your training ground and then adapting to Tanzanian providers is more productive than struggling with limited documentation from the start.