PayFac-as-a-Service vs. Registered PayFac Tradeoffs for SaaS Platforms

Payment processing revenue flowing through U.S. Payment processing revenue flowing through U.S. software platforms hit an estimated $16 billion in 2025, growing at roughly 20% a year, McKinsey reports. Most of that money is not landing in the platforms generating the transactions. It's landing with whoever owns the compliance stack underneath them. McKinsey's Merchant Acquiring Survey shows nine in ten small and mid-sized merchants in that same market now handle payments through some kind of independent software vendor, so the baseline has already shifted from "sh... small and mid-sized merchants now handle payments through some kind of independent software vendor, per McKinsey's 2025 Merchant Acquiring Survey, so the baseline question has already shifted from "should a platform monetize payments" to "which structure lets it keep the margin." Most platforms answer that question by picking whatever's fastest to set up, not what actually fits their volume, risk tolerance, or five-year plan. That mismatch gets expensive slowly, then all at once.

This is a framework for figuring out where a given platform sits on three axes: scale, operational readiness, and risk appetite. Neither PayFac-as-a-Service (PFaaS) nor full registration is the better model in the abstract. Each is the right model for a specific set of conditions, and the conditions are measurable.

What the two models are and what they share

Payments monetization for software platforms isn't a binary choice. It runs on a spectrum, from basic referral deals (small fee, no ownership of the merchant relationship) through branded or integrated partnerships, then PFaaS, then full registered PayFac status. The tradeoffs sharpen at the two ends, so that's where this piece stays.

A registered PayFac is listed directly with Visa and Mastercard as a payment facilitator. It holds its own master merchant account through a sponsor bank and onboards sub-merchants underneath that account. It owns every piece of the processing system: compliance, financial liability, underwriting rules, pricing, and settlement logic, start to finish. Nobody sits between the platform and the card networks.

PFaaS runs on rented infrastructure. The platform pays a provider for access to its license, its bank relationships, its compliance stack, and its risk monitoring, then plugs in through an API and brands the experience to whatever degree the provider allows. The provider is the one registered with the card networks and holding the sponsor bank relationship. The platform still owns the merchant relationship day to day and still earns a cut of every transaction, but the underlying legal and financial weight sits with the provider.

In either case, the platform sets merchant pricing, controls onboarding, and owns the sub-merchant relationship. That's the line that separates PFaaS and registered PayFac from a basic referral arrangement or a plain integrated-payments setup, where a third party controls pricing and the relationship belongs to them, not the platform. A standard integrated payments configuration, where a processor operates beneath the platform's checkout flow but sets its own pricing and owns underwriting, doesn't give a platform the same economics as PFaaS. The confusion is common, and it costs platforms money when they assume "we're integrated with a payments partner" and "we're running PFaaS economics" mean the same thing. But integration and PFaaS economics do not mean the same thing.

The real cost of becoming a registered PayFac

Preczn's research puts registration costs at an average of up to $500,000 to launch and about $100,000 a year to maintain after that. Setup alone can run two years from decision to live transactions, with the formal registration process with the card networks taking 12 to 18 months on its own.

What buys that money and that time is a full compliance and operations stack, not a single approval letter. PCI Level 1 compliance requires a Qualified Security Assessor audit, a formal, recurring process, not a checkbox. ACH processing requires NACHA compliance. The sponsor bank relationship needs ongoing management, not a one-time signature, and the bank has to be comfortable with the constant movement of funds through an FBO (For Benefit Of) account structure. Every sub-merchant needs KYC and KYB checks at onboarding, and those checks don't end at onboarding: they continue for the life of the relationship. On top of all that sits chargeback management infrastructure, dedicated risk and compliance staff, insurance, and reserve accounts to cover losses.

None of this is getting easier. The regulatory bar is rising: some of the more established PayFacs are now going back to existing merchants to collect information they should have gathered at onboarding in the first place, because compliance expectations have shifted for firms that thought they'd already cleared the bar. Full registration pulls engineering time, legal time, and operational bandwidth away from the core product for a sustained stretch. For most vertical SaaS companies, that's not a side initiative that runs in parallel with everything else. It's a redirection of the roadmap.

