Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
One order shows two successful payments of the same amount, and the business does not know whether both are real, which one to refund, or how the refund will show in the books.
Confirm both payments are captured and linked to one order, refund the later one to its original source, and expect the refund to be netted from the next settlement as its own line.
A daily duplicate check on the gateway export grouped by order ID, and by customer plus amount within a short time window, with a note on each order where a refund was made.
Every duplicate is refunded once to the right source, the refund line in the next settlement is matched to the original payment, and no unexplained customer credit sits in the ledger.
If one order shows two successful payments, one of them is a duplicate. First confirm that both are captured (money actually taken, not just held). Then refund the extra one to the same card, UPI account or bank account it came from, and write a note on the order. Do not keep it as credit against a future order.
Why does a customer end up paying twice?
Most duplicates are not fraud. They come from the checkout moving slowly and the customer trying again.
| Likely cause | What happened | How it shows in the dashboard |
|---|---|---|
| Double click on Pay | The button was pressed twice before the page responded | Two payments, same order ID, seconds apart |
| Back-button retry | Customer went back and paid again thinking the first failed | Two payments, same amount, often a minute or two apart |
| Payment link paid twice | Link was shared on WhatsApp and email and both were used | Two payments on the same link reference |
| UPI collect request paid twice | Customer approved the request on two apps or retried | Two UPI payments with different RRNs, same amount |
| Two modes used | First card payment looked stuck, so customer switched to UPI | One card and one UPI payment for one order |
A useful point for beginners: a “captured” payment is money the gateway has taken and will settle to you. An “authorised” payment is only a hold on the customer’s card. Only captured payments need a refund.
How do I spot duplicates without opening every order?
Download the day’s payments export from the gateway and sort it. You do not need to open orders one by one.
- Sort by order ID. Any order ID with two or more captured payments is a candidate.
- For payment links and UPI requests, which may not carry your order ID, sort by customer phone or email, then by amount.
- Flag pairs with the same amount within, say, 10 minutes of each other.
- Check delivery. If only one order was shipped or served, the second payment is a duplicate.
- Refund, and add a note with the refund reference on the order.
Doing this once a day takes a few minutes in Excel or Google Sheets. Doing it once a month means customers have already complained, or raised a dispute with their bank.
Worked example: a ₹3,250 order paid twice
A customer places order 10482 for ₹3,250 at 7:42 pm. The gateway shows two captured card payments: one at 7:42:10 pm and one at 7:42:50 pm, 40 seconds apart. Only one parcel was packed.
| Step | Amount |
|---|---|
| Payments captured on order 10482 | ₹6,500 (2 × ₹3,250) |
| Value of goods supplied | ₹3,250 |
| Duplicate to refund (the 7:42:50 pm payment) | ₹3,250 |
You raise one full refund of ₹3,250 against the second payment ID. In the next settlement, the report shows a refund line of minus ₹3,250 tied to that payment ID. If that day’s captures were ₹48,000, the payout before fees is ₹48,000 − ₹3,250 = ₹44,750. In your books, the sales invoice stays at ₹3,250; the second receipt and its refund cancel out, so nothing is left in the customer’s account.
Do I get the gateway fee back on the duplicate I refund?
Not always. When the duplicate was captured, the gateway charged its fee (the MDR, or merchant discount rate) plus 18 percent GST on that fee. On a refund, some gateways reverse that fee and some do not. Your merchant agreement and the refund line in the settlement report tell you which applies to you. If the fee is not reversed, book it as a payment-processing expense, and keep the gateway’s tax invoice so the GST can be claimed as input tax credit.
What should I avoid doing?
- Do not refund to a different account or by bank transfer unless the original source is closed. Refunding to source keeps a clean trail.
- Do not refund both payments by mistake. Refund one payment ID, not the order.
- Do not wait. A customer who sees two debits may raise a chargeback, which is a forced reversal through their bank and usually costs more effort than a refund.
- Do not leave a duplicate as an “advance” in Tally or Zoho Books without the customer agreeing to it.
How much can duplicates add up to?
More than most owners expect. Say a shop takes 5,000 orders a month at an average of ₹1,200, and 10 of them are paid twice. That is ₹12,000 a month owed back to customers. If the gateway keeps its fee on refunds and that fee is an illustrative 2 percent, each duplicate also costs ₹24 plus ₹4.32 GST, or ₹240 plus ₹43.20 GST across the 10. Small per order, but it repeats every month until the checkout is fixed.
What to read next
Duplicates are one type of exception. At higher volume you need a routine for all of them:
- Exception management in reconciliation: how to sort, own and close unmatched items.
- Refund reconciliation for payment gateways: matching each refund line back to the original payment.
- Payment gateway reconciliation: the full picture.
Payment-gateway settlement reconciliation is on the TransactIG roadmap.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →