There is more than one way to collect a recurring mobile-money bill
A Kenyan business can collect a monthly obligation through several different payment patterns. The right model depends on how much customer action is acceptable, how tightly the payment needs to map to an invoice and what the merchant's provider arrangement actually supports.
This is a comparison of collection models, not a recommendation to replace one provider product with another.
1. Manual PayBill with an account number
The customer opens M-PESA, chooses PayBill, enters the business number, enters an account reference and types the amount.
Where it works well
- The merchant already has a familiar PayBill workflow.
- Customers know the business number and account-reference convention.
- The business wants a low-friction fallback that does not depend on a payment link.
What the business still has to solve
- Customers can mistype the account reference.
- The merchant must match C2B transactions to the correct customer or invoice.
- The payer has to remember or retrieve the amount and due date.
Safaricom's C2B API exposes the BillRefNumber supplied with the payment. A merchant can use that field for matching, and can use C2B validation where appropriate to reject an unknown account reference before accepting the payment.
2. Payment link tied to an invoice
A payment link gives the customer a contextual entry point: merchant, amount, billing period and available payment methods can be prepared from the invoice.
Where it works well
- The merchant wants to send a specific payment request by SMS, WhatsApp or email.
- The business wants less reliance on the customer remembering PayBill details.
- The same invoice may offer more than one payment method.
What it does not solve by itself
- The customer still has to complete the chosen payment method.
- The merchant still needs invoice state, recovery and reconciliation.
3. STK payment request
With M-PESA Express, the merchant initiates a payment request and the customer receives a prompt on the phone. The request returns a CheckoutRequestID that should be stored against the payment attempt.
Where it works well
- The merchant knows the exact invoice amount.
- The customer is already in a payment flow and expects to authorize.
- The business wants the payment attempt linked tightly to the invoice.
Operational requirements
- Do not mark the invoice paid when the prompt is merely sent.
- Process the asynchronous callback.
- If the callback is late, use M-PESA Express Query with the CheckoutRequestID before retrying.
- Treat cancellation, timeout and unresolved results differently.
4. Standing-instruction or mandate-based recurring payment, where supported
Some payment rails can support a customer-authorized standing instruction or reusable mandate that allows future collections under defined terms. This creates a different recurring-payment experience from prompting the customer each cycle.
Availability is rail-, provider- and merchant-specific. Do not assume that a standing-instruction capability is available to every merchant simply because the wallet exists in the market.
Some standing-instruction arrangements are set up and controlled by the payer, while others depend on provider-specific merchant approval and a formal mandate. The merchant still needs clear invoice references, payment matching and a process for instructions that fail or are cancelled. Confirm the exact mechanisms available to the merchant before designing the collection workflow.
Where it can fit
- The payer explicitly authorizes a recurring arrangement.
- The merchant and provider support the required mandate or standing-instruction product.
- The business wants fewer customer actions at renewal.
What still remains
- The business still needs subscription or invoice state.
- Failed collections still need recovery.
- The merchant still needs reconciliation and service-state rules.
Which model should a business choose?
Choose based on the job, not on a hierarchy that assumes one method is always superior.
- Small, low-volume merchant: a clear PayBill or payment link may be enough.
- Merchant that wants invoice-linked initiation: STK requests can reduce manual entry.
- Merchant with several wallets: a payment link can present valid choices while one invoice stays authoritative.
- Merchant with an approved recurring mandate product: a standing-instruction model can reduce repeat authorization steps.
The billing system should survive the collection method
Whichever method is used, the merchant should keep one stable record of what is due. Payment attempts, references and provider results should attach to that record.
That prevents the collection method from becoming the business's source of truth.
Collection-model choice: separate customer action from back-office work
The following decision aid is deliberately about merchant workflow, not a claim that any route is enabled for every business.
| Model | Customer action | Merchant must still verify | Common operational pitfall |
|---|---|---|---|
| PayBill + account reference | Enter business details, reference and amount | Actual transaction, reference and invoice match | Typo or shared payer number |
| Invoice-linked payment link | Open link, choose and complete an enabled route | The chosen route's final result and invoice state | Treating link opened as payment received |
| M-PESA Express / STK request | Approve a specific prompt on the handset | Callback or status query against the stored request ID | Treating request accepted as paid |
| Provider-approved recurring instruction | Authorize according to that product's mandate rules | Each collection outcome, cancellation and settlement evidence | Assuming approval applies to an unsupported merchant or route |
A recurring instruction is not interchangeable with an ordinary STK request. Ask the actual provider which initiation, permission and cancellation rules apply to your merchant account rather than assuming the wallet brand determines them.
A quick suitability exercise
Take five recent renewals, remove personal identifiers, and ask: Where did staff retrieve the amount? Who provided the payment reference? Which transaction evidence proved the invoice was paid? What stopped a second reminder? What would happen if the payer changed wallets? If the answers depend on copying screenshots or manually remembering who paid, the missing capability is likely invoice operations, not another way to initiate a transaction. For safe switching across approved methods, see the M-PESA and Airtel Money workflow.
Sources
- Safaricom Daraja C2B API: https://developer.safaricom.co.ke/apis/CustomerToBusiness
- Safaricom M-PESA Express API: https://developer.safaricom.co.ke/apis/MpesaExpressSimulate
- Safaricom M-PESA Express Query API: https://developer.safaricom.co.ke/apis/MpesaExpressQuery
