What Causes Interchange Downgrades? A Technical Breakdown

If you run payments at a vertical SaaS platform, you have probably read the standard advice on interchange downgrades: settle within the window, pass AVS, send enhanced data on commercial cards. That advice is not wrong. It was written for a single merchant who owns their own checkout and can act on all of it. A platform sitting above thousands of sub-merchants is in a different position. Some of the causes are yours to fix. Some belong to your provider. And the hardest part is usually not fixing the downgrade at all. It is isolating it.

What is an interchange downgrade?

An interchange downgrade is a transaction that fails to qualify for the interchange program it was eligible for and gets rated into a more expensive category instead. The rating is not decided at checkout. It is decided at clearing, when the card network evaluates the fields in the clearing record: the merchant category code, the card type, the amount, verification data such as AVS, and the consistency of the clearing record with the original authorization. If a rating-relevant field is missing, malformed, or inconsistent, the network does not reject the transaction. It processes it at a worse rate. The payment succeeds, it just costs more, and nothing at the point of sale tells you it happened.

That last point is worth sitting with. Authorization data tells you whether a payment succeeded. Clearing and settlement files tell you what it cost, in a different shape and on a different schedule. A platform can have a perfectly healthy authorization stream and still be paying downgraded rates on a meaningful slice of its volume, because the two datasets answer different questions.

Which causes can a platform fix itself?

Every downgrade cause has an owner, and the owner is not always you. In practice, the causes we see fall on both sides of a clear line.

On the platform’s side: verification data, AVS in particular, that is not captured or not passed. And data that used to flow and stopped: an integration change, a field dropped somewhere between your software and your provider, a payload that no longer carries what it carried last quarter. These are fixable at the platform level, once you know which merchants and which transactions they touch.

On the provider’s side: the merchant category code assigned at boarding, and the construction of the clearing record itself. Networks rate transactions against programs whose requirements interlock: fields whose required values depend on each other and on the MCC, the amount, and the card type. That record is assembled downstream of you. A platform can pass everything correctly and still see downgrades, because the record the network rates is not exactly the record the platform sent.

One example from our own work. A Visa downgrade across a platform’s portfolio traced to a single amount field arriving as 0.00 in the clearing record. The platform’s data was correct. The fix happened at the provider level, and the platform could not have found the cause in its own authorization data, because nothing in the authorization was wrong.

Sometimes the platform is not even the party that notices. We have seen a platform learn something was wrong because merchants started flagging that their pricing was abnormally high. In an ISO or reseller setup, nobody may be monitoring interchange at all, and the merchants become the alerting system. That is the worst version of detection.

Why are interchange downgrades so hard to detect on a platform?

A downgrade that hits the whole portfolio moves the blended cost of payments, and someone eventually asks why. A downgrade that hits one segment disappears into the average. Across thousands of merchants, a segment paying downgraded rates is invisible in a portfolio-level effective rate, because higher-volume, better-rated merchants mask it. This is the same masking that makes [processor contract drift] expensive: the aggregate looks stable while a subset quietly moves.

The cut that unmasks it is per merchant, per interchange plan, over a defined period. When something looks off at that resolution, the investigation goes narrower still: isolate the impacted segment, then work through each fee and each interchange plan of each merchant until you know which fee, which merchant, which plan is downgraded. That work is tedious, which is why it rarely gets done by hand, and why detection so often starts with a complaint instead of a report.

A downgrade is not a missed program

Two different things get mixed together under interchange optimization, and separating them changes what you do next. A downgrade is a problem: a transaction that failed to get the rate it qualified for. Problems can almost always be resolved, even when the fix sits with the provider, or between the provider and the network, rather than with you. A better program you have not reached yet is something else entirely. If reaching it requires program enrollment or provider support you do not have, that is not the network punishing you. It is an optimization you have not made yet, with its own cost-benefit question attached.

Visa’s Commercial Enhanced Data Program is the current example: it needs Level 2 and Level 3 data on business cards, and whether it is reachable depends on what your provider can support. We have seen a platform pass every CEDP formatting requirement and still not access the better margin on commercial credit, its largest card volume. Nothing was malformed. That is precisely what makes it an optimization question rather than an issue: the answer lives in program access and provider support, and it cannot be read off the platform’s own data.

Which downgrades can’t you fix from the platform’s seat?

Three patterns come up again and again. The provider cannot support what the program requires. The solution sits between the network and the provider, so the platform has no lever to pull. Or the reason simply cannot be understood from the platform’s seat, because the data that would explain it lives elsewhere. There is also a fourth category that looks similar but is not: volume too small to be worth the effort. That is not a downgrade you cannot move. It is a resource decision, and a sane one, about where investigation time goes.

Finding a problem is not the same as being able to solve it yourself. What follows detection is a loop: recognize the pattern, validate it on the specific merchant’s data, fix it with whoever owns the cause, then monitor that the cost actually falls. Interchange failure modes are finite and they repeat: a failed data verification, a rating-relevant field missing or malformed. Seeing a pattern gives you a strong hypothesis. Validation on the merchant’s own data is what turns it into a confirmed cause, and monitoring is what proves the fix held.

This is where my own work sits. At Flexibl, I spend my days with the team watching these patterns repeat across platforms and turning that recognition into a product, so that finding which fee, which merchant, which plan no longer costs a payments team its quarter. The patterns are finite, from [payment margin leakage] down to the individual rating field. What we build is the judgment on top: what a downgrade means, who owns the cause, and whether it is worth moving.

If you want to see your own portfolio at per-merchant, per-plan resolution, [book a demo].

FAQ

What is an interchange downgrade? An interchange downgrade is a transaction rated into a more expensive interchange category than the one it was eligible for. It happens at clearing, when the card network finds a rating-relevant field missing, malformed, or inconsistent with the authorization. The payment still succeeds; it just costs more.

Can interchange downgrades be fixed? Most can be resolved, but not always by the merchant or the platform. Causes like missing AVS data or fields that stopped flowing are fixable at the platform level. Causes inside the clearing record or the MCC assignment are fixed with the provider, and some require support the provider has to build.

Why don’t interchange downgrades show up in my effective rate? A portfolio-level effective rate blends thousands of merchants, so a downgraded segment is masked by the volume around it. Downgrades become visible when cost is cut per merchant and per interchange plan over a defined period, not when it is averaged.

What is AVS and why does it affect interchange? AVS, the Address Verification Service, checks the billing address and zip code a customer provides against what the card issuer has on file. Several interchange programs for card-not-present transactions expect AVS data to be present, so a platform that does not capture or pass it can see those transactions rated into a more expensive category.

Does interchange analysis require cardholder data? No. Interchange rating is computed from category-level attributes such as MCC, card type, scheme, and amount, so the analysis works on rating attributes and aggregates from clearing and settlement data rather than on cardholder details.