What is Embedded Finance?

Embedded finance is the integration of financial services directly into non-financial software products. Payments, billing, lending, insurance, and banking features that used to require separate providers now happen inside the platform the customer already uses. The user never leaves the product. The financial transaction is invisible, or close to it.

As an example: When a Shopify merchant gets a loan based on their sales data without leaving Shopify, that's embedded lending. When an Uber ride ends and the fare is charged without opening a payment app, that's embedded payments. When a SaaS platform invoices its customers, collects payment, and recognizes revenue without the customer ever touching a separate billing portal, that's embedded billing.

This isn't a minor feature addition. Embedded finance is restructuring how SaaS companies make money and how sticky their products become. Shopify now generates roughly 70% of its revenue from financial services, not software subscriptions. The shift from "software with payments bolted on" to "software with finance built in" is the defining business model evolution for SaaS in 2026.

The market context

The embedded finance market is growing faster than most categories in fintech. Bain & Company projects the global market will reach $7 trillion in transaction value this year (2026), more than doubling from $2.6 trillion in 2021. The U.S. embedded finance revenue pool alone is expected to hit $51 billion by 2026, growing at a 19% CAGR. Embedded payments, the most mature category, are growing at 23% CAGR according to EY-Parthenon.

These numbers are important for SaaS companies because they signal where the revenue opportunity is moving. As AI puts pressure on traditional seat-based pricing and subscription revenue, embedded finance offers SaaS platforms a way to participate in the transaction flows that already run through their software. A vertical SaaS platform serving restaurants doesn't just sell software for $200/month. It processes payments on every order, advances working capital against future revenue, and manages payroll through its platform. Each of those financial touches generates revenue that scales with the customer's business, not with the number of seats.

For B2B SaaS companies in particular, the embedded finance opportunity starts with payments and billing. Payments are the entry point because they're well understood and the infrastructure is mature. But billing, invoicing, and revenue operations are where the real complexity lives, and where companies spend the most engineering time building custom solutions.

The categories of embedded finance

Embedded finance covers a spectrum of financial capabilities, each at a different stage of maturity and relevance for SaaS companies.

The trajectory for most SaaS companies follows a predictable sequence. Payments come first because every platform needs to collect money. Billing comes next, because once you process payments, you need to figure out how much to charge, generate invoices, manage subscriptions, and reconcile revenue. Lending and banking follow for vertical SaaS platforms that have enough transaction data to underwrite risk.

The gap between payments and billing is where many companies get stuck. They integrate Stripe or Adyen to process payments and assume billing is handled. Then hybrid pricing arrives (seats + usage + credits), enterprise contracts need custom invoicing, multi-entity expansion requires separate tax treatment, and suddenly the payment layer can collect money but nothing upstream can calculate how much to collect.

Why SaaS companies embed financial features

The reasons SaaS companies invest in embedded finance have shifted over the past few years. It used to be about convenience, giving customers a slightly better experience by keeping payments in-platform. Now it's about economics, competitive moats, and survival in a market where AI is compressing the value of software itself.

Revenue diversification beyond subscriptions. 91% of SaaS platforms expect embedded payments to play a larger role in their growth strategy (Stax). For platforms facing margin pressure from AI or seat-based pricing commoditization, transaction fees add a revenue stream that scales with customer volume rather than headcount. A SaaS platform processing $10M in annual payment volume at 2.9% + $0.30 per transaction generates meaningful revenue that doesn't depend on selling more seats.

Product stickiness through financial dependency. When a customer's billing, payments, and financial data live inside your platform, the switching cost goes from "export my data" to "migrate my entire financial infrastructure." PYMNTS research found that embedded finance increases product stickiness by tying software usage directly to cash flow. Customers don't churn from software that handles their money. The relationship becomes infrastructural rather than optional.

Competitive differentiation in crowded verticals. Vertical SaaS companies competing for the same restaurant, gym, or contractor customer base can differentiate on embedded finance when features are comparable. The platform that removes the most financial friction, that handles payments, invoicing, and working capital in one place, wins deals that would otherwise go to a cheaper competitor with better marketing. 90% of SMBs consider embedded finance tools integrated into their management platforms essential to operations, according to PYMNTS Intelligence in collaboration with Worldpay.

AI pricing demands new billing infrastructure. Hybrid pricing models (seats + usage + credits) require real-time metering and flexible invoicing that generic billing tools weren't designed for. As AI features proliferate across SaaS products, the billing layer needs to handle consumption-based charges, credit burndown, and committed-spend contracts alongside traditional subscriptions. This is the embedded billing challenge: not just collecting money, but calculating the right amount to charge when pricing models are complex and changing frequently.

