MoneyGone,OrderNowhere
Payments · reliability
The scenario
You pay for something. Your bank sends you a confirmation. Your account balance drops. And then the app tells you the order failed, or worse, says nothing at all, just spins, or shows a generic error. Your money is gone, but there is no order, no receipt, nothing to point to. Now you have to decide: do you wait, do you contact support, do you just try to pay again and risk being charged twice?
This is one of the most anxiety-inducing failures in any transactional product, because it directly touches someone's money and leaves them with zero information.
Why it happens
Payments and orders usually live in two separate systems that talk to each other asynchronously. The payment gateway processes the transaction and reports success back to the platform, but that confirmation does not always arrive instantly, or reliably, at the order management system. If the platform is relying on the user's app to poll for a status update, and that connection drops, times out, or the response gets lost, the two systems can end up out of sync. The bank knows the money moved. The platform does not yet know that, or worse, never finds out cleanly.
This is especially common with UPI in India specifically, where the bank-side confirmation and the merchant-side confirmation are genuinely two separate technical events that are supposed to reconcile but do not always do so cleanly or quickly.
What I would build instead
- Move to webhook-based reconciliation, not polling. Instead of the app asking "did it work yet?" repeatedly, the payment gateway should push a confirmed status directly to the order system the moment it is available. This closes the gap where a successful payment can sit unmatched for an unpredictable amount of time.
- Never leave the user with silence. The moment a payment is initiated, the user should see a live status, "payment received, confirming your order," rather than a spinner or a dead screen. If reconciliation takes longer than expected, that status should update with a real timeline, not just keep spinning.
- Guarantee a specific refund SLA, and hold to it. If an order genuinely cannot be completed after a successful payment, commit to a clear window, 24 to 48 hours, and proactively notify the user when the refund is initiated and when it lands, rather than making them come ask.
- Close the loop with warmth, not just a refund. Once the refund is confirmed, a short, low-pressure message pointing the user back to the item they wanted, sometimes with a small goodwill credit for the inconvenience, turns a bad experience into one the user actually remembers as being handled well.
Why this matters, and how I would measure it
This failure mode is disproportionately damaging to trust relative to how often it happens, because it involves someone's actual money disappearing with no explanation. Fixing the visibility and speed of resolution matters as much as fixing the underlying technical sync issue.
I would track refund-related support ticket volume as the primary signal, it should drop meaningfully once users can see real-time status instead of needing to ask a human. I would also track SLA adherence directly, since a refund promise that gets broken is arguably worse than not making the promise at all.