Reconciling Mobile Money Payments via Webhooks in Anglophone Africa 2026

The verdict in three sentences

Without reconciliation, 2 to 5% of orders stay pending because a webhook was never received on an unstable network, blurring your accounting and frustrating customers. The fix: a transaction ledger with status, amount and operator reference, paired with a catch-up cron that queries the API every 15 minutes. This guide details the architecture of reliable reconciliation for Paystack, M-Pesa and Flutterwave, with a comparison of transaction identifiers.

Why reconciliation is essential

A webhook is never 100% guaranteed. On mobile networks across Anglophone Africa a notification can be lost, duplicated or delayed. If you rely on the webhook alone, a fraction of your paid orders will stay stuck as "pending" even though the customer's account was debited. Reconciliation cross-checks three sources: your internal ledger, the webhook payload and a direct query to the operator's API.

On a 300-order store with an average basket of NGN 25,000 equivalent, 3% stuck orders means 9 orders, or NGN 225,000 of cash in limbo each month.

Ledger and cron architecture

The core of the system is a transactions table that stores, per order: the internal reference, the operator reference, the expected amount, the received amount, the status (pending, success, failed, mismatch) and a timestamp. A cron queries every 15 minutes the transactions left pending beyond 3 minutes and updates their status via the API. Each operator exposes a different transaction identifier to map.

The rule: never fulfill on pending, fulfill only on success confirmed by at least two concordant sources (webhook + API), and raise an alert on any amount mismatch.

Mini case study

Grace runs a cosmetics store in Lagos with 400 orders a month split between Paystack (60%) and Flutterwave (40%). Before reconciliation, 4% of orders stayed pending, i.e. 16 orders, on an average basket of NGN 20,000, or NGN 320,000 of murky cash flow monthly. After adding the ledger + 15-minute cron, the rate drops to 0.4%, under 2 orders. She recovers about 14 x 20,000 = NGN 280,000 of accounting visibility each month, and her bank reconciliation goes from 3 hours to 20 minutes.

FAQ

Isn't a webhook enough on its own? No. On unstable networks, 2 to 5% of webhooks are lost or duplicated. API reconciliation is the only way to reach reliability close to 100%.

How often should the catch-up cron run? Every 15 minutes is a good balance between freshness and API load. For urgent orders, a first poll at 30 seconds completes the setup.

How do I handle an amount mismatch? Mark the transaction mismatch, block delivery and alert a human operator. It is often a partial payment or an entry error to arbitrate manually.

Which identifier is the reconciliation key? The operator reference (Paystack id, MpesaReceiptNumber, tx_ref, etc.) paired with your internal reference. Always store both in the database.

Become a Kolonell referral partner. Know merchants losing payments for lack of reconciliation? Refer them and earn a commission: 12% on an e-commerce project, 15% + 5% recurring on a showcase site, 10% on a marketplace and 8% on institutional.

Let's talk about your project. We build multi-operator reconciliation systems reliable to over 99%. WhatsApp +221 77 596 93 33.