The sequence problem that costs most programs millions
Most embedded payments programs start with a vendor conversation. Someone books a Stripe demo. A Marqeta rep emails. A BaaS provider sends a deck. The conversation happens before the program model exists — and the vendor's defaults become the program's economics.
That's not a metaphor. It's a mechanical description of how most programs end up with economics they didn't design and can't easily change.
The five decisions below need to be made before you talk to any infrastructure provider. Not because vendors are adversarial — most aren't. Because their defaults reflect their economics, not yours. And once infrastructure is selected around those defaults, changing them is expensive.
Decision 1: What program model do you actually need?
BaaS, PayFac, direct sponsor bank, or hybrid. Each has different economics, different compliance requirements, and different scaling characteristics. The right answer depends on your volume trajectory, your operational capability, and the economics you need at scale.
Most companies that end up in BaaS didn't choose it deliberately. They defaulted to it because it was the fastest path to a working demo. That's a legitimate reason to start with BaaS. It's not a reason to build your long-term economics around it without modeling the alternatives.
Define the model that serves your economics at 24-month target volume. Then select infrastructure that supports it — or that gives you a clear migration path to it.
Decision 2: What are your economics targets, explicitly?
Not "we want to make money on payments." Specifically: what take rate do you need at $20M in monthly volume? At $50M? What's the minimum interchange capture rate that makes the program viable? What fee structure supports your unit economics?
These numbers have to exist before the first vendor conversation — because vendors will offer you packages, and you need to be able to evaluate them against a defined standard rather than against each other.
Programs that enter vendor conversations without explicit economics targets negotiate against the vendor's model. Programs that enter with explicit targets negotiate against their own.
Decision 3: What compliance exposure are you taking on?
Every payment program model carries different compliance obligations. BaaS puts you under the bank's BSA/AML program — limiting your flexibility but reducing your direct compliance burden. PayFac puts sub-merchant underwriting on you. Direct sponsor bank relationships require you to maintain a compliance program the bank will examine.
These aren't equivalent. The compliance model you choose determines your staffing requirements, your operational overhead, and your product flexibility for years. It should be chosen deliberately, not inherited from whichever vendor was fastest to respond.
Decision 4: What does your bank relationship need to include?
If your program requires a sponsor bank relationship — BaaS or direct — the commercial terms of that relationship determine float economics, interchange sharing, product flexibility, and scaling constraints. The bank's defaults do not include float economics. They do not include favorable interchange sharing. They include what the bank offers to an undifferentiated program.
Preparing a defined program model, compliance framework, and commercial term requirements before approaching a bank changes the negotiation entirely. You're no longer a fintech asking what the bank offers. You're a program with defined requirements evaluating whether the bank is the right fit.
Decision 5: What is your 36-month infrastructure path?
The infrastructure that serves you at $5M in monthly volume is usually not the infrastructure you want at $50M. Knowing where you're going — and designing a migration pathway before you need it — dramatically reduces the switching cost when the time comes.
Most programs don't have this conversation because it feels premature. It's not. Every week you operate on infrastructure designed for your current scale is a week you're deepening the integration cost of moving to infrastructure designed for your target scale.
What happens when you skip these decisions
Interchange flows to the infrastructure layer. Float economics belong to the bank. Fee structure is inherited from vendor schedules. The program model optimizes for the vendor's scale, not yours. And twelve months after launch, the question becomes: how did we end up here, and how expensive is it to change?
The answer is usually: expensive. Not impossible, but expensive. And the cost compounds the longer you wait.
The conversation that should happen first
Before Stripe. Before Marqeta. Before any BaaS demo. The conversation that determines your payments economics should be with someone who has operated inside these programs at scale — and can help you define the model before vendor selection constrains it.
That's the engagement model ExpandUp was designed around. Architecture first. Vendor selection second. The economics you design before the build are the economics you operate at scale.