Why Platform Fees Became the Only Math That Works in Vertical SaaS

There is a moment in the lifecycle of a vertical software company when the board deck stops leading with monthly recurring revenue and starts leading with total payment volume. That moment is not cosmetic. It marks a structural decision about what the business actually is.

The shift is worth understanding because it explains a decade of product decisions across legal tech, construction, healthcare administration, and a dozen other sectors where the pattern repeats almost identically.

Here is the basic problem. Building software for a regulated vertical is expensive in ways that horizontal SaaS is not. Compliance work, EDI integrations, credentialing workflows, specialty support staff - none of that is cheap, and none of it scales the way a general-purpose CRM scales. A company serving 400 independent insurance brokers has a cost structure that looks nothing like a company selling project management seats to knowledge workers.

Subscription pricing, at the rates the market will bear in most verticals, does not cover that cost structure while also returning venture-scale multiples. So operators look for a second lever.

The lever is almost always payments or a payments-adjacent financial product. The logic is straightforward. If your software sits at the point where money moves in an industry, you can take a basis-point cut of that movement. Basis points on large transaction volumes become real numbers. A platform processing a few hundred million dollars annually at 50 to 150 basis points generates seven figures in fee revenue without adding a single software seat.

This is not a new insight. What changed over the past decade is the infrastructure to act on it. The emergence of embedded finance tooling - payment facilitation APIs, lending-as-a-service rails, insurance distribution layers - dropped the build cost of owning that transaction layer from something requiring a dedicated fintech team to something a small engineering squad can wire up in a quarter.

The architectural consequence is that the software itself becomes a funnel. Features are evaluated partly on whether they move more transaction volume through the platform. A feature that saves a contractor two hours of scheduling time is good. A feature that saves the same two hours and routes the resulting invoice through the platform's payment rail is better, because it has a measurable revenue attachment.

Critics of this model point out the misalignment risk. When the platform earns on volume, it has an incentive to maximize volume rather than optimize outcomes for the operator using the software. In healthcare billing, that tension is acute. In construction draw management, it is visible but more contained. The severity depends on how captive the end user is and how transparent the fee structure is.

The more interesting structural question is what happens to competition when platform fees dominate unit economics. Subscription price wars are common in SaaS. Basis-point competition is harder to execute because the switching costs are higher - migrating payment flows means retraining staff, updating vendor records, and absorbing a period of reconciliation risk. Incumbents with established payment volume have a moat that pure software companies do not.

This is why acquirers in vertical software pay premiums for companies with high payment attach rates. The multiple is not just on ARR. It reflects the defensibility of the transaction layer sitting underneath the software.

For operators evaluating these platforms, the practical implication is that the software license fee is increasingly the cost of entry rather than the primary cost of the relationship. Reading the payment terms carefully, and modeling what basis points on your transaction volume actually equals in dollars, is now as important as reading the SLA.