The verdict in three sentences
In Uganda, collecting on two operators (MTN MoMo and Airtel Money) multiplies callback sources and thus till mismatches if reconciliation isn't centralized. Each operator has its own webhook format and retry window — up to 24 h — leaving around 2 % of transactions in ambiguous status. A daily status pull brings the mismatch under 0.2 %: normalize webhooks, reconcile each night, alert above 0.5 %.
Where mismatches come from
The problem isn't the fee rate but the reliability of the confirmation signal. A webhook can arrive twice, late, or never. Here are the typical causes and their 2026 order of magnitude.
| Mismatch cause | Estimated frequency | Till impact |
|---|---|---|
| Webhook never received | ~ 1 % | paid transaction not recorded |
| Duplicate webhook | ~ 0.5 % | double-counting risk |
| Late retry (up to 24 h) | ~ 0.5 % | temporary ambiguous status |
| Format divergence MTN vs Airtel | permanent | parsing errors |
| Client-side timeout | variable | orphan order |
Combined, these produce around 2 % of transactions in uncertain status — enough to distort a daily till if nothing is reconciled.
The reconciliation method
The fix rests on three principles: a single transaction model, a nightly status pull, and an alert threshold. Here is the expected effect.
| Practice | Till mismatch before | Mismatch after |
|---|---|---|
| Raw webhooks, no reconciliation | ~ 2 % | — |
| Single-format normalization | ~ 1.2 % | — |
| Daily status pull | — | ~ 0.3 % |
| Pull + anti-duplicate idempotency | — | ~ 0.2 % |
| Automatic alert > 0.5 % | — | immediate detection |
The nightly status pull is the keystone: it recovers lost webhooks and resolves ambiguous statuses by querying the operator directly.
Mini case study
David runs an online shop in Kampala collecting on MTN MoMo and Airtel Money, about 900 transactions a month. Before reconciliation, he saw a monthly till mismatch of around 2 %, nearly 18 disputed transactions — refunds claimed, orders paid but unfulfilled. By setting up webhook normalization, a nightly status pull and an anti-duplicate idempotency key, his mismatch drops to 0.2 %, fewer than 2 ambiguous transactions a month. He saves several hours of manual reconciliation and avoids customer disputes.
Need a professional website?
Kolonell builds websites that attract clients, optimized for the Sénégalese market. Free quote in 2 minutes.
FAQ
Why not rely on webhooks alone?
Because a webhook can be lost, arrive twice, or come 24 h late. The webhook is a fast but not 100 % reliable signal: confirm it with a status query before considering a transaction closed.
What is a status pull?
It's a scheduled query where your system asks the operator for the real state of each pending transaction. Run each night, it recovers missing webhooks and resolves ambiguous cases without human intervention.
How do I avoid double-counting?
By assigning a unique idempotency key per transaction: if two webhooks carry the same key, only the first is processed. This neutralizes duplicates, a common cause of positive till mismatch.
What alert threshold should I set?
A reasonable order of magnitude is 0.5 % daily mismatch: below it is normal noise; above it, an automatic alert should warn your team for same-day investigation.
Do I need a common data model for both operators?
Yes: normalizing MTN and Airtel into a single format (amount, reference, status, timestamp) simplifies everything else — parsing, reconciliation, reporting — and removes errors tied to divergent formats.
Let's talk about your project. We centralize MTN MoMo and Airtel Money into a single reconciliation with nightly status pull and mismatch alerts. WhatsApp +221 77 596 93 33.
Mohamed Bah
Fondateur, Kolonell
Passionate about digital and entrepreneurship in Africa, Mohamed has been helping Sénégalese businesses with their digital transformation since 2020. Founder of Kolonell, he believes every SME deserves a professional and accessible online présence.
