A mobile-money payment should feel local before it feels clever
A customer in Nairobi choosing M-PESA, a customer in Kampala paying with MTN MoMo and a customer in Lagos using a mobile-money or instant-transfer product are all making digital payments. Their expectations are not identical.
That matters for recurring revenue.
A card-based subscription can make the payment step nearly invisible after the first authorization. Mobile-money renewals often do the opposite: the payment moment stays visible because the customer may need to act on a phone, wallet app, USSD menu or provider prompt each billing cycle.
The design challenge is therefore not to hide the payment. It is to make the payment request recognizable, expected and easy to complete.
Consider a Kenyan monthly membership
Suppose a Nairobi customer receives this message:
"Your KES 890 September Letu Plus subscription is due. Pay securely with M-PESA or Airtel Money."
They open the merchant's checkout and see:
- Letu
- September Letu Plus subscription
- KES 890
- M-PESA
- Airtel Money
If they choose M-PESA and the merchant's approved route uses STK Push, the customer should expect a prompt on the phone. Safaricom's published flow has the customer review the payment request and enter an M-PESA PIN to confirm it.
The merchant's interface should prepare the customer for that hand-off:
"Check your phone for the M-PESA prompt. Confirm the merchant and amount before entering your PIN. RoamerWave and Letu will never ask you to type your M-PESA PIN into this page."
That is a recognizable payment moment because the commercial context survives the hand-off to the wallet.
The same principle applies to Airtel Money: the customer should know which wallet they chose, what amount they are authorizing and where the sensitive PIN-controlled step belongs.
Keep seller, purpose and amount consistent
The fastest way to make a legitimate mobile-money payment look suspicious is to change its identity halfway through the journey.
- The reminder should identify the same seller the checkout identifies.
- The checkout should show the same amount the phone request is supposed to contain.
- The billing period or invoice purpose should be understandable.
If the customer is paying KES 890 to renew a Letu Plus subscription, the experience should not begin with "Letu," switch to an unexplained payment processor name and end with an ambiguous wallet prompt.
Provider branding may appear where the provider controls the payment, but the customer should still understand the relationship.
Before asking for authorization, show:
- the actual merchant;
- the invoice or subscription purpose;
- amount and local currency;
- billing period or due date;
- the wallet selected;
- what happens next on the customer's phone;
- how the customer can return safely if the flow is interrupted.
A familiar payment experience is not the same as a generic payment experience.
Design the hand-off for the market in front of you
For many Kenyan customers, M-PESA is a deeply familiar payment environment. Safaricom supports merchant payment patterns such as Paybill, Buy Goods and merchant-initiated STK requests. Airtel Money is another relevant wallet, and Airtel Kenya also supports payments to M-PESA tills from Airtel Money.
A Kenya checkout can therefore speak plainly about M-PESA and Airtel Money when those methods are actually enabled for the merchant. It should also prepare the customer for what comes next: a prompt on the phone, a confirm-the-amount step and a PIN entry inside the wallet.
The same discipline applies in every other market, even when the mechanics differ. In Uganda, MTN MoMo merchant payments run through a merchant code, amount and MoMo PIN. In Nigeria, licensed mobile money operators such as OPay and PalmPay sit alongside a large instant account-transfer ecosystem, so the checkout may need to present a very different flow than an M-PESA STK prompt.
The common product layer should preserve the same commercial meaning—who is paying whom, how much, for what and whether the obligation is settled—without pretending that every country uses the same authorization interface.
Do not call a customer-authorized wallet payment "automatic" by default
Words matter.
If every monthly M-PESA or MTN MoMo payment requires the customer to approve a request, the subscription schedule may be automatic while the payment authorization is not.
That distinction should be visible in customer-facing language.
- Better: "Your monthly invoice is ready. Choose a wallet to renew."
- Potentially misleading: "We will automatically charge your mobile-money wallet every month."
A reusable mandate or standing instruction can exist on particular rails and products, but it should be claimed only where that exact capability is approved and supported.
For RoamerWave's current assisted-recurring model, the safer principle is: schedule the commercial obligation automatically; let the customer authorize the payment through the enabled wallet.
Design an honest unresolved state
Mobile-money payments are often asynchronous.
- The merchant may send a request, receive an acknowledgement and wait for final provider evidence.
- The customer may approve late.
- A callback may be delayed.
- The prompt may expire.
- The merchant's interface may temporarily lack enough evidence to say whether the payment succeeded or failed.
That middle state needs real product copy.
For example:
"We're checking your M-PESA payment. You don't need to pay again yet."
That sentence is more useful than prematurely showing "failed" and inviting a second attempt.
A clear unresolved state protects the customer from duplicate-payment risk and gives operations time to reconcile provider evidence.
Confirmation should close the customer loop
Once the payment is verified, tell the customer clearly.
A useful mobile-money confirmation can show:
- amount paid;
- merchant;
- invoice or membership;
- wallet used;
- payment reference where appropriate;
- resulting service or account state;
- support route for discrepancies.
Then stop reminders.
A finance team may still need to reconcile the payment or wait for settlement reporting, but those internal tasks should not make a paid customer look overdue again.
Build the return path
A mobile-money checkout should also answer what happens when the happy path breaks.
- What if the M-PESA prompt expires?
- What if the customer closes the browser?
- What if MTN MoMo authorization is not completed?
- What if the provider result is still unknown?
- What if the customer wants to use another enabled wallet?
The answer should take the customer back to the same commercial obligation.
The invoice remains due until verified payment closes it. Individual payment attempts can fail, expire or remain unresolved without forcing the merchant to create a new invoice every time.
Run a design review
Good African mobile-money checkout is not achieved by placing several wallet logos on a generic card-payment screen. It starts by recognizing local payment behavior.
Before shipping a renewal checkout, ask:
- Does the customer know who is being paid, what for and the exact amount?
- Does the language match the market's real wallet behavior — an M-PESA prompt in Kenya, a MoMo merchant-code flow in Uganda, a very different journey in Nigeria — without importing another market's assumptions?
- Is the PIN or sensitive step clearly inside the wallet, never on this page?
- Is an unresolved result phrased honestly, without asking the customer to pay again?
- Is there a safe return path to the same invoice if the flow is interrupted?
- Does confirmation state the amount, wallet, period and the resulting service state?
Keep the seller, purpose and amount stable. Put the PIN or sensitive authorization step inside the wallet/provider-controlled environment. Make pending and unknown states truthful. Give the customer a safe return path. Confirm the result clearly.
The interface can stay simple only when the operating record underneath it is precise.