M-Pesa prompts when a customer collects their car
How a Kenyan workshop sends an M-Pesa prompt for the job invoice at collection, why only whole shillings are asked for, and when the payment counts.
By Achekam · · 4 min read · For Automotive businesses in Kenya
In a Kenyan workshop, the question at collection is almost always the same: "Can I pay with M-Pesa?" The usual answer is to read out the paybill number and the account number, wait while the customer types them, and hope there is no slip of the thumb. A wrong digit means a payment the workshop cannot find, a customer who insists they have paid, and a car that either leaves unpaid or sits in the yard while everyone argues.
There is a better way. Instead of asking the customer to type anything, the workshop sends a payment prompt straight to the customer's phone, for the exact job invoice. The customer enters their PIN, and the payment is confirmed before anyone hands over the keys. This article explains how that works in Achekam and the details that catch workshops out.
Two places to send a prompt from
Achekam can send an M-Pesa prompt, an STK push, from two places, and a workshop may use both:
| Route | Use it when | What the prompt pays |
|---|---|---|
| The job invoice | The work was invoiced, for example a service or repair booked to a customer account | The shilling invoice, to your paybill or Buy Goods till |
| The till | The customer is paying for a counter sale, such as parts bought over the counter | The till sale, with the amount rounded to whole shillings |
This article concentrates on the invoice route, because that is how most service and repair work is billed.
Sending the prompt for the job invoice
When the customer arrives, the service adviser opens the job invoice and sends an M-Pesa payment prompt to the customer's phone number, to the workshop's paybill or Buy Goods till. The prompt goes through the workshop's own Daraja app with Safaricom.
The prompt appears on the customer's phone and they enter their PIN. Nothing counts yet. Achekam records the payment only after it has been confirmed with Safaricom.
Once confirmed, the payment is recorded as a receipt against the invoice. In the ledger, it debits the M-Pesa clearing account and credits trade receivables, and the invoice shows as paid, or part-paid if the amount did not cover it. The amount is checked against what was asked for, and a repeated notification never pays the same invoice twice.
At the counter, step by step
- Confirm the job invoice is issued and the customer agrees the amount.
- Ask which phone number will pay; it need not be the customer's own, for example when an employer or relative is paying.
- Send the prompt and tell the customer it is on its way.
- Wait for Achekam to show the payment as confirmed.
- Hand over the keys and the invoice, now marked paid.
Whole shillings only: the cents stay due
An invoice prompt asks for whole shillings only. If the job invoice has cents on it, those cents stay due on the invoice after the M-Pesa payment.
That small detail creates irritating balances. A customer pays the prompt, drives away, and the invoice shows a few cents outstanding for ever. The simplest fix is to price labour and parts so that invoices come to whole shillings. If that is not practical, agree with your accountant how small leftover balances should be cleared, and do it consistently.
The till works differently. On a shilling till, the amount is rounded to whole shillings by the business's rounding rule. By default Achekam rounds an M-Pesa amount up to the whole shilling; the rule can be set to round down or to the nearest shilling, and the difference is recorded on the sale.
Confirmed with Safaricom before it counts
The rule for the service desk is simple: the keys go back when Achekam shows the payment as confirmed, not when the customer says "it has gone through".
Usually that takes moments. Occasionally Safaricom's notification is delayed or never arrives. Achekam still picks those payments up, because the server asks M-Pesa about open payments on a schedule and while the pay page is open. If a customer insists they have paid and nothing shows, wait a little before sending another prompt; the payment may still appear.
One prompt a minute per phone
The same phone can be prompted once a minute. If the customer dismisses the first prompt, or their phone was locked, the adviser must wait before trying again. Telling the customer that up front saves frustration at the counter.
Before the first prompt: Go-Live
Prompts need a working connection to Safaricom in production. To take M-Pesa for real, the workshop completes Safaricom's Go-Live for its short code, then enters its own production short code, passkey and Daraja keys in Achekam. Safaricom e-mails the production passkey after Go-Live. Until that is done, prompts cannot reach customers' phones for real payments. Safaricom's Daraja documentation for M-PESA Express explains how the STK push works, from the request and callback to sandbox testing, and sets out the go-live steps for a paybill or till.
Refunds and payouts
Two follow-up tasks happen outside the prompt itself:
- Refunds. Achekam does not refund or reverse M-Pesa payments. If a customer is owed money back, the workshop refunds it in its M-Pesa org portal and records the refund in Achekam.
- Payouts. When M-Pesa money moves from the clearing account to the bank, the payout is recorded by hand against the M-Pesa clearing account with its fees, so the clearing account empties as it should.
Setting up the service desk
Make sure every customer record has the right M-Pesa number, price jobs in whole shillings where you can, and agree the release rule with the service advisers. Customers who prefer to pay by card or bank transfer can still do so; see recording card payments from the bank terminal and bank transfers at the service counter.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
