Embedded Finance and BaaS for SMB Software: How Vertical SaaS Adds Payments, Lending, and Issued Cards

Toast — a point-of-sale platform for restaurants — earned roughly $5 billion from financial services last year. Its software subscriptions, the thing it was originally built to sell, brought in $936 million. The fintech tail is now five times bigger than the SaaS dog.

The same pattern is repeating across vertical software: Shopify's merchant solutions account for 73% of revenue. ServiceTitan's IPO mix was 71% subscription and 25% fintech, but analysts watching net new revenue see the split converging on 55/45 — payments are growing faster than the software core. By the time a vertical SaaS company hits Series B in 2026, the investor question is no longer whether to embed payments, but which embedded finance stack to use and how fast lending and issued cards can follow.

This is what the industry calls embedded finance — financial products served inside non-financial software — and the plumbing underneath it is Banking-as-a-Service (BaaS). The opportunity is real: US platform revenue from embedded finance is projected to grow from roughly $22 billion in 2021 to $51 billion in 2026, and the BaaS market is on a 17.8% CAGR through 2031. But there's a graveyard of consent orders, frozen programs, and missed audits next to that opportunity, and most of the founders who fall into it didn't realize they were running a bank-like business until a regulator told them.

This guide walks through what embedded finance actually is, why vertical SaaS is the natural home for it, what the stack looks like in 2026, how to choose between providers, and the compliance traps that turn promising launches into existential incidents.

What "Embedded Finance" Actually Means

Embedded finance is shorthand for financial products — payments, deposit accounts, debit cards, loans, insurance, payroll — delivered inside a piece of software that is not, on its face, a financial product. A construction software platform that lets contractors accept ACH payments from their customers, hold the cash in a sub-account, and tap an instant advance against unpaid invoices is doing embedded finance. So is a veterinary clinic management system that issues branded debit cards to vet techs for buying supplies.

The technical engine behind most of these features is Banking-as-a-Service: a regulated bank (the "sponsor bank") rents out its charter, its access to the ACH and card networks, and its FDIC-insured ledger to a fintech middleware provider, which in turn exposes those capabilities as clean APIs that ordinary software companies can call. The software company never holds a banking license. It does, however, take on a long list of operational and compliance responsibilities that look a lot like running a bank when you read the fine print.

Three products dominate the embedded finance stack:

• Embedded payments. Accepting cards and ACH on behalf of the SaaS platform's end customers. This is the gateway drug — easiest to deploy, fastest to revenue, and the foundation everything else sits on.
• Embedded lending. Cash advances against future receivables, line-of-credit products, and term loans underwritten using the platform's first-party transaction data. Take rates and net spreads are far higher than payments.
• Issued cards and accounts. Branded debit cards, virtual cards, and FDIC-insured operating accounts ("spend cards" for crews, "earnings accounts" for gig workers, store-credit cards for buyers).

Each of these layers compounds with the others, because each one captures more of the customer's working capital flow.

Why Vertical SaaS Has the Unfair Advantage

A horizontal payments app sees a credit card swipe in isolation. A vertical SaaS platform sees the contract that produced the swipe, the labor hours scheduled against the contract, the materials invoice that has to be paid by Friday, the historical seasonality of every customer in the same zip code, and the operator's bank balance trending toward overdraft.

That context is the moat. It changes three things at once:

1. Underwriting becomes cheaper and more accurate. A construction SaaS company knows which contractors get paid on time and which always have 90 days of receivables on the books. That makes a cash advance product a far better bet than a generic small-business loan from a bank that only sees a tax return.
2. Distribution costs collapse. The customer is already inside the app. There's no acquisition funnel for a new financial product — there's a banner inside the screen the user is already on. Industry analysts estimate platforms that successfully embed financial products multiply revenue per customer by three to four times.
3. Retention compounds. Once payroll, payments, and a line of credit run through your software, switching costs become enormous. The fintech layer turns a $99-a-month subscription into a $5,000-a-year financial-services account.

This is why the vertical SaaS fintech playbook has gone from "experimental side bet" to "default Series B planning assumption" in roughly four years.

The 2026 Stack: Who Does What

The embedded finance vendor map is crowded, and the categories overlap. A simplified view of the providers most often shortlisted by SMB software teams in 2026:

Payment processing and orchestration

• Stripe Connect and Stripe Treasury. The developer-first default. Strong APIs, great documentation, broad coverage from card acceptance through stored balances and issued cards. Best for teams that want a single vendor for most of the stack.
• Adyen for Platforms. Volume-priced and globally strong. Better economics above $50 million in processed payments; slower onboarding and less generous on smaller programs.
• Finix and Payabli. "PayFac-as-a-Service" — they help platforms become payment facilitators (or at least look like one) without the full regulatory build.

