Disputes are a merchant experience problem before they are a payments problem. Here is how they work, why they land on your desk, and what your product can do about them.
A merchant logs into their bank account and sees money pulled back out. The amount is familiar. The label next to it is not. Somewhere in the description there is a code and the word chargeback, and the first thing the merchant does is call the company whose software they use every day. Not the processor. Not the bank. You.
That is the reality for any vertical software company whose customers take payments inside the product. The acquirer and the card networks are invisible to the merchant. Your product is the thing they see, so a dispute becomes your support ticket, your relationship problem, and sometimes your churn risk, long before anyone frames it as a payments issue.
This piece explains how chargebacks actually work, what the reason codes are really saying, where the clock matters, and what a platform can do upstream so fewer of those calls happen in the first place.
What a chargeback actually is
A chargeback is a forced reversal of a card transaction, started by the cardholder’s bank on the cardholder’s behalf. The cardholder contacts their issuer, the issuer pulls the funds back through the card network, and the acquirer debits the merchant’s account. The merchant is usually the last party to hear about it.
It helps to keep three things apart, because merchants often use the words interchangeably:
- A refund is voluntary. The merchant gives the money back, and nothing else happens.
- An inquiry, sometimes called a retrieval request, is the issuer asking for more information before deciding whether to file a dispute. Answer it well and the matter can end there.
- A chargeback is the dispute itself. The funds move first, and the merchant has to make a case to get them back.
Five parties sit in the chain: the cardholder, the issuing bank, the card network, the acquirer or payment facilitator, and the merchant. Your software is not one of the five. It is simply the one the merchant trusts, which is why the first call lands with you.
The four families of reason codes
Every network has its own numbering, but every reason code falls into one of four families. Learning the families is far more useful than memorizing the codes.
Fraud. The cardholder says they did not authorize the transaction. In card-not-present environments this is the largest family by volume, and it includes a surprising number of cases where the cardholder simply did not recognize the charge on a statement. A confusing billing descriptor manufactures a lot of so-called fraud.
Consumer disputes. The cardholder admits the purchase but says something went wrong: services not received, not as described, a recurring charge that should have been canceled, a refund that was promised and never arrived. This is where most winnable disputes live, because the merchant usually has evidence.
Processing errors. Duplicate charges, the wrong amount, a transaction presented late, a currency mismatch. These are the merchant’s or the platform’s mistake, and the fix is operational rather than evidentiary.
Authorization issues. The transaction was run without a valid authorization, or the authorization had expired by the time the charge was captured. Rare in a well-built integration, and expensive when the integration is not.
The same discipline that applies to reading decline codes applies here. The code is a message, and the message tells you which workflow to route it to.
The lifecycle and the clock
A dispute moves through a predictable sequence. The details differ by network, but the shape is always the same.
- The acquirer tells the merchant a dispute has been filed, usually with the funds already debited or held.
- Evidence window. The merchant has a fixed number of days to respond. Miss it and the dispute is lost by default.
- The merchant submits evidence through the acquirer, which forwards it to the issuer.
- The issuer reviews the evidence and either reverses the chargeback or upholds it.
- Pre-arbitration and arbitration. If either side disagrees, the case can escalate to the network, which charges fees to the losing party.
The most common way merchants lose winnable disputes is not weak evidence. It is a missed window. The exact timelines vary by network and by reason code, and they change, so the right habit is to treat every notification as urgent and to know in advance where the evidence lives and who submits it.
Why recurring and card-on-file businesses get hit hardest
Subscriptions, memberships, maintenance agreements, service contracts: anything that bills on a schedule attracts disputes for three reasons that have little to do with fraud.
- Forgotten commitments. A member stops attending but keeps being billed. A service contract renews. The cardholder sees a charge they stopped expecting and disputes it rather than calling.
- Unclear descriptors. The merchant’s legal name on the statement is not the brand name the customer knows, so a legitimate charge looks like a stranger.
- Cancellation friction. If canceling is harder than disputing, cardholders dispute. The issuer’s app is one tap away and the merchant’s cancellation form is not.
This is the dispute-side twin of the involuntary churn problem that failed payments create, and a well-designed recurring billing setup has to address both.
What a platform can do upstream
Most of the levers that reduce disputes are product decisions, not payment features. A software company controls them whether or not it ever touches the payments stack.
- Make the descriptor match the brand. The name on the cardholder’s statement should be the name on the invoice, the receipt, and the login screen.
- Send a receipt and, for recurring charges, a reminder. A short message before a scheduled charge removes the surprise that drives most consumer disputes.
- Put cancellation and refunds inside the product. Self-serve cancellation feels like a loss, but a refund costs far less than a chargeback and its fee, and it keeps the merchant’s dispute ratio healthy.
- Keep the evidence where the merchant can find it. Signed work orders, delivery confirmations, timestamps, communication logs, proof of service. If your product already holds the job record, the invoice, and the customer’s acknowledgment, surfacing those together turns a lost case into a two-minute response.
- Watch dispute data the way you watch declines. Rate by merchant, by reason family, and over time. A spike in one merchant usually means a descriptor or process problem that can be fixed before the network notices.
None of this requires a specific vendor. It requires treating disputes as part of the merchant experience you already own, in the same way PCI scope and processor migration are shaped by product decisions long before they become payments decisions.
What to ask a payments partner about disputes
When the conversation does turn to the payments stack, four questions separate partners who will help from vendors who will forward an email.
- How, and how quickly, are merchants notified? A dispute the merchant learns about late is a dispute already half lost.
- Where is evidence submitted? If the answer involves a separate portal, a fax number, or a support ticket, the evidence window is going to be missed.
- Are reason codes surfaced in reporting, grouped into families? Raw codes in an export are not reporting. Trends by family and by merchant are.
- Who guides the merchant through representment the first time? The first dispute is the one that decides whether the merchant trusts the platform.
The answers say a great deal about what the partnership actually means once a merchant has a problem.
Disputes are part of the product
Chargebacks will never be zero. What a software company controls is how many of them were avoidable, how quickly its merchants can respond, and whether the merchant feels supported or abandoned when the call comes in. Those three things are decided inside the product, and they compound across every merchant on the platform.
CSIPay is the embedded payments platform built for Constellation Software and Jonas operating companies, covering the US and Canada on PCI DSS Level 1 infrastructure with a 99.9% uptime SLA, 4,000+ merchants, and $40M+ distributed to partners. If your merchants are calling you about chargebacks, talk to our team.