How to Accept Mobile Money Payments on a Website in Tanzania (All 3 Rails)

In Kenya, you can build a payment checkout that supports only M-Pesa and cover over 90% of the mobile money market. In Tanzania, you cannot. The market is split across Vodacom M-Pesa, Tigo Pesa, and Airtel Money. No single provider dominates the way Safaricom does in Kenya.

A checkout that only supports Vodacom M-Pesa excludes millions of Tigo Pesa and Airtel Money users. These users are not going to transfer money to M-Pesa just to pay you. They will go to a competitor that accepts their provider, or they will not buy at all.

Building for all three rails sounds like three times the work, but it is not. The architecture is the same for all three: REST API, request-callback pattern, webhook handling. The difference is credentials, endpoints, and payload formats. And if you use an aggregator, even those differences disappear behind a single API.

Tanzania was the first African country to achieve full mobile money interoperability, back in 2014. Customers can send money between providers. But for merchant payments, the customer pays from their own wallet. Your system needs to handle payments from all three.

A mobile money checkout on a Tanzanian website looks different from a card payment checkout. There are no card numbers, no expiry dates, no billing addresses. The flow is:

1. Customer enters their phone number. Your checkout page has a single input field for the phone number. Optionally, you can detect the provider from the number prefix (Vodacom, Tigo, or Airtel) and show the relevant logo.
2. You send a payment request. Your backend sends the phone number, amount (in TZS), and a transaction reference to your payment provider (aggregator or direct telco API).
3. The customer gets a prompt on their phone. A USSD or STK push notification appears on the customer's phone asking them to enter their PIN to confirm the payment.
4. Your server receives a callback. Once the customer confirms (or the request times out, or they decline), the payment provider sends a POST request to your callback URL with the result.
5. You update the order status. Your callback handler parses the result, updates the transaction in your database, and triggers whatever comes next: send a confirmation email, activate a subscription, fulfill an order.
6. You show the result to the customer. While waiting for the callback, your frontend polls your backend for the transaction status (or uses WebSockets). Once the callback arrives, you show the customer a success or failure message.

The time between step 2 and step 4 is typically 10 to 60 seconds, depending on how quickly the customer responds to the prompt. Your frontend needs to handle this waiting state gracefully with a clear loading indicator and a message like "Please check your phone and enter your M-Pesa PIN."

For most Tanzanian websites, a payment aggregator is the right choice. Here is why:

• One API, three providers. You integrate once. The aggregator detects which provider the phone number belongs to and routes the payment request accordingly.
• One callback format. Instead of handling three different callback formats, you get a single, normalized callback from the aggregator.
• Faster time to production. Aggregators already have production access to all three telcos. You do not need to go through three separate approval processes.
• Card payments included. Some aggregators (Pesapal, Selcom) also support Visa and Mastercard, giving you a fourth payment option through the same API.

The main aggregator options for Tanzania:

• Selcom: The largest Tanzanian aggregator. Supports all three rails plus cards. Strong documentation and local support. Used by many major Tanzanian businesses.
• Azampay: A newer Tanzanian aggregator with a modern, developer-friendly API. Growing fast.
• ClickPesa: Tanzania-based. Supports mobile money and bank payments. Good for fintech use cases.
• Pesapal: East Africa-wide. Supports mobile money and cards across Kenya, Tanzania, and Uganda. Familiar to developers who have worked in other East African markets.

We compare these in detail in our aggregator comparison article.

Your checkout page needs to be simple. Mobile money users are accustomed to quick transactions. A checkout with too many fields or confusing steps will lose customers.

The minimum checkout page includes:

• An order summary. What they are buying, the amount in TZS. Clear and visible.
• A phone number input. Pre-formatted for Tanzanian numbers. Validate that it starts with a valid prefix (07xx, 06xx, etc.) and strip the leading zero when sending to the API (use the 255 prefix).
• A "Pay" button. Triggers the payment request.
• A waiting state. After they click pay, show a clear message: "A payment prompt has been sent to your phone. Enter your PIN to confirm." Include a spinner or progress indicator.
• A result screen. Success or failure, clearly communicated. On success, show a transaction reference and next steps. On failure, show the reason (if available) and a retry option.

Optional but helpful:

• Provider detection. Detect whether the number is Vodacom, Tigo, or Airtel from the prefix and show the relevant logo. This reassures the customer that you support their provider.
• Provider selection. If auto-detection is unreliable, let the customer choose their provider. Three buttons with logos, then a phone number field.
• Timeout handling. If the customer does not respond within 60 to 90 seconds, show a "Payment timed out" message with an option to retry.

Keep the page mobile-friendly. Most Tanzanian internet users access the web on smartphones. A checkout that does not work well on a 5-inch screen will lose transactions.

Your backend handles the payment logic. The key components:

• Payment initiation endpoint. Your frontend sends the phone number and amount to your backend. Your backend forwards this to the aggregator (or telco API), records the pending transaction in your database, and returns a transaction ID to the frontend.
• Callback endpoint. A publicly accessible POST endpoint where the aggregator sends the payment result. This endpoint must validate the callback (check for expected fields, verify the source if your aggregator supports signature verification), update the transaction status in your database, and return a response to the aggregator.
• Status check endpoint. Your frontend needs to know when the payment completes. Either poll this endpoint at intervals (every 2 to 3 seconds) or use WebSockets. This endpoint returns the current transaction status from your database.
• Transaction database table. Store every transaction with: ID, phone number, amount, provider, status (pending, success, failed, timeout), aggregator reference, raw callback payload, timestamps.

Critical backend rules:

• Idempotency. Callbacks can arrive more than once. Your handler must be idempotent: processing the same callback twice should not charge the customer twice or create duplicate records.
• Do not trust the frontend. The payment amount must be set by your backend based on the order, not sent from the frontend. A customer could modify the amount in the browser otherwise.
• Log everything. Store the raw callback payload. When transactions fail and you need to debug, the raw data from the aggregator is the only reliable source of truth.

McTaba's M-Pesa Integration for Developers course (KES 9,999 / ~TZS 200,000) teaches exactly this checkout architecture. You build a working payment integration with a checkout page, backend payment handling, callback processing, and status tracking.

The course uses Safaricom Daraja because it has the most accessible sandbox. But the checkout flow you build, the callback handling, the polling mechanism, the idempotency patterns, they all apply directly to a Tanzanian multi-provider checkout. The only changes are the aggregator API (Selcom or Azampay instead of Daraja) and the currency (TZS instead of KES).

Once you have the pattern working, adapting it to a Tanzanian aggregator takes one to two days of development work. The architecture does not change. The API calls change.

For the full-stack skills to build the website around the checkout (React frontend, Node.js backend, database, deployment), the Full-Stack Software + AI Engineering course (KES 120,000 / ~TZS 2,400,000) covers the entire stack. Deployment is covered in the Deployment: Going Live course (KES 4,999 / ~TZS 100,000).