Chargebacks: the cost that sits between teams
Who in your company owns the chargeback rate? Ask around and each team will point at another one, and each of them will be partly right.
Finance treats dispute fees and lost amounts as a cost line, or never sees them separately at all because they arrive as debits netted out of a settlement file. The operations team has a case queue with deadlines. Support handles the contacts that come before a dispute and the angry ones that follow it. Risk looks at the cases coded as fraud. Product usually hears about none of it, although a billing descriptor nobody recognizes and a cancellation button nobody can find will produce disputes every month for years.
Because the cost is split four or five ways, nobody sees the total. Nobody has much reason to reduce a number they cannot see.
Say a PSP handles 1,000 disputes a month on behalf of its merchants. The figures here are illustrative, but the arithmetic is worth doing with your own. If assembling and submitting each evidence pack takes an analyst 20 minutes, that is over 300 hours a month, roughly two full-time people, before anyone counts the scheme and acquirer fees, the amounts written off when a case is lost, the support contacts on either side of it, or the finance time spent matching chargeback debits to cases. That last one is its own source of reconciliation breaks, since the debit and the case rarely carry the same reference.
If you run a card program on the issuing side, the picture is reversed and just as scattered. Cardholders raise disputes through support, operations files chargebacks with the processor against scheme deadlines, provisional credits move balances around, and the write-offs land with finance when a case fails. The teams are different and the split is the same.
The part everyone sees first is the evidence pack. Card-scheme rules set deadlines at each stage of a dispute, and a response filed after the deadline loses by default, however good the evidence was. Meanwhile the evidence itself sits in four systems: delivery confirmation in the logistics platform, login and device data in application logs, the customer's acceptance of the terms in a database table somebody has to query, and the support transcript in the CRM.
Two changes do most of the work here. The first is a template per reason-code family, naming the evidence that wins that kind of case and where each piece lives, so an analyst is not deciding from scratch at 4pm on a Friday. The second is automated collection: a script that pulls the order, delivery and login records into one file the moment a dispute arrives will save more analyst time than any amount of training.
Then measure two things. Win rate by reason code tells you which templates are weak. The number that matters more is disputes lost because nothing was submitted in time. That one should be zero. When it is above zero, the cause is usually a queue problem: cases arriving faster than they are worked, or deadlines tracked in one person's calendar.
Many chargebacks are a customer's second complaint, made to their bank after the first one, made to you, went unanswered.
Giving the cost an owner
Winning more disputes reduces losses. It does nothing about why they happen, and for that you need a cause the reason code will not give you. Scheme reason codes record what the cardholder or the issuer claimed. A case coded as fraud is often a customer who did not recognize the descriptor. A case coded as goods not received is sometimes a delivery that arrived the day after the customer gave up waiting.
So add an internal root cause to each case once it has been investigated, from a short list that maps onto teams who can act: unclear descriptor, refund promised and never processed, cancellation not honored, delivery failure, genuine third-party fraud, first-party misuse. Keep the list short enough that analysts use it consistently, and review the coding quarterly, because a category that collects 60% of cases has stopped being useful.
Then give one person the dispute rate as a whole. They do not need to fix anything themselves, and they will not have the authority to. Their job is to produce one page a month showing each root cause with a count, a cost and a team, and to sit in a meeting where those items get put on someone's backlog. The cost figure matters more than the count, because a hundred descriptor disputes and a hundred delivery failures are not the same problem in money terms.
The feedback then runs in several directions at once. Product changes the billing descriptor to something a cardholder will recognize on a statement, and moves the cancellation link to where people look for it. Risk tunes rules against fraud that is real and stops treating confused customers as fraudsters. Operations sees which merchants generate disputes out of proportion to their volume, which is a commercial conversation as much as an operational one.
Support may matter most of all, because a customer who gets a clear answer and a refund within a day has no reason to call their bank. Track the share of disputes that arrive from customers who had already contacted you, and how long those tickets had been open. If that share is high, the cheapest improvement to your chargeback rate is sitting in the support queue.
None of this needs a project. Take last quarter and add up what disputes cost across every team that touches them. Put the total on one page next to the count, and bring it to the meeting where budgets are argued about. A number that nobody owned tends to find an owner quickly once it has a total attached.
Discuss your operations
