Every Chargeback Tool Is Built for One Merchant

Chargeback management software helps a merchant fight its own disputes. If you are an ISO, payfac, or software company that has taken payments in-house, that is not your problem. Your problem is that the network measures fraud and disputes at your portfolio level, your sponsor bank holds you to those thresholds, and when a sub-merchant fails, the losses land on you. No vendor on the market builds the portfolio view, because no vendor sits across all of your acquirers. Here is what exists, what does not, and where the line between buying and building actually falls.

Who actually eats a chargeback, in order

For operators, the useful question is not “Can I win this dispute?” It is “Where does the liability end up if I do nothing?” The answer follows the payment chain.

1. Cardholder disputes a transaction with the issuer.
2. Issuer evaluates the claim and, if valid under scheme rules, submits the chargeback into the network.
3. Card network routes the dispute to the acquiring side and applies the program rules.
4. Acquirer is the first financial counterparty that feels the operational and program impact.
5. ISO, payfac, or portfolio sponsor eats the economic loss when the merchant agreement, reserve, or indemnity makes it theirs.
6. Sub-merchant is ultimately responsible for the transaction economics, but if it is gone, insolvent, or underreserved, the exposure stops with the party that guaranteed it.

That last point matters. “The merchant absorbs it” is true right up until the merchant is gone. In a portfolio model, the liability usually sits with the party that has the indemnity, reserve control, or sponsor-bank obligation. That is why payfac chargeback liability is not a merchant support problem; it is an underwriting and loss-control problem.

Merchant-level monitoring vs portfolio-level monitoring

Most chargeback tools assume one merchant owns one dispute stream. ISO and payfac reality is different: you may have 200 to 5,000 active sub-merchants, multiple acquirers, and one portfolio ratio that can trigger remediation even if no individual merchant looks alarming in isolation.

Visa’s current monitoring framework is the Visa Acquirer Monitoring Program (VAMP), which consolidated earlier fraud and dispute programs into a single ratio. The important shift is not cosmetic. It combines fraud and dispute records, and it measures performance at both the merchant and acquirer/portfolio level. The practical result is that the acquirer or portfolio can breach a threshold while each individual merchant appears acceptable. Because VAMP thresholds have been revised more than once, verify every figure against Visa’s published rules or your acquirer bulletin before using it operationally.

Mastercard’s excessive-chargeback programs create a parallel operating reality: the sponsor and acquirer care about aggregate behavior, not just whether one merchant won a representment. Exact thresholds and remediation steps should also be verified against the current network rules and your processor’s guidance.

Why your portfolio ratio is not a number you currently own

The second gap is data. Fraud reports and dispute records do not arrive as a clean, unified ledger. They show up in acquirer-specific files and portals, on different schedules, with different field names, different merchant identifiers, and different definitions of what happened when.

That means the acquirer portal’s number is usually the acquirer’s number, computed their way, arriving after you needed it. If a merchant moved between MIDs, switched processors, or was boarded under one legal entity and settled under another, your “merchant” dimension is already broken unless you normalize it yourself.

A trustworthy portfolio chargeback ratio requires one merchant dimension across:

• TC40 / fraud files
• TC15 / dispute files
• acquirer settlement and chargeback reports
• boarding records, MID mappings, and merchant hierarchy
• reserve and exposure balances

That normalization work is why no vendor solves this for you. No vendor sits across all your acquirers, knows your reserve logic, or understands which merchant changes should roll up into one risk identity. A merchant-side dispute dashboard cannot tell you what your portfolio ratio is likely to be next month.

The three decisions that actually move the ratio

The number that matters is not the one you report. It is the one you can still change before month-end.

1) Underwriting at onboarding

This is where you decide what you will accept, at what reserve, and at what price. The right data is historical fraud, dispute intensity, MCC behavior, business model, shipping lag, refund behavior, ticket size, and acquirer mix. If you underwrite aggressively here, you are buying future monitoring pain.

2) In-life controls

These are the controls that slow the bleed before it becomes a program event: velocity caps, reserve step-ups, delivery-delay monitoring, refund monitoring, descriptor changes, and merchant outreach. These actions only work if you can see the trend early enough to act.

3) Exit

Offboarding late is the most expensive risk decision an ISO makes. If a merchant is already past the point where reserves cover expected losses, the portfolio inherits the shortfall. Exit needs to be modeled, authorized, and auditable before the ratio crosses the line.

In other words: the dispute queue tells you what happened. Underwriting and offboarding decide what happens next.

What to buy and what to build

There is a clean boundary here. Buy commodity dispute operations. Build the portfolio risk model.

When should you not build? If you have fewer than about 200 sub-merchants, one acquirer, no meaningful reserve program, and no sponsor-banked portfolio obligation, a merchant-side tool may be enough. The moment you carry contractual liability for sub-merchant losses, the build case changes.

FAQ

Who is liable for a chargeback? In practice, liability flows from the cardholder’s dispute through the issuer, network, and acquirer to the merchant side. In an ISO or payfac structure, the party with the indemnity, reserve obligation, or sponsor-bank exposure usually ends up holding the loss.

What are the three types of chargebacks? In operator terms, people usually group them as fraud-related, authorization-related, and consumer-dispute-related. Scheme taxonomies vary, so use your network’s current categories for reporting and modeling.

What is the 540-day rule for chargebacks? That phrase is often used online to describe the outer window for some card-not-present and delayed-presentment dispute scenarios, but the exact timing depends on the network, reason code, and transaction type. Check the current scheme rules rather than relying on a generic rule of thumb.

What is a chargeback ratio, and whose ratio is it? A chargeback ratio is the count or amount of chargebacks compared with processed transactions over a defined period. For a merchant tool, it is the merchant’s ratio. For an ISO or payfac, the number that matters is the portfolio ratio: the aggregate result across sub-merchants, acquirers, and sometimes legal entities.

What is chargeback management software, and who is it actually built for? It is software for assembling evidence, managing disputes, and improving a single merchant’s win rate. It is built for the merchant defending its own transactions, not for the portfolio owner underwriting hundreds or thousands of sub-merchants.

A one-week diagnostic before you spend anything

Before you buy software, reconstruct twelve months of your portfolio ratio from the files you already receive.

• Pull TC40/fraud, TC15/dispute, settlement, and reserve reports from each acquirer.
• Map every merchant ID, MID, DBA, legal entity, and portfolio bucket into one merchant dimension.
• Recompute chargeback ratio by month, by merchant, by MCC, and by acquirer.
• Flag merchants that moved between processors or changed ownership during the period.
• Overlay reserves, rolling holdbacks, and actual loss realization.
• Compare the forward trend against your sponsor’s threshold, not just the prior month’s close.

If that exercise reveals three bad merchants, you have a merchant problem. If it reveals one sponsor-level drift pattern across a whole portfolio, you have a modeling problem. That is the line between buying dispute software and building portfolio risk infrastructure.

Better’s work in financial services has followed this same shape: normalize many feeds into one trustworthy ledger, then make a defensible decision on top of it. The pattern shows up in trading operations and mortgage servicing as much as it does in payments—see the fintech work and related case studies such as UTR8, AllOptions, and Valon. The sector changes; the operating problem does not.

The chargeback number that can end your business is your portfolio’s, not any single merchant’s. If you underwrite two thousand merchants, the question is not whether you need a better dispute queue. It is whether you can see, forecast, and control the ratio you are already responsible for.