M-Pesa C2B validation: should you switch it on
What M-Pesa C2B confirmation and validation do, what Safaricom requires for validation, and how to decide whether your Kenyan business needs it.
By Achekam · · 5 min read · For Running a business businesses in Kenya
A customer pays your paybill and types "JOHN" as the account number. The money has arrived, but nobody in accounts can tell which invoice it belongs to. Multiply that by a busy month and you have a pile of unidentified receipts and a team phoning customers to ask what they paid for.
There are two ways to deal with it. You can stop the payment at the door, by having your system check the account number before M-Pesa completes the transaction. Or you can let every payment through and sort out the unclear ones afterwards. Safaricom calls the first approach validation and the second confirmation. This article explains both, what switching validation on involves, and how to decide.
Confirmation and validation compared
Safaricom's Customer to Business (C2B) service lets a merchant receive notifications of payments to its paybill or till by registering two addresses with Safaricom: a validation URL and a confirmation URL.
| Confirmation | Validation | |
|---|---|---|
| When Safaricom calls you | After the payment has gone through | Before the payment completes |
| What your system does | Records the payment | Says yes or no |
| Can it stop a payment? | No | Yes |
| Switched on by default? | Used with every registration | No, you must ask Safaricom |
Confirmation is the message every business relies on. Validation is an extra gate in front of it.
Validation is off until you ask for it
Safaricom's Customer to Business API page explains how the two URLs are registered, how validation is activated and which replies M-Pesa expects. It says external validation is optional and disabled by default. To turn it on, a business e-mails apisupport@safaricom.co.ke or M-pesabusiness@safaricom.co.ke. Safaricom's Daraja FAQ says activating external validation takes 24 working hours, and it counts working hours as Monday to Friday, 8am to 5pm. A request sent late on a Friday will not be done over the weekend.
Once validation is on, your system has very little time to answer. Safaricom says the merchant's system must respond to a validation request within about 8 seconds. Every payment to your short code then depends on your server being up, reachable and quick enough to look up the account number and reply.
ResponseType: what happens when your system cannot answer
Servers go down, connections drop, and deployments happen at awkward times. Safaricom lets you choose in advance what M-Pesa does if it cannot reach your validation URL, through a setting called ResponseType:
- "Completed" means M-Pesa completes the transaction automatically. Customers can still pay while your system is unreachable, but those payments skip your check.
- "Cancelled" means M-Pesa cancels the transaction. Nothing gets through unchecked, but customers are turned away whenever your system is slow or offline.
Safaricom says these words must be written in sentence case and spelled correctly. A typing mistake here is not a small thing: it decides whether customers can pay you during an outage.
For most businesses, "Completed" is the safer choice, because a payment that skips a check can still be matched later, while a customer who could not pay may simply go elsewhere.
Rejecting payments with result codes
When your system does answer, it tells M-Pesa what to do with a result code. Safaricom says a merchant accepts a payment by replying with ResultCode 0 and ResultDesc "Accepted", and rejects it with any other code. Its examples are C2B00012 for an invalid account number and C2B00013 for an invalid amount.
In practice, that means your validation logic needs reliable answers to questions such as:
- Does this account number match a real customer or invoice?
- Is the amount one we would accept, or could it be a part payment we are happy to take?
- What should happen to a customer who pays a closed invoice?
If your answers are not reliable, validation will reject good payments. That costs more than an unidentified receipt does.
How Achekam matches payments to invoices
Achekam deals with the problem from the other end, once payments have gone through, so it works with validation left off. A Kenyan business can register its paybill or till with Achekam. A payment where the customer quotes an open shilling invoice number as the account number is receipted against that invoice automatically. Any other payment, including the customer who typed "JOHN", waits in a list for a person to allocate to the right customer and invoice.
That receipt goes straight into the books. It is recorded against the invoice, debiting the M-Pesa clearing account and crediting trade receivables, and the invoice shows as paid or part-paid. There is no separate spreadsheet of M-Pesa payments to reconcile against the ledger at month end.
Keep in mind that registering URLs in production is a one-time step per short code at Safaricom, and changing a registration needs two operators in the M-Pesa organisation portal. If you are moving from another system, read moving your C2B URLs to a new system first. For the full set-up with Safaricom, see taking M-Pesa live.
When validation is worth it
Validation earns its place when a wrongly identified payment is genuinely expensive and your system can answer quickly and correctly. Ask yourself:
- Do customers pay against fixed references? If every payment should quote a known account or invoice number, rejecting unknown ones may save real follow-up work.
- Is a wrong amount a problem rather than a part payment? Some businesses only accept exact amounts; most are glad of a part payment.
- Can your system reliably answer within about 8 seconds, all day? If not, validation will turn customers away or quietly let payments through.
- Who will watch it? Someone must notice when rejections climb, because that usually means a fault, not a wave of bad payments.
If you answered "no" to the first question, validation probably adds risk without much benefit. A clear instruction on every invoice ("use the invoice number as the account number") and a daily look at the allocation list will do more.
If payments go missing altogether rather than arriving unidentified, the problem is the notification, not the account number; see M-Pesa callbacks that never arrive.
Decide on validation before you register, and write down which ResponseType you chose and why. Whoever looks after M-Pesa next will need to know.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
