Recurring mobile-money operations need more than an overdue list
If a Kenyan customer has not completed an M-PESA renewal, the invoice may be overdue.
If an M-PESA prompt has been sent and the customer has not authorized it, the invoice may still be waiting on customer action.
If the provider has not returned a conclusive result, the attempt may be unresolved.
If the provider confirmed payment but the merchant has not matched the transaction to the invoice, the customer may be paid while finance still has an exception.
Those are four different operating problems.
A revenue-operations team should not put all of them into one "failed payments" queue.
That is especially important for recurring mobile-money payments across African markets, where each billing cycle may depend on fresh customer authorization through M-PESA, Airtel Money, MTN MoMo or another approved wallet.
Start with the invoice, then inspect the wallet attempt
Consider a monthly KES 890 membership sold in Kenya.
The invoice answers the commercial question:
Does this customer still owe KES 890 for September?
The payment attempt answers the execution question:
What happened when the customer tried to pay through M-PESA or Airtel Money?
One invoice can have more than one attempt.
A customer may first choose M-PESA and let the STK prompt expire. The September invoice remains due.
Later, if Airtel Money is enabled for that merchant, the same customer may return and authorize a new Airtel Money attempt.
The revenue-operations view should preserve both attempts under one invoice.
This makes the next action much easier to determine.
Queue 1: Due, no wallet attempt yet
These are genuinely unpaid invoices with no active attempt.
Example: Amina’s Letu Plus KES 890 September invoice was issued yesterday. No M-PESA or Airtel Money attempt exists.
Possible next action: Send the merchant-approved reminder and secure payment link.
Useful context:
- due date;
- invoice amount and currency;
- last customer communication;
- enabled wallets;
- customer's market;
- service or entitlement policy.
There is no need for payment investigation yet because no payment attempt has started.
Queue 2: Awaiting customer authorization
Now suppose Amina selects M-PESA and a wallet request is initiated.
The customer still needs to complete the provider-controlled authorization step.
That is not the same as a failed payment.
The right action may be to wait, show instructions or allow the attempt to expire according to the provider's actual behavior.
The operator should not immediately trigger another M-PESA prompt simply because the first one is still waiting.
For Uganda, the same principle applies even though the customer experience may differ. An MTN MoMo merchant payment ultimately depends on the customer authorizing the payment from their MoMo account. A revenue queue should preserve that customer-action state instead of collapsing it into "failed."
Queue 3: Failed or expired and eligible for recovery
This queue contains attempts where the system has enough evidence that the previous payment did not settle the invoice.
Examples include:
- an expired M-PESA request;
- a customer rejection;
- a provider-confirmed failure;
- another terminal state that clearly leaves the invoice unpaid.
Now a recovery action can be explicit.
The team may send a respectful follow-up.
The customer may return to the same unpaid invoice.
A new customer-authorized payment attempt may be created.
If another wallet is genuinely enabled, the checkout may allow the customer to choose it.
What should not happen is overwriting the earlier attempt. The merchant needs the history for support, reconciliation and duplicate-payment protection.
Queue 4: Unknown or under investigation
This is one of the most important queues in mobile-money operations.
Suppose a merchant sends an M-PESA request and receives an acknowledgement, but the final result is not yet trustworthy.
Or suppose a callback is delayed.
Or the customer says they entered the PIN, but the merchant cannot yet match a confirmed transaction.
The system does not have to guess.
The attempt can remain unknown or unresolved while the operator waits for provider evidence, queries the provider or escalates the case.
During that period, actions that could create duplicate collection risk should be suppressed.
Do not tell the customer "payment failed" merely because the merchant's application stopped waiting.
Queue 5: Paid, but not reconciled
This is a finance problem, not a collections problem.
Suppose the M-PESA payment is confirmed and the invoice is paid.
Recovery must stop.
But finance may still need to match:
invoice → M-PESA or Airtel Money attempt → provider transaction/reference → provider reporting → reconciliation result → settlement evidence.
If the provider reference is missing from the expected report, finance should investigate it without reopening the customer's invoice.
A customer who already paid should not receive an overdue message because an internal reconciliation job has not finished.
Add country and wallet context to every case
A regional merchant should be able to see where an exception occurred.
Useful fields include:
- country;
- currency;
- wallet;
- PSP or provider account;
- invoice reference;
- payment-attempt reference;
- provider reference;
- last verified state;
- age of the exception;
- next permitted action.
This matters because a "payment pending" issue in Kenya may involve an M-PESA route, while a similar commercial obligation in Uganda could involve MTN MoMo or Airtel Money.
Nigeria adds another operating pattern. CBN lists mobile money operators such as OPay and PalmPay, while instant account transfers are also central to the country's electronic-payment environment. A pan-African revenue queue therefore needs a stable commercial state without assuming that every local payment attempt has the same semantics.
Prioritise by value, age and ambiguity
Not every exception deserves the same urgency.
A revenue-operations team can prioritize using understandable factors:
- overdue age;
- invoice value;
- number of prior attempts;
- whether the latest payment state is unresolved;
- whether access or entitlement depends on resolution;
- whether the customer has already contacted support;
- whether a finance or settlement deadline is approaching.
A high-value invoice with an ambiguous M-PESA result may deserve attention before a low-value invoice that simply became due this morning.
The purpose is not to invent a mysterious score. It is to help an operator understand why one case should be worked first.
Make every state have an owner
Mobile-money payment problems cross teams quickly.
- Support hears: "I already paid."
- Finance sees a provider transaction.
- Engineering sees a delayed callback.
- Revenue operations sees an overdue invoice.
If they work from different interpretations, the customer receives contradictory answers.
Define ownership.
- Revenue operations or support: customer communication and recovery.
- Payments operations: provider-state investigation.
- Finance: reconciliation and settlement exceptions.
- Engineering: integration failures or provider incidents.
- Merchant owner: service suspension, reinstatement or exception policy.
A useful case record should show the full sequence:
invoice created → reminder sent → wallet selected → attempt started → customer authorization state → provider evidence received → invoice state changed → reconciliation completed.
That history is more useful than a dashboard with only green and red badges.
Measure the work the queue removes
For recurring mobile-money operations, track:
- manual touches per invoice;
- unresolved cases and their age;
- time from customer payment to reconciled invoice;
- percentage automatically reconciled;
- staff time spent confirming M-PESA, Airtel Money or other wallet payments;
- support contacts about payment status;
- duplicate or ambiguous payment incidents;
- recovery after an incomplete first attempt;
- payment completion by enabled wallet and country.
Those measures show whether the merchant is building a calmer collection operation rather than simply adding more notifications.
The operating rhythm
A useful renewal queue distinguishes customer delinquency from payment execution and finance exceptions.
The daily rhythm is simple: work the queues in order of value, age and ambiguity. Do not chase a customer whose payment is already confirmed. Do not initiate another wallet payment while an earlier result is genuinely unresolved. Do not call "awaiting customer authorization" a failure. Do not let an unmatched finance record reopen a paid invoice.
The weekly rhythm checks whether the queues are getting calmer: fewer unresolved cases, faster time from payment to reconciliation, fewer duplicate incidents. Across Kenya, Uganda, Nigeria and other African payment environments, the local rail may change. The operating question remains stable: what does the customer still owe, what payment evidence exists, and what is the next safe action?
That is the problem RoamerWave is designed to organize around.