What is a residual, exactly?
A residual is the ongoing share of processing revenue an ISO, agent, or sub-ISO earns from a merchant's transaction activity, for as long as that merchant continues processing. It's the reason the ISO channel is often described as a residual-income business: the value of a portfolio isn't just the merchants signed this month, but the compounding stream of revenue from every merchant signed in every prior month who's still processing.
The core mechanic is simple — a merchant is charged a rate for processing, the cost of actually moving that transaction (interchange, network fees, processor cost) is subtracted, and what's left is split between the parties in the chain according to whatever agreement governs that merchant. The complexity comes from how many parties can be in that chain, and how many different agreements can apply across a single portfolio.
Where does residual revenue actually come from?
Residual revenue is the spread between what a merchant is charged and what it actually costs to process that merchant's transactions. That spread has to cover:
- Interchange — the fee paid to the card-issuing bank, set by the card networks and largely non-negotiable.
- Network assessments — fees paid to Visa, Mastercard, and other networks for using their rails.
- Processor cost — what the actual processing infrastructure charges to authorize and clear the transaction.
Whatever remains after those costs is the revenue available to split among the retail ISO, any sub-ISOs or agents involved, and any FSP or ISV partner with a commercial stake in that merchant. How that remainder gets split — and to whom — is defined by the agreements each party has, which is where residual calculations start getting genuinely complicated.
Why do residual splits get complicated fast?
A single merchant's residual can touch several distinct commercial relationships at once:
- An agent who originated the merchant relationship, earning a percentage of that merchant's residual.
- A sub-ISO operating beneath a larger ISO, earning its own share and passing a portion upward.
- An ISV or software partner who referred the merchant through an embedded payments integration, earning a revenue-participation percentage.
- The retail ISO itself, earning what remains after every other party's share.
Each of these relationships can have its own commercial terms, and a portfolio with hundreds or thousands of merchants can easily have dozens of different split structures active simultaneously. Multiply a merchant's monthly transaction volume by its specific rate, subtract true cost, then apply however many splits apply to that specific merchant — and do that correctly, every month, for every merchant in the portfolio.
Why are residual disputes so common?
Residual disputes tend to come from one of a few recurring sources:
- The split percentage on file doesn't match what someone believes was agreed. Verbal agreements or outdated records drift from what a processor's system actually applies.
- The underlying transaction data doesn't match. A processor's report and an ISO's own tracking disagree on volume, chargebacks, or fees for a given period.
- A merchant's true cost changed — a new pricing tier, an interchange change, or a fee schedule update — without every party's split calculation reflecting it at the same time.
- Nobody can point to the specific transactions behind a number. When a residual figure is a spreadsheet total rather than something traceable to individual transactions, resolving a dispute becomes a matter of trust rather than evidence.
That last point is usually the real issue. A residual dispute is fastest to resolve when every dollar in a statement can be traced back to the specific transaction that produced it — and slowest to resolve when the number is an aggregate nobody can immediately decompose.
What actually prevents residual disputes from becoming a monthly event?
The structural fix isn't a better spreadsheet — it's calculating residuals from the same transaction-level data every party can see, rather than from separately maintained records that inevitably drift apart. When every commercial split (agent, sub-ISO, ISV, retail ISO) is calculated from one unified ledger, a dispute becomes a matter of pointing to the transaction in question rather than reconciling two different systems' totals.
This is the specific problem NGnair's revenue and portfolio management infrastructure is built to solve — residuals, splits, and partner statements calculated from one transaction ledger, so a disputed number is always traceable to the activity behind it.
The short version
Residuals are the ongoing share of processing revenue an ISO and its partners earn from a merchant's continued activity — calculated from the spread between what a merchant is charged and true processing cost, then split according to whatever agreements apply. Disputes are common not because the math is inherently hard, but because the underlying transaction data usually isn't shared across the parties who need to trust the same number.
A residual number every party can trust starts with a shared ledger — see how NGnair calculates them.
