Abandoned Payments and How to Recover Them
The customer paid. The money left their wallet. But your system never marked the order as complete, and your dashboard shows it as pending or failed. Somewhere between the Khalti or eSewa success screen and your own confirmation page, the thread snapped. This is the "paid but never returned" problem, and it is quietly one of the most costly reconciliation gaps for Nepali online businesses - because it is money you actually earned that you never recorded.
This article explains why redirects fail, why a redirect is not a confirmation, and how to recover the payments that fall through the crack.
The gap between paying and returning
Here is the flow every wallet checkout follows. Your site sends the customer to the gateway. The customer authorises the payment. The gateway captures the money. Then the gateway redirects the customer's browser back to your site, carrying a signal that the payment succeeded, so your server can mark the order paid.
That final step - the redirect back - is the fragile one. It depends on the customer's browser actually completing the journey home. And browsers, on Nepali mobile networks, drop that journey constantly:
- The customer closes the tab the moment they see the success screen, satisfied, never waiting for the redirect.
- The mobile connection stalls between the wallet app and your site during the hop back.
- The customer switches apps, the browser tab is killed by the OS, and the return never fires.
- A deep-link back from the wallet app to your site fails silently on a particular phone.
In every one of these, the money was captured at the gateway - but your server never got the return signal, so your order sits pending forever. The customer is charged and confused; you are unpaid on paper while holding their money in your wallet.
A redirect is not a confirmation. The customer's browser arriving back at your site is a convenience, not a source of truth. If you mark orders paid only when the browser returns, every dropped redirect becomes a paid order you recorded as failed - and a customer who was charged for nothing they can see.
Why redirect is not confirmation
The core mistake is treating the browser redirect as the event that means "paid." It is not. The redirect is just the gateway telling the browser to carry good news home. The actual source of truth is the gateway's own record of the capture, which exists whether or not the browser ever makes it back.
There are two reliable channels to that truth, and both are independent of the redirect:
- Server-to-server callbacks. The gateway calls your server directly to announce a capture, browser or no browser. This does not depend on the customer's device completing anything.
- Status polling / lookup. You ask the gateway, "what is the status of this transaction?" and it tells you authoritatively. Both Khalti and eSewa document lookup endpoints for exactly this - verifying a transaction's real status rather than trusting the redirect.
If you confirm payment through either of these, a dropped redirect stops mattering. The customer closing the tab is now harmless: your server learned about the capture from the gateway directly.
Detecting the payments you missed
Even with callbacks in place, some will slip - a callback your server missed during a deploy, a network blip on both channels at once. So you need a reconciliation-level detector that catches what the checkout flow missed:
- List the gateway's captured transactions for the period, straight from the gateway report.
- Match each against your orders. Every capture should map to an order marked paid.
- The unmatched captures are your recovery list - payments the gateway confirms it took that your system never recorded as complete.
- For each, resolve the order. If the goods were never sent because the order looked unpaid, ship them or arrange fulfilment. If the customer never got what they paid for, that is a service failure to fix fast.
This detector is the same mechanic that catches duplicate and double payments - both come from comparing gateway captures against your orders. An unmatched capture is either an abandoned-return payment you owe fulfilment on, or a duplicate you may owe a refund on. The comparison surfaces both.
Run the unmatched-capture check daily, not monthly. A payment recovered the next morning is a happy customer who gets their order a day late. The same payment found at month-end is a customer who gave up, disputed the charge, or never came back.
Recovering gracefully
Recovery is not only bookkeeping - it is a customer moment. When you find a captured payment with an incomplete order:
- Confirm the capture is real at the gateway before acting, so you do not chase a payment that actually failed.
- Complete the order - fulfil, ship, or activate whatever the customer paid for.
- Reach out. A short message - "we saw your payment came through, your order is on its way" - turns a frustrating experience into a reassuring one. The customer was already worried they lost money.
- Reconcile the payment into the settlement it belongs to, so your books finally show the money you actually earned.
Handled well, an abandoned payment recovered becomes a trust-building interaction. Handled poorly - or not at all - it becomes a chargeback, a bad review, or a customer who never returns.
Why this belongs in reconciliation
Abandoned payments are invisible to anyone looking only at their order system, because by definition the order looks unpaid. They only surface when you compare your orders against what the gateway actually captured - which is exactly what reconciliation does. This is why the "paid but never returned" problem is not a checkout bug to fix once, but an ongoing reconciliation control. The wider discipline is covered in what is payment reconciliation.
RakamHQ makes the recovery list a natural output of the daily close: it matches every gateway capture against your orders and surfaces the captures with no completed order, so payments that fell through a dropped redirect show up the next morning as a short list to act on. Prove where every rupee went, and the rupees that never made it home stop staying lost.
Frequently asked
Why does an order stay pending after the customer paid?
The gateway captured the money but the redirect back to your site never completed - the customer closed the tab, the mobile connection stalled, or the browser was killed. Your server never got the return signal, so the order sits unpaid on paper.
Why is a redirect not a payment confirmation?
The redirect just tells the customer's browser to carry good news home; it depends on the device completing the journey. The real source of truth is the gateway's own record of the capture, reachable through server callbacks or a status lookup.
How do I recover abandoned payments?
List the gateway's captured transactions for the period and match each against your orders. The unmatched captures are your recovery list - payments the gateway confirms it took that your system never recorded as complete.
How often should I check for abandoned payments?
Daily. A payment recovered the next morning means a happy customer who gets their order a day late. The same payment found at month-end is a customer who gave up, disputed the charge, or never returned.
Keep reading
Get your free reconciliation.
Send us last month's eSewa report, Khalti export, bank statement and orders sheet. Within 48 hours we send back a one-page close - every payment matched, every fee computed, every settlement decomposed.
Files only · private upload link · nothing to install