Illustrative workflow — not a RoamerWave customer case study
A missed mobile-money renewal does not always mean the customer has decided to leave.
Sometimes the customer never saw the prompt.
Sometimes an M-PESA STK request expires.
Sometimes the customer cancels because the timing is inconvenient.
Sometimes they would rather pay with Airtel Money.
And sometimes the merchant simply does not yet have enough provider evidence to know whether the payment succeeded.
The next useful action depends on which of those things actually happened.
Here is a fictional Kenya-based example.
Monday: Amina's monthly Letu Plus subscription becomes due
Amina lives in Nairobi and subscribes to a fictional video-podcast, documentary and audio subscription service called Letu.
Her September Letu Plus subscription costs KES 890.
On Monday, Letu creates one invoice:
- Seller: Letu
- Purpose: September Letu Plus subscription
- Amount: KES 890
- Country: Kenya
- Due date: Monday
Amina receives a reminder with a secure link.
The message tells her that she can pay using the mobile-money options currently enabled for Letu.
Nothing has failed.
The invoice is simply due.
Amina chooses M-PESA
Amina opens checkout and selects M-PESA.
Letu's approved payment route initiates an M-PESA request.
In Safaricom's merchant-initiated STK model, the customer receives a prompt on the phone, reviews the amount and enters the M-PESA PIN to authorize or cancels the request.
The payment attempt now has its own record.
- Invoice: KES 890 still owed for September.
- Attempt 1: M-PESA, Kenya, awaiting customer authorization.
That distinction matters.
The invoice is the commercial obligation.
The M-PESA attempt is one effort to settle it.
The result becomes unclear
Suppose Amina is interrupted before she completes the prompt.
The merchant receives no conclusive successful-payment evidence within the expected period.
A simplistic subscription system might immediately mark the invoice "failed" and send another M-PESA prompt.
A safer system does not guess.
The M-PESA attempt moves into an unresolved or waiting-for-evidence state until the provider behavior or subsequent query resolves it.
Amina sees:
"We're checking the result of your M-PESA payment. You don't need to pay again yet."
Revenue operations sees the same thing.
No second payment is requested while the first result is genuinely uncertain.
Why this matters
If Amina actually completed the M-PESA payment and the provider result is merely delayed, another prompt could create a duplicate-payment problem.
If she did not complete it, waiting briefly for trustworthy evidence loses little and gives the merchant a clean basis for recovery.
The important rule is:
Unknown is not the same as failed.
The provider resolves the first attempt
Later, Letu receives enough provider evidence to determine that the M-PESA attempt did not complete.
Now the states are clear:
- Invoice: Still due, KES 890.
- Attempt 1: M-PESA, not completed.
The business can enter recovery without guessing.
Amina receives a useful follow-up
The next message does not say only:
"Payment failed. Try again."
It says:
"Your September Letu Plus subscription of KES 890 is still due. Your earlier M-PESA payment was not completed. You can return to the same invoice and choose an available payment option."
The message tells Amina what the business knows and what she can do.
Amina chooses Airtel Money
Assume Airtel Money is genuinely enabled for Letu under its approved provider setup.
Amina returns to the same September invoice and chooses Airtel Money.
A new payment attempt is created.
- Attempt 1: M-PESA — not completed.
- Attempt 2: Airtel Money — customer-authorized attempt.
The first attempt stays in the history.
It is not overwritten.
The second attempt succeeds
The provider confirms that Amina's Airtel Money payment succeeded.
At that point:
- the September invoice becomes paid;
- reminders stop;
- Amina receives payment confirmation;
- Letu can apply its normal membership-access policy;
- finance receives the references needed for reconciliation.
There is no reason to keep asking Amina to act.
Finance still has its own work
The customer collection problem is closed.
Finance may still need to connect:
September invoice → Airtel Money attempt → provider transaction reference → provider reporting → reconciliation result → settlement evidence.
If the references match, the case closes automatically or with minimal review.
If a provider report is delayed, finance can investigate without reopening Amina's invoice.
Paid is still paid.
A finance exception should not become another customer reminder.
What this Kenya scenario illustrates
The useful part of the workflow is not that Amina tried two wallets.
The useful part is that the system preserved payment truth.
- One invoice remained stable.
- Each mobile-money attempt had its own history.
- The M-PESA result stayed unresolved until the merchant had enough evidence.
- A new payment was requested only after it was safe to do so.
- Amina controlled authorization through the wallet.
- Airtel Money was offered only because it was assumed to be enabled in this fictional merchant setup.
- Once payment was confirmed, recovery stopped.
- Finance then completed reconciliation separately.
This is fundamentally different from repeatedly firing mobile-money prompts until one appears to work.
Recovery should be respectful by design
A strong mobile-money recovery policy defines:
- when a reminder is appropriate;
- how long to wait for an unresolved attempt;
- when a fresh wallet attempt can be created;
- whether another enabled wallet can be offered;
- when human support should take over;
- when service access changes;
- when all collection activity must stop.
More prompts are not automatically better.
The goal is to help the customer complete the real obligation without creating pressure, confusion or duplicate-payment risk.
What to monitor in a recovery workflow
Track the operational outcomes that show whether the workflow helps customers complete a real obligation without creating avoidable payment risk:
- invoices that miss the first mobile-money payment moment;
- later recovered invoices;
- time from due date to confirmed payment;
- M-PESA and Airtel Money completion where enabled;
- number of reminders;
- number of wallet attempts;
- unresolved-payment incidents;
- duplicate-payment incidents;
- customer support contacts;
- manual staff time per recovered invoice.
Use those outcomes to improve the customer journey, recovery timing and operational follow-up.
The operating discipline
A failed or missed M-PESA renewal is not one universal event.
The customer may not have acted.
The prompt may have expired.
The result may still be unknown.
The invoice may already be paid while finance is reconciling it.
The next useful action should depend on the real state: wait, verify, remind, offer a new customer-authorized wallet attempt, escalate to a human, or stop because the payment is already confirmed.
The same states apply beyond Kenya: a customer paying through a different local rail is still served by one stable invoice, traceable attempts, honest unresolved states and recovery that stops the moment payment is verified.
That is the operating discipline RoamerWave is designed around for recurring mobile-money revenue.