Customer effort usually appears before and after the PIN screen
The M-PESA authorization step is familiar to many Kenyan customers. The avoidable friction is often everything around it: remembering the due date, finding the merchant details, knowing which account reference to use and wondering whether payment went through.
Carry the invoice context into the payment moment
A recurring payment request should tell the customer:
- who is requesting payment;
- what period or service it covers;
- the exact amount;
- which payment methods are available;
- what to expect next;
- how they will know payment is confirmed.
Do not make customers reconstruct PayBill details every month
A payment link or invoice-linked flow can pre-fill or carry more context than a generic “Pay via PayBill” message. Manual PayBill can remain a valid route, but it should use a clear account/reference convention.
Make each payment state understandable
Before due date
“Your November membership of KES 3,500 is due on 5 November. No action is needed until then.”
Due
“Your November membership of KES 3,500 is due today. Choose an available payment method to complete it.”
STK request sent
“Check your phone for the M-PESA payment request. Confirm the merchant and amount before authorizing.”
Previous result still being checked
“We’re checking your previous payment. You don’t need to pay again yet.”
Final failure or expiry
“That payment did not complete. Your invoice is still due, and you can try again.”
Paid
“Payment confirmed. No further action is needed for this invoice.”
These examples are templates, not mandatory wording. The merchant's tone and service terms should shape the final copy.
Use one source of customer copy
Keep these state messages in one shared library so SMS, WhatsApp, email, the payment page and support replies say the same thing at each stage.
Do not ask the customer to prove a payment that the system can verify
If the provider record can resolve payment state, use it before asking for a screenshot. Screenshots are useful as exception evidence, not as the normal confirmation workflow.
Make wallet choice reversible but safe
If another wallet is enabled, let the customer choose it after the previous attempt is safely final. Do not push a second payment while the first result is unresolved.
Payment confirmation should update the business quickly
Once payment is verified, the customer should not continue receiving reminders. Membership or account state should update according to the merchant policy while finance reconciliation continues separately.
What to measure
- Payment completion time.
- Support contacts asking whether payment was received.
- Reference-entry errors.
- Reminders per paid invoice.
- Duplicate-payment incidents.
- Wallet-switch recovery.
A better customer experience should reduce work for the merchant as well as friction for the payer.
Sources
- 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
- Safaricom C2B API: https://developer.safaricom.co.ke/apis/CustomerToBusiness
