M-PESA Merchant Collection: Integrating and Reconciling Mobile Money
Many teams meet an African market for the first time and treat mobile money as another form of card, then apply the card acquiring playbook they already know. That assumption almost always breaks in three places: collection confirmation, refunds and reconciliation. The reason is simple. In mobile money the user funds do not sit in a bank account but in an operator account, and the flow passes through neither a card scheme nor an acquiring bank. You are not facing a card rail but a completely separate money system.
This guide follows M-PESA as its main thread and sets out the integration mechanics and reconciliation points of mobile money. M-PESA is a mobile money service launched and led by Safaricom in Kenya, later extended to several African markets through different operators, with users depositing, withdrawing and transferring through a phone-number account. For the wider African structure start with the Africa Payment Guide.
1. Positioning: An Operator-Led Mobile Money System, Not Card Acquiring
1.1 The Money Sits in an Operator Account, Not a Bank Account
The core of mobile money is account ownership. User funds are held in a phone-number account inside the operator system, and deposits, withdrawals, transfers and payments all happen there. The user does not need a bank card, and often does not need a bank account at all, because in many scenarios the phone number is the account. This is a parallel infrastructure to cards, and neither automatically interoperates with the other.
Only by grasping this can you grasp what integration really means. A merchant integrating M-PESA is not integrating an acquiring bank or a card scheme but an operator collection interface. That means three things must all be solved inside the operator system: how collection is confirmed, how a refund is initiated, and what evidence reconciliation rests on. Any attempt to force the card acquiring flow onto it will stall at one of those points.
For cross-border teams the test should change accordingly. Do not ask which card types it supports. Ask: what identifier does the buyer pay with, how do I confirm the money actually arrived, which path does a refund take, and what evidence defines the reconciliation.
1.2 What It Is Not
First, it is not a card rail. Mobile money does not pass through a card scheme, so the whole card vocabulary of authorisation, capture and chargeback does not map onto it.
Second, it is not a pan-African general solution. M-PESA is run by different operators in different countries, and integration methods, short codes and rules are not unified, so cross-border operations must be assessed country by country.
Third, it is not a single interoperable wallet across operators. Mobile money from different operators usually does not move directly between them, and cross-operator transfers often pass through extra steps or agent networks.
Fourth, it cannot replace your repatriation design. Collection lands in an operator account or merchant wallet, and how it is settled out is a separate mechanism.
2. Onboarding and Entity Requirements
2.1 Merchant Short Code, Entity Qualification and Business Explainability
Mobile money onboarding differs from card acquiring, and the central action is obtaining a merchant collection identifier. The typical path is applying for a merchant short code, meaning a collection number allocated to your business inside the operator system that users can recognise, with buyers entering the short code on the phone and confirming the amount to pay. Short codes come in a bill-style collection type and a store-style collection type, and the two differ clearly in usage scenario, reconciliation fields and buyer expectation.
Entity qualification and business explainability still matter when applying for a short code. The reviewer has to judge what you sell, to whom, and whether restricted categories are involved. Compared with card acquiring, the mobile money system is equally sensitive to the purpose of funds and the reality of the business, only with different evidence. Organising material as what you sell, how it is delivered and how it is refunded remains an effective approach.
2.2 Settlement, Currency and Repatriation
This is the most underestimated section. Collecting successfully and receiving funds are two different things. After a buyer confirms on the phone, the money usually lands first in a merchant account or wallet inside the operator system, and only then is settled to your bank account or another designated account according to the agreement. The currency, cycle and evidence in that process must all be clarified before integration.
For cross-border teams there is another layer of constraint: foreign exchange and cross-border transfer. How local currency settlement is converted, how it is transferred out and what supporting documents are required usually live not in product documentation but in the contract and in commitments from the account manager, and they have to be put in writing. For multi-currency and multi-account design see the Multi-Currency Payment Account Guide.
3. Integration Options and Account Structure
3.1 Merchant Short Code, Paybill and Till Number Plus Interface Integration
Mobile money collection usually has two routes. One is a bill-style merchant number, where the user enters the merchant number plus an account reference or amount, suitable for subscriptions, bills and online orders. The other is a store-style number, where the user simply enters an amount, suitable for in-person scenarios. The user experience and reconciliation fields differ clearly between the two, and online business usually needs the order-level information the former provides.
The other route is interface integration. The merchant initiates a collection request through the operator interface, the user confirms on the phone, and the result comes back as an asynchronous notification. This route yields structured order data that suits reconciliation and automation, but it needs engineering investment and a solid handling of notification retries, ordering and loss.
Which route to take depends on stage and volume. At low volume a short code plus manual checks can get the business running. Once order volume rises and reconciliation becomes the bottleneck, the automation gain from interface integration quickly exceeds the integration cost.
3.2 Asynchronous Notification, Active Polling and Idempotency
Mobile money results are almost always asynchronous. The user confirms on the phone, the operator processes it and returns the result by notification, and that process has latency that can extend further for network or system reasons. So the server has to get three things right: notification handling, active polling and idempotency.
Notification handling must tolerate duplicates and out-of-order arrival, and must not assume delivery. Active polling is essential: query the final state from the operator side using the order or transaction identifier to pull hanging orders out of limbo. Idempotency means a duplicate creation request must not produce two collections, and order IDs must be duplicate-proof on the creation, notification and query paths. For the wider method see the Payment Reconciliation and Bill Operations Guide.
4. Core Capabilities and Market Coverage
4.1 Difference Dimensions Between Mobile Money and Cards
The most effective way to understand mobile money is to compare it with cards dimension by dimension. The difference is not in the rate level but in where the money sits, how it is confirmed, how it is refunded and what evidence backs reconciliation.
| Dimension | Mobile money | Card |
|---|---|---|
| Account holder | Phone-number account inside the operator system | Bank account or card account |
| Collection identifier | Merchant short code, merchant number or phone number | Card number plus merchant ID |
| Confirmation mechanism | Buyer confirms on the phone, result returned asynchronously | Authorisation and capture, result returned in the request |
| Refund path | Operator refund process, with its own timing and state differences | Card scheme refund and chargeback, open to evidence |
| Reconciliation evidence | Operator transaction receipts and settlement reports | Acquirer settlement reports and scheme clearing files |
Use the table by treating each dimension as a question that must be answered rather than background knowledge. The refund and reconciliation rows especially decide whether your operations can be automated. For the operational detail see the Refund and Settlement Operations Guide.
4.2 The Boundary of Cross-Operator and Cross-Country Coverage
Mobile money is not a single network. Within one country, mobile money from different operators can be independent of each other; between countries, the operating entities, rules and interfaces are separate again. That means a working integration in one country often has to be rebuilt in the next, including short code application, interface work and reconciliation fields.
Expansion should therefore be layered: use direct operator integration in primary markets to perfect experience and reconciliation, and a covering aggregator in long-tail markets to get collection working. The deciding factor is whether order volume supports the separate integration and operating cost. For regional differences see the Local Payment Methods by Region Guide.
5. Fee Structure and Real Cost
5.1 Fee Components
| Fee component | Description | What to judge |
|---|---|---|
| Collection fee | Charged per transaction or as a share by the operator or aggregator | Who bears it, user or merchant, must be stated on the page |
| Withdrawal and settlement | Cost of settling from the merchant wallet to a bank account | Cycle and evidence matter more to cash flow than the rate |
| Refund handling | Whether refunds are charged and whether they retrace the original path | Mobile money refund paths differ from cards and need separate confirmation |
| Integration and maintenance | Interface work, reconciliation and operations headcount | Commonly underestimated |
| Compliance and entity cost | Entity, licensing, tax and audit | A fixed cost created by local onboarding |
Current rates and conditions belong to the official quote and the signed contract. Any percentage in an article goes stale, and budgeting from old numbers is the easiest error to make.
5.2 Who Bears the Fee and How to Judge Real Cost
Mobile money has a question that is less prominent in the card world but critical in African markets: who bears the fee. In some models the paying user bears it and sees an extra charge on the confirmation screen; in others the merchant bears it, deducted from the collected amount; and in others an amount band decides. These three models affect conversion and gross margin completely differently, and all must be reflected in pricing and checkout wording.
Do not judge real cost on the collection fee alone. Build a mix that matches your business, with the same method share, the same order value bands and the same refund rate, then compare the final received amount. In mobile money markets the impact of settlement cycle and withdrawal cost on cash flow is often more worth watching than the fee difference.
6. How It Divides Work With Other Options
6.1 Against Multi-Market African Platforms
Multi-market African platforms solve the pain of covering several countries through one integration, at the cost of less depth per market than direct integration. The typical division is direct operator or local acquirer integration in primary markets and a coverage platform in long-tail markets. Compare Flutterwave with the Flutterwave Guide for the aggregator approach, and Paystack with the Paystack Guide for the single-country specialist approach.
Do not stack two deep solutions on the same market. Every extra provider adds another reconciliation flow, state machine and dispute process. For a local option in a different African market compare the PayFast Guide, but do not move its lessons straight onto East Africa.
6.2 Against Card Acquiring and Collection Account Options
Card acquiring still matters in Africa, especially where order values are higher and buyers hold cards. Mobile money and cards are not either-or but cover different buyer groups. Compare the combined local method and card capability of dLocal and Adyen.
One combination is often overlooked: a collection platform plus a collection account. Collection brings the money in; the collection account holds it and settles it out. If the repatriation path is complex, evaluating those two layers separately is usually more realistic than demanding every capability from one provider.
7. Who It Fits and Who It Does Not
7.1 Good Fit
First: teams whose target market pays mainly through mobile money and whose volume already justifies direct operator integration. In these businesses the conversion difference from mobile money coverage usually dwarfs the integration cost.
Second: teams with modest order values but high order frequency and mostly local consumers. Checkout failure hurts these businesses most directly, so method coverage is close to revenue.
Third: teams willing to invest engineering in asynchronous notifications, active polling and reconciliation. Mobile money latency is routine, and without that capacity operations get dragged down by hanging orders.
7.2 Weak Fit
First: teams treating the market as a test with very low volume and most buyers abroad. Direct operator integration cannot be amortised, so a coverage platform is more sensible for a while.
Second: teams hoping one interface solves all of Africa. Mobile money is a per-country, per-operator system, not a single network.
Third: teams treating refunds and reconciliation as something to handle later. Mobile money refund and reconciliation logic differs from cards, and postponing it accumulates unmatched accounts.
Fourth: teams with no server-side engineering capacity that expect configuration alone to work. A short code plus manual checks can carry you for a while, but volume quickly forces an interface.
8. Rollout Notes and Common Misreadings
8.1 Rollout Notes
| Rollout point | Practical approach |
|---|---|
| Confirm the short code type first | Distinguish bill-style and store-style numbers, and make sure online business gets order-level data |
| Design asynchronous first | Treat every result as asynchronous, with notification plus active polling as double insurance |
| Order numbers and idempotency | Guard creation, notification and query against duplicates so one order never collects twice |
| State who bears the fee | Make clear whether the user or the merchant bears it in pricing and on the page |
| Ask about the refund path first | Whether refunds retrace the original path, are charged and how long they take, confirmed before integration |
| Draw the repatriation path first | Clarify wallet, settlement account, conversion and cross-border transfer in one pass and get it in writing |
8.2 Common Misreadings
The first misreading is treating mobile money as the Alipay of Africa. It is indeed mobile payment, but it is an operator account system that sits alongside the banking system, and cross-operator movement usually does not interoperate. Reading it as one unified super app makes every integration and expansion calculation wrong.
The second misreading is assuming a refund can be initiated like a card refund. Mobile money refunds follow operator processes with timing and state differences, are not guaranteed to retrace the original path instantly, and do not follow the same evidence logic as a card chargeback.
The third misreading is treating a successful collection as funds in hand. The money first lands in an account inside the operator system and is only later settled to your bank account, with a settlement cycle and possibly a cross-border leg in between.
The fourth misreading is using card reconciliation evidence for mobile money. The evidence is different, the fields are different, and reconciliation must follow the operator transaction receipts and settlement reports.
| Common misreading | What actually happens |
|---|---|
| Mobile money is a unified African Alipay | It is an operator account system that usually does not interoperate across operators, so assess per country and operator |
| Refunds retrace the original path instantly like cards | Refunds follow operator processes with timing and state differences and need separate design |
| A successful collection means funds in hand | Settlement, possible conversion and cross-border transfer still apply |
| Reconciliation evidence is interchangeable with cards | Mobile money evidence differs in fields and granularity |
| The merchant always bears the fee | The bearing party depends on the model and directly affects conversion and gross margin |
If you are working on collection selection for African markets, use this guide as a checklist: confirm which mobile money your buyers mainly use, confirm its confirmation mechanism and refund path, then put the fee bearing party and the repatriation path in writing. For the wider regional judgement, continue from the Payment category page.
Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.