How does a Mixx by Yas payment work?
Mixx by Yas is a mobile money wallet tied to a Yas phone number. Customers use it to send and receive money, pay bills and government payments, pay merchants and take cash out at agents, called Wakala, through a USSD menu or the Yas app.
An online pay-in is usually a push prompt. At checkout the customer chooses Mixx by Yas and enters their phone number. The merchant’s payment provider sends a USSD push request to that number, and the customer is asked to enter their wallet PIN on their phone to approve. The provider then confirms the result by status query, using the merchant’s order reference. A Tanzanian aggregator documents this flow for Mixx by Yas alongside M-Pesa, Airtel Money and HaloPesa.
Businesses can also be paid to a number. With Lipa Kwa Simu, a merchant receives payments from customers on its merchant number, gets an SMS alert for each one and can schedule free automatic transfers to a bank account daily, weekly or monthly. Larger businesses use Collection Services, where customers pay a Paybill number into a collection wallet, funds are available at once, and the business can connect its own systems and receive end-of-day reports. Mixx by Yas says there is no limit on the amount a collection wallet can receive.
Payouts go through Disbursement Services. A business can pay many recipients at once to mobile networks, bank accounts and billers in Tanzania, schedule payments, require maker-checker approval and run name checks and national ID (NIN) verification on recipients before money is sent.
Why does Mixx by Yas matter for merchants?
Reach. TCRA counted 27.85 million active Mixx by Yas subscriptions in June 2026, a 32.0% share, second only to M-Pesa at 40.6%. A subscription is a SIM card with a mobile money account used at least once in the previous three months. In June 2026 alone, Mixx by Yas carried 228.59 million transactions, against 286.41 million on M-Pesa and 129.14 million on Airtel Money. A Tanzanian checkout without Mixx by Yas leaves out about a third of active wallet users.
Card payments from a wallet. The Mixx Mastercard is a virtual card linked to the wallet, made for online payments wherever Mastercard is accepted. Each purchase is taken from the wallet balance, and purchases in a foreign currency carry a 5% markup on the exchange rate. The Bank of Tanzania lists Mixx by Yas among the providers of virtual cards, which processed 2.25 million TZS transactions worth TZS 181.83 billion across all providers in 2025.
Continuity after the rebrand. Tigo Tanzania, owned by Axian Telecom, was rebranded as Yas in November 2024, and Tigo Pesa became Mixx by Yas. Phone numbers did not change and the wallet kept the same USSD codes, so long-standing Tigo Pesa customers moved across without new accounts.
What can go wrong?
Many failed payments are approvals that never happen. The customer misses the prompt, enters a wrong PIN or does not have enough balance, and the payment stays pending or fails. A status query for every pending request closes the gap when no notification arrives.
Limits apply. Mixx by Yas caps sending and cash-out at TZS 5,000,000 a day and a fully registered account balance at TZS 10,000,000, so a large order may need splitting or a different method.
Names cause confusion. Some customers and older integrations still say Tigo Pesa, so checkout labels should show both names during the transition.
Refunds need care. On Lipa Kwa Simu, no refund is processed without the merchant’s approval, and there is no card-scheme chargeback on a wallet payment, so disputes are settled between the customer, Mixx by Yas and the merchant. A payout or refund that times out should be checked before it is sent again, or the customer may be paid twice.
How would Omno handle Mixx by Yas?
A merchant would show Mixx by Yas in the hosted checkout, where the customer enters a phone number and sees a clear prompt to approve, or offer it on its own checkout through Direct Links. Routing rules would send the request to a provider that holds a Mixx by Yas connection. In the hosted checkout, if that provider is unavailable or rejects the request, the payment would cascade to the next provider in the rule until one accepts. Pending payments would be checked by status query as well as notification, and the final result would reach the merchant by webhook, the source of truth for confirming an order. Payouts could follow PSP eligibility rules and the customer verification level set by the merchant’s own verification provider. The routing-decision log would record which provider handled each step.