Key takeaways
- An ISO (independent sales organization) or referral arrangement pays you a share of processing revenue while the provider holds the merchant contract and sets the rate. A PayFac (payment facilitator) takes on pricing, boarding, and the merchant of record position, together with the underwriting and compliance work that sustains them. A managed PayFac delivers that same ownership through a provider already carrying the registration, which is why it suits most vertical SaaS companies.
- A platform processing $50 million a year may earn only 5 to 15 basis points under an integrated referral model, while McKinsey puts PayFac’s revenue share at 70 to 90 percent of processing revenue against 30 to 50 percent for traditional software partnerships.
- Neither card network allows a software company to register itself as a facilitator, since Mastercard Rule 7.8 places that step with the acquirer, which makes sponsorship the practical constraint on this decision.
- Full PayFac registration runs 12 to 18 months before the first transaction settles, while boarding onto an established facilitator takes days.
- Platforms are rarely locked into one structure, and the common path runs from a referral arrangement to a managed PayFac as volume concentrates, with registration a separate question many never need to answer.
The commercial structure underneath a software product decides who signs the merchant, who sets the rate, and who keeps the spread between wholesale cost and what that merchant pays. Two platforms in the same vertical can run identical volume and book very different payment revenue because of that one decision, which also fixes their compliance load and whose brand merchants deal with.
An ISO, a PayFac, and a managed PayFac each answer those questions differently, and the right structure depends on your volume, how central payments are to the workflow, and what your team can realistically run.
ISO vs. PayFac vs. managed PayFac: A side-by-side comparison
Whoever holds the merchant agreement also sets pricing, owns the transaction data, and absorbs the loss exposure, which is why that single row predicts most of the others. The comparison below runs through all three structures, from who underwrites and who prices, to how long each takes to launch and which compliance functions your team ends up staffing:
What is an ISO in payments?
An ISO sells payment processing under an acquiring bank’s sponsorship. Software companies use the term loosely, which matters because the two arrangements it gets applied to have very different economics.
Registered ISO vs. referral partner
A registered ISO holds sponsorship from an acquiring bank, issues its own merchant paper, and negotiates a share of the margin above wholesale. A referral partner introduces merchants to a provider, collects a fee once they activate, and stays outside the money movement entirely. Most software companies describing their setup as an ISO deal are running the second one, which comes with no pricing leverage at all.
What an ISO controls and what it does not
Whether you are a registered ISO or a referral partner, the acquirer holds the parts that determine your economics, while your product holds the parts your merchants see.
What you control
- The interface, since payments happen inside your product
- A negotiated revenue share, reset whenever the agreement comes up again
- Which provider you recommend to new merchants
What the acquirer controls
- Merchant approval, on their underwriting and their timeline
- The contract, since merchants sign with them
- The rate, set before your share is calculated
- The transactional record, where your access is limited to what they report
On $50 million of annual volume, a platform may see only 5 to 15 basis points, where a facilitator’s share of processing revenue runs 70 to 90 percent. Merchants deal with two brands and receive statements from a company they never chose, which is what separates a referral deal from the other two structures in SaaS payment processing.
What is a PayFac?
A payment facilitator signs merchant acceptance agreements on behalf of an acquirer, receives settlement proceeds on behalf of the underlying seller, or both. Visa’s third-party agent rules classify an entity performing either function as a facilitator, without requiring it to perform both.
What registration requires
A software company cannot register itself as a payment facilitator. Visa’s facilitator model assigns registration to the acquirer, which completes a risk and financial review of the applicant first, so sponsorship rather than engineering capacity governs whether this path opens at all. Most payment facilitator myths trace back to that constraint being overlooked.
Registration commits you to:
- Sponsorship: An acquirer willing to register you, after reviewing your risk profile and finances.
- Network fees: Annual and per-transaction charges from each card brand you accept.
- PCI DSS scope: A compliance program covering every merchant you sponsor, not only your own systems.
- Ongoing rule compliance: Obligations that shift as the networks revise their rules, with implementation windows you do not set.
How the sub-merchant model works
A PayFac holds a master MID (merchant identification number) and boards customers beneath it as sponsored merchants. Absorbing underwriting complexity into its own aggregate risk position lets boarding finish in hours or days where traditional acquiring runs to weeks. The facilitator pays for that speed by answering to its acquirer and the card networks for everything its sponsored merchants do.
What a PayFac has to operate
Those obligations translate into staffed functions rather than software you configure once. Applications need reviewing and limits need setting, someone watches the portfolio for fraud signals and volume anomalies, and disputes get worked end-to-end with evidence gathered and representments filed. Someone maintains the PCI program, the screening infrastructure, and the responses to network reviews, while another person reconciles settlement and corrects it when funding lands wrong. None of this is a one-time build, and every one of these functions carries payroll for as long as the registration stands.
What is a managed PayFac?
A managed PayFac, also called PayFac-as-a-Service (PFaaS), divides those responsibilities. A registered facilitator operates the infrastructure and holds the network position, while your company boards merchants beneath it, sets their pricing, and runs the experience under your own brand.
How the managed PayFac model works
Your merchants apply through your onboarding flow, and the provider’s decisioning runs against the submitted data while the interface, the rate presented, and the agreement stay yours. Merchant boarding completes on infrastructure you never built, reached through APIs and embedded payment components that keep card data out of your systems. The registered-entity position with the networks sits with the provider, and everything your merchants actually experience stays with you.
What the provider carries and what your platform owns
The line between the two sits in the same place across providers.
Network registrations and compliance programs look identical across every platform running them, so maintaining your own version returns nothing. Pricing, support, and workflow integration are specific to your vertical and your customers, which is the part of monetizing payments that a provider cannot do for you.
Where the managed PayFac model has limits
Your provider decides which merchants it will underwrite, so a book weighted toward one high-risk category can hit approval limits partway through your growth. New rails and features arrive on the provider’s schedule instead of yours, which constrains any roadmap that depends on a specific rail landing by a certain quarter. The one thing this structure cannot supply is a direct sponsor bank relationship, which matters if you intend to build a banking charter or a lending program on top of it.
Weigh these against registration, which carries the same dependencies through an acquirer who audits your underwriting and a sponsor bank that can end the relationship.
Which model fits your platform?
Three questions settle this, and they carry different weights depending on where your platform sits today:
How much volume runs through your product
Start with annual processed volume instead of subscription revenue, since payment economics scale with the former. McKinsey projects software vendor payment revenue in the US reaching $16 billion in 2025, up from $6.5 billion in 2020 after five consecutive years of 20 percent growth. Which structure you run determines your share of it. The gap between structures compounds as the book grows, so a platform at modest volume can reasonably favor operational simplicity, while a platform whose volume is concentrating will find that gap outweighing its subscription margin.
How central payments are to the workflow
In property management, construction, healthcare, field service, and education, payment volume per customer routinely exceeds software revenue per customer, because the software exists to move money that has to move. Where that holds, the payment experience is part of the product, and a white-labeled experience affects retention and revenue per customer. Where customers transact rarely, or an incumbent processor is already entrenched across the vertical, a referral arrangement produces revenue without the operational load.
What your team can realistically operate
Registration commits you to merchant approvals, risk, disputes, and compliance as permanent functions, at a standard your acquirer audits. A managed PayFac narrows that to merchant support and the vertical risk judgment only you can make, since you read your customers’ businesses better than a provider will. Large mixed portfolios sometimes run both, keeping the main book on one structure and routing outliers to another, though maintaining two reconciliation paths costs more than most teams budget for.
None of this is a permanent commitment, since platforms commonly start with a referral arrangement and move to a managed PayFac once volume justifies owning the experience.
Run payments through Payabli’s managed PayFac
Payabli holds the registration, so platforms building on it work through an established sponsor relationship, network registrations, and compliance program instead of standing up their own.
Payabli operates the infrastructure across Pay In for card, ACH, and check acceptance, Pay Out for paying vendors and subcontractors, and Pay Ops for boarding, underwriting, billing, disputes, and reporting, all through one unified API. Your platform keeps merchant pricing, the branded experience, and the transaction data, and integrates through direct APIs, no-code components, or a white-labeled portal.
To see how this maps onto your vertical and your existing stack, book a demo.
Frequently asked questions
- Is a managed PayFac the same as PayFac-as-a-Service?
Yes. Managed PayFac, PayFac-as-a-Service, and PFaaS describe one arrangement, where a registered facilitator supplies the infrastructure and the network position while your company owns merchant pricing, branding, support, and data. The naming varies by provider, the division of responsibility does not.
- Who is responsible for chargebacks under each model?
Under a referral or ISO arrangement, disputes belong to the acquirer holding the merchant. PayFac answers to its acquirer and the card networks for its sponsored merchants’ disputes and staffs the function that works them. Under a managed PayFac the provider carries system-level exposure and supplies the dispute tooling, while merchant boarding decisions stay with the platform. Commercial agreements allocate the remainder, so that section repays close reading before signing.
- Can you switch payment models later?
Most platforms do, though the move is not free. Stored cards need re-tokenizing when the underlying processor changes, settlement flows have to move, and the merchant of record relationship changes hands with customer communication attached. Moving a thin slice of volume first contains the exposure, where a rushed switch after a rate change or a provider exit rarely goes cleanly.