These costs are fixed, and they're front-loaded. Whether $500,000 and two years make sense depends entirely on how much volume a platform is running and how much margin is on the table, which is a math problem, not a philosophy.

What PFaaS costs and what it gives up

Speed is the real selling point. A platform can go live on PFaaS in weeks, compared with 12 to 18 months of registration work for full PayFac status.

The revenue numbers back it up, with a caveat: below. A platform processing $10 million a month through PFaaS can generate around $57,500 in net revenue, against $5,000 to $8,000 for the same volume under a traditional referral deal, a jump of 700% to 1,000%. That's real money. But the $57,500 figure already has the provider's cut baked into it: PFaaS revenue is split with whoever owns the license and the bank relationship, while a registered PayFac keeps the full margin, just not until it's absorbed $500,000 in setup costs and $100,000 a year in overhead.

Three drawbacks tend to get left out of the pitch. First, margin dilution goes beyond the revenue split itself: many providers layer additional fees on top of the share they take, so the real unit economics need all cost components modeled together, not just the headline split. Second, the provider controls risk policy, contract terms, and often branding guardrails, which means a platform can't fully set its own underwriting criteria or pricing logic the way it could under its own registration. Third, moving away from a PFaaS provider later can be slow and costly, especially if that provider holds merchant data or controls key integrations. Read the contract terms around data portability closely before signing, not after deciding to leave.

There's a structural mismatch too. Some PFaaS infrastructure is better suited to generic payment acceptance than to the specific needs of vertical SaaS platforms. Those limitations can create friction when a platform tries to build an actual payments business rather than just accept cards. And none of this works without volume. The revenue share only means something if there's meaningful margin being generated to share.

The breakeven math that determines which model fits your volume

The decision comes down to one comparison: does the incremental margin a platform would recover by eliminating the provider's revenue share exceed the upfront setup costs and ongoing annual overhead of registering directly? That crossover happens at a specific volume level, not a matter of preference.

Based on the available research, that breakeven point for owned infrastructure falls in a broad middle band of processed volume, well above the entry level but still short of the higher tier platforms eventually reach. Below that band, PFaaS economics tend to win even after accounting for the revenue share taken off the top. Above a certain processing scale, platforms should be actively evaluating direct registration or some hybrid structure, because the margin recovered by cutting out the provider's share can eventually dwarf the cost of building and running the compliance stack.

The referral comparison sets the floor. Referral deals generate $5,000 to $8,000 in net revenue at $10 million in monthly volume; PFaaS can generate around $57,500 at the same volume. What matters more than choosing between PFaaS and referral is identifying the point along the volume curve at which registered PayFac economics overtake PFaaS as the better answer.

Practically, that breaks into three bands. Early and growth-stage platforms processing well under that breakeven band find PFaaS economics superior almost every time. Platforms approaching that breakeven band should start modeling the registered path now, not to switch immediately but to know when the crossover is actually coming. Platforms operating at significant scale with existing compliance infrastructure and internal risk staff already have a real business case for full registration.

Volume by itself doesn't settle the question, though. A platform processing a substantial volume each month with no compliance staff and a three-person engineering team isn't ready for registered PayFac status no matter what the volume math says. Readiness is its own variable.

Operational readiness as a distinct variable from volume

A platform can clear the volume threshold for registration while still being organizationally unprepared for it. The compliance burden lands on people who have to do the work every day, not just on systems that run in the background.

Real readiness means dedicated payments operations and compliance staff, not a function shared with three other teams. It means KYB and KYC capability for every single sub-merchant at onboarding: verifying the legal entity, its registration status, its beneficial owners (each of whom needs individual KYC), its business activity, and its regulatory standing. A national regulator's Beneficial Ownership Rule, which took effect in 2024 and has continued evolving through 2026, has seen significant permanent exemptions established as of August 14, 2026, substantially narrowing its scope. persons were permanently exempted as of August 14, 2026. Platforms should confirm whether any reporting obligations remain applicable to their specific merchant base given the evolving regulatory landscape. Add chargeback infrastructure, transaction monitoring for AML and BSA purposes, and continuous management of the FBO account and banking relationship, and the operational load is substantial.

