The Hidden Revenue in
Payment Processing Fees

Every payment your users process generates a fee. Some of that fee goes to the card networks (Visa, Mastercard). Some goes to the issuing bank. A portion goes to the payment processor. And if you're not structured as a payment facilitator, you see none of it — even though your platform is the reason the transaction happened at all.

This isn't a niche fintech insight. It's just how the payments stack works, and most SaaS founders learn about it after they've already given away millions in potential revenue.

How the fee waterfall actually works

When a cardholder makes a payment, the gross fee — typically 1.8% to 3.5% depending on card type — splits between several parties before anyone sees net settlement.

Interchange goes to the issuing bank. This is the largest component and non-negotiable — it's set by Visa and Mastercard and varies by card type (consumer debit, commercial credit, rewards cards all carry different rates). A typical consumer Visa transaction might carry 1.51% + 10¢ in interchange. A corporate rewards card can hit 2.35% + 10¢.

The assessment fee goes to the card network itself — roughly 0.13% to 0.15% for Visa, slightly more for Mastercard. Small but unavoidable.

What's left after interchange and assessment is the acquirer/processor margin. On a standard retail rate of 2.9% + 30¢, the processor's gross margin on a $100 transaction is roughly 90–110 basis points. That's where the economic opportunity for payment facilitators lives.

What changes when you become a PayFac

A payment facilitator (PayFac) sits between the processor and your end merchants. Instead of each of your users having their own merchant account, they're onboarded as sub-merchants under your master merchant account. This has two major effects on your economics.

First, you pay acquirer rates rather than retail rates. Instead of 2.9% + 30¢, you're typically paying 2.2–2.4% + 15–20¢ for standard card volume, depending on your processing volume and risk profile. On $1M per month in volume, that's a cost reduction of $6,000–$8,000 per month just from better rates.

Second, you set the rates your sub-merchants pay. If you charge your users 2.9% + 30¢ and pay 2.3% + 18¢ underneath, you're capturing roughly 60 basis points on every transaction. On $500M annual volume, that's $3M in gross payment revenue before any operational costs.

The math works at smaller scales too. $50M annually at 50 basis points net is $250K in payment revenue — meaningful for a company at $5–10M ARR in subscription fees.

The operational cost you have to factor in

Payment facilitation isn't free money. There's real operational overhead to account for.

KYC and onboarding for sub-merchants costs time and money. If you're onboarding merchants manually, you're spending $15–40 per merchant in compliance processing costs before they process a single dollar. Automated KYC via API reduces this significantly but it's still not zero.

Chargeback liability is the other major factor. As a PayFac, you absorb chargeback risk for your sub-merchant portfolio. If a sub-merchant has an unusually high dispute rate and you don't catch it early, you can end up with reserve holds or liability that eats into your processing margin on that account. A well-run PayFac operation has monitoring in place to flag high-risk accounts before they become a problem, but this is engineering work.

Realistic operating costs for a mature PayFac setup — KYC ops, fraud monitoring, dispute handling, reconciliation — typically run 15–30 basis points of volume. So if you're grossing 60 basis points on spread, expect 25–30 basis points in net after ops. That's still a significant revenue line at meaningful scale.

The simpler path: revenue sharing

Not every platform needs to go full PayFac. There's a middle path that captures some payment economics without taking on full sub-merchant liability: revenue sharing arrangements with your payment processor.

Under a revenue share structure, your processor handles all the PayFac compliance and merchant liability — you just refer your users to their platform through an integrated experience. In exchange, you receive a share of the processing margin, typically 10–25 basis points of volume depending on your deal terms.

It's less margin than operating as a PayFac yourself, but the operational complexity is substantially lower. For platforms under $50M in annual payment volume, revenue sharing often makes more economic sense than building a full PayFac operation.

What the actual numbers look like at scale

We see a fair amount of platforms that have gone through this analysis. The pattern is pretty consistent: platforms discover the payment revenue opportunity, underestimate the operational overhead, then end up landing somewhere between full PayFac and revenue share depending on their volume and risk appetite.

At $10M annual payment volume: revenue share at 15 basis points generates $15,000/year. Not enough to justify a PayFac build.

At $100M annual payment volume: PayFac at 30 basis points net generates $300,000/year. Now the math is interesting.

At $500M annual payment volume: PayFac at 30 basis points net generates $1.5M/year. This is a business unit, not a line item.

The inflection point where full PayFac economics outperform revenue sharing is typically around $75–100M in annual processing volume, accounting for the operational costs to run it properly.

The infrastructure requirement

Whether you go full PayFac or revenue share, you need payment infrastructure that can handle sub-merchant management, split payments, and real-time reporting. That's not something you build from scratch — it's something you integrate via a platform designed for it.

The platforms that capture payment economics successfully are the ones that treat it as a product investment, not a finance project. The reconciliation tooling, the dispute workflow, the sub-merchant dashboard — these need to work as well as the rest of PayLoop. The ones that bolt it on as an afterthought end up with operational overhead that eats the margin they were trying to capture.