Moving M-Pesa payment notifications to a new system

How a Kenyan business moves its paybill or till payment notifications from an old system to a new one without losing track of customer payments.

By Achekam · 11 October 2026 · 5 min read · For Running a business businesses in Kenya

Your customers do not care which accounting system you use. They keep paying the same paybill or till number they always have. What changes when you move systems is where Safaricom sends the message that says "this customer just paid". If that message still goes to the old system, the new books never hear about the payment, and someone ends up matching M-Pesa statements by hand.

Moving those notifications is not hard, but it is not a setting you can flip either. Safaricom treats the production registration as a one-off, and undoing it takes paperwork and people with the right roles. This article sets out what Safaricom says about the process and gives you a cut-over plan that keeps payments visible throughout.

What the registered addresses do

Safaricom's Customer to Business (C2B) service, also called the Register URL API, is how a merchant receives notifications of successful payments to its paybill or till. The merchant registers two web addresses: a validation URL and a confirmation URL. When a customer pays, Safaricom calls those addresses with the details of the payment.

Whatever system sits behind those two addresses is the one that learns about your payments. Your new accounting system can be fully set up and still see nothing, because Safaricom is still talking to the old one.

Production registration happens once

This is the rule that catches businesses out. Safaricom says that registering C2B URLs in production is a one-time call. To change them, the existing URLs must be deleted and new ones registered. In the sandbox, Safaricom's test environment, URLs can be re-registered as often as you like, so a developer who only ever worked in the sandbox may not expect the live short code to behave differently.

Safaricom's C2B page says the deletion can be done on the URL management tab under self-service, or by e-mailing apisupport@safaricom.co.ke. Its Daraja FAQ describes a stamped request letter instead. Either way, allow time for it, and do not schedule the switch for your busiest trading day.

There is also a people step on your side. Changing the registration needs two operators in the M-Pesa organisation portal, so check now who holds those roles and whether they are still with the business. Our article on M-Pesa org portal roles covers who should hold them.

Rules the new addresses must follow

Safaricom is strict about what it will accept as a production address. On its Customer to Business API page, Safaricom sets out how the validation and confirmation URLs are registered and the rules they must meet. In summary, production URLs must:

• use HTTPS (the sandbox accepts plain HTTP, production does not);
• be publicly reachable from the internet;
• avoid words such as M-PESA, Safaricom, exe, exec, cmd, SQL or query anywhere in the address;
• not use public URL testers such as ngrok, mockbin or requestbin.

That last point matters if a developer tested your integration through a tunnelling tool. An address that worked in testing can be refused when you go live.

One app per short code

Safaricom says an app is revoked if it duplicates the short code of another approved app. When a business changes systems, it is common for the old provider's app and a new app to both be pointed at the same paybill. Before anyone creates a new Daraja app for your short code, find out which app currently holds it and agree with the old provider how it will be retired.

If you are setting up M-Pesa with Achekam for the first time rather than moving from another system, the Go-Live steps are covered in taking M-Pesa live.

What Achekam does once it receives the notifications

Achekam can register a Kenyan business's paybill or till so that its payment notifications come to the business's own books. From then on, a payment where the customer quotes an open shilling invoice number as the account number is receipted against that invoice automatically. Any other payment, for example one where the customer typed their name or a phone number, waits in a list for a person to allocate. Nothing is guessed.

The receipt is not a note on the side. It is recorded against the invoice in the ledger, debiting the M-Pesa clearing account and crediting trade receivables, and the invoice shows as paid or part-paid. Because the invoice was posted to the books when it was issued, the customer's balance, the invoice and the money all stay in one place.

Safaricom does not sign these notifications. Achekam protects them instead with a secret address and a check that the message came from Safaricom's own source addresses.

Remember the rule above: production registration is one-time per short code. If the short code is still registered to the old system, the old URLs have to be deleted first, and changing an existing registration needs those two operators in the M-Pesa organisation portal.

A cut-over plan

Treat the switch as a small project with a named owner and a date.

1. Pick the date. Choose a quiet trading day, ideally early in a month so the overlap falls in one period.
2. Confirm the operators. Make sure the two people who will act in the M-Pesa organisation portal have working logins and know the plan.
3. Settle the app question. Agree with the old provider which Daraja app holds your short code and how it will be retired, so a duplicate app is not revoked.
4. Request the deletion. Use the self-service URL management tab, or contact Safaricom as its pages describe, and record when the old URLs were removed.
5. Register from Achekam the same day. The sooner the new registration follows the deletion, the shorter the gap.
6. Test with real money. Pay a small invoice from your own phone quoting its invoice number, and check that it is receipted. Then make one payment with a wrong account number and check that it lands in the list waiting for allocation.
7. Close the gap by hand. Any payment made between deletion and re-registration had no address to be notified to. Pull those payments from your M-Pesa statement for that window and record them against the right invoices.
8. Keep the old records. Export what the old system received before you lose access to it.

After the switch

For the first few weeks, look at the allocation list daily. A long list usually means customers are not quoting invoice numbers, which is worth fixing on the invoice wording itself. If you are also deciding whether to let your system approve or reject payments before they complete, read whether to switch on C2B validation before you make that request to Safaricom, since it changes what happens when your system cannot answer.

Start by finding out who your two portal operators are. Everything else in the move can be scheduled around them.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.