The revenue most SaaS platforms are leaving on the table
Every vertical SaaS platform that processes payments on behalf of its customers is sitting on a revenue opportunity most of them aren't capturing. Not because the money isn't there — it is. Because the architecture was never designed to capture it.
The average embedded payments program captures 5–15% of available payment revenue. Programs designed for monetization from the start capture 30–42%. That gap is architectural. Here's what it actually consists of.
The four revenue streams embedded payments generates
1. Interchange revenue
Every card transaction generates interchange — a percentage of the transaction value paid by the merchant's bank to the card issuer. In a well-designed program, a meaningful portion of that interchange flows to you. In most SaaS platforms, it flows entirely to the infrastructure layer.
The difference is program model and BIN structure. BaaS platforms capture interchange on their own account and share a portion with you — or don't, depending on how your contract is structured. A direct or hybrid program model puts interchange capture in your control.
Typical range: 0.5%–1.8% of card transaction volume, depending on card type, interchange category, and Level 2/3 data transmission.
2. Float revenue
Customer balances held in FBO accounts generate yield. At current interest rates, $10M in average daily balances generates $400K–$500K annually. Most SaaS platforms have no visibility into this — the bank keeps it by default unless float economics were explicitly negotiated into the bank relationship.
This is one of the most consistently uncaptured revenue streams in embedded finance. It requires negotiation at the program design stage — it cannot be retrofitted easily once the bank relationship is established.
3. Fee revenue
Speed fees, convenience fees, premium rail pricing — the willingness to pay for faster payment delivery is consistently underestimated. Enterprise AP programs pay for same-day settlement. Marketplace sellers pay for instant payout. The spread between your delivery cost (RTP or FedNow transaction cost) and what the recipient values (immediate cash) is real margin.
Most platforms price fees by benchmarking competitors. The correct approach is pricing against value delivered — which almost always supports higher fees than the market average.
4. Data and remittance products
Structured remittance data — invoice-level detail attached to a payment — eliminates manual reconciliation for your customers' AR teams. That has real economic value. Most SaaS platforms provide it for free because they never modeled the willingness to pay.
Why most SaaS platforms undermonetize
The mechanics are consistent across programs that underperform:
Infrastructure was selected before the economics model was defined. The BaaS provider or processor was chosen because they had the fastest demo cycle or the most familiar brand. Their default commercial terms became the program's economics — because no one had defined an alternative.
Fee structure was copied from competitors or inherited from vendor schedules. Neither is a revenue optimization strategy. Both are a failure to model what your customers will actually pay for the value you're delivering.
Float economics were never negotiated. The bank relationship was established without explicit terms around yield sharing. This is a default condition — the bank keeps it unless you ask for otherwise.
The calculation most SaaS founders haven't run
Take your current monthly payment volume. Apply a 0.8% blended interchange capture rate (conservative for a well-designed program). That's your annual interchange revenue opportunity.
Take your average daily customer balance. Multiply by 4% (conservative yield estimate). That's your annual float revenue opportunity.
For most vertical SaaS platforms processing $20M–$100M monthly, these two numbers together represent $2M–$15M in annual revenue that currently flows to the infrastructure layer rather than to you.
That's not a small number. And it doesn't require more volume — it requires better architecture applied to the volume you already have.
What it takes to capture it
Three things have to be true simultaneously:
The program model has to support interchange capture. BaaS by default does not — interchange flows to the BaaS provider and you receive a portion only if the commercial terms explicitly provide for it. A direct or hybrid model gives you full interchange visibility and negotiating position.
The BIN structure and card mix have to be optimized. Card type, Level 2/3 data transmission, and interchange category selection all determine the interchange rate you actually receive. These are configuration decisions that most platforms never revisit after launch.
The bank relationship has to include float economics. This is a negotiation that happens at program inception — not after. Once the bank relationship is established without explicit float terms, recovering them requires a relationship renegotiation or a bank change.
The question to ask before your next payments decision
If you already have a payments program running, the question isn't whether you're leaving money on the table. You almost certainly are. The question is which specific leakage categories apply to your program and what fixing them is worth at your current volume.
If you're designing a payments program, the question is whether the economics model is being designed before infrastructure selection — or whether vendor defaults are about to define your revenue ceiling for the next several years.