M-Pesa launched in Kenya in 2007 as a way to send airtime credit between phones and turned into the default consumer payment rail for the country. It is operated by Safaricom, with sister deployments run by Vodacom and other operators in Tanzania, Mozambique, the DRC, Lesotho, Ghana and Egypt. For a trading firm the practical point is simple: in these markets a large share of clients hold a mobile money wallet and no payment card at all, so a checkout built around Visa and Mastercard converts close to nothing.
The two flows a firm actually integrates
Merchant collection runs through either a paybill or a till number. Paybill takes an account reference, which is what a broker wants, because the reference is how the deposit is matched to a client. The client can push money manually from the phone menu, or the firm can trigger an STK push: the platform sends a request, the client's handset displays a prompt, the client enters the mobile money PIN and the transfer completes. STK push is the flow that converts, because the client never leaves the deposit page to go and copy numbers.
Payouts run the other way through a business to customer disbursement. The firm funds a working balance and instructs transfers to individual numbers. This is the part that surprises people coming from card processing: mobile money payouts are usually near instant and the firm's constraint is not the network but keeping the float topped up. Anyone building a withdrawal queue should read that alongside the general comparison of payout rails, because the operational shape is closer to a bank file than to a card refund.
Direct API or aggregator
Safaricom publishes a developer API for paybill, STK push and disbursements. Going direct means a merchant account with the operator, local presence requirements and a separate integration for every country you expand into, because each deployment is a separate operator with its own interface. Aggregators cover several mobile money networks and card rails behind one API and one settlement account, at a cut of each transaction.
For a firm entering one market with real volume, direct is cheaper and gives better control of the reference matching. For a firm serving clients across five African markets, an aggregator is the only sane starting point. This is the same build or buy question that shows up in payment orchestration generally, and the answer changes as volume concentrates.
Mobile money is not a card rail, so it has no chargeback mechanism. A completed transfer is final and reversals are a manual operator process, not a scheme right. That removes a large category of chargeback exposure and replaces it with a different risk: money sent to a wrong number is genuinely hard to recover, so payout confirmation screens matter more than usual.
Limits, tiers and what breaks at scale
Mobile money accounts carry transaction and balance limits set by the operator under central bank rules, and the limits move up as the customer completes higher identity tiers. A client on a basic tier may not be able to fund an account in one transfer, so a deposit page has to handle partial funding gracefully rather than failing the whole attempt. Firms that assumed a single deposit equals a single trade allocation end up rewriting that logic.
Identity is the second constraint. Mobile money registration is tied to a national ID and a SIM registration, which is a genuinely strong signal, but it is the operator's KYC and not yours. A trading firm still runs its own verification levels and still has to check that the payer name on the mobile money account matches the account holder. Third party funding is the single most common abuse pattern on these rails, and the mismatch is easy to detect because the operator returns the registered name on the transaction.
Settlement, currency and the treasury problem
Collections settle in local currency into a local account. A broker quoting accounts in USD then has an FX conversion and a repatriation question on every cycle, and in several African markets there are exchange control rules that govern how and when funds leave. This is the part firms underestimate. The payment integration takes a few weeks. Getting a local banking relationship, an approved conversion route and a predictable schedule to move funds out can take a lot longer, and it belongs in the same planning as banking for trading firms rather than being treated as a payments detail.
Fees are set per transaction band by the operator and published in public tariff tables, and the merchant side is negotiated. The useful comparison is not against card interchange but against what the alternative costs a client: an international wire from these markets is slow and expensive relative to the deposit sizes involved, so mobile money often wins on client experience even where the merchant fee looks high.
Where it fits in a deposit page
Show mobile money as its own option, not buried under an other methods link, and detect the market from the client's country rather than making them hunt. Ask for the phone number, trigger the push, and hold the page in a polling state with a clear timeout, because the client is looking at their handset and not at your browser tab. On failure, say whether the request expired, was cancelled or was declined for insufficient balance, since each has a different next step for the client.
The wider lesson generalises past Kenya. Every region has a rail that beats cards locally: UPI in India, PIX in Brazil, mobile money across East and West Africa. Building the deposit page around one global method and treating the rest as exceptions is the mistake, and firms that fix it usually see the improvement in approval rates before they see it anywhere else. The same reasoning drives the wider case for local payment methods.
"People ask why we bother integrating mobile money when cards exist. In half the markets we work in cards do not exist for the client we are trying to serve. The phone is the account."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- In several African markets mobile money is the primary consumer payment rail, so a card-only deposit page fails most clients before risk or compliance ever sees them.
- Collections use a paybill reference with an STK push prompt on the handset, while payouts run as near instant disbursements that depend on the firm keeping a funded float.
- There is no chargeback mechanism on mobile money, which removes card dispute exposure and makes payout confirmation and number verification the main operational risk.
- The integration is the easy half. Local settlement currency, exchange control rules and a workable banking relationship take longer to arrange than the API work.
Frequently Asked Questions
Can a broker accept M-Pesa deposits without a Kenyan entity?
Direct merchant access from Safaricom involves local requirements, so firms without a local entity generally connect through a licensed aggregator that holds the merchant relationship and settles onward to the firm.
Are M-Pesa deposits reversible?
A completed mobile money transfer is final. There is no card scheme chargeback right, and reversals are a manual operator process, so firms should treat a confirmed deposit as settled rather than provisional.
How does a firm match a mobile money deposit to the right client?
Paybill transactions carry an account reference that the client enters or that an STK push supplies automatically. The transaction record also returns the registered payer name, which is used to check against the account holder.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.