What the Card Fee Lawsuits Mean for Your Payment Setup

Visa, Mastercard and several major banks are facing new litigation over what's being called anticompetitive fee structures. I'm not going to guess how that plays out in court. But it's worth pausing on a question it raises for anyone running software that takes card payments: if the rules around interchange fees, surcharging or processor rates changed tomorrow, could your software cope?

For a lot of businesses, the honest answer is no. Not because the payment itself would break, but because the fee logic sitting around it was never built to change.

Fees get hardcoded more often than you'd think

When a developer builds a checkout, a booking deposit or an invoicing flow, the fee calculation is often one of the last things added, and it tends to get written as a quick constant rather than something configurable. A 1.5% processing fee becomes a number typed directly into the code. A £0.20 fixed fee becomes another. Surcharge rules, if there are any, get written as an if statement that assumes the current provider's pricing will stay the same.

That's fine until one of these happens:

• Your payment processor changes its pricing tiers.
• A regulator or court ruling changes what you're allowed to pass on to customers.
• You want to switch providers because a competitor offers a better rate.
• You start taking payments in a new country with different surcharge rules.

Any one of those turns into a code change and a deployment, when it should really be a settings update. If the Visa and Mastercard litigation does lead to changes in what merchants can charge or how fees are disclosed, that's exactly the kind of shift that catches hardcoded fee logic out.

The deeper problem: fees mixed into the payment record

This gets worse when the fee isn't just hardcoded but baked permanently into a historical record. If a past invoice stores "total paid minus fee equals net amount" without recording what the fee rate actually was at the time, you lose the ability to audit or reconcile properly later. Change the fee structure going forward and your historical reports suddenly don't line up with what you remember charging.

I've written before about why payments should be recorded as a ledger rather than a single balance column. The same principle applies to fees. Every transaction should record the rate that applied to it at the time, not just the outcome. That way, when the rate changes, you don't have to go back and reconstruct what happened. You just start applying the new rate to new transactions, and the old ones stay accurate.

Processor lock-in is a related risk

A lot of bespoke software I've seen ties payment logic directly to one provider's API in places far beyond the actual charge call. Webhook handling, refund logic, dispute tracking and reporting all end up written against that one provider's specific field names and response shapes. Switching providers later, whether because of fees, reliability or just a better deal, means touching far more code than it should.

The fix isn't exotic. It's keeping a thin layer between your business logic and the payment provider's SDK, so that "charge this card" and "process this refund" are functions your software calls, with the provider-specific detail tucked behind them. It costs a bit more time upfront. It saves a lot more time the day you need to move providers, negotiate a better rate, or respond to a regulatory change that affects how fees are presented to customers.

What to actually check

If you've got bespoke software handling card payments, it's worth asking whoever built it, or checking yourself if you can read the code, whether:

• Fee percentages and fixed amounts are stored as configuration, not hardcoded values.
• Historical transactions record the fee rate applied at the time, not just a final net figure.
• Payment provider calls are isolated behind your own functions rather than scattered through the codebase.
• Surcharge display and disclosure can be changed without a developer needing to edit source code.

None of this needs to be elaborate. It's the difference between a half-day change and a multi-week one when the ground shifts under card fees, whether that's from litigation, a new regulation, or simply your processor changing its pricing with 30 days' notice.

Not every business needs to build this themselves

If you're a trades business taking deposits and card payments and you don't want to think about any of this, that's exactly why I built Patch with a single flat processing rate rather than a tiered structure that changes depending on volume or card type. Simpler pricing is easier to reason about, both for you and for whoever builds around it.

But if you're running bespoke software with payments woven through invoicing, bookings, subscriptions or payroll, it's worth treating fee logic as something that will change, because at some point it will. Building that flexibility in now is a lot cheaper than discovering its absence the week a fee structure you've relied on for years stops being legal.