What Is Payment Margin Leakage? A Vertical SaaS Guide
A few months ago, one of our clients found something buried in their statements: a per-transaction fee that had been charged twice, on every transaction, for five months. Nothing was hidden. The line was sitting right there in the statement the entire time. Nobody had caught it, because nobody was watching that number closely enough to notice.
That is payment margin leakage. It is not fraud, and it is usually not a processor scheming against you. It is money quietly leaving a vertical SaaS platform’s payments business because nobody owns the job of watching it.
I run a payment intelligence company for vertical SaaS platforms, so I see this pattern constantly. I want to give you a real definition of the term, not a repackaged version of generic “margin leakage” content written for retailers and manufacturers, and not a rebrand of SaaS billing leakage either. Payment margin leakage is its own problem, specific to platforms that embed payments, and it deserves its own definition.
What payment margin leakage actually means
Payment margin leakage is the gap between the payment margin a vertical SaaS platform should be earning on its embedded payments volume and what it is actually earning. It happens at the processing and settlement layer, not the billing layer.
In plainer language, and this is close to how I would describe it to a founder over coffee: it is the revenue a platform is missing out on by not having its payments business well organized and tracked.
Why payment margin leakage is hard to detect
Here is the part that took me a while to really internalize: this is not hard to catch because the data is hidden. It is hard to catch because you have to look at the same data through several lenses at once, per merchant, per fee type, and per potential dollar impact, to find what is actually driving a change. Most finance and ops teams do not have the tooling or the time to hold all three lenses up simultaneously. So the shift in margin gets noticed eventually, usually months later during a spreadsheet exercise, and by then the cause is much harder to trace.
What causes payment margin leakage
Most content on this topic assumes the processor is always the one at fault. Processors absolutely can be, and I have plenty of evidence of that. But treating it as the whole story is a mistake, because a meaningful share of leakage is the platform’s own doing.
On the processor side, the most common driver is what we call processor contract drift: pricing quietly shifting away from what was agreed, interchange downgrades, fees that creep up after a network change. We go deep on that specific mechanism in a separate piece, since it deserves its own treatment.
On the platform side, three patterns show up repeatedly:
Mispriced merchant segments. Platforms often assume a new merchant segment will have the same payment mix as their existing base, the same split of commercial versus consumer cards, the same ACH versus debit versus credit ratio. It usually does not. That mismatched assumption alone creates leakage from day one.
Under-captured volume. A platform may only be capturing a fraction of a merchant’s actual payment volume because the rest is routing somewhere else. I have seen this come up recently with a platform debating whether to add ACH as a payment method, a rail their merchants clearly wanted, because they were not confident they could make good margin on it. My honest view: they absolutely could, given who their merchants are. Hesitating on a rail your merchants are already asking for is its own kind of leakage, just the opportunity-cost version.
Simply not owning the number. This is the pattern behind most of what I see. Platforms treat payment margin as the processor’s problem to manage, not their own. I do not think that is right. It is too large a revenue line to fully outsource to a processing partner.
How much payment margin leakage costs vertical SaaS platforms
I would rather show you real numbers than cite an industry-wide estimate, so here are three forms of leakage we have found in client data:
A duplicate per-transaction fee, caused by an integration issue, charged on top of the correct fee for five months before the client started using Flexibl. This was one of the reasons that client decided they needed to actively monitor payment margin going forward.
An agreement-versus-statement mismatch worth roughly 3.9 basis points of the client’s processing volume over a six-month period, mostly driven by ISV fees the processor was not actually collecting from the merchant. That is under 4 hundredths of a percent, easy to write off as noise, and it still translated into a six-figure undercharge for that client, which gives a sense of how small a percentage gap can be and still matter.
Roughly $100,000 in interchange pass-through overcharges, from a processor raising pricing 5 to 15 percent on certain plans after a network change. This one is especially hard to catch, because it is small on a per-transaction basis. You only find it by aggregating per merchant and per card plan at the same time, which is exactly the kind of multi-lens problem I described above.
These are specific, anonymized examples from real client engagements, not an industry-wide average. Your own exposure will depend on your processor relationships, merchant mix, and how closely anyone is currently watching this number.
What most content on payment margin leakage gets wrong
I have read a lot of what is out there on this topic, and I think it misses in two specific ways.
First, almost nothing addresses what a platform should actually do about leakage once it finds it. Everything stops at diagnosis. That is a real gap, and one we plan to write about separately.
Second, the one piece I have seen that takes a platform-level view, rather than the usual “your processor overcharged you” framing, lands on a fix I disagree with: add more monetizable payment products. My view is closer to the opposite. I do not think you should add more products before you understand what is not working in what you already have and what your merchants actually need. Adding surface area on top of a payments business you do not fully understand tends to compound the problem, not fix it.
Who else is working on payment margin leakage
A few other companies are circling this problem from different angles, and it is worth being upfront about where we differ. Margin Labs is an advisory firm that audits take rate and processor economics for vertical SaaS platforms through manual, human-delivered engagements. Their estimates on recoverable margin, published on their own site, are in the range of 40 to 60 basis points for a typical platform. That is a reasonable outside estimate, and I would treat it as their claim rather than a universal number, since every platform’s exposure is different. Where we differ is delivery: Flexibl is software that watches this continuously, rather than a periodic manual audit.
You will also find broader “payment margin” content from middleware and orchestration platforms like Fiska, Payabli, and Rainforest. That content is mostly about how to size and structure payment monetization in the first place, a genuinely different question from leakage, which is about what happens to margin after it has already been set up.
Payment margin leakage FAQ
What is payment margin leakage? Payment margin leakage is the gap between the payment margin a vertical SaaS platform should be earning on its embedded payments volume and what it actually earns, caused by problems at the processing and settlement layer after a charge has already been correctly billed and authorized.
Is payment margin leakage the same as “payment margin” or general “margin leakage”? No, and the terms get confused often enough that it is worth being precise. “Payment margin” on its own usually means how much a platform earns per dollar of processing volume, the sizing and monetization side of the business. General “margin leakage” is a broader category from discounting, rebates, and shipping errors, mostly used in retail and manufacturing content. Payment margin leakage is specific to embedded payments: what erodes a platform’s payment margin after a charge has already been billed and authorized.
How common is payment margin leakage? There is no standardized industry benchmark for this yet, which is part of why it goes undetected for so long. What we can say directly is that we have found real, material leakage, from a few hundred dollars in a single duplicate fee to over a quarter million dollars in undercollected fees, in client data across different causes and different platforms.
What causes payment margin leakage? Causes fall into two groups. Processor-side causes include processor contract drift, interchange downgrades, and pricing changes following network updates. Platform-side causes include mispriced merchant segments, under-captured payment volume on rails merchants already want, and simply not assigning ownership of payment margin to anyone on the team.
How do you detect payment margin leakage? Detection requires looking at the same data across several dimensions at once, per merchant, per fee type, and per potential dollar impact, since leakage is often small on a per-transaction basis and only visible in aggregate. This is difficult to do manually in a spreadsheet, which is why most platforms find it late.
How do you prevent payment margin leakage? Prevention starts with someone on the team owning payment margin as an actively monitored number, not a line item you check once a quarter. Beyond that, it means validating new merchant segments against real payment mix data, revisiting rail decisions when merchants are asking for them, and reconciling processor statements against your actual agreements on an ongoing basis rather than assuming they match.
Find your own payment margin leakage
If any of the numbers above sound familiar, or you simply do not know whether they apply to you, that is the point. Most platforms do not know until someone looks closely. If you want to see what Flexibl finds in your own payment data, get in touch about a demo and we will show you.