Automation is compressing some of this. Machine learning has cut merchant onboarding time from days to minutes for lower-risk applicants, with document AI, beneficial-owner extraction, risk scoring, and straight-through processing now running at scale across the industry. For a PayFac onboarding thousands of small merchants, manual review of every single application simply isn't possible, so risk-based automation isn't a nice-to-have, it's the only way the model functions at that volume. But automation handles execution. It doesn't move the compliance obligation off the platform's books. The platform still owns it.

PFaaS shifts most of this operational weight onto the provider, but that doesn't mean a platform can ignore what's happening underneath. The sub-merchants are still the platform's customers, and a platform needs to understand what its provider is doing on its behalf, because when something goes wrong, the merchant calls the platform first, not the provider.

A short readiness check helps here. Can the platform hire or already staff dedicated compliance and risk people? Can engineering support the integration and maintenance work, which PFaaS integration and maintenance work typically requires dedicated engineering support, and meaningfully more for a registered PayFac's larger integration surface? Does the banking relationship support an FBO structure with constant fund movement? A "no" on any of those is a real constraint, independent of how much volume is flowing through the platform.

Risk appetite as the third axis: what liability you are accepting

Registration makes the platform the merchant of record. That means absorbing fraud losses, chargeback losses, and regulatory liability for every sub-merchant it onboards. Compliance becomes a core function, and the costs that come with it are not small.

Under PFaaS, the provider absorbs a meaningful share of that liability, since it holds the master merchant account and the card network registration. The platform still carries exposure through its merchant relationships, but the heaviest legal and financial weight sits one layer up, with the provider.

Three questions define risk appetite in practice. Can the platform absorb chargeback and fraud losses on behalf of its merchants, including whatever reserve requirements come with that? Is the platform willing to be named directly with Visa and Mastercard, with the reporting and audit obligations that status carries? Does the platform's merchant base skew toward a single vertical, where fraud or chargeback events tend to cluster together rather than spread out, so that a registered PayFac in that market absorbs that correlated risk directly instead of it being diluted across a broader book?

None of that is purely a management decision, either. It's what a board, a set of investors, and a banking partner will actually support. A venture-backed platform running thin reserves is often structurally boxed out of taking on PayFac liability even if its leadership wants to move that direction. PFaaS doesn't make risk disappear, it just relocates where the compliance ownership sits, while the platform keeps the commercial and reputational fallout if its merchants have a bad payment experience.

Some providers built a bridge for this exact tension. Infinicept, for one, structures PFaaS as a staged path with a defined route toward full registration later, letting a platform operate under PFaaS risk parameters now while building the internal muscle to take on registration once its risk appetite and operational capacity catch up to its volume.

How the 2026 provider landscape maps to these decision dimensions

The provider market splits along the same three axes covered above: how much control a platform gets over pricing and the merchant relationship, how much of the compliance burden the provider actually absorbs versus merely administers, and how easy the exit is if the platform outgrows the arrangement.

Vertical-specific PFaaS providers tend to compete on depth of payment method coverage in a single API (cards, ACH, and wallet options bundled together), full ownership of compliance functions like KYC, PCI, and fraud monitoring sitting with the provider rather than the platform, and contractual terms that avoid exclusivity clauses or making it hard to retrieve merchant data and tokens later. Faster go-live times, sometimes measured in days rather than months, are a competitive differentiator among providers built specifically for software platforms rather than general merchant acquiring.

The broader point holds regardless of which provider a platform evaluates: the contract terms around data portability, the specifics of who absorbs credit and fraud losses, and how much pricing control the platform actually retains outweigh the headline speed-to-market number. A platform doing real diligence on a PFaaS provider in 2026 should be asking the same three questions this piece opened with. Where does this land on volume. Where does it land on operational readiness. Where does it land on what liability the platform is actually willing to hold.