When prepaid reload fails on a busy Friday

Prepaid reload is not evenly spread through the week. In the Malaysian apps we sit with, Friday after 6 p.m. is when balances run down before a weekend of calls and short video, and when dealer counters are already full. The customer app is supposed to take that pressure. Measurement often does not.

Three records of the same tap

A completed reload usually leaves three traces: a confirmation screen, an SMS from the billing side, and an event with a name like reload_success. On a quiet Tuesday those three agree. On a Friday they often do not. The screen may show a spinner long enough for the person to tap again. The SMS may arrive while the app still says “processing.” The event may fire on the first tap, the second tap, or not at all if the activity was killed.

When commercial reads a weekly count that only knows the event, they under-count completed reloads and over-count “abandoned” ones. When product only watches the spinner, they think the journey is slow but honest. The review has to put the three records on one page for the same test accounts.

Devices that still matter

Product rooms test on recent flagship phones. Johor and East Coast stores still hand out Android models with less memory, older WebView, and aggressive battery savers. We walk reload on those. A WebView checkout that survives a Pixel can lose the success callback on a two-year-old mid-ranger after the screen locks in a queue.

If your event catalogue has no app_backgrounded or equivalent during checkout, you cannot tell a killed session from a person who walked away. That gap belongs in the written review, not in a later “phase two.”

What we ask teams to change first

The smallest honest fix is usually not a new funnel chart. It is a single success definition: balance increased, or billing confirmed, before reload_success is allowed to fire. Until that definition exists, Friday arguments will continue, and the store reviews will keep mentioning “duit gone, credit never came.”