If you’re building Vertical Software or AI, you’re probably building a fintech company.
You just might not know it yet.
The founders who figure out when to lean into payments (and how to avoid the classic traps) can dramatically expand revenue per customer—without derailing the core product. In the history of vertical platforms, that has often been the difference between growth-stage stall-outs and IPO-worthy businesses.
This week’s guest is Rahul Hampole, who’s built embedded fintech multiple times across Plaid (as Head of Payments) and Yelp (as VP Product). Today, he runs the fintech operation at ServiceTitan, the vertical OS for the trades.
As we’ll cover below, Rahul’s advice to founders on fintech vendors is this: time-to-value is the silent killer, so early on, pick the partner that gets you live quickest. Parafin, our partner on VERTICALS, does just that. Click below to learn more about their turnkey embedded fintech.
I) Vertical Titan
Rahul Hampole — VP, FinTech @ ServiceTitan
The backstory
Rahul’s career has lived at the intersection of software and money movement.
He started as an engineer, spending eight years at Yelp building revenue products (including payments) and founding the enterprise business. He then moved to Plaid, where he eventually ran payments. Today, he leads fintech at ServiceTitan, where he’s applying his SMB fintech chops to the vertical ecosystem.
The hardest parts
Picking the right financial product for your customer (resisting “shiny fintech”)
Nailing the timing: going multi-product too early vs. waiting until growth stalls
Avoiding “paper GMV”: contracts signed, but time-to-live and usage lagging
Managing the trade-offs of speed vs. control (e.g., plug-and-play vs. enterprise)
Designing comp that drives attach and real adoption (not just optimistic forecasts)
Memorable lines from Rahul
“Optimize for the customer, get the product out there, and focus on attach and usage — you can worry about take later.”
“The silent killer in fintech is time to value.”
“Fintech shouldn’t feel separate. It should feel like a natural part of the experience.”
If you’re building software, you’re building fintech (eventually)
Rahul’s core framing is simple: vertical SaaS already sits in the workflow where money changes hands. If you’re the system of record, you’re positioned to simplify the “financial moments” that happen around your core product.
But he’s equally clear on the potential failure mode. Adding payments (or lending, or cards) just because it has attractive margins—without a customer-specific value prop—is how most attempts die, especially as they start rolling out from 10s to 100s.
Take-rate reality check
Early-stage founders should bias toward shipping and learning, not perfecting take rate from day one.
In his view, a reasonable early target for card payments in many vertical SaaS contexts is roughly 80–100 bps of take (and yes, it varies by vertical and rails of choice). Squeezing out every basis point is far less important than proving the product is valuable enough that customers actually adopt it.
Once adoption is real, you can improve economics through vendor changes, routing, pricing, and deeper control.
Stripe vs. “enterprise” processors vs. building in-house
Rahul doesn’t prescribe one vendor — he prescribes a decision posture:
If you need to prove value fast, pick the path that gets you live quickly.
As you move upmarket, you may want more control, configurability, and a more consultative GTM motion — which can push you toward different processor relationships.
Don’t underestimate the long-term “maintenance tax” and the regulatory nightmare if you try to own too much too early.
His practical advice: the urge to optimize take on day one often forces trade-offs that slow shipping and reduce learnings — the opposite of what most early teams need.
When to build the next fintech product
Timing matters more than most founders admit.
Rahul’s heuristic for “are we ready to go build the next adjacent product?” centers on attach becoming meaningfully easier — not just inching up, but showing step-function improvement. When customer pull starts to feel automatic (and your team is no longer manufacturing demand), that’s the green light to expand.
And it’s not just attach — it’s usage and time-to-live. If time-to-value is dropping, rollout friction is shrinking, and usage ramps faster, you’re climbing the S-curve. That’s when adding the next product won’t distract you into mediocrity on both.
Pressure-testing the next product before building it
His recommendation might sound familiar to early-stage founders:
Keep ~20 of your best customers in a high-trust feedback channel (text, WhatsApp, whatever). Not a formal advisory board — a real-time “what’s keeping you up at night” loop.
Then, before building anything, sell the idea. Pitch the product as if it exists, to customers who will tell you the truth. If you can’t get conviction there, the MVP won’t save you.
Why vertical fintech is different
The most “vertical” story in the episode came from the field.
ServiceTitan, as you likely know, services tradespeople. In one case, a contractor collected a big check, left it in his truck… and it literally flew out the window while driving. As Rahul tells it, stuff like that isn’t even really an edge case in the contractor world — that’s just how analog a lot of money movement still is in SMB vertical categories like the trades.
Beyond a cute anecdote, there’s an insight here as to why vertical fintech can be so powerful. Seemingly “small” or “solved” products like tap-to-pay can be massively transformative: they remove friction, reduce loss, and make the job feel simpler for both the tech and their customers. You’d be surprised at how much of a leap forward seemingly basic digital finance tools are for some of these operators, and how much loyalty and retention it can drive. These are busy people who don’t spend all day in front of a computer. They don’t have time for your AI. They do appreciate solutions that make them more money, that help them serve customers… and a team that supports them in getting up to speed rather than ramming tech down their throat.
GTM incentives & comp nuances in fintech
Rahul laid out the reality (which is frankly universally true in startup land): there’s no single comp model that works forever.
Downmarket / SMB tends to demand a stronger product-led motion where education, onboarding, and adoption are built into the product experience. Upmarket GTM often needs consultative sellers who can map the customer’s workflow, design a migration plan, and drive conversion.
And focus between SMB and enterprise may shift greatly over a startup’s life. There is a common pain-point, however, in figuring out the right seller incentives when monetization isn’t as simple as a monthly subscription fee.
Put another way: if 70% of a startup’s revenue comes from payments, what goes towards quota? You can’t forecast it like SaaS; but comping on subscriptions alone clearly isn’t fair.
Per Rahul, you want to pay for initial attach and initial usage — but you generally can’t pay forever on natural customer growth. Structuring incentives to drive real adoption in the first year (and avoiding “I sold it, good luck” handoffs) is where most teams iterate again and again. For earlier-stage founders, he suggests starting with incentives that drive attach. Then you bake in early payments usage. After some amount of time, comp on payments activity tapers.
Rahul on the next five years in fintech
Two threads he’s watching closely:
Agentic Commerce: more automated, “hands-off” financial workflows where software takes action without the customer living in dashboards and forms.
Stablecoins: when crypto adoption will begin to pressure traditional interchange (and their fees), the economic implications will start to get interesting fast.
II) Vertical Playbook
Attach-First Vertical Fintech
Why it works
Embedded fintech wins when it’s not “another module,” but a seamless extension of the workflow your customer already trusts.
If you’re the system of record, you can reduce steps, reduce errors, and compress time-to-cash — which is often worth more to the customer than the basis points are to you. That’s how you earn adoption, and adoption is what creates the right to monetize.
How to run it (ServiceTitan-inspired blueprint)
Foundation: make sure the core product works before you touch payments
Identify a financial “moment” already happening in workflows (usually payments)
Define the unique value only you can create because you own the workflow / data
Ship the fastest credible version (bias to speed over perfect monetization)
Track three numbers obsessively:
Attach rate
Usage depth
Time-to-live / time-to-value
Don’t add the next fintech product until attach and usage show step-function improvement
Validate the next product by selling the concept before building:
Keep ~20 power users in a direct feedback channel
Pitch the product, then build the smallest version that proves the outcome
Revisit take economics only after adoption is real and rollout friction is falling
Founder litmus tests
Are customers explicitly asking to do payments (or financing) inside your platform?
Do you have a clear “only we can do this” or “we’d be the preferred partner overnight” value prop tied to your workflow/data?
Is your attach rate improving because the product is pulling — not because you’re pushing?
Is time-to-value dropping as you scale rollout?
Do you have a team you trust to keep the first product climbing the S-curve while you start working on the next?
Once attach is there: are your economics ready to scale from 10s to 100s? Take your time on this rollout as it’s where most fintech dies on the vine.
What we debated on-air
Whether it’s ever rational to optimize take rate early
When fintech is “commodity plumbing” vs. a differentiated product experience
How much to rely on PLG vs. consultative selling depending on ICP and ACV
Where agentic experiences create real advantage (especially in B2B workflows)
How middlemen rent-seekers will feel the heat from crypto adoption in payments
