How online subscriber payments reach the books
When a subscriber pays an invoice online, how the payment is checked and recorded against it, and what happens if the gateway's notification goes missing.
By Achekam · · 4 min read · For Telecoms businesses in South Africa, Nigeria, Kenya
A subscriber pays their monthly invoice from their phone late on a Sunday night. On Monday morning they call your support line: the account still shows the invoice as unpaid, and they want to know why they are being chased for money they have already paid. Or the opposite happens: the account shows paid twice, and nobody can say which payment is real.
Both calls come down to the same question. Between the subscriber pressing "pay" and the invoice showing as settled, what actually happens, and what can go wrong? This article follows one online payment from the pay link to your ledger, and explains how Achekam handles the notification that arrives twice and the one that never arrives.
From invoice to pay page
A business can create a payment link for an issued customer invoice, copy it or e-mail it with the invoice, and the subscriber pays on a public page that shows the business's name and branding. There is no link for a draft or a voided invoice. A link lasts 14 days by default, and an open link for the same amount is reused rather than duplicated, so sending a reminder with the same link does not create a second payment request.
For a provider that bills every subscriber at the start of the month, the order matters. Issue the month's invoices first, then create and send the links. A draft has no link to send, and a link to last month's invoice settles last month, not this one. Checking that each link belongs to the current month's invoice before it goes out saves a surprising number of support calls.
Behind the pay page sits your own payment gateway account. A workspace administrator enters the business's own gateway credentials in Settings under Payment Gateways & Checkout, and can test the connection with a real call to the gateway. Other users can see the settings but not change them. If you have not set this up yet, setting up your own payment gateway for invoices walks through it.
Verified before it is recorded
When the subscriber pays, the gateway sends a notification. Achekam does not take that notification at its word.
For Paystack, notifications are checked by their signature and the payment is re-verified with Paystack's verify service before it is recorded. You paste the webhook address into your Paystack dashboard once, during setup. Paystack's developer documentation on webhooks explains how those event notifications are received and verified. For Flutterwave, each payment is re-verified with Flutterwave before it is recorded. The amount is also checked against what the pay link asked for.
The point is simple: an invoice shows as paid because the gateway confirmed the money, not because a message claiming to be from the gateway said so.
What the books show
Once verified, the payment is recorded as a receipt against the invoice. The entry debits that gateway's clearing account and credits trade receivables. The invoice shows as paid, or as part-paid if the subscriber paid less than the full amount.
The clearing account is the important part for your accountant. The money is not in your bank yet; it is with the gateway until the next payout. The clearing account holds it in the meantime. When the gateway pays out, the payout is recorded against the same clearing account with its fees, either by hand or, for Paystack and Flutterwave, from the gateway's own payout list. After that, the clearing account holds only the payments still waiting to be paid out.
A notification that arrives twice
Gateways sometimes send the same notification more than once, for example when they did not receive an acknowledgement quickly enough. A repeated notification never pays an invoice twice. The second message finds the payment already recorded and adds nothing.
So if a subscriber's account ever shows a double payment, it is worth checking whether the subscriber actually paid twice, perhaps once by link and once by transfer. That is a refund conversation, not a system fault.
A notification that never arrives
Notifications can also go missing: a network fault, a webhook address typed wrongly, a gateway having a bad day. For M-Pesa, Paystack and Pesapal, a payment whose notification never arrived is still picked up. The server asks the provider about open payments on a schedule, and while the subscriber still has the pay page open.
For other gateways, build a simple check into your week:
- Export the gateway's list of successful payments.
- Compare it with the payments recorded against your invoices.
- Investigate any payment the gateway has and your books do not.
The Sunday-night subscriber from the start of this article is often one of these cases, and the scheduled check or your weekly comparison is what puts their account right.
What the pay link does not do
Two limits are worth knowing for a subscription business. Achekam never charges a customer automatically: there are no saved cards and no debit orders. And the overdue reminders sent by credit control carry no pay link.
For providers used to collecting by debit order, that changes the monthly routine. Each month's invoice needs its own pay link, sent with the invoice. When a subscriber falls behind, send the link again yourself rather than relying on the reminder to carry it.
Your next step
Pick last month's online payments and trace three of them from the gateway's dashboard to the invoice, the clearing account and the payout. If all three line up, the process is working. If one does not, you have found the gap before a subscriber did. To be sure the invoice and its link reached the subscriber in the first place, see knowing a subscriber actually got the invoice.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
