Recovery starts when the first attempt does not produce a paid invoice
Recurring businesses should expect some payments not to complete on the first attempt. The customer may not act, a prompt may expire, the provider may return a final failure, or the result may be temporarily unknown. A good recovery process does not treat these cases the same. Its job is to move an unpaid invoice to the right next state without creating duplicate payments or putting unnecessary pressure on the customer.
Start with the invoice, not the failed transaction
The recovery question is "Is this invoice still due, and what action is safe now?", not "Did one payment attempt fail?" One invoice can have several attempts over time. If one fails, the invoice is still due. If another succeeds, recovery stops. Keeping that separation stops a single failed transaction from becoming your record of what the customer owes.
The five situations that matter most
Each situation calls for a different response:
| Situation | What you know | Typical next action |
|---|---|---|
| No attempt | The customer has not tried to pay | Send a reminder or a payment link |
| Awaiting customer | A payment request is open | Wait, or send a well-timed reminder |
| Failed or expired | The last attempt ended without payment | A new attempt may be allowed |
| Unknown | Success or failure cannot yet be confirmed | Check the result before any retry |
| Paid | The invoice has been satisfied by a verified payment; provider settlement may follow later | Stop all collection activity |
This is more useful than a generic "retry after X hours" rule, because the next action depends on evidence.
Unknown is not failed
An unresolved payment is one of the most important recovery cases. If the expected callback does not arrive, you cannot safely conclude that the customer did not pay. For M-PESA, Safaricom provides ways to check:
- For a payment request sent with M-PESA Express (STK Push), the M-PESA Express Query API returns the status of the request using its CheckoutRequestID.
- For a completed transaction, the Transaction Status API looks it up by M-PESA receipt number. Safaricom describes it as a secondary reconciliation mechanism when callbacks are not received.
The recovery process should hold further collection, check the transaction, resolve the attempt, and only then decide whether another payment is needed. That protects the customer from being charged twice.
Policy first, then failure-specific rules
Your recovery policy sets the overall shape:
- when follow-up begins;
- which channels you use;
- how long any grace period lasts;
- how many retries are allowed;
- whether another wallet can be offered;
- what happens if recovery does not succeed.
Within that policy, retry timing should also depend on why the last attempt failed. A request the customer cancelled, an account with insufficient funds and a request that simply timed out usually call for different timing. Keeping the policy and the failure-specific rules as separate settings makes both easier to tune.
Offer another wallet only when it is safe
A second wallet can recover a payment, provided the earlier attempt has a final result. Our guide to handling M-PESA and Airtel Money in one workflow shows the clean version. The risky version looks like this:
Invoice: KES 2,750, due
Attempt 1: M-PESA Unknown
Attempt 2: Airtel Money Succeeded
Later: Attempt 1 reports success
Result: The customer has paid twice
Offering another wallet should therefore require the previous attempt to be resolved first.
Grace periods are a business policy
You may not want to suspend service the moment a payment is late. A grace period gives the customer time to complete payment while recovery runs:
Due date: 5 November
Grace ends: 9 November
Service action: allowed from 10 November if still unpaid
The right length depends on your product and your customers. What matters is that the billing system applies whatever policy you choose consistently.
Stop recovery the moment the invoice is satisfied
Before every reminder or retry, check that the invoice is still due. It may have been settled by the original attempt arriving late, a later wallet attempt, a manual PayBill payment, a bank transfer, another approved method, or an adjustment or waiver. A reminder that was correct yesterday can be wrong today, so check the state when the reminder is about to go out, not when it was scheduled.
Send the cases automation cannot resolve to people
Some situations need human review:
- a payment that stays unknown after checking;
- a duplicate payment;
- a wrong payment reference;
- an amount mismatch;
- a customer dispute;
- a provider outage;
- an outside payment that has not been matched.
These should leave the normal recovery path and go to an exception queue. The goal is not to automate every edge case; it is to make the edge cases visible.
Keep decisions separate from wording
Decide the action first (remind, retry, offer another wallet, wait), then choose the message. Keeping the decision logic apart from the customer-facing wording means you can improve your messages without changing your recovery policy, and the reverse.
What to measure
- Paid by due date: how much is settled before recovery starts.
- Recovery rate: the share of invoices in recovery that are eventually paid.
- Time to recovery: how long an overdue invoice stays open.
- Attempts per recovered invoice: whether customers need repeated payment actions.
- Unknown-state rate: how often provider uncertainty blocks safe recovery.
- Wallet-switch recovery: how often a second wallet recovers a failed or expired attempt.
- Manual touches: how much staff work remains.
- Duplicate payments: whether recovery is creating unsafe second attempts.
The point is to see where revenue gets stuck, not just how many reminders went out.
When recovery should end
Your policy should define when recovery stops:
- Paid: recovery succeeded.
- Cancelled or waived: the invoice no longer needs collecting.
- Manual review: automation stops and staff take over.
- Service consequence applied: your commercial policy moves to the next stage.
Recovery should not run indefinitely just because an invoice is still unpaid.
A recovery policy template to adapt—not a universal retry schedule
Write the policy around evidence and permissions, not a fixed number of hours after every timeout. The following is a model for drafting your own policy, not a recommendation that every merchant contact customers at the same intervals.
| Trigger | Decision rule | Customer communication |
|---|---|---|
| Invoice becomes due, no attempt | Notify once through the agreed channel | Give merchant, period, KES amount and a supported payment path |
| Attempt awaiting authorization | Avoid overlapping payment requests | Show that the request is awaiting a customer action |
| Provider outcome unknown | Pause new attempts, check available provider evidence and assign unresolved cases | Say the result is being checked; do not accuse the customer of non-payment |
| Final failure or expiry, invoice still due | Apply merchant retry limits and consent requirements | Offer an authorized new attempt or another enabled method |
| Confirmed payment, waiver or cancellation | Stop queued messages and new attempts atomically | Send the appropriate confirmation or closure notice |
| Still unresolved beyond internal review threshold | Escalate to a named operator | Provide a support route without displaying confidential evidence |
Before sending any reminder, re-read the invoice and latest verified attempt state. A reminder scheduled yesterday may be unsafe today after an external PayBill payment, late callback, credit or cancellation.
Three questions for a recovery review
Track the count of unnecessary reminders, the number of unknown payments resolved before another attempt, and the number of duplicate-success exceptions. These quality measures sit alongside revenue recovery, because a higher retry count is not automatically a healthier collection process. The multi-wallet workflow covers the extra safety check when offering another payment route.
