How does an M-PESA payment work?
There are two ways to collect. The first is M-Pesa Express, also called STK Push. The merchant sends a request through Safaricom’s Daraja API with its paybill or till number, the amount, the customer’s phone number, an account reference of up to 12 characters and a callback URL. The customer’s phone shows a prompt with those details filled in. The customer enters their M-PESA PIN, M-PESA debits the wallet and credits the merchant, and the result goes to the callback URL with an M-PESA receipt number.
The second is customer-initiated. With a Paybill, the customer opens the M-PESA app or the *334# menu, enters the business number, an account number and the amount, and confirms with the PIN. A Till, used for Buy Goods, needs only the till number and amount. An optional validation step for paybills lets the merchant accept or reject an incoming payment based on the account, amount or sender.
Payouts use Business to Customer (B2C). The merchant sends a request from a B2C shortcode, or an account that can both receive and disburse, with a unique OriginatorConversationID, the customer’s number and the amount. The result arrives at a result URL. Safaricom lists salary payments, cashback payments and loan disbursements among the B2C use cases. For an online store, the same API sends a refund for a cancelled order or a payout to a marketplace seller straight to the recipient’s wallet.
Why does M-PESA matter for merchants?
Reach. Safaricom reported 40.99 million one-month active M-PESA customers in Kenya for the year to March 2026, up 14.5%, with 46.41 billion transactions worth KES 41.68 trillion and 3.1 million merchants. The Central Bank of Kenya counted 95.31 million registered mobile money accounts across all providers in August 2026.
Fewer errors. Because STK Push fills in the payment details, Safaricom says wrong payments and reversals are significantly reduced. Payouts land in the wallet customers already use, with no bank details to collect.
What can go wrong?
Many failed STK Push payments end without a PIN: the customer cancels, which returns result code 1032, or ignores the prompt. Safaricom also warns that a push fails if a session is already open for that customer, and recommends waiting at least a minute between requests. Results are asynchronous, so a merchant that does not wait for the callback may ship an unpaid order.
Limits stop large payments. Since 2023 they have been KES 250,000 per transaction, KES 500,000 a day and a KES 500,000 balance, with changes approved by the Central Bank of Kenya. A paybill payment with a wrong account number leaves the customer’s wallet but cannot be processed, which validation helps prevent. On payouts, a retry without first checking status by OriginatorConversationID can pay twice. Refunds go back as a reversal or a B2C payout, not a card-style refund.
Is M-PESA available in Tanzania?
Yes. Vodacom Tanzania runs its own M-Pesa service, separate from Safaricom’s in Kenya, and payments are made in Tanzanian shillings (TZS). Vodacom Tanzania reported 14.1 million M-Pesa customers in the year ended 31 March 2026, up 22.6%, and M-Pesa revenue of TZS 734.8 billion. The regulator TCRA counted 35.31 million active M-Pesa subscriptions in June 2026, 40.6% of the market and the largest of six services. Vodacom Tanzania opened its M-Pesa API to developers in 2020 for consumer-to-business, business-to-consumer and business-to-business payments.
Is M-PESA available in Ethiopia?
Yes, but it is still small there. Safaricom Telecommunications Ethiopia runs M-PESA in Ethiopian birr (ETB). In the year to March 2026 Safaricom reported 5.2 million 90-day active M-PESA customers in Ethiopia, more than double a year earlier, and 70,000 one-month active merchants. Ethio telecom’s telebirr is far larger, with 60.6 million registered customers in its 2025/26 financial year, so a merchant selling into Ethiopia should not rely on M-PESA alone.
How would Omno handle M-PESA?
Omno would treat M-PESA as a pay-in and payout method with an asynchronous result. A merchant would show M-PESA in the hosted checkout or offer it through Direct Links on its own checkout, and the request would go to a provider that holds an M-PESA connection for the merchant’s paybill or till. The order would stay pending until the final status arrives by webhook, the source of truth for confirming the order.
Routing rules set by the merchant would choose the provider, and in the hosted checkout, if a provider is unavailable or rejects the request, the payment would move to the next provider in the rule until one accepts. PSP eligibility rules could send payouts only to providers with a B2C shortcode, and the routing-decision log would record which provider handled each payment.