Stopping reused M-Pesa messages at the bar
How Kenyan event cashiers stop customers paying with an old or forged M-Pesa message, by matching each code once at the till or sending a prompt.
By Achekam · · 4 min read · For Events businesses in Kenya
It is the second set at an outdoor concert in Nairobi, and the bar is three deep. A customer holds up a phone showing an M-Pesa confirmation, takes two beers and is gone before the cashier has read the message properly. Next morning, the M-Pesa statement shows no such payment. The message was yesterday's, or someone else's, or typed to look like the real thing.
The fix is not sharper eyes. It is a till that refuses to accept a message as proof and checks the payment itself.
How the trick works
A confirmation SMS proves only that a message exists on a phone. It can be:
- Old. A genuine message from an earlier payment, perhaps to your own bar on a previous night.
- Borrowed. A friend's genuine message, forwarded or shown on their phone.
- For someone else. A real payment to a different business, with the name and amount glossed over.
- Made up. Text written to look like a confirmation, sent from an ordinary number.
At a crowded bar, a cashier glancing at a screen cannot tell these apart. The payment has to be checked against what Safaricom actually reported to your business, not against what the customer is showing.
Typing the M-Pesa code at the till
When a customer pays your paybill or till number from their own phone, Achekam's till lets the cashier claim that payment by its M-Pesa code. The cashier types the code from the confirmation into the sale, and the server looks for a payment with that code among the ones reported for your business.
This changes the cashier's job from judging a message to typing a short code. If the server finds the payment, it is attached to the sale. If it does not, the sale cannot be completed with that payment, because the server refuses any till sale that is not paid in full. The customer either pays properly or does not get the drinks.
Each payment matches once only
The server matches an M-Pesa payment to a sale once only. That single rule closes most of the tricks above:
| The customer shows | What happens when the code is typed |
|---|---|
| An old message from a payment already used at your bar | The payment is already matched to an earlier sale, so it cannot pay this one |
| A message for a payment to another business | There is no such payment reported for your business to match |
| A made-up message | The code matches nothing |
| A genuine new payment | It is matched and the sale completes |
Cashiers should still look at the amount on screen before handing anything over, especially when a customer paid "in advance" while queuing and the round has grown since.
Prompts to the customer's phone are safer still
The cleanest way to avoid message tricks is not to rely on a message at all. On a shilling till the cashier can send an M-Pesa payment prompt straight to the customer's phone. The customer enters their PIN on their own handset, and the payment is recorded on the sale once it comes through. There is nothing to show, forward or forge.
Amounts are rounded to whole shillings by your rounding rule. By default the till rounds up to the whole shilling, and you can set it to round down or to the nearest shilling instead; the difference is recorded on the sale. Decide the rule before the event, so cashiers are not explaining rounding to customers at the bar.
A simple rule for bar staff: send the prompt first; accept a code only when the customer has already paid from their phone.
Registering the paybill so codes can be matched
Matching by code works only after your paybill or till is registered for payment notifications. Without that registration, the server never hears about payments made from customers' phones, so there is nothing for a typed code to find.
Getting there takes some set-up with Safaricom:
- Complete Safaricom's Go-Live for your short code.
- Enter your own production short code, passkey and Daraja keys in Achekam. Safaricom e-mails the production passkey after Go-Live.
- Register the short code so payments are reported to Achekam. Production URL registration is a one-time step per short code at Safaricom, and changing it later needs two operators in the M-Pesa organisation portal.
Safaricom's developer documentation on Customer to Business (C2B) payments explains how validation and confirmation addresses are registered for paybill and till payments and what the go-live steps involve. Safaricom does not sign these notifications; Achekam protects them with a secret address and a check of Safaricom's source addresses.
After the event: payments nobody claimed
Customers mistype things, and so do cashiers. A genuine payment that was never matched to a sale does not disappear. Payments that do not quote one of your open invoice numbers wait in a list for a person to allocate. Go through that list after the event with the Z reports beside you. A payment with no sale behind it may be a customer who paid and walked off without waiting, or a cashier who completed the sale with cash by mistake.
Brief every cashier before the gates open: prompt first, type the code if they already paid, never hand over drinks against a message. For the full set-up, see taking M-Pesa live, and for how the same matching works at a front desk rather than a bar, see M-Pesa at reception.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
