Billing faults are the most expensive faults an ISP has, because every one of them is either money you did not collect or a customer who is offline while holding a payment receipt. This guide covers the M-Pesa and billing problems African ISPs hit most often, how to resolve each when it happens, and the structural change that stops it happening again.
The payment does not reflect on the customer's account
The customer has an M-Pesa confirmation SMS and your system shows nothing. Work through the chain.
- •Was the callback delivered? For Paybill and Till collections, Safaricom posts the transaction to your registered C2B confirmation URL. If that URL is unregistered, unreachable, behind an expired certificate or returning an error, the payment exists at Safaricom and nowhere else.
- •Did the account number match? Customers mistype account numbers constantly, or use a name, a phone number, or the account of the neighbour who set up their WiFi. The payment arrives unmatched and sits in limbo.
- •Is the payment matched but not applied? Some systems record the payment but only apply it on the next billing run, which leaves the customer disconnected in the meantime.
The fix that lasts: automatic matching that does not depend on the customer typing correctly. Iterative Billing normalises the payer's phone number, matches on multiple identifiers rather than the account reference alone, applies the payment immediately and reactivates the subscriber, and keeps an audit trail of every match.
The STK push never arrives on the phone
Check the number format first, Daraja expects the international format, and a number saved locally as 07 must be normalised before it is sent. Then check that the customer is not on a call, has network, and does not have an old prompt still open on screen. If STK requests are failing across the board rather than for one customer, look at your Daraja credentials, the shortcode configuration and the callback URL, and read the error the API actually returned instead of retrying blindly.
Payments made to the wrong account number
This is unavoidable at scale, so the system must be built for it. What you need is a queue of unmatched payments an operator can resolve in seconds, with the payer's number, amount and timestamp visible, and a one-click assignment to the right subscriber that also triggers activation. What you must avoid is a spreadsheet and a WhatsApp thread.
Duplicate payments
A customer pays twice, or a callback is delivered twice. Without idempotency, the second event either double-credits the account or breaks the reconciliation. Payments must be recorded against a unique transaction identifier so a repeated callback is recognised and ignored, and genuine double payments should land as account credit rather than vanishing. Iterative Billing handles payment writes idempotently and keeps a full balance audit trail, so a repeated callback can never quietly change a balance.
The customer paid and is still disconnected
The payment reconciled but nothing told the network. On a manual setup, someone has to re-enable a PPPoE secret or release a hotspot session, and at 9pm nobody does. This is why payment and provisioning must be a single automated loop: confirmed payment, account credited, RADIUS session restored, all in seconds. The network-side symptoms are covered in the PPPoE and hotspot troubleshooting guides.
The month's numbers do not reconcile
If your M-Pesa statement and your billing report disagree, the usual culprits are unmatched payments never resolved, refunds and reversals recorded on one side only, payments applied to the wrong period, and manual adjustments with no audit trail. A billing system with proper double-entry accounting, wallet statements per subscriber and a full transaction history makes this a five-minute check rather than a weekend.
Invoices and receipts that do not satisfy the taxman
In Kenya, KRA eTIMS electronic invoicing applies broadly to businesses, and receipts that are not compliant create real risk. Generating compliant fiscal records automatically at the moment of payment is far safer than reconstructing them later. Iterative Billing produces eTIMS-aligned invoicing as part of the billing run.
Customers say they were never reminded
If reminders go out manually, they go out inconsistently. Automated reminders before expiry, on expiry and after suspension are the cheapest collections improvement available to any ISP, and they must ride on delivery routes that actually work in your country. Iterative Billing sends over twelve SMS gateways including TalkSasa, AdvantaSMS, Celcom Africa, Hostpinnacle, Bytewave, Zettatel and mNotify, plus WhatsApp, with a WhatsApp AI assistant that answers customers directly.
The structural fix
Every problem in this guide comes from the same root: payment, billing and network are three systems held together by a person. When one automated platform owns all three, an unmatched payment becomes a queue item instead of a lost customer, a duplicate callback becomes a no-op instead of a wrong balance, and a confirmed payment becomes an open session instead of a phone call.
Iterative Billing collects across M-Pesa Paybill, Till and STK Push, Co-op Bank, KopoKopo, SasaPay, Pesapal, Flutterwave, Paystack, MTN MoMo and WaafiPay, matches automatically, and provisions instantly through built-in RADIUS. Adding a MikroTik takes at most 8 minutes, fully automated.
Apply for access at https://billing.iterativebilling.com/register, or read the M-Pesa billing integration page for how the payment flow is wired. Be Wisp B.
Frequently asked questions
- Why is an M-Pesa payment not reflecting on my customer's account?
- Check three things in order. First, whether the C2B confirmation callback was delivered at all: if your registered URL is unreachable, unregistered or returning errors, the payment exists at Safaricom and nowhere else. Second, whether the account number matched, since customers frequently mistype it or use a phone number or another person's account. Third, whether the payment was matched but not applied until the next billing run, which leaves the subscriber offline in the meantime.
- Why is the M-Pesa STK push not arriving on the customer's phone?
- Most often the phone number format: Daraja expects international format, so a number stored locally beginning with a zero must be normalised before the request is sent. Also check that the customer is not on a call, has network coverage, and does not have a previous prompt still open. If STK requests fail for everyone rather than one customer, check your Daraja credentials, shortcode configuration and callback URL, and read the error the API returned rather than retrying.
- How should an ISP handle duplicate M-Pesa payments?
- Payments must be written idempotently against a unique transaction identifier, so a repeated callback is recognised and ignored rather than double-crediting the account or breaking reconciliation. Genuine double payments by a customer should land as account credit rather than disappearing, and every write should leave an audit trail so a balance can never change silently.
- What do I do when a customer pays to the wrong account number?
- At scale this is unavoidable, so the system needs to absorb it: an unmatched-payments queue showing payer number, amount and timestamp, with one-click assignment to the correct subscriber that also triggers activation. Automatic matching that normalises phone numbers and matches on several identifiers rather than the typed account reference alone prevents most cases from reaching the queue at all.