Integrating mobile money: what actually breaks

In the markets we work in, mobile money is not an alternative payment method bolted on at the end. For a large share of customers it is the only one. Treating it as a secondary option is the root of most of the failures we are called in to fix.

Confirmation is asynchronous, and that is the whole problem

A card authorisation answers in a second or two. A wallet payment asks the customer to approve a prompt on their handset, which may arrive late, may be dismissed, and may be confirmed several minutes later when your request has already timed out. If your checkout assumes a synchronous answer, it will show failures for payments that actually succeeded.

The fix is to treat the initiating request and the confirmation as separate events, and to let the order sit in a pending state that the interface explains honestly rather than hiding behind a spinner.

Providers disagree about what failure means

One provider returns an error for a timeout that later settles. Another reports success on acceptance rather than on funds moving. If you map every provider onto one internal status without reading the documentation carefully, you will eventually credit an order that was never paid.

Make every write idempotent

Retries are guaranteed — by the network, by the customer pressing the button again, by your own job runner. Every operation that moves money needs a client-generated key so a duplicate request returns the original result instead of charging twice. This single decision removes an entire category of incident.

Reconciliation is a feature, not a report

Wallet, bank and card flows settle on different schedules and in different formats. If reconciliation is a monthly spreadsheet somebody maintains by hand, it will be wrong and nobody will trust it. We build it into the system: every balance-affecting operation writes an immutable record, and settlement is checked automatically against what the provider says happened.

Design for the handset people actually have

Payment flows are used on mid-range Android devices, on congested networks, often with a second app in the foreground while the prompt is approved. If the flow cannot survive being backgrounded and resumed, it does not work — whatever it does on your desk.