Margin expansion from financial flows. Vertical SaaS companies with embedded payments earn revenue from transaction flows that already run through their software, without diverting engineering resources from product development. The incremental revenue from payment processing, float on held funds, and lending margins can add 2-5x to per-customer revenue over the lifetime of the relationship.

Embedded payments vs. embedded billing

These two categories get confused constantly - and while they are similar, they solve different problems.

Embedded payments answers one question: "Can we collect money?" It handles payment processing, checkout flows, and disbursements. The technology is mature, the providers are well established (Stripe, Adyen, PayPal, Square, Finix), and for simple transactions, a payment integration might be all you need.

Embedded billing answers a different question: "How much do we charge, for what, and how do we account for it?" It handles metering, rating, invoicing, subscription management, credit and wallet logic, entitlement enforcement, and revenue recognition. Billing is the layer that sits between your product (which generates usage) and your payment provider (which collects money). Without it, you're collecting payments but guessing at the amounts.

For SaaS companies with simple pricing (one plan, one price, monthly charge), embedded payments might be sufficient. You connect Stripe, charge a flat rate, and move on. Once you introduce tiers, usage-based components, credits, enterprise contracts, or multi-entity billing, you need an embedded billing layer that can calculate charges before the payment layer collects them.

This is where most companies underestimate the problem. Payment integration takes days or weeks. Billing architecture, done properly, takes months and touches product, finance, sales, and engineering. Companies that treat billing as a feature of their payment integration end up with custom code, spreadsheet reconciliation, and finance teams who spend the first week of every month manually matching invoices to usage data.

The embedded billing problem in detail

Payments get the attention because they're visible. The customer clicks "pay," and money moves. Billing is the invisible layer underneath, and it's where SaaS companies accumulate the most technical debt.

Consider what embedded billing actually needs to do for a SaaS company running hybrid pricing. It captures usage events in real time (API calls, tokens consumed, agent actions, storage used). It aggregates those events by customer, metric, and billing period. It applies pricing rules: per-unit rates, tiered pricing, volume discounts, committed-spend drawdown, credit conversion rates. It checks entitlements to verify what the customer is allowed to use based on their plan, contract overrides, and any grandfathered terms. It generates an invoice that combines fixed subscription charges with variable usage charges, applies taxes across jurisdictions, and handles multi-entity billing if the customer operates in multiple countries. It sends that invoice to a payment provider for collection. And it recognizes revenue according to ASC 606 or IFRS 15, treating prepaid credits as liabilities and usage revenue as recognized at consumption.

Each of these steps is a potential failure point. Miss a usage event and you underbill. Apply the wrong rate card and you overbill. Fail to handle multi-entity tax and you create compliance risk, and if you recognize credit revenue at purchase instead of consumption, your auditor flags it.

This is why embedded billing is the hardest category of embedded finance to implement well, and why most SaaS companies either build custom systems that become maintenance burdens, or settle for billing platforms that can't handle the full complexity of hybrid pricing.

What embedded billing requires

Embedding billing into a SaaS product means the billing layer needs to handle the full lifecycle from usage to revenue. This isn't a single API call. It's an architectural commitment.

The SaaS-to-fintech roadmap

The gradual transformation of SaaS companies into financial infrastructure is pretty interesting:

Recall that Shopify started as e-commerce software, but now 70% of its revenue comes from financial services: payment processing, merchant cash advances, and Shopify Balance accounts. Toast started as restaurant management software. Now payment processing is its primary revenue driver. Vertical SaaS companies across construction, healthcare, education, and field services are following the same playbook: start with software, embed payments, add lending and banking, and shift the business model from subscription revenue to financial infrastructure revenue.

This change is accelerating because of AI, naturally - as AI compresses the value of software features (any startup can build a functional CRUD app in weeks), the durable competitive advantages shift to data and money flow. If your platform processes a merchant's payments, holds their cash, advances them capital, and manages their billing, you're not a software tool. You're infrastructure. And infrastructure is much harder to replace than software.

For B2B SaaS companies that aren't building vertical financial platforms, the embedded finance priority is simpler: get billing right. The billing layer is where pricing strategy meets execution, where revenue recognition meets compliance, and where product decisions about usage-based and credit-based pricing actually become invoices that customers pay. Companies that treat billing as a solved problem ("we connected Stripe") and companies that treat billing as infrastructure ("we built a monetization system") end up in very different places at $50M ARR.

The build vs. buy decision

Every SaaS company embedding financial features faces the same question: build it or buy it? The answer depends on pricing model complexity, engineering capacity, and how fast pricing needs to change.

The decision often comes down to pricing model complexity and rate of change. Simple subscription? A payment platform is probably enough. Hybrid pricing with seats, usage, credits, committed spend, and enterprise overrides that changes quarterly? You need billing infrastructure that treats pricing as configuration, not code.

Learn more about this transition in our post on hybrid pricing and the architectural challenge of credit systems.