The decisions that feel abstract — until they're expensive
Before a SaaS company writes its first line of payment integration code, five decisions have already determined what the payments program can become: the program model, the bank partner, the compliance framework, the infrastructure stack, and the economics design. These decisions are made whether or not the company makes them deliberately. If they are not made deliberately, the vendors make them by default.
The problem with vendor-default decisions is not that vendors make bad choices. It is that vendors make choices that are right for the median customer and optimized for the vendor's business model — not necessarily for any specific program's economics requirements and three-year trajectory.
Architecture decisions feel abstract before you build. They feel expensive after — when the program is live, volume is growing, and the foundation the program was built on is the wrong one for where it is going.
Decision 1: Program model
BaaS, PayFac, direct bank, or ISO arrangement — the program model determines the economic structure of everything downstream. It determines who captures interchange, who owns compliance obligations, what products are possible, and what the migration path looks like when the current model is outgrown.
Most SaaS companies choose a program model by choosing a vendor — Stripe implies merchant/PayFac, Unit implies BaaS, a direct bank implies direct program. The sequence should be reversed: choose the program model first, then find vendors that implement it.
The program model decision should be made against three inputs: the economics requirements at projected 36-month volume, the compliance capacity the organization has or can build, and the product requirements at the same volume projection. Most program models that make sense at launch do not make sense at three times launch volume. Design for the three-year state, build for the launch state, and define the migration path between them before you start.
Decision 2: Bank partner
The bank partner decision is the most consequential and the most frequently deferred. The sponsor bank determines: what interchange economics are available to the program, what products the program can offer, what compliance standards apply, and what the operating ceiling looks like as volume scales.
Most SaaS companies don't choose a bank partner at launch — they choose a BaaS provider that has a bank partner. The bank relationship is implicit, not explicit. This means the bank's commercial terms — interchange share, float economics, product capabilities — are whatever the BaaS provider negotiated on behalf of all its customers, not what your specific program requires.
Defining the bank partner strategy — even if the direct bank relationship is 18 months away — belongs in the architecture conversation, not the vendor selection conversation.
Decision 3: Compliance framework
The compliance framework is the set of processes, controls, and infrastructure that keeps the payments program inside the regulatory requirements it operates under: BSA/AML, KYB/KYC, OFAC screening, Regulation E for consumer programs, bank reporting.
Most SaaS companies design their compliance framework by accepting the BaaS provider's or processor's compliance defaults. Those defaults cover the minimum required to operate the vendor's program — they are not designed for the specific risk profile, customer segment, or bank relationship requirements of any particular program.
The compliance framework should be designed to match the target program model — not the launch program model. A program designed for BaaS that needs to migrate to a direct bank relationship in 18 months needs a compliance framework that is ready for the direct model before it needs to be, not built from scratch when the bank relationship is already in negotiation.
Decision 4: Infrastructure stack
The infrastructure stack — processor, ledgering system, card issuing processor, reconciliation infrastructure — should be selected against the program model requirements, not against feature lists. The right question for each infrastructure component is not "what does this do?" but "does this support the program model I've defined, at the volume I'm projecting, with the migration path I've designed?"
The most common infrastructure mistake: selecting infrastructure optimized for launch velocity (BaaS-bundled ledgering, Stripe-native reconciliation, BaaS-provided card issuing) that is difficult to migrate away from when the program outgrows it. The integration architecture should include abstraction layers that allow infrastructure components to be replaced without requiring the full payment flow to be rebuilt.
The abstraction layer investment at build time — adding an integration interface between the SaaS application and each infrastructure component — typically adds 2–4 weeks of development time. It saves 4–6 months of re-architecture work when the infrastructure component needs to be replaced. At scale, every infrastructure component will eventually be replaced.
Decision 5: Economics design
The economics design is the specific structure of how the program generates revenue: interchange capture rate, float economics, fee structure, monetized rail economics. This design is not determined by the infrastructure — it is negotiated with the bank partner and the infrastructure vendors. Most SaaS companies accept the default economics structure of their chosen vendor. The default almost always favors the vendor.
The economics design should be modeled before vendor selection against the volume projection. What take rate is required for the program to generate meaningful revenue at 12-month volume? At 36-month volume? What specific commercial terms — interchange share, float yield, fee structure flexibility — does the bank and vendor agreement need to include to meet those targets? These are negotiable terms. Knowing what you need before you negotiate is the prerequisite for negotiating it.
What "architecture first" actually looks like in practice
For a SaaS company beginning its payments program, architecture first means a 4–6 week design process before any vendor conversation: model the economics requirements, evaluate program model options, define the compliance framework philosophy, identify the bank strategy, and document the infrastructure requirements. The output is a program design document that specifies what the payments program needs to accomplish at launch and at 3x launch volume, and what each architecture decision needs to enable.
That document changes every vendor conversation. Instead of evaluating vendors against feature lists, you evaluate them against specific requirements. The questions become answerable: does this vendor's economics structure meet my take rate requirements? Does their compliance approach match my bank's standards? Does their infrastructure support the migration path I've designed?
The architecture design process takes 4–6 weeks. The cost of skipping it is 12–18 months of re-architecture work when the program outgrows the vendor-default foundation it was built on.
About to build your payments program? See ExpandUp's 7-step architecture process, or talk with us before vendor selection.