Banking and accounts (BaaS middleware)

• Unit. The fastest path to a launched program for US SaaS companies that want to hold customer balances or issue branded cards. Strong product, but tightly coupled to a few sponsor banks.
• Treasury Prime. Multi-bank API — useful when you want bank-level features like FDIC pass-through and real-time payments without locking into one sponsor.
• Synctera. Compliance-forward middleware that tries to bring BSA/AML tooling into the developer experience from day one.
• Column. A bank that also exposes its own APIs, removing one layer of the middleware sandwich.

Card issuing

• Marqeta, Lithic, Highnote. Card-issuing infrastructure for branded debit, prepaid, and increasingly credit programs. Marqeta scales; Lithic appeals to teams that want a leaner, developer-friendly surface; Highnote leans into credit and consumer products.

Lending and capital

• Parafin, Kanmon, Liberis. Embedded lending APIs that underwrite using the platform's transaction data and handle origination, servicing, and (in some cases) the balance sheet.

Ledger and money movement

• Modern Treasury. Reference implementation for ledger infrastructure inside platforms; used by companies like Gusto and Marqeta to keep their own books straight before money even hits a bank.
• Dwolla, Moov. ACH-focused programmatic money movement, often used alongside a card processor.

Most live programs combine three or four of these — for example, a property-management platform might use Stripe for card acceptance, Unit for landlord earnings accounts, Marqeta for branded debit cards to property managers, and Parafin for cash advances against rental income.

A Realistic Sequencing Plan

The single most common mistake is trying to launch payments, lending, and cards in one big release. Don't. The compliance, ops, and economic complexity of each layer is genuinely different, and the right sequence in almost every case is the same.

Phase 1 — Payments (months 0 to 6). Add card acceptance for your customers' customers. This is the lowest-risk, highest-volume layer. Build the integration so the platform earns a small piece of every transaction (typically 30 to 100 basis points). Use this phase to harden your customer onboarding, KYB (Know Your Business) checks, and fraud monitoring.

Phase 2 — Accounts and disbursements (months 6 to 12). Once payments are stable, add the ability for customers to hold balances inside the platform, send ACH payouts, and issue virtual cards for specific spend categories. Branded debit cards are usually the second card product, not the first.

Phase 3 — Credit and capital (year two). Cash advances against receivables come first — they are short-duration, easier to underwrite, and recover automatically from incoming payments. Term loans and lines of credit come later because they require deeper credit, collections, and charge-off operations.

Bain & Company's data shows that platforms that follow this sequence have meaningfully higher take rates and lower charge-off ratios than those that skip ahead. The temptation to launch lending early is strong because the unit economics are so much better than payments, but the operational maturity required to absorb a 4% charge-off rate is real, and it's almost always missing in year one.

The Compliance Trap Nobody Wants to Talk About

In February 2024, the FDIC issued consent orders against two banks for BaaS-related safety-and-soundness concerns — primarily Bank Secrecy Act compliance and third-party oversight failures. Piermont Bank's order touched programs operated through Treasury Prime and Unit. Sutton Bank, which works with fintechs including Robinhood, Square, and Upgrade, received similar findings. More orders followed throughout 2024 and 2025. The FDIC reported twelve enforcement orders in May 2025 alone. The Office of the Comptroller of the Currency has issued comparable actions on the national bank side.

When a sponsor bank takes a consent order, the downstream platform doesn't just get a stern letter — programs often freeze, new customer onboarding halts, and in some cases existing balances become hard to move. Founders who were running what felt like "just a SaaS feature" suddenly discover that their roadmap is hostage to a regulator they've never met.

A handful of specific obligations consistently trip up software companies:

• KYC and KYB (Know Your Customer / Know Your Business). Every end user who holds a balance, gets a card, or receives a loan must be identity-verified to the standard required by the sponsor bank — not the standard your product team thinks is enough.
• Beneficial ownership and CIP. Customer Identification Program rules apply to business customers, and the rule for collecting beneficial-owner information at 25% ownership thresholds is enforced literally.
• Transaction monitoring and SAR filing. Suspicious activity reports are not optional. The platform usually does the front-line monitoring; the sponsor bank files. If the monitoring is weak, the bank takes the regulatory hit and the platform takes the contract termination.
• Marketing and disclosure. What you say about FDIC insurance, interest, and credit terms is regulated. "FDIC insured" with no asterisk has been the cause of more cease-and-desist letters than almost any other phrase.
• Complaint handling and Reg E. Consumer financial products bring consumer protection obligations, including specific timelines for handling disputed transactions.

