The refund that was never a return.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

Hollow Oak Supplements has a refund rate of 4 per cent and is proud of it. Customer service is told to say yes. Then the finance lead notices that refunds for one product line are running at 11 per cent, that two-thirds of those were issued by the same two agents on the evening shift, and that the returned stock, which the policy requires, has not arrived for any of them. Ines has asked for a view on whether this is a fraud problem or a process problem. Our answer is that it is both, and that the second one is the way in.

What is actually being decided.

A refund is the merchant choosing to give money back. A dispute is the cardholder asking the issuer to take it back, and Visa’s dispute-resolution guidance is a clear account of how much more that second path costs in time, fees and ratio exposure. Merchants quite reasonably prefer the first path, and a generous refund policy is one of the cheapest dispute-prevention tools there is. Refunds, fraud reports and disputes are distinct events. Do not assume issuing a refund automatically removes other events from a network metric; reconcile the network’s actual extract and documented exclusions.

That is why refund abuse is awkward. The control you would tighten is the same one keeping the dispute ratio down. Three parties carry something. The merchant carries the lost goods and the refunded cash. The genuine unhappy customer carries any friction you add. And the PSP, Northbank, carries the risk that a merchant which fixes its refund problem by refusing refunds will turn a refund problem into a dispute problem within a quarter.

The decision is not "tighten refunds or not". It is: which type of refund is being abused, by what pattern, and what is the narrowest change that interrupts the pattern while leaving the goodwill path open?

Three refund types, one word.

The word "refund" covers three different transactions and only two of them scale as abuse.

A goodwill refund is a decision by the merchant to give money back with no claim attached: a late delivery, a rude e-mail, a gesture. It is discretionary, usually small, and bounded by the agent's authority. It can be abused by an insider but not easily by an outsider.

A return-based refund is conditional on goods coming back. The abuse here is the one Hollow Oak has: the refund is issued on the promise of a return, and the return never happens. the gap between "refund issued" and "return received" is a useful measure for this example; joining the two events exposes the unresolved return.

A claim-based refund is issued on the customer's statement that something went wrong: not received, damaged, not as described. No goods come back because, on the claim, there are none to send. This is the type most exposed to outsiders, because the only evidence is the claim, and the pattern OWASP catalogues under OAT-019, mass account creation, is the usual way the claim gets made many times. It is also the one that shades into the subject of the companion article on first-party misuse: a cardholder who is the customer, saying something that is not true.

Hollow Oak's 4 per cent is the sum of all three. Split it and the 11 per cent product line becomes a return-based problem concentrated on two agents, which is a different investigation from a claim-based problem spread across hundreds of new accounts.

The pattern lives in the joins.

An observation, in this fictional case: 212 return-based refunds on the product line in 60 days; 140 issued by two agents; zero returns received against those 140; 96 of the 140 refunded to a payment instrument different from the one that paid; 31 of the receiving accounts share four delivery addresses.

Each of those is a fact in a system. None of them alone is a finding. A refund to a different instrument happens legitimately when a card has expired. An agent concentration happens when two people work the shift where returns are processed. Shared delivery addresses happen in student halls. The finding is in the join: the same 140 refunds sit at the intersection of all four facts, and the probability of that by chance is low enough that we would call the inference strong. The Volume 01 note on shared signals and the Volume 02 piece on link analysis are the method; a shared attribute is a lead, a ring is a finding.

The alternative explanation we would keep alive: the two agents may have been following an instruction. If a supervisor said in September "refund on request, do not wait for the return, we are behind", the pattern is a process failure with a fraud opportunity sitting inside it, and the agents are witnesses rather than suspects. The difference matters for what you do next and for how you write the note. The piece on case notes someone can audit is written for exactly this moment.

Hold the claim to the dispute standard.

Here is a test that reframes claim-based refunds. If this customer had gone to their issuer instead of to you, what evidence would you have had to produce to win the dispute? Proof of delivery, a matching address, a device or login footprint, a history of undisputed orders. Visa’s dispute-resolution guidance lists the kinds of evidence a merchant assembles; the Volume 02 article on compelling evidence goes into the scheme detail.

Now ask why the refund path asks for none of that. the answer is "because it is faster", which is correct and is also why abuse goes there. The fix is not to make every refund a dispute. It is to apply the evidence check to the subset where it is cheap and decisive: a claim of non-delivery against a tracked parcel with a signature is answerable in seconds. A claim from an account created yesterday, on its first order, to a new address, is a question worth asking before saying yes. A claim from a three-year customer with forty undisputed orders is a goodwill refund with extra steps, and should be treated as one.

A synthetic illustration of the trade. Suppose Hollow Oak receives 1,000 claim-based refund requests a month and currently approves 980. Suppose an evidence check on new accounts holds back 60 of them for a question, of which 45 turn out to be abuse and 15 are genuine customers who are mildly annoyed. The merchant saves 45 refunds and irritates 15 people. Whether that is a good trade depends on the refund value and on what the 15 do next; it is the same precision-and-recall arithmetic as any other rule, and the article on thresholds as prices is the frame. What is not a good trade is holding all 1,000 for the sake of 45.

A failure mode to watch.

A broad refund restriction can displace legitimate complaints into disputes without addressing the underlying abuse. Measure both outcomes on comparable cohorts, distinguish support quality from misuse and limit interventions to evidence-supported patterns. Do not assume every prevented refund becomes a dispute or that a fixed waiting period fits every merchant.

A way to work it.

1. Split refunds into goodwill, return-based and claim-based. Compute each as a rate by product, agent, channel and account age.
2. For return-based refunds, compute refund-issued-to-return-received gap and the share with no return after 30 days.
3. For the concentrated segment, join on instrument, address, device and account creation date. State observations first, then the inference, then the alternative.
4. Interview before accusing. Ask the agents and the supervisor what the instruction was.
5. Design the narrowest control: evidence check on claim-based refunds from accounts under 30 days old; return-received before refund on the affected product line. Leave goodwill alone.
6. Owner, start date, 30-day review. At review, compare refunds and disputes together.

Take it to the desk.

What is our refund rate for customers who have never raised a dispute, and do we know it per agent? If nobody can answer the second half, the pattern at Hollow Oak could be running at your merchant and nothing would show it.

Try it: Refund ring at Hollow Oak, and the Volume 01 case Promo abuse. Read next: When the cardholder is the customer. Look up: refund abuse, linked entities.

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.