Ask most people what a card transaction costs and you get a single number: 2.9% plus 30 cents, maybe. That number is a convenience, not a fact. Underneath it, the US interchange system sorts every transaction into one of roughly a thousand distinct rates, and the one it lands on is decided by details most platforms never see.
Understanding that system is the difference between managing your largest cost line and hoping it behaves.
Every transaction is quietly assigned one of a thousand rates. You are billed the outcome, never the reason.
Interchange is the base cost, and it is not one number.
Interchange is the fee the card-issuing bank keeps on every transaction. The card networks, Visa and Mastercard, publish the rates, and interchange is the largest component of what you pay to accept a card. It is also not negotiable: interchange is broadly the same wherever you process, which is why switching processors does nothing to it.
What makes interchange hard is not the size. It is the shape. Visa alone publishes an interchange schedule running to dozens of pages with hundreds of individual entries, and across the networks the system contains roughly a thousand rate permutations. Each is defined by a specific combination of card type, merchant category, transaction data, and how the transaction was processed.
Qualification decides which rate you get. Data decides qualification.
A transaction does not pick its own rate. It qualifies for one, based on what the network sees. The main inputs:
- Card type — a basic consumer debit card and a premium corporate rewards card carry very different interchange, often tens of basis points apart.
- Data provided — commercial and corporate cards can qualify for lower rates when richer Level 2 and Level 3 data is passed. Missing that data means a higher rate.
- Timing and integrity — settlement timing, address and card verification, and authorization integrity all affect qualification.
- Channel — card-present, card-not-present, and keyed transactions qualify differently.
Get the inputs right and the transaction settles at the rate it is entitled to. Get them wrong and it downgrades.
A downgrade is a silent tax on a transaction that should have cost less.
When a transaction fails to qualify for the rate it was eligible for, it downgrades to a more expensive one. The transaction still goes through. The customer notices nothing. The only trace is a slightly higher cost on a line item buried in a statement with dozens of others.
Downgrades happen for mundane reasons: a commercial card processed without Level 2 data, a transaction settled a day late, a missing verification field. Individually, cents. Across a book, a persistent leak.
Whether a given downgrade can be fixed depends on the merchant’s transaction flow, integration, and card mix, and it has to be validated per merchant before anyone promises a number. Statements size the problem. Transaction-level data proves the fix.
Blended pricing is designed so you cannot see the rate at all.
Under a blended plan, every transaction is billed at the same headline rate regardless of what it actually cost to process. A debit transaction that cost a few basis points and a premium rewards transaction that cost far more can show the same price to the merchant. The averaging is convenient, and it is exactly what hides the thousand rates underneath.
The processor’s statement compounds it. It reports the outcome, the blended effective rate, not the qualification decisions that produced it. To see whether transactions are qualifying correctly, you need the transaction-level data and the interchange logic to check it against. Neither is on the statement.
You cannot fix what you cannot decompose.
Managing the thousand-rate problem is not a pricing negotiation. It is a data problem. It requires decomposing cost to the transaction level, mapping each transaction to the rate it was entitled to, and identifying where and why it downgraded.
From there the fixes are real but specific: passing Level 2 and Level 3 data where the card type supports it, tightening settlement timing and verification, and matching the lever to the actual cause rather than assuming one. What it is not is a single switch. The complexity that hides the cost is the same complexity that makes the fix a per-merchant, evidence-first exercise.
