Wiring up a Mobile Money payment takes a few days. Making it hold up in production takes much longer, because most of the work is about what happens when the payment does not go normally.
The payment is not instant
Unlike a bank card, a Mobile Money transaction goes through a device the user has to handle. Between the moment your store requests payment and the moment the operator confirms, a few seconds may pass — or several minutes if the customer is looking for their phone. A store that treats the absence of an immediate response as a failure cancels orders that were about to succeed.
Partial failure is the rule
The customer is debited but the notification never arrives; the notification arrives twice; the customer retries and pays twice. All three will happen. They are handled with an idempotency key on every attempt, an explicit order state and a daily reconciliation against the operator’s statements.
A payment integration is judged on what it does when it fails, not when it succeeds.
Reconcile, every day
Reconciliation is not an accounting luxury, it is the only way to know what actually happened. Every night we match the operator’s transactions against the store’s orders, then flag the differences. Without it, errors surface at month end, when nobody remembers the context.
What to tell the customer
Show the payment state in plain language, with a message that says what to do. “Payment awaiting confirmation, do not retry” prevents half of the double payments on its own.
Budget for it in the quote
Count the time to handle edge cases in the initial estimate, not as a fix after launch. That is the part of the work that decides whether your store is reliable.