Fictional scenario. Synthetic data. Your notes stay on this browser; do not enter real customer information.
A dispute is loud. It arrives with a code, a deadline and a fee, and somebody owns it. A refund is quiet. It arrives as a line in a support queue, is approved by someone whose job is to make customers happy, and leaves through a flow that most fraud monitoring was never pointed at. That asymmetry is the whole of refund fraud. Nobody is looking at refunds because refunds are a cost of doing business rather than a loss.
OWASP's catalogue touches this under OAT-012, Cashing Out: converting obtained value into money. A refund is one of the cleanest conversions there is. The merchant does the work and the payment rails do the delivery.
What the scheme needs.
From the defender's view, refund fraud needs some combination of the following; each variant needs a different subset.
A refund path that does not require the original transaction. A standalone credit, issued to a card without reference to a sale, is a payment from the merchant to whoever holds the card. If your merchant's tools allow it, your monitoring has to count it.
A person who can approve refunds without a second look, below some limit. Every support team has one. The limit is the scheme's price list.
A claim that is hard to verify. "It never arrived." "I was charged twice." These are also what honest customers say, which is the point.
Something to keep. Goods refunded but not returned, a subscription refunded and still active, a digital product refunded after download. Hollow Oak Supplements, our fictional subscription merchant, sells the kind of product where the return is never checked.
What it looks like in your data.
A synthetic illustration at Hollow Oak, 90 days of refund and credit flows.
- Refunds as a share of sales look normal by month: 3.1 per cent against a baseline of 2.8. The monthly ratio hides everything that follows.
- Standalone credits, in their own column, have doubled year on year. Nobody has a rule on that column.
- 53 credits went to cards that never made a purchase at Hollow Oak. Honest reasons exist for some: a replaced card, a goodwill gesture. Fifty-three is a lot of goodwill.
- Amounts cluster just below the agent approval limit. In this illustration the limit is EUR 150 and 31 of the 53 fall between EUR 140 and EUR 149.
- One agent reference carries 38 of the 53, concentrated on Friday evenings. The same agent's other credits are spread across the week at a third of the value.
- "Item not received" claims by account over 90 days: 14 accounts with three or more, in a population where almost nobody makes two.
- Refunded subscriptions still active 30 days after the refund: 22.
The pattern is never in the ratio. It is in the distribution: by agent, amount, day, account and column.
What else looks like this.
A recall or a bad batch. A product fault produces a wave of honest goodwill credits, many to customers paying with a different card from the one on their subscription. The wave has a start date, a product and a ticket reference on each credit.
A generous policy. Some merchants refund without question and accept the cost. Their refund rate is high and flat, not spiky.
A courier problem. A regional delivery failure produces "not received" claims with a postcode in common and a date range matching the courier's incident.
A new agent. Someone learning the job approves too freely for a month, and the distribution corrects.
Each has a ticket, a date, a product or a postcode as its explanation. The fraud variant has an agent and an amount, and no ticket.
Where it is usually caught.
Rarely by the merchant, and almost never by the monthly refund ratio. It is caught when someone looks at refunds by agent, by card, or by whether the original transaction exists, which happens when a PSP, an auditor or a colleague asks a question.
The PSP's view is wider than the merchant's. A PSP sees the same card receiving credits at one merchant and being used at another, and the refund that was never a return sets out what the PSP can do with that without accusing anyone. The case Refund ring at Hollow Oak gives you the export to work.
The control that catches it earliest is the dullest: a second approval on standalone credits above a threshold, and a weekly export of credits by agent and by card-with-no-purchase. Neither stops anything. Both make it visible.
A desk card.
- Put standalone credits in their own column and put a rule on it.
- List credits to cards with no purchase history, weekly, by agent.
- Clusters just below the approval limit are a question.
- Count "not received" claims per account over 90 days, not per month.
- When you find an agent pattern, hand it to the merchant. Who did what is their decision.
Read next.
When the cardholder is the customer. covers the dispute-side cousin of this scheme. Write the note for the person who reopens it. is for when the finding involves a named employee at a client. Look up refund abuse. Part four is bust-out, where the merchant itself is the scheme.
Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.
Fictional learning material. Any numerical examples are synthetic. Use only authorised, appropriately minimised records for workplace exercises; do not upload customer information to this learning site.