2 June 2025 · Journal
The quiet cost of silent failures in checkout flows
When the UI says nothing and the session still “completes,” quality programmes go blind. Checkout is where this happens most often.
A silent failure is a session in which the product does not tell the person that something went wrong, yet the backend did not finish the job. In Session Quality Analytics it is worse than a crash: crashes usually emit an event. Silence looks like success until support tickets arrive two days later.
The thank-you page that lied
A Bangkok e-commerce partner fired checkout_complete when the thank-you view rendered, not when the payment switch confirmed. On a bad afternoon the switch queued. The UI was optimistic. Completion rates looked excellent. Fulfilment did not. The quality score, which trusted the front-end event, congratulated the squad.
OTP screens with no timeout copy
Several wallet flows we reviewed in the Field Lab let the OTP wait expire without a message. People retried, created duplicate transfers, or left. Replay looked calm: few rage clicks, modest duration. Transcripts from Voice of Session were not calm. Respect and completion both failed; reliability events were empty.
What to instrument
Bind completion to the authoritative state, not the view. Add explicit timeout, retry, and duplicate-attempt events. If the switch can be pending, the UI must say pending, and the score must treat pending-then-fail as incomplete. Latency Budgets for Interactive Products covers the timing side; this note is about the semantic side.
A limitation we teach
You cannot always get switch-level confirmation into the product warehouse. When you cannot, do not invent a proxy that looks like confirmation. Publish a known gap. Silent failures you cannot see should appear in the charter as an exclusion, not as implied success.