Payments Infrastructure Architecture for Vertical SaaS
Choosing the wrong payments model early locks your revenue ceiling for years to come.
The three implementation models and what each one transfers to the platform
Three ways exist to embed payments into a vertical SaaS product, and most platforms pick the wrong one because they optimize for speed to launch instead of speed to revenue ceiling. That choice, made in month one, raises a ceiling that becomes visible two years later as a line item nobody can move. What matters is what each model hands the platform and what it quietly keeps for itself.
Integrated payments, where the platform redirects to a third-party processor, is the fastest to launch and asks almost nothing of the platform in terms of compliance. That speed is also the trap. The platform doesn't own the merchant relationship and doesn't own the pricing spread either. Revenue appears as a referral fee, an indirect cut, or nothing at all, and there's no path from that arrangement to a lending or insurance product down the line, because the platform never touches the underlying merchant data closely enough to build one.
Payment facilitator-as-a-service sits in the middle, and it's the model most platforms should be evaluating, since it's the only one of the three where the economics scale with effort. The platform acts as the merchant of record in practice: it controls onboarding, sets pricing, and owns the relationship with each sub-merchant, while a licensed partner underneath handles acquiring registration, the sponsor bank relationship, and the regulatory paperwork. The platform negotiates a buy rate from that partner and keeps the spread between what it pays and what it charges merchants. That spread only exists, though, if the arrangement gives the platform real rate transparency. Some setups route everything through a provider's master merchant account and never hand over that visibility or margin control. So "PFaaS" is a spectrum of arrangements rather than one thing, and a platform that doesn't negotiate for rate transparency up front is signing up for a worse version of the same label, one where the buy rate is fixed by someone else and called a partnership.
Full Payment Facilitator registration means the platform does the acquiring work itself, with no partner in between. It carries the most revenue and the most control, but the registration process takes more than a year and demands a dedicated payments operations and compliance function; that function requires dedicated ownership, and cannot be a part-time assignment handed to someone on the engineering team. Most platforms aren't ready for this on day one. Treating full PayFac status as the default goal rather than an earned upgrade is how teams burn a year on registration before they've proven the merchant base is worth the overhead.
Several infrastructure providers now sell into the PFaaS layer, each with a different angle. Some position themselves for platforms planning to graduate into full PayFac ownership later, building compliance tooling meant to prepare a team for that jump. Others compete mostly on speed of integration, with deployment windows measured in weeks rather than months. The category is growing fast: registered PayFacs worldwide grew at a 13.8% compound annual rate between 2018 and 2025. Everyone is racing into the same layer, and the platforms that picked PFaaS with real rate transparency are the ones with room to negotiate later. The rest will find out their buy rate was never actually negotiable.
Merchant ownership as the first structural decision in payments architecture
Processing volume and merchant ownership get treated as the same thing constantly, and they aren't. A platform can run every transaction for a merchant and still not own that merchant, if the pricing terms, the support relationship, and the underlying agreement belong to someone else. This is the mistake that caps a platform's revenue before the product team ever notices it happened.
Owning the merchant relationship means something specific. The platform controls what onboarding looks like and what terms the merchant actually sees. It sets pricing itself, within whatever buy-rate economics it negotiated, instead of passing through a rate card written by its processor. It holds the sub-merchant agreement directly and is the first call when a chargeback or dispute comes in. And the transaction data flows to the platform itself, even though a separate processor handles the card behind the scenes.
That data flow is the whole point. BCG's research found platforms running embedded payment strategies retain customers at 2.5 times the rate of traditional payment providers, and merchants on those platforms adopt 18% more value-added services. Ownership of the relationship is what makes lending, insurance, and payroll products possible later, since all of them depend on transaction data and on a level of trust that only exists when the platform, not a third party, is the one the merchant already knows.
There's a switching-cost angle too, and it cuts against platforms that treat payments as an afterthought. Research indicates a large share of businesses are willing to switch software platforms entirely for better payment capabilities. That's a threat to platforms with weak payments, and it's the exact asset a platform builds when it owns the merchant relationship well. Picking a model where the processor keeps the merchant caps the revenue ceiling on day one, and unwinding that decision later means a full merchant migration: new agreements, new onboarding, the whole relationship rebuilt from scratch with a customer who has no reason to trust the process the second time.
Money movement architecture: Pay In, Pay Out, and the underlying rails
Money moving into a merchant's account and money moving out of it get lumped together under "payments" constantly, as if they're the same engineering problem wearing two hats. Money moving into a merchant's account and money moving out of it get lumped together under "payments" constantly, as if they're the same engineering problem wearing two hats, but they are not the same problem. Different rails, different timing, different risk exposure. Treating them as one undifferentiated system is one of the more common architecture mistakes a platform can make, and it becomes visible first in the margin line, not the engineering backlog.
On the Pay In side, card rails through Visa and Mastercard carry interchange costs and chargeback liability, and the specific acquiring relationship a platform has determines how that interchange gets structured and who's on the hook when a dispute lands. ACH is cheaper and fits recurring billing, B2B invoicing, and larger-ticket transactions where a flat card network fee eats too much margin. Pricing for ACH and pricing for cards are two separate decisions, not one policy applied twice, and a platform that only supports cards is leaving ACH volume, and the margin sitting on top of it, on the table. Revenue per transaction typically runs 30 to 100 basis points across card and ACH volume combined, and across a large book of merchants, the gap between the low and high end of that range adds up fast.
Pay Out is a separate problem, with its own rails for disbursing money to sub-merchants, contractors, or vendors: standard ACH, same-day ACH, RTP, or push-to-card, each with a different price tag and a different speed. Accounts payable work sits on top of that: lien waiver tracking, vendor payment scheduling, remittance detail. Procore Pay handles subcontractor payments in construction with automated lien waiver management built in, and that's what a vertical-specific Pay Out product looks like once it's built for the industry instead of bolted on generically. Whether Pay Out is a core product feature or a standalone financial service is a decision the platform has to make, and it shapes both pricing and the operational team required to support it.
Pay In and Pay Out belong on the same data layer. What happens at the point of acceptance has to inform disbursement timing, reconciliation, and risk decisions downstream, and platforms that build these as two separate systems end up with reconciliation gaps, losing the compounding value that comes from one clean data set instead of two that don't talk to each other. Reliability at scale isn't optional either. Payment infrastructure running at the level major processors operate at, handling hundreds of millions of transactions across peak shopping periods, is what "production-grade" actually means in this business, and that's an architectural requirement, not a line in a sales deck.
The merchant onboarding layer: KYB, underwriting, and risk as architecture, not compliance theater
Onboarding is the first place a merchant actually experiences the architecture decisions made behind the scenes. How fast it goes, how accurate it is, and how consistent it stays across thousands of merchants determines both how many sign up and what kind of risk sits in the portfolio the platform is left holding.
The Bank Secrecy Act and related anti-money-laundering rules set a regulatory floor that isn't optional and isn't shrinking. Those rules require identifying legal entity customers, including who actually owns and controls them. FinCEN's Beneficial Ownership Rule, which took effect in 2024, introduced reporting requirements on beneficial ownership for domestically registered entities, though its scope has continued to shift through ongoing regulatory and legal developments. Visa and Mastercard both mandate due diligence on every merchant before it gets boarded, and state money transmitter laws pile additional licensing and know-your-business requirements on top for platforms moving money beyond straight card processing.
Visa raised the stakes in 2025 with the Visa Acquirer Monitoring Program, which folded older, separate monitoring thresholds into one framework and holds acquirers and payment facilitators directly accountable for the fraud and dispute performance of every merchant in their portfolio. Fines and processing restrictions follow when KYB and ongoing monitoring fall short, and that failure is now measured at the portfolio level, not merchant by merchant. A single bad-actor merchant buried in a large book can drag down the whole platform's standing with the network, not just its own account.
The fix is building the onboarding stack correctly from the start: automated know-your-business checks that combine entity verification, anti-money-laundering screening, ultimate beneficial owner verification, sanctions screening, and risk scoring into one flow instead of five separate ones, plus risk-based routing that lets low-risk merchants clear in minutes while sending genuinely risky applications to a human. Ongoing due diligence matters just as much: risk gets reassessed after boarding, rather than scored once on day one and never revisited.
Reducing friction for good merchants and satisfying a regulator watching for bad ones get talked about as a tradeoff. Reducing friction for good merchants and satisfying a regulator watching for bad ones get talked about as a tradeoff, but they are not one. Adaptive onboarding forms that cut duplicate data entry while feeding accurate information into the compliance workflow underneath solve for both at once. What the platform has to decide at the architecture stage is whether KYB and underwriting get built in-house, bought from a vendor, or inherited from whichever infrastructure partner handles the PFaaS relationship, and that single decision shapes both onboarding speed and how much compliance risk sits on the platform's own books.
AI as an operational layer across the payments stack, not a product feature on top of it
The adoption curve here is steep. A survey from the Cambridge Centre for Alternative Finance found 71% of financial services respondents adopting generative AI, and 52% actively adopting agentic AI, the fastest-scaling technology category the sector has seen in years.
Fraud detection is where AI has already become standard rather than novel, with a broad majority of financial institutions now running some form of AI or machine learning fraud detection. For a vertical SaaS platform, the meaningful split is between a model that sits inside the platform's own infrastructure, where it sees the platform's merchant context directly, and a model outsourced to a vendor working off a thinner, secondhand view of the same data. The first version catches more, faster, because it isn't reconstructing context a third party never had. Onboarding benefits the same way: document extraction, business verification, and risk scoring can all be automated, cutting both the manual review load and the time it takes a new merchant to go from signed up to active.
Reconciliation and reporting are getting the same treatment. Generative AI is increasingly taking over document-heavy administrative work: compiling financial statements, reconciling accounts, pulling figures off invoices, tasks that used to eat significant analyst hours every week. Dispute handling is following the same pattern, with AI-assisted approaches to chargeback management becoming more common across the payments industry.
The frontier past all of that is agentic payments: AI systems with delegated authority to initiate and manage transactions on their own, not simple autopay, but systems that make judgment calls toward a goal a person set for them. Phronetic AI's PayCentral, launched in October 2025 on Google's Agent Payments Protocol, is an early working example, with agents designed to create payment links, manage refunds, handle subscriptions, and reconcile accounts without a human clicking anything.
None of this works if AI gets bolted onto a payments stack after the fact. The data flows, the event hooks, the points where a model actually gets access, all of it has to be part of the design from the start, not retrofitted later. The federal government released a National Policy Framework for AI Legislative Recommendations following a December 2025 executive order, and states are moving on their own timelines too, so the regulatory ground under AI is still shifting. Building for that means favoring infrastructure with compliance controls that can be reconfigured, rather than logic hardcoded against today's rules.
Pay Ops: the operational infrastructure that holds the stack together
Pay Ops governs everything else described so far. Merchant onboarding is part of it, but so is the ongoing management of a merchant's lifecycle: keeping billing configurations correct as pricing changes, producing revenue reports that mean something, running the operational workflows that keep the payments business functioning long after the launch announcement.
If this layer is skipped, specific things break, in a specific order. Billing configurations drift out of sync with actual pricing over time, causing reconciliation errors and merchant disputes nobody can trace back to the source later. Risk monitoring becomes a periodic review instead of a live signal, leaving windows where a problem merchant goes unnoticed longer than it should. Reporting gets stitched together by hand from disconnected systems, burning operations staff time and producing numbers too stale to act on by the time anyone sees them. Merchant support ends up escalating to the platform's own team constantly, because there's no structured process to resolve the common cases at first contact.
BCG's research found software platforms now manage 60% to 70% of their clients' payment processing contracts directly. That's a heavy operational load, and Pay Ops is what makes carrying it manageable instead of chaotic.
Whether Pay Ops is built right comes down to a simple test: does headcount have to grow in lockstep with merchant volume? If headcount has to grow in lockstep with merchant volume, that's an architectural failure, not a staffing problem to solve with another hire. Automation should handle the routine lifecycle events, so people are only needed for the exceptions. This also affects how the business gets valued. Acquirers and investors look at the quality of a platform's payments operations as a stand-in for how defensible its payments revenue actually is. A merchant book with consistent risk controls, clean reconciliation, and documented compliance workflows earns a different multiple than one where the revenue is real but nobody outside the company can tell how it's actually being run.
The rising monetization ceiling from compounding architectural layers
None of these layers pays off in isolation. A platform that owns the merchant relationship but hasn't built Pay In and Pay Out on a shared data layer is sitting on retention numbers it can't turn into cross-sell. A platform with clean money movement but a manual, understaffed onboarding process is capping how fast its merchant base can grow, no matter how good the rails underneath are. Pay Ops is what makes the other two scale instead of just function, and skipping it is the most common way platforms cap themselves without noticing it.
Payments revenue in vertical SaaS is a stack built layer by layer, in a specific order, where each decision either compounds the one before it or quietly undermines it. Mindbody and Shopify didn't end up with payments as the majority of their revenue by accident. They made the ownership decision first, built the money movement rails to match it, then built the operational machinery to keep the whole thing running without linear headcount growth. That sequencing, ownership, then rails, then operations, is what separates payments as a line item from payments as the business.
