Payment operations
Refunds, disputes and chargebacks: how they differ
Three ways money can flow back to a customer, who starts each one, what it costs a merchant, and how to handle each so fewer turn into chargebacks.
· 6 min read
Three different processes
Refunds, disputes and chargebacks all end with money moving back towards the customer. They are easy to confuse, but they are started by different parties, follow different rules and have different consequences for a merchant.
- Refund
- The merchant returns all or part of a payment. The merchant decides and initiates it.
- Dispute
- The cardholder challenges a payment with their card issuer. It is a general term that covers the early stages of the process as well as the chargeback itself.
- Chargeback
- The issuer reverses the payment under card scheme rules. The merchant can contest it with evidence, within a deadline.
Refunds: the merchant's decision
A refund is the simplest of the three. You decide that a customer should get money back, for a return, a cancellation or a service problem, and you issue it against the original payment. It can be for the full amount or part of it.
In Rainbow Pay's API, a refund is requested against the payment token of the original payment, for the full amount or a partial amount. Its status is reported in the same way as a payment's, so your records and your customer's expectations stay aligned.
- Refund to the original payment method. Sending money back by a different route creates reconciliation problems and can raise compliance questions.
- Keep the original payment token linked to the order so a refund can be issued without searching.
- Tell the customer when you have issued the refund and that it can take time to appear on their statement, depending on their card issuer.
Disputes: the cardholder goes to the issuer
A dispute begins when a cardholder contacts their card issuer instead of the merchant. The cardholder may not recognise the charge, may say the goods did not arrive or did not match their description, or may have cancelled a subscription that was charged again.
Depending on the card scheme and the case, the issuer may first request information, or may move straight to a chargeback. Monitoring disputes as they arrive, rather than only when funds are debited, gives you the most time to respond. Rainbow Pay's API provides a list endpoint for dispute information so you can bring disputes into your own tooling.
Chargebacks: scheme rules and deadlines
A chargeback reverses the payment. Each one carries a reason code assigned by the card scheme, which states the grounds, such as suspected fraud, a processing error or a consumer dispute. The reason code determines what evidence is relevant and how long you have to respond.
If you believe the chargeback is not justified, you can submit evidence: proof of delivery, records of the customer's use of a digital service, correspondence, the terms the customer accepted and authentication results. The evidence should answer the specific reason code, not the dispute in general.
Chargebacks usually carry fees, and card schemes monitor merchants whose chargeback levels are elevated. A merchant that consistently exceeds scheme thresholds can face additional requirements or lose the ability to accept cards. This is why reducing chargebacks is worth effort even when each case is small.
Side by side
| Refund | Chargeback | |
|---|---|---|
| Who starts it | The merchant | The cardholder, through their issuer |
| Governed by | Your terms and refund policy | Card scheme rules |
| Can the merchant contest it? | Not applicable | Yes, with evidence, within a deadline |
| Typical extra cost | Usually none beyond the refunded amount | Fees, and scheme monitoring if frequent |
| Customer relationship | Often preserved | Often damaged |
Keep the records that answer each process
Each of the three processes depends on records you create at the time of the sale. When a refund request, a dispute or a chargeback arrives weeks later, those records are what let you respond quickly and accurately.
- Link every order to its payment token, so refunds, callbacks and disputes can be matched to it without manual searching.
- Keep the terms, prices and refund policy that applied on the date of purchase, not only the current version.
- Store delivery confirmations, tracking references or service access logs with the order.
- Keep customer correspondence in one place, with dates.
- Record refunds against the original order, so that a later dispute on a refunded payment can be answered with proof of the refund.
A refunded payment can still be disputed, for example if the customer did not see the refund before contacting their issuer. Proof that the refund was issued, with its date and amount, is usually the evidence that resolves it.
Reducing chargebacks
Many chargebacks are disputes that a refund would have resolved more cheaply. The practical measures are mostly about clarity and responsiveness.
- Use a statement descriptor the customer will recognise.
- Publish a clear refund policy and a support contact that answers.
- For subscriptions, send reminders before renewal and make cancellation straightforward.
- Use cardholder authentication, such as 3-D Secure, where it is available and appropriate.
- Keep delivery evidence and customer communications linked to each order.
- When a customer has a valid complaint, refund promptly rather than waiting for a dispute.
The terms used here are defined in the glossary. For how refunds and callbacks fit into an integration, see the integration guides.