A useful rule of thumb: if a feature would require a license were you doing it yourself, then your sponsor bank's compliance team is treating it that way too, even if your product manager isn't.

Choosing Build, Buy, or Partner

There are three legitimate paths, and the right answer depends on capital, regulatory appetite, and how central financial services are to the long-term roadmap.

Pure partner / referral model. The platform refers customers to a financial provider and earns a flat fee or a small revenue share. Lowest risk, lowest upside, fastest to launch. Right for SaaS companies where finance is adjacent rather than core.

Embedded via BaaS middleware. The platform looks and feels like a financial provider to its customers, but the regulated activity sits with a sponsor bank and a middleware partner. Most vertical SaaS programs are here. Take rates are real, the compliance load is real, and the unit economics start working at modest scale.

Charter, license, or PayFac directly. A small number of platforms eventually acquire a money-transmitter license, become a registered payment facilitator, or pursue a bank charter. This is expensive, slow, and only makes sense once the program is generating tens of millions in financial-services revenue and the savings from cutting out the middleware exceed the regulatory cost.

A simple test: if your current or planned financial services revenue is below $5 million a year, partner or use middleware. Between $5 million and $50 million, middleware almost always wins. Above $50 million, you should at least be modeling what it would cost to take more of the stack in-house.

The Numbers Game: What Realistic Economics Look Like

The economics differ sharply by product. As you build a financial plan, use these rough 2026 benchmarks as a starting point, then adjust for your vertical:

• Card acceptance: 30 to 100 basis points of processed volume to the platform, after the sponsor bank and middleware take their cut.
• ACH: Single-digit cents to low-dollar fixed fees, plus small percentage take rates on value-added flows.
• Issued debit / spend cards: Interchange split that typically nets the platform 50 to 100 basis points of spend, minus card production and program-management costs.
• Cash advances on receivables: Effective APRs in the 30 to 60% range, with charge-offs of 2 to 6% for a well-underwritten book. Net margins after capital cost can run 8 to 15% of originations.
• Term lending: Lower APRs, longer duration, higher operating cost. Margin depends heavily on the cost of capital and the collections operation.

For B2B embedded ACH payments specifically, industry forecasts project platforms will capture roughly $4 billion in net revenues from value-added services by 2026, and embedded card volume will add another roughly $800 million in platform revenue. Those numbers add up because of who captures them — the platform that owns the customer relationship and the transaction context, not the bank that owns the rails.

Avoid These Five Mistakes

Patterns that show up over and over in postmortems of failed or troubled programs:

1. Building before you've staffed compliance. The first hire for an embedded finance program is not an engineer or a product manager. It's someone with real BSA/AML experience, ideally with prior sponsor-bank relationships.
2. Treating the sponsor bank as a vendor instead of a regulator. Your sponsor bank's compliance team has effective veto power over your roadmap. Loop them in early, even when you don't have to.
3. Skipping KYB for "small" customers. There is no exception for small. There is no exception for "we know this customer." The rules apply to every account holder.
4. Underestimating the cost of capital for lending. Net interest margin on cash advances looks beautiful on a spreadsheet until you add the cost of a credit facility, charge-offs, servicing costs, and the periodic write-down of a cohort that went wrong.
5. Letting marketing get out in front of legal. Most consumer-financial-services enforcement actions trace back to a single ad, a single web page, or a single in-app banner. Marketing copy for financial products needs a review process and a record.

Where Plain-Text Accounting Fits In

Embedded finance creates one technical problem that almost nobody talks about until it bites: the ledger explosion. Every customer balance, every card swipe, every payout, every loan disbursement, every recovery, and every chargeback is now an accounting event in your system, not just in the bank's. You need to reconcile your books to a sponsor-bank statement, to your card processor's settlement file, and to a lending servicer's report — often daily.

Vendors like Modern Treasury exist precisely because traditional ledgers can't keep up with money-movement velocity. For internal company finance — your own books, the ones the CFO has to certify — the same principle holds: ledger transparency, audit trails, and the ability to script reconciliations against external sources matters more once financial services start flowing through your platform than it ever did when you were a pure SaaS subscription business.

Keep Your Own Books as Transparent as Your Product

Embedded finance turns a software company into a company that moves money — and the accounting backbone underneath your business has to be at least as good as the financial product you're shipping to customers. Beancount.io provides plain-text, version-controlled accounting that is fully transparent, scriptable, and built for the kind of high-velocity reconciliations that fintech-flavored SaaS businesses need. There are no black boxes and no vendor lock-in — your books live in a text file you can audit line by line. Get started for free and see why developers and finance teams are switching to plain-text accounting as their financial stack gets more complex.