One invoice, more than one way to pay
Supporting M-PESA and Airtel Money should not create two billing systems. The business should still have one record of what is due, who owes it, when it is due and whether it has been paid. The wallet belongs to the payment attempt, not the invoice. That is the simplest way to let customers choose between your enabled methods while keeping operations coherent.
Here is the pattern for a membership business with a KES 4,000 November renewal:
Invoice: November renewal, KES 4,000
Status: Due
Attempt 1: M-PESA Expired
Attempt 2: Airtel Money Succeeded
Invoice: Paid
The customer received a payment request, chose M-PESA, and let the prompt time out. Later they paid with Airtel Money. The business still has one November obligation, with two attempts recorded against it.
Step 1: create the invoice independently of the wallet
Do not label the business record "M-PESA November invoice." Use a neutral record:
Invoice: INV-2026-11-4281
Amount: KES 4,000
Due date: 5 November
Status: Due
Create a payment attempt only once the customer chooses a method, or your policy starts an approved payment flow. Billing then stays stable if the customer pays with a different wallet next month.
Step 2: show only methods that are enabled for you
Your PSP may support several payment methods, but that does not mean each one is live for your merchant account. The options a customer sees should reflect merchant approval, country, currency, provider route and production configuration. A wallet should appear because you can accept it, not because its logo is common in the market.
M-PESA is typically reached through Safaricom's Daraja APIs or a PSP. Airtel Money has its own developer platform for collections through Airtel Africa, and many merchants reach it through a PSP instead. The billing workflow should not depend on which route you use.
Step 3: keep each attempt traceable
Every payment attempt should record at least:
- the invoice ID;
- the payment method and provider;
- the provider reference;
- the amount;
- the normalized state, plus the raw provider result where useful;
- timestamps.
This gives you one history across both wallets, so operations can see what happened without keeping separate customer ledgers.
Step 4: do not switch wallets while the first result is unresolved
This is where multi-wallet recovery becomes risky. If the M-PESA result is still pending or unknown, do not ask the customer to pay with Airtel Money yet: the first payment may still succeed. Wait for a final result, or check the status of the M-PESA request first.
A safe switch normally needs all of these to be true:
- the invoice is still due;
- the previous attempt has a final result;
- another wallet is enabled;
- the customer approves the new attempt.
Step 5: tie reminders to invoice state
Before any follow-up, check whether the invoice is still due, whether a payment has succeeded, whether an attempt is unresolved and whether the customer has paid through another accepted route. If the invoice is paid, stop. If the previous attempt expired, offer a valid next action. If the result is unknown, check it first. The logic is the same whether the previous method was M-PESA or Airtel Money.
Step 6: reconcile both wallets in one finance view
Finance should not keep one customer ledger for M-PESA and another for Airtel Money. Each successful transaction should link back to the same invoice, with the customer or account, payment method, provider, provider reference, amount, payment time and reconciliation status.
Finance can then answer:
- how much became due and how much was collected;
- which wallet was used;
- which payments remain unmatched;
- whether any invoice has more than one successful payment;
- which paid transactions are still awaiting settlement reconciliation.
Step 7: keep provider differences out of the everyday workflow
M-PESA and Airtel Money do not have identical status names, approval screens, timeout behavior or response fields. Your billing operation only needs a stable internal meaning for each result. For example, an M-PESA request waiting for the customer's PIN and an Airtel Money request waiting for the customer's approval can both map to "awaiting customer." A provider adapter handles that translation, so the merchant's workflow stays the same.
What changes for the customer
The customer gets a choice: they can use whichever enabled wallet suits them at that moment instead of being forced into one route. What should not change is the meaning of the payment: the same merchant, billing period, amount and invoice. That continuity reduces confusion.
What changes for the business
The business adds a payment route without adding invoices, reminder systems, customer ledgers or service-state logic. The benefit is not simply "two wallets." It is two wallets inside one recurring billing workflow.
Another payment method does bring more provider configuration, support, reconciliation detail, testing and checkout choices. Add it when there is a real customer or recovery reason, such as a meaningful share of customers who prefer Airtel Money or frequent M-PESA attempts that never complete.
A wallet-switch decision table
A second payment option helps only if the business can explain why a second attempt is safe. This table is an illustrative merchant policy, subject to actual PSP capability and merchant approval.
| Current invoice and attempt state | Show another wallet? | Reason |
|---|---|---|
| Invoice due; no active attempt | Yes, if that wallet is enabled | Customer can choose how to start payment |
| Invoice due; first attempt awaiting approval or unknown | Not yet | The first transaction may still succeed |
| Invoice due; first attempt confirmed failed or expired | Potentially, with customer authorization | A new attempt can reference the same invoice |
| Invoice paid through either route | No | Further collection would risk a duplicate |
| Paid externally but not yet matched | Pause while verifying the external payment | Billing records must reflect the evidence before prompting again |
Never infer account eligibility from a provider's public marketing page. Request confirmation of the approved merchant route, KES collection capability, how approval is obtained, status/query behavior and which transaction/settlement references are available.
Handover to finance: one record across two rails
For each successful payment, finance needs the common invoice/account ID plus provider-specific evidence: method, PSP/merchant account, transaction reference, amount, currency and confirmation time. A normalized status makes the queue readable; the original provider reference makes disputes and reconciliation auditable. Compare the underlying collection models before deciding which customer choices to expose.
