The conversation that shouldn't be the first one
A vertical SaaS company decides to add payments. The first conversation is almost always with a vendor — Stripe, Unit, Adyen, a BaaS provider, a PayFac. The vendor explains what their platform enables. The SaaS team evaluates it against their requirements. They select a vendor and start building.
This sequence is backwards. And the cost of getting it backwards compounds every month the program runs.
The vendor conversation is a conversation about implementation. What needs to happen before it is a conversation about program design: what economics should this program generate, who owns the compliance obligations, what bank relationship is required, and what product capabilities does the program need at three times current volume — not just at launch.
The vendors are good at getting in front of SaaS companies early. Their developer experience is excellent, their time-to-live is fast, and their sales process is designed to move quickly. None of that is bad. What is bad is when the vendor's commercial defaults fill the design decisions that the SaaS company should have made deliberately.
What happens when the vendor decides by default
When a SaaS company chooses Stripe without first defining their economics requirements, Stripe's flat-rate pricing becomes the economics design. At $1M monthly processing volume that is an acceptable tax on speed. At $5M monthly it is a $300,000–$600,000 annual gap versus a well-designed interchange-plus program. At $10M monthly it exceeds $600,000 annually.
When a SaaS company chooses a BaaS provider without first defining their bank relationship strategy, the BaaS provider's revenue share becomes the economics ceiling. The interchange share — typically 40–60% going to the platform — is in the contract. Most SaaS companies don't model what that share means at their three-year volume projection before signing.
When a SaaS company launches without defining their compliance framework, the vendor's compliance defaults become the program's compliance design. Those defaults are designed for the median customer, not for the specific customer segment, risk profile, and bank relationship requirements of any particular program.
None of this is the vendor's fault. The vendor answered the question they were asked. The problem is that the SaaS company asked the wrong question first.
The correct sequence
Step 1: Define the economics requirements. What take rate does the program need to generate at 12-month volume? At 36-month volume? What is the minimum viable economics to justify the build investment? Model this before any vendor conversation. The answer determines which program models are viable — and eliminates others before you've spent any time evaluating them.
Step 2: Choose the program model. BaaS, PayFac, direct bank, or ISO arrangement — each has different economics, compliance obligations, and time-to-market. The economics model from Step 1 typically eliminates one or two options immediately. The compliance capacity question (do you have or can you build the infrastructure a direct bank relationship requires?) narrows it further. The remaining options are the ones worth evaluating vendors against.
Step 3: Define the compliance framework. Who owns BSA/AML? How is KYB/KYC structured? What are the bank reporting obligations? These questions have different answers under different program models, and the answers have operational cost implications that affect the economics model from Step 1. Design the compliance framework for your target program model before the vendor conversation — not as a follow-on to it.
Step 4: Select the bank partner. For programs that need a bank relationship (everything except pure processor arrangements), the bank selection is more consequential than the technology vendor selection. The bank determines economics terms, compliance standards, product flexibility, and operating scale. Most SaaS companies spend more time evaluating payment processors than bank partners. That priority is inverted.
Step 5: Now select the technology vendor. With the program model defined, the economics requirements set, the compliance framework designed, and the bank partner selected or shortlisted, the technology vendor conversation has specific, answerable requirements. Which vendors support this program model? Which integrate with this bank? Which pricing structures meet the economics requirements? These are evaluable questions. Without the preceding steps, they are not.
Why this matters more for vertical SaaS than horizontal
Horizontal SaaS companies — those serving customers across multiple industries — often add payments as a feature: accept card payments, facilitate marketplace transactions. The economics are secondary to the product utility.
Vertical SaaS companies — those serving customers deeply within a specific industry or workflow — have a different opportunity. Their customers process payments as part of their core business workflow, not as an incidental feature. The payment volume is concentrated, the customer relationships are deep, and the opportunity to capture payment economics is proportionally higher. A vertical SaaS company serving healthcare AP, for example, has concentrated visibility into payment flows that a horizontal company does not.
That concentration makes the program design decision more consequential, not less. The economics gap between a well-designed and a poorly-designed payments program is larger for vertical SaaS because the volume and customer depth justify a more direct program structure. Getting the sequence backwards costs more.
About to have your first payments vendor conversation? Read how ExpandUp approaches the program design sequence, or talk with us first — before the vendor conversation, not after.