A request is not a payment
When a system sends a Mobile Money prompt, it has only asked the customer to pay. The customer may decline, abandon the request, enter the wrong PIN or complete it after a delay.
The booking, order or vote should not be treated as paid merely because the request was created.
The callback changes the business record
The payment provider later sends a server-to-server update. The system verifies that update, matches it to the original transaction and records the result before it fulfils the service.
A stable transaction reference and a record of each provider event help prevent the same callback from allocating two seats, issuing two vouchers or applying the same payment twice.
Tell the customer only what is known
The screen and SMS should distinguish between a request being sent, a payment being processed and a payment being confirmed. Clear wording reduces false reassurance and gives staff a better starting point when a customer asks for help.
- Payment request sent
- Payment pending
- Payment confirmed
- Payment failed or expired
- Payment needs staff review
Make exceptions visible
Some cases cannot be resolved safely by guessing. A good operating portal shows unmatched payments, delayed callbacks and failed messages for staff review while keeping a complete record of what changed.