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 provider reports the result
The payment provider handles the payment and later sends the result to the connected system. The software checks that result, matches it to the original transaction and records it before updating the booking, order, vote or account.
A stable transaction reference and a record of each provider update help prevent the same result 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.