There's a quiet conversation happening in board rooms across the SaaS industry: "what if we owned payments?" The math is seductive. A vertical SaaS company charging $200/month for software can layer payment processing on top, take 30 basis points of every transaction the merchant runs, and double or triple their per-customer revenue without selling a new product.
Toast did this with restaurants. Mindbody with fitness studios. ServiceTitan with home services. Vagaro with salons. The pattern is clear, the success stories are public, and every other SaaS CEO is asking their CFO whether the company should follow.
The math works. The execution is harder than it looks. I've watched several SaaS companies attempt this transition. Some succeeded. Some quietly abandoned the project after burning $5–10M building infrastructure they didn't really understand. The pattern of who wins and who loses is more predictable than you'd think.
What "embedded payments" actually means
The term gets used loosely. Three distinct models, with very different economics and complexity:
Referral / partnership. The SaaS platform refers customers to a payment processor (Stripe, Square, etc.) and gets a small revenue share. Lowest revenue, lowest complexity. Mostly a marketing arrangement. Not really "embedded payments" in any meaningful sense.
ISV (Independent Software Vendor) integration. The SaaS platform integrates a processor's APIs deeply, embedding payment flows in their product. The processor still owns the merchant relationship, sets fees, handles compliance. The SaaS platform takes a revenue share, often 5–20 basis points.
Payfac (Payment Facilitator) or PSP-of-record. The SaaS platform becomes the payment processor — or close to it — for their customers. They own the merchant relationship, set the fees, handle the compliance, take the bulk of the take rate (anywhere from 60–250 basis points depending on the model).
The third model is what people usually mean when they say "becoming a payments company." It's also where the complexity lives.
The take-rate math
Let's be specific about why this is attractive.
A SaaS company charges $200/month per merchant. They have 5,000 merchants. Annual SaaS revenue: $12M.
The same merchants process $50,000/month each on average through the SaaS platform. That's $250M of payment volume per month, $3B per year, across the merchant base.
If the SaaS platform becomes the payment processor at a 100 bps (1%) take rate (roughly typical for vertical SaaS), they earn $30M annually on payments. Two and a half times their SaaS revenue, with the same customer base.
This is why every vertical SaaS company wants payments. The volume is already flowing through their software. They just need to insert themselves between the merchant and the processor and capture the take rate.
The full payfac model
The full payfac model means becoming a payment facilitator under Visa/Mastercard rules. The SaaS platform applies for sponsorship from a sponsor bank, signs agreements with the card networks, and then onboards their own customers as "sub-merchants" rather than directly as merchants.
The platform becomes responsible for:
- Underwriting their sub-merchants (KYC/KYB).
- Compliance with PCI DSS at the highest level (Level 1 for most).
- Risk monitoring and chargeback management.
- Settlement to sub-merchants.
- Funding the sub-merchants from processor settlements.
- Reporting (1099-K in the US, equivalents elsewhere).
- Defending sub-merchant disputes.
- Absorbing fraud losses (or charging them back to sub-merchants).
The economics: the platform earns the full merchant discount rate (2–4%), pays the interchange and assessments to the networks (1.5–2.5%), and keeps the difference. On a $1B annual volume, that's $5–15M of net take rate, before operational costs.
The operational costs are not small.
What payfacs actually do
I've worked with payfac platforms. Here's what their teams look like:
- Engineering. Building and maintaining the payment platform itself. Probably 30–50 engineers at scale, across orchestration, fraud, compliance, reporting.
- Risk and underwriting. A team of analysts reviewing applications, monitoring sub-merchant behavior, deciding when to terminate accounts. 10–30 people for a mid-size payfac.
- Compliance. A dedicated compliance officer, typically a VP-level hire with banking background. Plus analysts handling SAR filings, sanctions screening, regulatory reporting.
- Operations. Handling chargebacks, disputes, customer support escalations. 20–50 people depending on volume.
- Finance. Reconciliation, settlement, treasury management. The platform is now a financial entity with cash management responsibilities.
That's roughly 75–150 people who didn't exist in the company before payments. Their fully-loaded cost is $20–40M/year. To break even, the platform needs at least $1B in annual processing volume at typical take rates.
This is why most SaaS companies that "want to be payments companies" eventually settle for the ISV model instead. The full payfac model is a different business, with different operational requirements, and most software companies don't have the appetite or the expertise.
Stripe Connect, Adyen for Platforms, and the middle ground
Recognizing that most SaaS companies want the economics without the operational burden, the major processors built platform offerings:
- Stripe Connect (and the various sub-products: Standard, Express, Custom)
- Adyen for Platforms
- Square's Payments API for platforms
- Worldpay for Platforms
These offerings let a SaaS platform get most of the payfac economics — typically 50–80 bps net take rate — while delegating most of the operational burden to the processor partner. The SaaS company onboards merchants through the partner's APIs, the partner handles underwriting and compliance, and the SaaS company collects a revenue share.
This is the right answer for most SaaS companies entering payments. The economics are still attractive. The operational burden is much lower. The time to market is months, not years. The major question becomes: how deep does the integration go, and how much of the merchant experience does the SaaS company control?
The deepest model (e.g., Stripe Connect "Custom") gives the SaaS company control over the merchant onboarding flow, the dashboards, the disputes UI, the reporting. The merchant experiences a single brand — the SaaS company's — even though Stripe is doing the underlying processing.
The shallowest model (e.g., Stripe Connect "Standard") sends merchants through Stripe's standard flows. The SaaS company gets a smaller revenue share but does almost no integration work.
The choice is mostly a function of how strategic payments is to the SaaS company's competitive position. If payments is the moat, you want the deepest integration. If it's a revenue add-on, the shallow integration is enough.
What the integration actually looks like
A SaaS company building embedded payments through Stripe Connect Custom (a typical "platform" model) ends up building:
Onboarding flows. A KYC/KYB collection experience embedded in the SaaS product, not branded as Stripe. Calls Stripe's APIs to register the sub-merchant.
Payment flows. Credit card collection (using Stripe.js or equivalent), payment intent creation, confirmation, capture. Integrated into the product's checkout, invoicing, or POS surfaces.
Webhooks. Receiving and processing Stripe events for the sub-merchant: payments succeeded, disputes opened, payouts settled, etc. Routing them to the right merchant in the SaaS database.
Reporting. Payment volume, fees, payouts, disputes — all surfaced to the merchant in the SaaS product. Plus internal reporting on the platform's own take rate.
Disputes. A workflow for sub-merchants to respond to chargebacks, with evidence collection and submission to Stripe.
Payouts. The mechanism by which sub-merchants receive their funds. Often the SaaS company holds the funds briefly (for reserve, for fee deduction) before paying out.
Reconciliation. Daily reconciliation between the SaaS company's records, Stripe's records, and the sub-merchant's expectations. Deviations get investigated.
Tax reporting. 1099-K generation at year end, plus state-level reporting where required.
This is a 12–24 month engineering project for a typical SaaS team. The first 6 months are basic flows; the next 6 are edge cases; the next 6+ are the long tail of disputes, reporting, regional expansion, compliance updates.
The hidden costs
A few costs that aren't obvious until you're in:
Reserves. The platform may need to hold reserves against potential chargebacks. For a fast-growing platform, this is real working capital tied up. Typically 2–10% of monthly volume, depending on risk profile.
Fraud absorption. The platform absorbs fraud losses from sub-merchants who can't or won't cover them. This is real money out the door, often 5–20 bps of volume.
Chargeback fees. Each chargeback costs $15–25 in fees to the platform, separate from the disputed amount. At scale, this is meaningful.
Compliance churn. Regulations change. The card networks change rules. New jurisdictions get added. New product types trigger new rules. Each change requires platform-side updates.
Sub-merchant termination. Sometimes the platform has to terminate a sub-merchant for fraud, compliance, or business reasons. This is a complex operational event involving fund holds, customer notification, asset transfer, regulatory filings.
Tax reporting accuracy. 1099-K errors are a serious problem at the IRS. The platform's tax reporting infrastructure has to be exactly right, every year, for every sub-merchant. Tax season is a high-stress operational period.
I've seen platforms launch embedded payments without budgeting for these costs and find their economics worse than projected by 30–50 bps. The take rate looks great until you net out fraud, reserves, chargeback fees, and operational overhead.
When embedded payments is the wrong answer
Not every SaaS company should do this. Signs you shouldn't:
- Your average transaction size is small. $5 transactions don't generate enough take rate to cover the operational overhead. You need either average transactions above $50 or volume above $500M annually.
- Your customers process payments only occasionally. A consulting firm that bills clients monthly isn't doing enough volume to make embedded payments compelling.
- Your customers are highly regulated or high-risk. Some industries — gambling, certain pharmaceuticals, cannabis — require specialized payment infrastructure that's not what a generalist SaaS platform should build.
- Your customers already have established processor relationships. Convincing an enterprise customer to switch their payment processing from their long-time provider to your platform is hard. They have negotiated rates, integrated reporting, established trust.
- Your existing margins are high. If you're a 90% gross margin software company and payments is a 60% margin business, doing payments dilutes your margins even if it grows your revenue. Some boards don't want this.
The companies that should pursue embedded payments are the ones where payments is core to the customer's daily operation, transaction volumes are predictable and meaningful, and the SaaS product is the customer's primary operational system. Toast for restaurants is the canonical example. The customer runs their entire business on Toast; payments are a natural extension; the customer's existing processor is replaceable.
The competitive dynamic
Once a SaaS vertical has a payments-led leader (Toast in restaurants, Mindbody in fitness), the dynamic forces the laggards to follow. Pure-software competitors can't match the per-customer revenue of payments-integrated competitors, so they either build payments themselves or get squeezed out.
This is why the conversations are happening everywhere now. Every vertical has a leader experimenting with embedded payments, and the rest are scrambling to catch up before the gap becomes impossible to close.
The window matters. A vertical SaaS company that builds embedded payments in year 5 of their existence is in a much stronger position than one that tries it in year 12. By year 12, the vertical likely has an established payments-integrated leader, and the laggard is trying to convince customers to switch processors — much harder than acquiring a customer who never had embedded payments before.
The build-vs-partner decision
Even after deciding to do embedded payments, there's the build-vs-partner question. Two choices:
Partner with a platform offering (Stripe Connect, Adyen for Platforms, etc.). Faster, lower upfront cost, smaller take rate. Less control over the merchant experience and economics.
Become a full payfac (with sponsor bank, direct network agreements). Slower, higher upfront cost, larger take rate. More control. More operational burden.
The vast majority of SaaS companies should partner. The full payfac path makes sense only for very large platforms (probably $5B+ in annual processing volume), where the take-rate difference compensates for the operational expense.
I've seen mid-market SaaS companies attempt the full payfac path because they want maximum economics. They typically underestimate the regulatory complexity, the operational team they need to build, and the time-to-market. They then either pivot to a platform partner after burning a year of effort, or limp along with a sub-scale payfac operation that loses money for years.
The smartest approach: start with a platform partner, prove out the embedded payments business, and only consider going full payfac if the volume justifies it. The platform partners make this easy on day one and don't lock you in for the long term.
What this means for the merchant
The merchant's experience under embedded payments is different from buying processing separately. They get:
- A single integrated experience: their software and their payments are the same product.
- Automated reconciliation: payments data flows directly into their books, invoices, reporting.
- Better support: one company to call instead of two.
- Worse pricing: typically. Embedded payments is rarely the cheapest option.
- Lock-in: switching the SaaS platform now requires switching processors too.
The trade is integration depth for pricing power. For most SMB merchants, the integration depth is worth it. They'll pay 50 bps more for a fully integrated solution that saves them ten hours a month of reconciliation work. For larger merchants with sophisticated finance teams, the math goes the other way — they'd rather pay less and reconcile manually.
What I'd do as a SaaS CEO today
If I'm running a vertical SaaS company and considering embedded payments:
- Validate the market. Are my customers paying meaningful volume through their existing processors? Is there a vertical leader who has done this? What's their take rate?
- Start with a platform partner. Stripe Connect, Adyen for Platforms, or whoever has the best fit for the vertical. Plan a 12–18 month build.
- Be honest about operational requirements. The team will need to grow. Hire someone with payments experience to lead it. Don't expect existing engineers to figure it out from documentation.
- Measure carefully. Net take rate, after fraud, reserves, chargeback fees, and operational cost. The reported gross take rate is usually 30–50 bps higher than what you actually keep.
- Build for the long-term operational requirements. Compliance, tax reporting, fraud monitoring — these are forever costs.
- Don't overpromise to investors. "We're going to be a payments company" sounds great in a board meeting and creates expectations that are hard to meet. Be specific about which model you're building and what the realistic timeline is.
The harder truth
Embedded payments is a real opportunity. It's also a serious commitment that changes the company's operational requirements, hiring profile, and risk surface. The companies that succeed at it treat it with the same seriousness they'd treat starting a new product line.
The companies that fail are the ones who treated it as a feature. "We'll add payments next quarter" is what their board hears; "we'll build a payments company over the next two years" is what's actually required.
The math is real. The market is open. The operational depth required is real too, and most companies underestimate it until they're committed. The window for entering this game is closing in many verticals, but for those still on the right side of it, embedded payments may be the largest revenue lever available.
Just don't ship it because it's trendy. Ship it because it makes your customers' lives meaningfully better and you've built the operational discipline to do it well. Anything else is theater.
This is part of a series on payment systems architecture. See also the real cost of payment integration nobody talks about and the merchant onboarding problem nobody wants to solve.