What's the actual difference between these two models?
Both models let a software platform offer payment acceptance to its customers. The difference is in how each individual customer's merchant status gets established:
- PayFac (payment facilitator) model — the platform (or its payments provider) holds one master merchant account, and each customer becomes a sub-merchant under it. Onboarding is fast because there's no individual underwriting step for most sub-merchants.
- ISO partnership model — each customer is onboarded as its own individually underwritten merchant, through a retail ISO relationship with an FSP and sponsor bank behind it. Onboarding takes longer because underwriting happens per merchant.
Neither model is a scam or a shortcut — both are legitimate, widely used approaches, and the right one depends on what a specific platform's customers and risk tolerance actually look like.
It's also worth understanding why the PayFac model exists at all. Before AI-assisted underwriting and programmable acquiring infrastructure made individual underwriting genuinely fast, aggregation was the only realistic way to onboard a merchant in minutes rather than days — the PayFac model traded per-merchant rigor for speed because, at the time, there wasn't a credible way to have both. That tradeoff was a reasonable engineering answer to a real constraint, not a shortcut invented to cut corners.
What does each model actually trade off?
| PayFac model | ISO partnership model | |
|---|---|---|
| Onboarding speed | Fast — minimal individual underwriting | Slower — full underwriting per merchant |
| Account stability | Subject to the master account's aggregate risk profile | Independently underwritten, stable from first transaction |
| Audit/reserve exposure | Shared across the aggregate; one customer's activity can affect others | Isolated to the individual merchant |
| Regulatory burden on the platform | Higher — the PayFac itself carries underwriting and compliance responsibility | Lower — underwriting sits with the ISO's FSP and sponsor bank |
| Best fit | Low-volume, low-risk, homogeneous customer bases needing instant onboarding | Customers with real or growing transaction volume, where account stability matters |
The PayFac model's core appeal — speed — comes with a real cost: every sub-merchant's ability to process is tied to the health and compliance standing of the master account above it. An audit, a reserve requirement, or a freeze triggered by the aggregate's overall risk profile can affect a specific sub-merchant even if that merchant individually did nothing to cause it.
AI-assisted underwriting has closed most of that speed gap
The onboarding-speed row in the table above is the one thing about this comparison that's changed the most recently, and it's worth spelling out why. Individual underwriting used to mean a person manually working through an application's business profile, financial standing, and compliance signals one at a time — identity verification here, business registration there, a document request that sits in an inbox for a day. That manual assembly work, not the underwriting judgment itself, was what made per-merchant review slow enough that aggregation felt like the only realistic path to fast onboarding.
AI-assisted underwriting changes what a reviewer starts with, not who makes the call. The technology can evaluate a merchant's application data, financial standing, and compliance signals together the moment an application comes in — cross-referencing identity, business registration, and risk indicators automatically instead of a person gathering each piece by hand. What used to take a reviewer days to assemble can reach them already organized and analyzed in minutes. The decision itself still belongs entirely to the ISO or FSP's own underwriters, operating inside the program their sponsor institution has approved — the AI narrows and organizes what they're looking at; it doesn't approve or decline anything itself.
Practically, this is what lets an ISO offer individual underwriting without conceding the onboarding-speed advantage that used to belong to PayFacs alone. NGnair's merchant acquisition and underwriting infrastructure is built around exactly this: AI-assisted analysis powering the ISO/FSP's own underwriting team, not replacing it.
Why does a merchant's own growth become a red flag under a PayFac?
This is the part of the tradeoff that's easy to miss until it happens: for a PayFac, a sub-merchant's rapid growth doesn't read as a success story the way it does to the merchant itself — it reads as a risk-profile change inside an aggregate the PayFac is ultimately accountable for. The industry's track record here is fairly consistent: a merchant that scales quickly under a PayFac is a common trigger for the account to be flagged and its payouts suspended, with the merchant then having to present evidence and justify its own activity before settlement funds are released — even when nothing the merchant did was actually improper.
An individually underwritten ISO account doesn't work this way. Because each merchant was approved on its own, growth in that merchant's volume isn't compared against an aggregate risk profile shared with unrelated businesses — a payout only gets halted if that specific account is flagged for something specific to it. The practical difference shows up exactly at the moment a merchant is succeeding: growth under a PayFac invites scrutiny of the whole arrangement; growth under an individually underwritten account is just growth.
This is also exactly why the PayFac model's genuine strength holds up best at low volume — a merchant that stays small and homogeneous with its peers in the aggregate is the case the model was built for, and where its risk-sharing math actually works in the merchant's favor rather than against it.
When does the PayFac model make sense?
The PayFac model tends to fit well when:
- Customers are numerous, individually small, and largely homogeneous in risk profile — this is the model's genuine strength, not just a speed tradeoff.
- Volume per customer is expected to stay low, so no single sub-merchant's growth is likely to draw scrutiny to the aggregate.
- Instant, frictionless onboarding is a core product requirement (a marketplace onboarding thousands of individual sellers, for instance).
- The platform is prepared to take on real underwriting and compliance responsibility itself, since that responsibility doesn't disappear — it moves from being distributed across individually underwritten merchants to being concentrated at the PayFac level.
When does the ISO partnership model make more sense?
The ISO partnership model tends to fit better when:
- Customers process meaningful volume, and account stability matters more than onboarding speed.
- Customers are expected to grow — a merchant whose volume scales quickly is exactly the case where individual underwriting stops being a nice-to-have and starts protecting the merchant from being treated as an aggregate risk event.
- Customer risk profiles vary enough that individual underwriting adds real value rather than just adding delay.
- The platform wants to offer payments without taking on the underwriting and compliance burden of becoming, functionally, a payments company itself.
- Customers would be uncomfortable knowing their processing ability depends on other, unrelated merchants sharing their master account.
Is one model "safer" than the other?
Safety depends on what's being protected against. The PayFac model can genuinely be safer from a fraud-detection standpoint in some contexts, since a PayFac has visibility across its entire sub-merchant base and can react quickly to patterns. It's less safe from an individual merchant's perspective, because that merchant's account stability is tied to decisions and events outside its control. The ISO partnership model protects individual account stability at the cost of onboarding speed, and shifts underwriting rigor to parties (the FSP, the sponsor bank) built specifically to carry it.
How should a platform actually decide?
A few honest questions tend to clarify which model fits:
- How much individual variation is there in customer risk profiles?
- How much does the platform want to be responsible for underwriting and compliance, versus delegating it?
- Would a specific customer's payments experience be materially hurt if a different, unrelated customer's activity caused a program-wide review?
- Is onboarding speed actually the binding constraint on growth, or is account stability a bigger factor in customer retention?
NGnair's embedded payments model follows the ISO partnership path deliberately — every merchant an ISV originates is individually underwritten and approved through a retail ISO, FSP, and sponsor bank structure, competing directly with PayFac aggregation rather than being a variant of it. AI-assisted underwriting is a large part of why that's now a realistic default rather than a slower alternative — the speed advantage that once justified aggregation doesn't have to come at the cost of account stability anymore.
The short version
PayFac and ISO partnership models trade onboarding speed against account stability and regulatory burden, in opposite directions. PayFac remains a genuinely good fit for low-volume, homogeneous, low-risk merchants — it's when those merchants grow that the aggregate model starts working against them, triggering scrutiny and held payouts that an individually underwritten account simply doesn't face. Neither model is universally correct; the right choice depends on customer risk homogeneity, how much compliance responsibility a platform wants to carry itself, and whether account stability or onboarding speed is the actual constraint on the platform's growth.
Programmable infrastructure and AI-assisted underwriting are what make individual underwriting fast enough to compete with aggregation today — see how NGnair puts that to work for ISVs.
