Operations
Chargeback management software for ISO and payfac portfolios
By Better Software · Fri Sep 18 2026 · 8 min read
If you run an ISO, payfac, or software company that has taken payments in-house, chargeback management software solves only part of your problem. It helps a merchant defend its own disputes. Your harder job is managing portfolio-level loss, because the network, acquirer, and sponsor bank can judge you on a ratio that rolls up many sub-merchants, not one storefront.
That means the useful question is not just “which chargebacks did we win?” It is “which merchants are moving our portfolio ratio, what will that ratio look like next month, and what should we do before we cross a threshold?” No merchant-side dispute tool answers that on its own. It can organize symptoms. It does not own the portfolio.
Who actually eats a chargeback, in order
For operators, the cleanest way to think about liability is as a chain. A failed dispute does not stop at the cardholder. It moves through the parties that signed up for the merchant, and the party holding the indemnity is usually the one left with the loss.
- Cardholder. The person who disputes the transaction.
- Issuer. The cardholder’s bank, which opens and evaluates the dispute.
- Network. Visa, Mastercard, or another network that routes the rules and settlement process.
- Acquirer. The merchant’s acquiring bank or processor, which is contractually upstream of the merchant relationship.
- ISO, payfac, or platform. The party that underwrote the merchant or sub-merchant and often agrees to cover losses, reserves, or chargeback exposure.
- Sub-merchant. The business generating the original sale.
In ordinary language, people say “the merchant eats the chargeback.” That is true until the merchant cannot. If the sub-merchant fails, disappears, or cannot reimburse the loss, the liability moves to whoever guaranteed the merchant relationship. For an ISO or payfac, that is often you.
This is why “who is liable for a chargeback?” has a different answer for consumers than for operators. The consumer answer is simple. The operator answer depends on the contract, reserve structure, and where indemnity sits in the merchant agreement.
Merchant-level monitoring and portfolio-level monitoring are not the same thing
Most chargeback tools are built around a single merchant. They track disputes, evidence, deadlines, and representment. That is useful if you are the merchant trying to reduce loss on your own MID, which is merchant identification data used by processors and acquirers.
For an ISO or payfac, the real question is whether the portfolio as a whole is drifting toward a monitoring threshold. Visa’s Acquirer Monitoring Program, or VAMP, combines fraud and dispute activity into a single program and measures it at both merchant and acquirer or portfolio level. Visa’s own published rules or your acquirer bulletin should be the source for any current threshold, because the numbers and effective dates have changed and secondary summaries disagree.
The practical difference is not subtle. A merchant can look acceptable on its own while the portfolio is moving toward a sponsor-level problem. That is why a portfolio ratio needs to be forecast from partial-month data, not just reported after the fact.
| Measurement point | What it tells you | Who can act on it | What a merchant tool usually does |
|---|---|---|---|
| Merchant level | How one merchant is performing on disputes and fraud | Merchant support, risk, underwriting | Tracks cases, evidence, deadlines, and outcomes |
| Portfolio or acquirer level | How the whole book is trending against a network or sponsor threshold | ISO, payfac, sponsor bank, portfolio risk owner | Usually not measured across all sub-merchants |
| Forecast view | What the ratio is likely to be before month end | Risk, underwriting, operations | Rarely included, and usually not across multiple acquirers |
Mastercard’s excessive-chargeback programs create a similar operator problem even if the details differ. The point is the same: if the consequence sits above the merchant, your monitoring has to sit above the merchant too.
Why your portfolio ratio is not a number you already own
An acquirer portal can show you a ratio. That does not make it your ratio. It is computed from that acquirer’s view of the world, on that acquirer’s schedule, using that acquirer’s merchant identifiers and filing conventions.
Portfolio truth is messy because the data arrives fragmented. Fraud reports and dispute records may come in different files, from different acquirers, with different lag times. The same sub-merchant may appear under more than one MID. A merchant may move between processors mid-year. Some records arrive after the month you need to act on is already closing.
To trust a portfolio ratio, you need one merchant dimension across all of those feeds. That means normalizing the identifiers, mapping MIDs back to the economic merchant you underwrote, and deciding what to do with merchants that have changed processors, legal entities, or verticals. This is not a simple dashboard problem. It is a ledger problem.
The reason this matters is that the sponsor bank will not care that your internal spreadsheet was clean. It will care about the number that appears in the program it measures you against.
The decisions that actually move the number
If you only look at the dispute queue, you act too late. The decisions that move a portfolio ratio happen before the final report closes.
1. Onboarding
At underwriting, you decide what you will accept, at what reserve, and at what price. A merchant with thin margins, high refund rates, delayed fulfillment, or poor historical dispute behavior may still be worth boarding, but only with tighter controls. If you do not encode that decision, you are underwriting by memory.
2. In-life controls
Once the merchant is live, you can still change the shape of the loss. Velocity caps, delivery-delay monitoring, reserve step-ups, refund scrutiny, and close review of descriptor changes can all reduce future dispute load. These controls only work if they are tied to the signals that predict loss early enough to matter.
3. Exit
Offboarding is the hardest decision and often the most expensive one to delay. If a merchant is clearly pushing the portfolio toward a threshold and the economics do not justify the exposure, late exit costs more than early exit. By the time the ratio is already breached, the sponsor bank has more leverage than you do.
Each of those decisions needs a different time horizon. Underwriting can be slower. In-life controls need weekly or daily signals. Exit decisions often need to happen before month end, when the portfolio ratio is still movable.
What to buy and what to build
The simplest rule is to buy commodity dispute work and build portfolio risk control. That is where the line usually falls for an ISO or payfac.
| Buy | Why it makes sense | Build | Why it belongs to you |
|---|---|---|---|
| Representment and evidence assembly | High-volume, repeatable work with limited strategic value | Merchant dimension and feed normalization | You need one view across your acquirers, MIDs, and legal entities |
| Issuer-facing dispute workflow | Standardized operations with known tooling | Rolling and forecast portfolio ratio | Your sponsor cares about your book, not a single case queue |
| Alert networks and deflection tools | Useful where they reduce avoidable disputes | Merchant risk scoring using your own loss history | Your underwriting policy and merchant mix are specific to your portfolio |
| KYC and KYB vendors | Commodity identity and verification checks | Reserve and exposure ledger | You need to know what exposure is covered, by whom, and when |
| Basic case management | Helpful for dispute operations | Offboarding workflow with audit trail | Exit is a risk decision, not just an operations task |
Do not build everything. If you have fewer than roughly 200 sub-merchants, a single acquirer, and no meaningful reserve program, a portfolio model may be premature. In that case, a strong dispute tool plus disciplined manual review may be enough.
Build once you have more than one acquirer, enough merchant count that one bad actor can move the ratio, and a liability structure that makes the book’s loss your problem. At that point, the risk model is part of the business, not a nice-to-have.
A one-week diagnostic before you spend anything
If you want to know whether you have a portfolio problem, reconstruct the last twelve months from the files you already receive.
Start with acquirer dispute reports, fraud files, settlement or reversal records, and your internal merchant master. Map every record to a single merchant dimension. Then group by month, merchant, and MCC, which is merchant category code, to see which businesses are driving the trend.
From there, answer four questions:
- Which merchants contribute the most to disputes and fraud combined?
- Which merchants are trending worse in the current month than in prior months?
- Which acquirer feeds are lagging, incomplete, or using inconsistent identifiers?
- What would happen to the portfolio ratio if the top one or two merchants continued at the current pace?
If you cannot answer those questions quickly, the problem is not your chargeback queue. It is your ledger and risk model. That is the point at which chargeback management software for a single merchant stops being the right category.
What the best fit looks like
Chargeback management software is still useful. It just solves the merchant-side workflow: disputes, evidence, deadlines, and representment. If you are an ISO or payfac, that is necessary but not sufficient.
Your real requirement is a portfolio view that normalizes data from multiple acquirers, rolls it into one merchant dimension, forecasts the ratio before month end, and turns that view into underwriting, reserve, and exit decisions. That is the line between buying and building.
That same shape shows up in other regulated financial workflows: normalize many feeds into one trustworthy ledger, then make a risk decision from it. Better’s work in financial services, including transaction and reconciliation systems such as UTR8, AllOptions, and Valon, points to that same pattern. The sector is different. The underlying problem is the same.