Start with the work you want to remove
A recurring-payment system should not be chosen by counting payment logos. A Kenyan business can already accept M-PESA and still spend hours each month:
- checking who is due;
- matching payments to customers;
- following up on failed attempts;
- confirming payments manually;
- updating service access;
- reconciling finance records.
Before comparing software, write down the recurring work that still happens by hand. That list is a better buying brief than "we need M-PESA."
A capability checklist
Use this table as a shortlist filter, then test the answers in a demo.
| Capability | Why it matters | Question to ask |
|---|---|---|
| Invoice tracking | Keeps one commercial record for each billing period | Can one invoice survive several payment attempts? |
| Local payment methods | Lets customers use the methods they already use | Which methods are enabled for our merchant account, not just supported by the provider? |
| Customer authorization | Avoids promising silent autopay where the method does not offer it | How does the customer approve each supported method? |
| Payment states | Prevents unsafe retries and customer confusion | Can it tell pending, unknown, failed, expired and paid apart? |
| Recovery rules | Turns non-payment into a controlled process | Does recovery change depending on why the last attempt did not complete? |
| Reminder suppression | Stops chasing customers who have paid | Are scheduled reminders cancelled as soon as payment is verified? |
| Multiple wallets | Lets customers switch method safely | Can another wallet pay the same invoice without creating a second bill? |
| Payment matching | Reduces screenshots and spreadsheet work | How is a provider transaction linked to the customer and billing period? |
| Reconciliation | Gives finance traceable evidence | Can finance connect invoice, attempt, provider reference and settlement evidence? |
| Exception queue | Focuses staff on what needs action | Can staff see unresolved, unmatched and duplicate payments separately? |
| Service events | Keeps billing aligned with your product | Can verified payment state update our membership, SaaS or service system? |
| Provider portability | Reduces future integration rewrites | What changes if we add another PSP or country? |
What to check in more detail
Can it represent what is due?
Recurring revenue begins with a commercial obligation, not a transaction. The system should hold the customer or account, amount, currency, billing period, due date and status, and that record should stay stable when the customer makes more than one attempt. If a customer's first payment request times out and they pay later in the week from a payment link, the business should still have one invoice for the month.
Does it support the payment methods your customers use?
Kenya is a mobile-money-heavy market: the 2024 FinAccess Household Survey reported that 82.3% of Kenyan adults used mobile money. That does not mean every merchant should accept only mobile money, but payment-method decisions should reflect your audience. Ask two separate questions: what does the provider support technically, and what is enabled for your merchant account? The answers are not always the same.
Does it describe customer authorization accurately?
Some payment methods support reusable mandates or standing instructions. Others need the customer to approve each payment. The software should show that difference clearly. Be wary of platforms that use "autopay" as a catch-all without explaining what the underlying method supports.
Can it tell payment states apart?
A spreadsheet with Paid and Not Paid is rarely enough. A recurring system should represent at least due, awaiting customer, pending, unknown, failed or expired, paid and reconciled. The most important distinction is usually unknown versus failed: if the software cannot prove a payment failed, it should not prompt the customer to pay again.
Is recovery based on what happened?
Good recovery is more than scheduled reminders. The next action should depend on the state of the invoice:
- No attempt yet: send a reminder.
- Expired attempt: offer a fresh payment action.
- Unknown attempt: check the result before any retry.
- Paid: stop.
A mature system also supports your policies on grace periods, retry limits and offering another wallet. Our failed-payment recovery guide covers this in depth.
Can it match and reconcile payments?
Receiving money and knowing what it paid for are different jobs. The system should connect the invoice, customer, payment attempt, provider transaction reference, amount, payment time and reconciliation status. For M-PESA C2B payments, the Daraja confirmation includes fields such as TransID, TransTime, TransAmount, BusinessShortCode and BillRefNumber, and the software should keep enough of that evidence to make matching defensible. Our M-PESA reconciliation workflow shows how those fields are used.
Can operations work from exceptions?
Staff should not have to inspect every customer. A useful dashboard surfaces overdue invoices, unresolved attempts, confirmed failures, unmatched transactions, duplicate payments and paid-but-unreconciled records, so the normal path runs automatically and the unusual cases are obvious.
Will it survive another wallet, PSP or country?
A business may later add Airtel Money, add a second PSP, enter Uganda or Tanzania, or change provider. You should not need to rebuild your billing model each time. Provider details should stay traceable, but billing should not depend on one provider's vocabulary.
Not sure you need recurring-payment software?
Some businesses are better served by a PayBill, Till or payment link plus a simple receivables process. Use the separate guide on when payment collection software is enough before comparing recurring-payment platforms.
Questions to ask in a vendor demo
Ask the vendor to show you each of these, not just describe them:
- A customer with one invoice and two payment attempts.
- An unresolved payment where a retry is blocked.
- A customer who pays through another approved route.
- A failed payment recovered with a different wallet.
- A payment matched to the correct invoice.
- A finance exception that needs manual review.
- What changes when a second PSP or market is added.
- Who processes and settles the funds.
If the demo cannot show those cases, the product may be a payment page rather than a system for running recurring payments.
Make the procurement decision with a real operational sample
Before a sales demonstration, anonymize one recent renewal period and tally:
- total invoices due and successfully paid;
- payments staff could not immediately match to an invoice;
- unresolved requests that blocked safe follow-up;
- reminders corrected or cancelled after a customer paid;
- time spent handling exceptions, in staff-hours;
- charges for software, messages and processing at your actual provider rates.
A useful comparison is total monthly operating cost per successfully collected invoice: add the vendor's monthly fee, applicable transaction/message costs and the estimated staff cost of payment administration; then divide by successfully collected invoices. This is a budgeting exercise, not a claim that a platform will produce a particular saving. Compare like-for-like volumes, payment methods and merchant terms.
Ask each vendor for three concrete pieces of evidence: a workflow demonstration using a sanitized invoice with a delayed result, an export that shows invoice-to-provider-to-settlement traceability, and written confirmation of which payment routes your merchant account can actually use.
Three buying outcomes—not one universal answer
| Current situation | Sensible next step |
|---|---|
| Low recurring volume, reliable manual matching | Keep the payment route; improve references and the ledger |
| Regular renewals, frequent follow-up and matching work | Trial a recurring operations layer against the sample period |
| Existing mature SaaS subscription engine entering Kenya | Keep the current billing engine and evaluate locally enabled wallet-payment adapters |
The broader vendor scorecard and demonstration script is for comparing shortlisted systems. This article helps determine whether that procurement exercise is justified at all.
