Why Every SaaS Platform Will
Embed Payments by 2028

Three years ago, embedding payments was a competitive differentiator. Something you did if you were building a marketplace or a vertical SaaS company trying to add a revenue line. Everyone else plugged in a hosted checkout page and moved on.

That's changing fast. And if you run a SaaS platform with more than a few thousand active users, the pressure to own your payment layer is already real — you just might not be labeling it as such yet.

What "embedded" actually means

Embedded payments is an overloaded term. When payments people say it, they usually mean one of three things:

First, there's the payment experience — your users never leave PayLoop to enter card details. The checkout UI lives inside your app, not on a third-party-branded page. Second, there's payment acceptance — your platform facilitates money movement between parties (your users and their customers), not just collects money from your own subscribers. Third, there's payment infrastructure — you control routing, settlement, reconciliation, and reporting, rather than consuming those as black-box services.

The distinction matters because each layer requires different technical work and unlocks different economics. Most SaaS companies start at layer one. The interesting transition is when they move to layers two and three.

The economics forcing the transition

Payment processing fees on a standard Stripe or Braintree integration run 2.7% to 3.5% per transaction for card-not-present volume. At low revenue levels, this is noise. At $5M ARR with meaningful transaction volume, it starts showing up as a material cost center. At $50M ARR, it's a board-level line item.

What changes when you embed payments properly is the ability to negotiate interchange rates directly, optimize routing by card type and issuer, and capture a portion of the payment margin rather than paying all of it to a processor. For a platform doing $100M in annual payment volume, routing optimization alone typically moves net processing costs from 2.8% to 1.9–2.1%. That's $700K to $900K annually — real money, not theoretical.

The revenue side is more significant. Platforms that facilitate payments between their users and end customers (think: a project management tool with client invoicing, a vertical SaaS for service businesses, a B2B marketplace) can capture payment facilitation economics directly. Instead of paying 2.9% + 30¢ to a processor, they collect 2.9% + 30¢ from their users and pay wholesale rates underneath. The spread — typically 0.3% to 0.8% of volume — flows directly to platform revenue.

That doesn't sound like much until you do the math. A platform processing $500M annually at a 0.5% net take rate generates $2.5M in payment revenue on top of subscription fees. For most SaaS companies, that's 10–20% of total revenue from a product surface they were previously just passing through.

The user retention angle

The economics case is straightforward. The retention case is less obvious but maybe more important.

When your users process payments through a third-party tool embedded (loosely) in PayLoop, payment data lives somewhere else. Dispute history lives somewhere else. Payout scheduling lives somewhere else. Your reconciliation reports are only as good as the export you can pull from your processor.

That fragmentation creates churn vectors you can't see in PayLoop analytics. A user who leaves because their payment experience was bad, or because they want consolidated reporting, won't tell your NPS survey that. They'll just churn to a competitor who has a more complete stack.

The SaaS companies with the lowest churn rates in payments-adjacent verticals — property management, contractor software, professional services tools — have consistently moved toward owning their payment layer. It's not coincidental.

Where the technical barrier has moved

The main reason SaaS companies didn't embed payments five years ago was the compliance burden. Getting an account with a payment facilitator, handling KYC for sub-merchants, maintaining PCI scope — these were real engineering and legal problems that took months to sort out.

The infrastructure layer has matured significantly. Modern payment APIs handle KYC as part of merchant onboarding, manage PCI scope on your behalf (keeping you at SAQ-A rather than SAQ-D), and provide the webhook infrastructure for real-time event processing that you'd otherwise have to build yourself.

The integration surface that used to take three months of engineering now takes three to four weeks for a team that's done it once. For teams using an embedded payments API directly, the timeline is shorter. The onboarding for sub-merchant KYC that used to require a custom banking integration is typically handled in the API layer.

What 2028 looks like

The trend lines are clear. Interchange optimization, payment facilitation margins, and user retention pressure will push every serious SaaS platform above roughly $10M ARR to embed payments rather than outsource them. Not because it's a product strategy — because leaving that revenue on the table will be increasingly hard to justify to investors.

The platforms that are starting this work now have a two-year head start on the ones waiting to see how it plays out. Two years in payment infrastructure is roughly the gap between having clean reconciliation data and spending two weeks every quarter cleaning up transaction logs manually.

If you're in the $5–50M ARR range and payments touch any part of PayLoop, the question isn't whether to embed. It's how soon you can staff the work.