Mobile Money gets discussed from the technical side all the time and from the customer's side almost never. Yet it is that journey which decides whether your sale goes through. Here it is in full, as it plays out on a Cameroonian buyer's phone - and, alongside it, what you see at the same moment.
An account attached to a number
A Mobile Money wallet is an account held by the operator and identified by the phone number itself. There is no card, no bank details, no mandatory app: the number is the account.
It is topped up at an agent - those kiosks on every street corner - by a transfer received, or by a salary paid into it. It is used to send money, pay bills, and pay merchants.
Two networks cover the country: MTN Mobile Money and Orange Money. A customer has one, the other, or both.
The journey, step by step
1. The amount and the number
On your payment page, the customer sees what they are paying and who to. They type in their Mobile Money number - not necessarily the one they are browsing with, by the way: paying from a relative's wallet is common.
They do not have to pick their operator. The prefix of the number settles it: the 67 and 650-654 ranges belong to MTN, the 69 and 655-659 ranges to Orange, and so on. Asking "MTN or Orange?" of somebody who has just typed their number is one question too many, and one more chance to get it wrong.
Those ranges move with the regulator's numbering plan: this is configuration data, not a constant carved into the code.
2. The prompt on the phone
A few seconds later, the customer's phone shows a confirmation request. Depending on the operator, the handset and the SIM configuration, it takes the form of a USSD window that takes over the screen, a message inside the operator's app, or a menu they have to dial themselves.
This is the most fragile moment of the journey. A USSD window disappears if the customer switches app, takes a call, or is slow to react. A payment page that says plainly "look at your phone, confirm with your PIN" prevents a good share of the drop-offs.
3. The PIN
The customer enters their Mobile Money PIN. That code never passes through your site, nor through ours: it is entered on the operator's network, and that is precisely what makes the mechanism safe. Nobody but the operator ever sees it.
4. The confirmation SMS
The debit goes through and the customer receives an SMS from their operator with the amount, the beneficiary and a transaction identifier. From their point of view, it is done.
That SMS is a confirmation for them - not a proof for you. Text can be retyped, and it must never be the basis for a delivery.
What you see at the same moment
During those few seconds, the payment moves through several states, visible in your dashboard and returned by the API.
- Pending - the payment is created, nothing has gone to the operator yet.
- Processing - the request was accepted by the operator and the prompt has gone out. This is the longest state: it lasts as long as it takes the customer to get their phone out.
- Awaiting confirmation - the state specific to merchant-code payments, where the customer paid through a USSD code and a human reconciliation is still needed.
- Succeeded - the money has left the customer's wallet. Your balance is credited, commission deducted.
- Failed - with a usable reason.
- Expired - nobody confirmed within the allotted time.
Each change of state is notified to you if you configured a callback address. And in every case the state stays queryable through the API: that re-read, and only that, is what authorises a delivery.
What can go wrong, and what to say about it
The balance is short. By far the most common case. The right message is not "payment declined" but "the wallet does not hold enough: top up at an agent and try again". That nuance changes how many customers come back.
A limit is hit. Mobile Money accounts have per-transaction, daily and monthly limits that depend on how thoroughly the customer is identified. A customer can have the money and still be unable to spend it in one go.
The prompt never arrives. Congested network, phone switched off, dual SIM with the wrong card active. Offer to resend the request rather than starting a new order.
The customer has forgotten their PIN. This happens more often than you would think, especially on wallets that are rarely used. There is nothing you can do from your side except leave the door open for another attempt.
The number was typed wrong. People write their number with spaces, with a leading +237, or as the nine local digits alone. Accept all three and normalise them yourself instead of answering "invalid number": every rejected keystroke is a customer wondering whether your shop actually works.
The request times out. The prompt does not stay on screen forever. A page that shows the remaining time and offers a "try again" button recovers a portion of those abandonments.
Two differences from a bank card
The operation is immediate and final. There is no equivalent of a card chargeback weeks later. For the merchant, that is real peace of mind. For the customer, it means they have to be able to trust you before they confirm - hence the importance of a payment page that states clearly who is collecting and what for.
The money arrives in a wallet, not a bank account. The proceeds of your sales are credited to your balance, then paid out to your Mobile Money number when you ask for it.
What the aggregator does in the middle
From the customer's side, none of this is visible: they type a number, confirm with a PIN, receive an SMS.
From yours, the aggregator absorbs the rest: recognising the operator from the number, speaking to two different APIs, translating two vocabularies of errors into one, polling the status until the fate of the transaction is settled, and notifying you once it is.
It is the least spectacular job in the chain. It is also the one that makes the difference between a payment page that completes and a sale that evaporates.