ISO vs. PayFac vs. Referral for Software Companies
ISO vs. PayFac vs. Referral for Software Companies
Compare the referral, ISO, and PayFac models. Learn which level of payment ownership your software company can support.
A payment model appears in the revenue forecast long before it reaches the daily operation.
Referral, ISO, and PayFac arrangements can all help software companies generate revenue from payments. Each one places merchant onboarding, pricing, support, risk, settlement, and reconciliation in different hands.
A referral model generally fits companies seeking limited operational involvement. An ISO arrangement offers greater commercial participation with responsibilities defined by contract. A registered PayFac suits platforms prepared to take on deeper merchant, risk, compliance, and payment-operations responsibilities.
The strongest fit comes from matching the model to the work the organization can support.
This guide explains where those responsibilities typically sit, how they change when a payment goes off course, and what software companies should evaluate before choosing.
Table of Contents
How Referral, ISO, and PayFac Models Work
The boundaries between these models can look blurry from the merchant’s perspective. All three can support embedded payment experiences, revenue sharing, and branded interfaces.
The structure behind that experience is what changes.
Referral Partner
A referral partner introduces its customers to a payment provider. The provider generally handles merchant onboarding, underwriting, processing, risk monitoring, settlement, and payment support.
The software company may earn a commission or share of payment revenue without building a large internal payments operation. In return, the provider often retains greater control over merchant approval, pricing, data, and the ongoing relationship.
Referral works well when speed and limited operational exposure carry more weight than control.
Registered ISO
A registered independent sales organization (ISO) works through a sponsoring financial institution to market and support payment services.
Merchants typically receive individual merchant accounts. The ISO may influence pricing, branding, merchant acquisition, integrations, support, and payment economics. Underwriting and core processing infrastructure commonly remain with the acquirer or processor.
ISO responsibilities vary considerably. One ISO may focus on sales and merchant service. Another may participate more deeply in onboarding, risk review, reporting, and portfolio management.
The agreement determines how much of the payment operation the ISO carries.
Registered PayFac
A payment facilitator, or PayFac, is a service provider registered by an acquirer to facilitate transactions for submerchants.
The PayFac brings submerchants into its sponsored structure rather than requiring each one to establish a separate acquiring relationship. This gives the PayFac greater influence over onboarding, pricing, monitoring, support, and the embedded payment experience.
That structure also creates deeper responsibility.
The PayFac must maintain the processes, systems, and oversight needed to manage its submerchant portfolio. Some work may be outsourced, but the registered arrangement still determines who is accountable.
Where PayFac-as-a-Service Fits
PayFac-as-a-Service, or PFaaS, can provide onboarding, compliance tooling, risk systems, payment interfaces, and processing infrastructure without making the software company a registered PayFac.
The term covers several possible arrangements. Industry guidance on payment facilitation submodels recommends examining registration status, merchant contracts, liability, and the activities each party performs.
A PayFac-like customer experience does not reveal the legal or operational structure behind it. Those answers live in the agreement.
Where Payment Responsibility Actually Moves
The three models become easier to compare when the focus shifts from features to ownership.
RESPONSIBILITY | REFERRAL | ISO | PAYFAC |
Merchant onboarding | Provider-led | Processor or acquirer-led with ISO involvement varying | PayFac-led |
Pricing and economics | Provider-defined commission or revenue share | Greater contract-defined control | Deeper pricing control |
Merchant support | Provider-led | Often shared | PayFac-led |
Risk and compliance | Primarily handled by the provider | Divided by agreement | Deeper PayFac responsibility |
Disputes and settlement | Provider investigates and resolves | ISO support varies | PayFac coordinates and oversees |
Reconciliation and reporting | Platform relies on provider data | Access and ownership vary | Stronger end-to-end capabilities required |
These are typical patterns rather than fixed rules. Sponsor relationships, processors, service providers, and contracts can move individual responsibilities between parties.
The movement also creates dependencies.
A platform may control its payment interface while relying on another company for merchant approval. An ISO may support the merchant but depend on processor records to explain a settlement. A PayFac may outsource underwriting technology while remaining accountable for the resulting decisions.
Every responsibility needs three things:
- A named owner
- Access to the necessary records
- A process for reaching and documenting the outcome
Gaps between those three create the operational problems that model comparisons often overlook.
Reconciliation is one example. A payment can involve the software platform, processor, bank, merchant balance, fees, reserves, and accounting system. The party expected to explain the final outcome must be able to connect those records.
For complex platform flows, split payment reconciliation may also need to trace merchant proceeds, platform revenue, processing costs, partner shares, and later adjustments back to the original transaction.
One Settlement Exception Across Three Payment Models
Consider a simple exception.
The platform expects a $50,000 settlement. The bank deposit arrives at $48,750.
The difference could involve processing fees, a reserve, a chargeback, a returned payment, a timing cutoff, or a missing transaction.
The amount is the same under every model. The investigation is not.
Under a Referral Model
The software company generally raises the issue with the provider.
The provider reviews its transaction and settlement records, identifies the difference, and sends an explanation. The platform’s finance team depends on the provider’s reporting, response time, and support process.
The operating burden remains relatively light, but visibility may also be limited.
Under an ISO Model
The agreement determines who leads the investigation.
The ISO may review portfolio reports, confirm pricing, support the merchant, and coordinate with the processor or acquirer. Another party may still control the settlement records or make the final correction.
A clear escalation path matters because the resolution can cross several organizations.
Under a PayFac Model
The PayFac carries deeper responsibility for explaining the submerchant’s outcome.
Its teams may need to connect the original transactions with fees, reserves, chargebacks, processor settlement, merchant funding, bank activity, and ledger records.
Infrastructure partners may supply some of that data, but the PayFac still needs a controlled process for resolving the discrepancy.
The first settlement exception turns the model from a commercial agreement into daily work.
How Software Companies Should Choose
The decision should begin with four factors:
1. Control
Identify which parts of the experience must remain inside the software platform.
This may include branding, pricing, merchant onboarding, support, payment data, settlement visibility, or product development. Each area of control should serve a clear commercial or customer need.
2. Economics
Compare the revenue available with the cost of supporting it.
A higher payment margin can require additional engineering, support, finance, risk, compliance, dispute, and reporting resources. The useful number is the value left after those costs.
Payment volume matters, but there is no universal threshold that makes one model right. Merchant risk, payment methods, exception rates, and existing capabilities change the calculation.
3. Risk Capacity
Determine whether the company can assess merchants, monitor activity, manage disputes, respond to compliance requirements, and absorb its contractual exposure.
Risk capacity includes expertise, systems, evidence, escalation paths, and decision rights. It cannot be measured through payment volume alone.
4. Operational Infrastructure
Trace one transaction from merchant onboarding through settlement, reconciliation, reporting, and any later adjustment.
Document every system, record, and team involved. Then, identify which responsibilities would move under each proposed model.
This separates commercial ambition from operating readiness. A company’s broader embedded payments maturity determines how consistently it can carry the responsibilities it accepts.
Which Model Fits?
Model | Best suited for | Operational readiness |
Referral | Companies treating payments as a supporting feature | Lean team seeking a faster, lighter operational model |
ISO | Companies making payments a meaningful revenue and customer-experience channel | Capacity to coordinate merchant service and payment operations with partners |
PayFac | Companies making payments central to their product strategy | Dedicated payment, risk, compliance, finance, and support capabilities |
Before signing, confirm the answers to these questions.
- Who signs the merchant agreement?
- Who approves and monitors merchants?
- Who controls pricing?
- Who handles support and disputes?
- Who carries merchant losses?
- Who explains settlement differences?
- What data will each party receive?
- Who reconciles processor, bank, platform, and ledger records?
The right fit is the model your organization can operate consistently as merchant volume and payment complexity grow.
Frequently Asked Questions
Who Is the Merchant of Record in Embedded Payments?
The merchant of record depends on who sells the underlying product or service and how the commercial and contractual arrangement is structured. Embedding the payment interface does not automatically make the software platform the merchant of record.
Does Changing Payment Models Require Changing Payment Processors?
Not always. A company may be able to change its commercial or operational model while retaining some existing processing infrastructure. The available path depends on its current contracts, sponsor relationships, technical integrations, and the capabilities of its payment partners.
Can a Software Company Move From a Referral Model to an ISO or PayFac Model Later?
Yes. Many software companies begin with a referral arrangement and assume more payment responsibility as their volume, resources, and strategy develop. Before moving, the company should assess whether its payment operations, financial controls, compliance processes, and support structure can handle the additional work.
Is PayFac Better Than ISO for SaaS Companies?
A PayFac provides deeper control over onboarding, pricing, and the payment experience. An ISO generally requires less risk and compliance infrastructure. The better fit depends on the company’s commercial goals, internal capabilities, and appetite for operational responsibility.
The Model Has to Hold Up After Settlement
Referral, ISO, and PayFac models distribute control, economics, and responsibility differently. Their value becomes visible when a merchant needs support, a settlement arrives short, or finance must explain the final outcome.
The right model gives the company room to grow without creating payment responsibilities its operation cannot reliably explain, control, or prove.
Paycile helps software platforms build payment and reconciliation operations around the level of ownership they are prepared to carry. Schedule a conversation.