Refunds, reversals and chargebacks, explained

These four terms get mixed up in support tickets all the time, and each one follows a different path. The difference that matters most is who starts it: you, the banking system, or the customer. That tells you whether you need to act, and whether acting would make things worse.

A refund has a short life. It is requested, checked, sent back through the provider, and then either lands or fails. The part customers care about, the credit showing in their account, happens last and outside your control.

A refund doesn't have to be the whole payment. One item comes back from a three-item order, or a customer downgrades mid-month, and you refund part of it. You can refund a payment several times, as long as the total never exceeds what was paid. That ceiling is what stops a double-click, or two support agents, from refunding twice.

A refund goes back to the method the customer paid with, through the provider that processed the payment: to the same card, the same UPI-linked bank account, or the same bank account for netbanking. That's how refunds work across the industry, and it's what lets each party match the refund to the original payment.

It also means a refund can't be moved elsewhere. If the original account is closed, or you owe the customer money for something they didn't pay for, that isn't a refund. It's a payout to an account you verify first.

"Processed" means the refund has left. When it shows up for the customer depends on where it is going, and each party in the chain sets its own pace. There's no single deadline for a refund you issue, so set the customer's expectation by method.

Sometimes a customer's account is debited but the payment never completes: the connection drops, the session times out, or the merchant never receives the confirmation. That's a failed transaction, and the money comes back on its own as an auto-reversal. RBI's turnaround-time framework sets deadlines for it, counted in calendar days from the transaction date (T), with compensation to the customer if the bank is late.

The framework covers failed transactions only. It doesn't cover refunds you choose to issue, or chargebacks.

A refund's status changes after you ask for it, sometimes minutes later, sometimes longer. Rather than asking repeatedly, systems are usually told when the status changes, by a notification such as a webhook. Treat that notice as a prompt: look up the refund's current status before acting on it.

A refund that stays in processingisn't failed. Don't issue a second refund for the same amount while the first is still open; the ceiling on the refundable balance will usually stop it, and if it doesn't, the customer is paid twice.

Most refunds go through. The ones that fail usually do so because the path back to the customer no longer exists.

A chargeback starts when a customer disputes a card payment with their card issuer, instead of asking you for a refund. The dispute travels through the card network to the provider and reaches you as a notice with a deadline to respond. The rules and time limits come from the card network and your provider.

If you have evidence the customer got what they paid for, such as a delivery confirmation, a signed-for parcel, usage logs or a clear cancellation policy they accepted, you submit it. If the decision goes your way, the amount comes back to you. If not, it stays with the customer.

The customer always gets back the amount you refund. The open question is what happens to the fee you paid on the original payment. Some providers return it when you refund, some keep it, and some charge a separate fee for handling refunds or chargebacks. It depends on your provider and agreement, so check before you plan refund-heavy promotions.

Refunds rarely arrive as separate debits. They are deducted from a settlement as negative lines against their original payments. Reconciling them means proving that every refund you asked for was deducted once, and only once.

Most refund complaints aren't about the money. They're about not knowing where it is. A short message at each stage, with a reference, answers the question before it's asked.

Your written refund and cancellation policy also matters, both for customers and under consumer-protection rules for online sellers. What it has to include is a legal question; check it with your adviser.

Refunds can be issued from a dashboard by support staff or from your own systems. For system-issued refunds, a few habits keep them safe:

• Always refund against the original payment's ID, and record a reason.
• Use your own reference, such as the return number, so a retried request can't create a second refund.
• Check the refundable balance before offering a refund in your own interface.
• Treat notifications as prompts, and look up the refund's status before updating the order.
• Never issue a second refund while the first is still processing.

The mechanics are the same everywhere. What changes is why refunds happen and how the amount is decided.