Every board deck about embedded finance eventually shows the same four logos. The reason is that a small number of vertical software companies made payments and financial products a serious part of their business, and everyone else is trying to work out how they did it. The useful thing is not that Toast or Shopify exist. It is that they all ran roughly the same play, in roughly the same order, and the order is the lesson.
The most successful embedded finance in vertical SaaS follows one pattern: start with payments, make it default-on inside the core workflow, get attach and activation high, then expand into lending, cards and accounts once the payments base is proven. Toast, Shopify, ServiceTitan and Mindbody all ran this sequence. None of them led with lending, and none of them treated payments as a checkbox feature.
What counts as successful embedded finance in vertical SaaS?
Embedded finance is financial product built into software so the customer never leaves the workflow to pay, get paid, borrow or bank. In vertical SaaS the platform serves one industry, so it knows that industry's money flows better than any bank does, and it can offer a financial product on data and distribution it already owns. That is the structural advantage, and it is why a restaurant platform can out-execute a generic processor at selling payments to restaurants.
Successful looks like three things stacked in order. Payments becomes a real revenue line, often the largest one. Attach and activation across the existing customer base are high, not just for new signups. And the platform then uses the payments relationship to add a second and third financial product without acquiring a single new customer. A platform that has bolted on a payments toggle almost nobody uses has embedded finance on the roadmap, not in the business. For the broader frame, see embedded finance for vertical SaaS.
Toast: how payments became the business
Toast is the cleanest example because the direction of travel is so stark. It started as a cloud point-of-sale system for restaurants, a software product. Today the payment processing that runs through that software is its largest revenue engine, far larger than the software subscriptions. The restaurant never thinks of Toast as a payments company. They bought a POS, and the payments came with it because that is how the product works.
That is the default-on lesson in one company. Toast did not ask restaurants to go choose a processor. Processing is simply how you run the register, so attach is effectively built into the core workflow. On top of that payments base Toast layered financing for restaurants, using the transaction history it already had to underwrite. The lending did not come first. It came after the payments relationship made the platform the natural place to borrow.
The restaurant never thinks of Toast as a payments company. They bought a POS, and the payments came with it because that is how the product works.
Shopify: from payments to a full financial stack
Shopify shows how far the sequence can run. It began with payments, its own processing product that a large majority of its merchants use rather than bolting on an outside gateway. Once that base existed, Shopify added an accelerated checkout wallet, then merchant financing and cash advances underwritten off store data, then a business money account, then installment payments and a business card. Each product rode on the merchant relationship and the data the previous product created.
The important part is not the length of the list. It is that the list is a sequence, not a menu. Shopify did not launch a bank account and a card and loans on day one. It earned each step by proving the one before it, and every new product was easier to sell because the merchant was already inside the financial relationship. This is the model most vertical platforms should study, not because they will match the scale, but because the ordering is copyable at any size.
ServiceTitan: embedding payments in the home-services workflow
ServiceTitan is the trades version of the same move. It is the software that home and commercial services businesses use to schedule jobs, dispatch technicians and invoice customers. Payments is embedded right where the invoice already lives, so the contractor collects through the software instead of running a separate terminal. Because the payment sits inside the job workflow, attach follows the workflow rather than depending on a separate sale.
ServiceTitan also added consumer financing, which matters more in the trades because the jobs are large. A homeowner facing a five-figure HVAC replacement is far more likely to say yes when financing is offered in the same flow that produces the quote. That is embedded finance doing what a standalone lender cannot: showing up at the exact moment of need, inside the tool that created the need. The payments came first, and the financing extended the same workflow.
Mindbody, Squarespace and Housecall Pro: the pattern repeats
The pattern is not unique to a few giants. Mindbody, the software for wellness, fitness and salon businesses, made integrated payments a core part of its monetization, so a studio takes bookings and payments through one system. Squarespace, better known as a website builder, expanded into commerce and then its own payments product, moving from tools to transactions. Housecall Pro, a home-services platform, built embedded payments and then instant payouts and financing on top, so a small contractor gets paid faster through the software they already run their day in.
Different verticals, same shape. Own the workflow, put payments where the money already changes hands, get the existing base using it, then extend into the next financial product. The verticals that look nothing alike on the surface converge on the identical structure underneath, which is the strongest signal that the structure, not the industry, is what is doing the work.
What do the successful examples have in common?
Read the examples together and four things repeat every time.
Payments came first. Not lending, not banking, not a card. Payments is the highest-frequency financial event in the workflow, and it produces the data that underwrites everything after it. Every platform that later offered credit earned the right to by first processing the payments that told them who was good for it.
It was default-on inside the core workflow. In each case payments is how the product works, not a feature the customer has to go find and switch on. That single design choice is the difference between the attach rates these platforms hit and the ones a buried payments toggle produces. The mechanics of that gap are in embedded payments for vertical SaaS.
They monetized the base, not just new signups. The revenue did not come only from new customers arriving into a payments-native flow. It came from converting the existing book of customers who predated the payments launch, which is the single largest and most underworked lever in the first years of any program.
Expansion was a sequence, not a leap. The second and third financial products came after the payments base was proven, each one easier because the relationship already existed. None of them tried to be a full financial stack on day one, and neither should you. Whether the right first step is a referral or owning more of the economics is the question in ISV Referral vs PayFac Lite.
What does this mean for your platform?
You are not going to reproduce Shopify's stack, and you do not need to. What the examples give you is the order of operations and permission to start small. Put payments where the money already changes hands in your product, make it the default rather than a toggle, and measure attach and activation against the base you already have before you think about the next product. The economics of that first step, at your specific volume, are exactly what the how much SaaS platforms make from payments math lays out.
The mistake is reading these examples as an argument for ambition, when they are really an argument for sequence. The platforms that struggle with embedded finance are usually the ones that skipped straight to the exciting products, or that launched payments as a feature nobody defaulted into. The ones that win did the boring thing first, did it as the default path, and let each financial product fund the next. If you want to pressure-test where your platform sits on that path and what the honest first move is, that is what a Quick Start Call is for.
Frequently Asked Questions
What is embedded finance in vertical SaaS?
Embedded finance in vertical SaaS is when a software platform for a specific industry builds financial products directly into its workflow, so its customers pay, get paid, borrow or bank without leaving the software. Payments is almost always the first and largest line, followed by lending, issued cards and deposit accounts. The point is that the financial product rides on data and distribution the platform already owns, which is why a vertical platform can offer it at better economics than a standalone bank or processor.
Which vertical SaaS companies do embedded finance well?
The most cited examples are Toast in restaurants, Shopify in commerce, ServiceTitan in the home and commercial trades, and Mindbody in wellness and fitness. Squarespace and Housecall Pro run the same playbook in their verticals. In every case payments came first and became a major revenue line, and lending or banking products were added on top of the payments base rather than launched cold.
Do you have to become a payment facilitator to do embedded finance?
No. Most platforms start with a referral or a managed PayFac-as-a-Service model, where a provider carries the heaviest compliance and infrastructure load, and only move toward full payment facilitator status once the volume justifies the operating cost. The successful examples reached full ownership of the economics over years, not on day one. The right entry point depends on your volume, your stage and how much operational load you can carry.
Should a vertical SaaS platform start with payments or lending?
Payments, almost always. Payments is the highest-frequency financial event in a customer's workflow, it produces the transaction data that underwrites everything else, and it funds and de-risks the later products. None of the well-known embedded finance winners led with lending. They earned the right to lend by first processing the payments that told them who was creditworthy.
How long does it take to build a successful embedded finance line?
Longer than a single roadmap cycle and shorter than most boards fear. The public examples took a few years to move from launching payments to a meaningful revenue line, and several more to layer on lending and banking. The pace is set less by the technology, which a provider can supply quickly, than by activation: how fast the platform gets its existing customer base actually using the product. Attach and activation are the clock, not the build.