M-PESA Business in Kenya: Choosing a Till or Paybill Around Your Records

For a Kenyan business, choosing how to collect M-PESA payments is also a decision about recordkeeping. A shop handling immediate purchases and a service business collecting recurring account payments may need different ways to identify what each receipt belongs to.

This guide focuses on Safaricom’s Kenyan M-PESA Business Hub and its descriptions of Buy Goods, Paybill and reconciliation services, checked on 27 October 2026. It does not describe every M-PESA market. ITBank has not opened a Till or Paybill, tested onboarding or measured settlement performance. Application requirements, tariffs and approval decisions should be confirmed directly with Safaricom.

Begin with the customer’s payment purpose

Write down what the customer is paying for and the information needed to match that receipt. In a hypothetical small shop, staff may associate the payment with the goods at the counter. In a hypothetical maintenance business, several customers may owe similar amounts for different account periods. A receipt alone may not resolve which obligation was paid.

This distinction should shape the collection workflow. Avoid choosing a product only because its number is familiar to customers. Ask how the business will recognise an incomplete payment, distinguish two identical amounts and investigate an unexpected reference at the end of the day.

Understand the documented distinction

Safaricom’s Business Hub describes Buy Goods as a collection service for merchants receiving payment for goods and services. It describes Paybill as a cash-collection service in which a business number and an account identifier can help identify the payment. The Hub supports applications for both.

The practical distinction is how the customer’s payment connects with the business record. Where account identification is important, decide exactly what customers should enter and how staff will handle a missing or incorrect identifier. Where purchases are settled at a counter, decide how the person serving the customer checks the actual receipt before completing the sale.

Build a reference convention people can follow

An account reference should be understandable to the customer and usable by the person reconciling receipts. Consider whether it identifies a customer, an invoice or a service period. Document the format and provide it consistently in the invoice and payment instructions.

For example, a fictional service provider might maintain a customer identifier separately from the month being paid. That is a proposed bookkeeping design, not a claim about a mandatory Safaricom reference format. Test your intended approach against the actual product and reporting tools before relying on automated matching. Do not place unnecessary personal information into a reference that may be visible to others.

Separate a receipt from a reconciliation decision

A customer message saying “paid” is the start of a check, not the entire check. Match the amount, transaction record and relevant reference with the sale or account. If the expected record is missing, use the authorised business channel to investigate rather than asking the customer to hand over their phone or reveal a PIN.

Create a simple exception list for duplicate-looking payments, incorrect references, disputed receipts and unmatched items. Each entry needs an owner and next action. That prevents a busy cashier or administrator from settling an uncertainty by memory, particularly when several staff members handle the same customer account.

Explore reporting before adding automation

The Business Hub describes transaction visibility and account management, and its Bill Manager offering includes invoicing, collections, receipts and reconciliation. Those descriptions make reporting worth examining during evaluation. They do not establish that a particular feature is enabled on an unapproved account.

Before commissioning an integration, identify what can be exported or reconciled through the authorised tools. If a developer is involved, keep the merchant-administration role distinct from software access and use the current Daraja documentation for the actual integration. Do not share account credentials in a project group or treat a developer demonstration as production approval.

Review the complete operating arrangement

Ask Safaricom which documents apply to your organisation, how authorised operators are managed, what transaction and withdrawal charges apply and which support process handles an exception. Do not extrapolate one business’s tariff or approval experience to your own application.

A short operational pilot should show who checks receipts, how the books are updated, who can initiate business payments and how access is removed when a staff member leaves. Retain an audit trail appropriate to the business without collecting more customer data than needed.

ITBank’s conclusion

Choose the collection method around the payment purpose and identification problem. A well-managed Till or Paybill is part of a wider system: clear customer instructions, controlled access, a dependable receipt check and reconciliation that can be explained. That system matters more than putting a payment number on a poster.