Refunds and Reversals: How Merchants Should Handle Them
By PayEurasia Team · 2 October 2026 · 6 min read
Last updated 2 October 2026
The difference between refunds, reversals and returns, how each behaves on South Asian rails, and how to record them so reconciliation stays clean.
Refunds look simple from the outside: send the money back. Inside a payment operation they are one of the most common sources of reconciliation breaks, duplicate payments and customer complaints. This guide separates the three things people call refunds, explains how each behaves on the rails PayEurasia supports, and sets out the operational rules that keep refunds fast and your books accurate.
What this guide covers
- Refunds, reversals and returns
- How refunds work on each rail
- Full versus partial refunds
- Preventing duplicate refunds
- Ledger and reconciliation treatment
- Customer communication
Refunds, reversals and returns
A refund is a new, merchant-initiated payment back to the payer, referencing an original successful transaction. A reversal cancels a transaction before it settles, so no money moves at all. A return is initiated by the rail or the receiving institution — for example a bank credit bounced because the account is closed.
Each needs its own record type. Treating a return as a refund, or a reversal as a failed payment, is how ledgers drift out of balance.
How refunds work on each rail
UPI supports refunds against the original transaction reference, which keeps matching straightforward. Wallets such as bKash, Nagad, JazzCash and eSewa support merchant refunds through their APIs, sometimes only within a set window. Bank transfers usually have no native refund; the merchant sends a fresh payout to the payer's account.
That last case matters: a bank-rail refund is operationally a payout, with all the validation and failure handling described in payout failures and retries.
Full versus partial refunds
Partial refunds are common in marketplaces and subscriptions. Always enforce that the sum of refunds never exceeds the original amount, and store each partial refund as its own record linked to the parent payment.
Some wallets limit the number of partial refunds per transaction. Check limits during integration, not during a customer escalation.
Preventing duplicate refunds
Duplicate refunds usually come from a support agent clicking twice, or a retry after a timeout. Every refund request should carry an idempotency key so the second attempt returns the first result instead of sending money again. The mechanics are covered in idempotency in payment APIs.
Add a pending state: once a refund is submitted, block new refunds on the same payment until the first one resolves.
Ledger and reconciliation treatment
Record refunds as debits against the merchant balance at submission, and confirm them when the provider reports success. If a refund fails, reverse the debit with an explicit entry rather than deleting the original. Settlement reports then reconcile line by line.
Reconcile refunds daily against provider statements. Unmatched refunds are a leading indicator of integration bugs.
Customer communication
Tell customers exactly when to expect funds: minutes for UPI and wallets, one or more banking days for bank rails. Share the refund reference so they can quote it to their bank. Clear communication prevents a refund from turning into a dispute.
Publish these timelines in your refund policy so support, customers and reviewers all work from the same expectations.
Frequently asked questions
How fast are refunds in South Asia?
UPI and wallet refunds are typically near-instant to a few hours; bank-rail refunds take one or more banking days.
Can I refund to a different account?
It is best practice to refund to the original payment source. Refunding elsewhere is a common money-laundering pattern and is often restricted.
Is a reversal cheaper than a refund?
Usually yes, because the transaction never settles. Reversals are only possible before settlement.
What if a refund fails?
Record the failure, reverse the ledger debit and retry through another route, typically a bank payout to the verified payer account.
Do refunds count toward dispute ratios?
No. Refunds are voluntary; disputes are payer-initiated. Refunding promptly lowers dispute ratios.
Where PayEurasia fits
PayEurasia runs local collections and payouts across Bangladesh, India, Pakistan and Nepal behind a single API, one reconciliation model and one settlement relationship. Provider redundancy sits behind that API, so an acquirer outage degrades approval rates instead of stopping money movement.
If you are scoping an integration, the API overview explains the object model and the API documentation covers authentication, webhooks and error handling. Merchant onboarding lists the documents needed before a live account is issued, and Compliance sets out the KYC and AML framework applied to every merchant.
Related guides
Talk to PayEurasia
Working in a high-risk vertical across South Asia? We can probably help.
Request integration →