PSP vs PayFac Operations: A Model Reference for Operators

The terms PSP, PayFac, acquirer, aggregator, marketplace, and merchant of record get used as if they were interchangeable pricing labels. They are not. They describe different operational roles, and the difference determines who holds your merchant account, who decides whether you get boarded, who eats a chargeback, and who controls when you get paid.

This reference separates the five operational models by what they actually do. It owns the operational-model comparison; it deliberately does not re-run the PSP selection process or the merchant-of-record decision — those live in their own references, linked below. Read this when you need to know which model a provider is offering you and what that means for risk, settlement, and onboarding.

Direct answer

Five models, separated by who holds the merchant account and who owns each operational responsibility.

Under a direct PSP model, your business is the merchant. You hold your own merchant account (MID), the PSP routes your transactions to an acquirer, and you own your own underwriting outcome, chargebacks, fraud monitoring, and reserves. Under a PayFac (payment facilitator) model, the facilitator holds a single master merchant account and boards you and others as sub-merchants beneath it — owning the onboarding flow, the KYB/underwriting decision, the funds flow, and a large share of the risk. An acquirer is the card-network-licensed entity that actually settles with the schemes; PSPs and PayFacs sit on top of one. An aggregator/marketplace is a platform routing payments to multiple parties — it can build its own PayFac, use PayFac-as-a-service, or sit behind a merchant of record. A merchant of record (MoR) is the reseller-of-record that owns the customer contract and the tax/compliance liability — a commercial layer above payment boarding.

Licensing obligations and card-network sub-merchant thresholds vary by market and program. Confirm them locally and with your acquirer; this is not legal advice.

Why PSP, PayFac, acquirer, marketplace, and MoR get confused

The confusion is structural, not careless. The models overlap commercially — a single vendor can sell you several of these roles bundled into one contract and one dashboard, so from the buyer’s seat they look like one thing. Stripe, for example, is a PSP for a direct merchant and a PayFac-as-a-service platform for a marketplace; the product surface is similar, but the operational model underneath is different.

They also overlap because the roles stack. A PayFac sits on top of an acquirer. A marketplace can sit on top of a PayFac. An MoR usually runs payment processing underneath its commercial role. When the roles are layered, a single transaction passes through several of them, and it is easy to attribute a responsibility to the wrong layer.

The way out is to stop comparing them on price or features and compare them on operational ownership: for any given model, who holds the merchant account, who decides who gets boarded, who carries the chargeback, and who controls the payout. Those four questions separate the models cleanly. The rest of this reference answers them model by model.

Model comparison table

The single most useful artifact here. Each column is an operational-ownership question; each row is a model. “Varies” means the answer depends on the provider’s terms or the integration type chosen — read the contract.

PSP operational model

In the plain PSP model, your business is the merchant. You apply for your own merchant account, the acquirer underwrites you specifically, and you receive your own MID. The PSP’s role is to route your transactions to that acquirer, present a gateway and API, and report what was processed — it does not stand between you and the network as the accountable merchant.

The consequences are direct. You own your underwriting outcome: if the acquirer declines or restricts your account, that is your account. You own your chargebacks and your fraud monitoring. If a reserve is imposed, it is held against your account, and the interchange and scheme costs flow through to you on your statement. The PSP is a facilitator and a reporting layer; the liability is yours.

This model is the default for a single business accepting its own payments, and the selection problem — which PSP, on what terms — is its own discipline. This reference does not re-run it. For the trade-offs and the scoring framework, use the PSP decision matrix and the PSP selection checklist; for the contract-level mechanics that make switching expensive, see PSP vendor lock-in and hidden costs.

PayFac operational model

In the payment facilitator model, the facilitator holds a single master merchant account and boards everyone else as sub-merchants beneath it. Public industry material describes this plainly: the PayFac operates its own merchant account as the “master merchant,” and client businesses are boarded as “sub-merchants” under that master MID rather than applying for their own. The sub-merchant never gets its own direct MID.

That single structural fact moves the operational ownership. Because the master account is the facilitator’s, the facilitator owns the onboarding flow, the KYB/underwriting decision for each sub-merchant, the monitoring obligation, and the funds flow into and out of the master account. To the acquirer and the card network, the facilitator is the accountable party for its entire sub-merchant portfolio.

You do not have to build this yourself to get the benefits of it. PayFac-as-a-service offerings provide the sub-merchant model as a product. Two are publicly documented:

• Stripe Connect is documented as Stripe’s solution for marketplaces and platforms to onboard connected accounts, route and split payments between sellers, and send payouts. Its account configurations — Standard, Express, and Custom (now expressed through controller properties) — shift onboarding, dispute liability, and payout control between Stripe and the platform.
• Adyen for Platforms is documented as letting software platforms onboard and verify their users (sellers, service providers, contractors) as account holders, process and split payments between one or more users, hold funds, and pay out via managed or custom payouts.

Both let a platform get sub-merchant onboarding, split payments, and managed payouts without registering as a payment facilitator itself. The control-versus-effort trade is the whole decision: a full in-house PayFac gives you maximum control over economics and funds flow at the cost of a heavy compliance and operations build; PayFac-as-a-service gives you most of the capability with the provider carrying the network registration. (Only Stripe Connect and Adyen for Platforms are named here, because they are publicly documented as PayFac-as-a-service / platform offerings; this reference does not label any other named vendor as a PayFac without a public source.)

Sub-merchant onboarding and KYB

Under a PayFac, the sub-merchant onboarding flow is the facilitator’s responsibility and its largest compliance surface. Because the facilitator is boarding businesses under its own master account, it must perform KYB (know your business) and underwriting on each sub-merchant before letting it transact: verifying the legal entity, beneficial owners, business model, and expected volume, and screening for prohibited or high-risk activity. PayFac-as-a-service providers document this as a core capability — Adyen, for instance, frames it as onboarding and verifying your users before paying out.

The operational point for an operator is that the speed advantage of the model — a sub-merchant can be live in minutes rather than after a multi-week direct underwriting process — exists because the facilitator pre-carries the network relationship and runs a lighter, automated KYB at the point of boarding. That speed is not free: it is the facilitator accepting portfolio risk in exchange for being able to onboard fast.

Card-network rules also place limits on how long a business can stay a sub-merchant. Historically, a sub-merchant exceeding a defined annual card-volume threshold was required to contract directly with the acquirer rather than remaining under the master account, and the networks have revised those thresholds and added exceptions (for example, certain low-risk merchant categories) over time. Do not hard-code a number into your model from this article — the threshold and its exceptions vary by network and program and are revised periodically. Confirm the current Visa and Mastercard sub-merchant thresholds with your acquirer or PayFac-as-a-service provider before you design around them.

Settlement, reserves, and payout responsibility

Funds flow differently per model, and “who controls the payout” is the question that exposes it.

In the direct PSP model, the acquirer settles the transaction and the funds reach your own account; the PSP reports what settled. You control your payout schedule within the acquirer’s terms, and any reserve is held against your own account.

In the PayFac model, money lands first in the facilitator’s master account and the facilitator then pays out to each sub-merchant. The facilitator controls the payout timing and can hold a reserve against a sub-merchant. In a PayFac-as-a-service arrangement, the provider exposes this as managed or custom payouts (Adyen’s documented terms) or as platform-controlled payout settings (Stripe’s documented account configurations) — meaning the platform, not the underlying seller, frequently controls when sellers get paid.

In the MoR model, the MoR collects the funds as the merchant of record and then remits to the underlying seller on its own schedule and terms.

This is why the settlement file you receive depends on the model: a direct merchant reconciles its own settlement file against its own bank statement, while a sub-merchant or platform reconciles a sub-account-level view inside the facilitator’s reporting. The field-level mechanics of those files — the IDs to persist, gross-versus-net treatment, the matching chains — are covered in the Stripe vs Adyen settlement file reference, and the break taxonomy when settlement does not reconcile is in the PSP reconciliation failure runbook. This article does not duplicate them; it tells you which settlement view each model produces.

Chargeback and fraud responsibility

Chargeback and fraud liability is the responsibility most often misattributed, because the dashboard hides the underlying accountability.

In the direct PSP model, the chargeback is yours: it hits your account, you defend it, and the loss and the fee are yours. Your fraud monitoring is your obligation.

In the PayFac model, the facilitator carries the primary operational exposure, because a chargeback or a negative balance on any sub-merchant flows back to the master account it holds. The facilitator typically passes the economic cost back to the sub-merchant contractually and may hold a reserve to cover it — but to the acquirer and the network, the facilitator is the accountable party, and it must run fraud monitoring across its whole portfolio. In a PayFac-as-a-service arrangement, the precise split between platform and provider depends on the integration type and the provider’s terms: under some configurations the platform absorbs disputes and negative sub-merchant balances. Read the terms before you build; do not assume the provider eats the loss.

In the MoR model, the MoR owns the dispute because it is the merchant of record for the sale.

The metrics you monitor are the same regardless of which seat you sit in — dispute rate, win rate, fraud-to-sales ratio. Those live in chargeback operations KPIs and fraud operations KPIs; the model only changes whose numbers they are.

Reporting and reconciliation implications

The model determines the granularity of your reporting. A direct merchant gets one settlement view for one account. A PayFac — or a platform on PayFac-as-a-service — gets a master-account view plus sub-merchant-level (or connected-account / account-holder-level) reporting, and has to reconcile at both levels: the master account against the bank, and each sub-merchant’s net against what the platform pays it.

That extra level is where reconciliation effort multiplies. Splitting one settled transaction across multiple parties, deducting platform fees, and netting refunds and chargebacks per sub-merchant all happen inside the facilitator’s reporting layer, not the acquirer’s. If you operate a platform, the reconciliation system you build has to mirror that structure — a flat single-merchant model will not reconcile a multi-party payout. The field-level detail of what to persist so this survives a provider switch is, again, in the settlement file reference; the point here is that the shape of the reconciliation problem is set by the operational model you chose.

MoR vs PayFac vs PSP boundary

The cleanest way to hold these three apart:

• PSP is processing only. It routes and reports; you are the merchant, you own the relationship and the risk.
• PayFac is payment boarding and processing. It boards sub-merchants under a master account and moves their card funds, but the underlying sale is still between the sub-merchant and its customer.
• MoR is the reseller-of-record. It owns the customer contract, appears on the customer’s statement, and carries the tax-collection and compliance liability for the sale itself.

The distinction that trips people up is PayFac versus MoR. A PayFac moves money on behalf of a sub-merchant whose sale it does not own. An MoR owns the sale — which is why an MoR also takes on sales-tax/VAT collection and the consumer-facing compliance of being the seller. A provider can be a PayFac without being an MoR, and an MoR without running its own PayFac. The decision of when a business should move from a plain PSP relationship to a merchant of record — and what that shifts in tax, compliance, and economics — is its own reference: see merchant of record vs PSP and when to switch. This article does not duplicate that boundary analysis; it places the MoR within the operational-model comparison.

Marketplace / platform implementation considerations

A marketplace has a problem the other models do not: money has to reach multiple sellers from a single customer payment. That forces three implementation choices, and they map directly onto the models above.

• Build your own PayFac. Register with the card networks through an acquirer, hold the master merchant account, and own onboarding, KYB, monitoring, and the full risk of your sub-merchant portfolio. Maximum control over economics and funds flow; the heaviest compliance and operations build.
• Use PayFac-as-a-service. Use a documented platform offering (Stripe Connect, Adyen for Platforms) to onboard sellers, split payments across multiple parties, and run managed payouts, while the provider carries the network registration. Most of the capability, far less of the registration burden; you accept the provider’s terms on liability and payout control.
• Sit behind a merchant of record. Let an MoR be the seller of record so it owns the sale, tax, and dispute liability, and remits to your sellers. Least operational risk; least control, and the MoR’s economics apply.

Split payments and multi-party payout are the technical core of all three — the difference is who holds the master account and who carries the risk. Choose by how much control over onboarding, funds flow, and economics you need against how much operational and compliance risk you are willing to carry.

Contract and implementation checklist

PaymentBrief operator guidance — what to pin down before you sign or build, across any of these models. (This is operator guidance, not legal advice; confirm specifics with your provider and your acquirer.)

• Which model is this, actually? Get the provider to state, in writing, whether you are a direct merchant with your own MID, a sub-merchant under their master account, or selling through them as merchant of record. The dashboard will not tell you.
• Who holds the merchant account? Confirm whether you have your own MID or sit under a master account — it determines your portability and your exposure.
• Who owns chargebacks and negative balances? Get the liability split in writing, including who absorbs a negative sub-merchant balance and under what integration type.
• Who controls payouts and reserves? Confirm who sets payout timing, whether a reserve can be imposed, on what trigger, and how it is released.
• Who owns onboarding and KYB? Under a PayFac model, confirm what the provider verifies and what obligations remain yours.
• What are the sub-merchant volume limits? Ask the provider for the current card-network thresholds that would force a sub-merchant to board directly, and plan the migration path before you hit them.
• What is the settlement-reporting granularity? Confirm you get the account-level and sub-merchant-level reporting your reconciliation needs.
• What is the exit? Confirm whether your boarding, customer tokens, and history are portable if you leave — see the lock-in reference for the mechanics.

Common mistakes

• Assuming PayFac = MoR. A PayFac boards payments; an MoR owns the sale and the tax liability. Conflating them leads to wrong assumptions about who handles VAT/sales tax and who the customer is contracting with.
• Not knowing who holds chargeback and reserve liability. Under a PayFac-as-a-service model the split depends on the integration type and the provider’s terms. Teams discover they own negative balances only after the first big dispute. Get it in writing first.
• Underestimating KYB and underwriting as a PayFac. Becoming a facilitator means owning the underwriting and monitoring of every sub-merchant under your master account — a continuing compliance obligation, not a one-time onboarding feature.
• Assuming you must become a full PayFac to run a marketplace. You usually do not. PayFac-as-a-service exists precisely so platforms can get the sub-merchant model without registering as facilitators.
• Conflating settlement responsibility. “We get paid by Stripe” hides whether funds settle to your own account or land in a platform’s master account that then pays you out — two very different control and risk positions.
• Hard-coding a sub-merchant volume threshold. Network thresholds and exceptions change. Treat any number you read as a concept to confirm with your acquirer, not a fixed rule.

Related references

• How to choose a PSP — decision matrix — the scoring framework for selecting a PSP once you know you want the direct model.
• PSP selection checklist — the operational checklist that pairs with the matrix.
• Merchant of record vs PSP — when to switch — owns the MoR-versus-PSP boundary and the switching decision.
• Stripe vs Adyen settlement file reference — the field-level settlement-file detail behind the reporting differences above.
• PSP reconciliation failure runbook — what breaks in reconciliation and how to triage it.

Scope note

This reference separates six layers deliberately. Keep them distinct when you apply it:

• (a) Commercial model — who owns the customer relationship and the sale (the MoR question), versus who merely processes or boards payments.
• (b) Settlement model — whose account funds land in first and who controls the payout (direct account vs facilitator master account vs MoR collection).
• (c) Risk / chargeback model — who carries the dispute, fraud, and negative-balance exposure, which shifts from the merchant (direct PSP) toward the facilitator/platform (PayFac) and to the MoR (MoR model).
• (d) KYB / underwriting model — who runs onboarding and verification and carries the continuing monitoring obligation.
• (e) Compliance / licensing variation — network registration, sub-merchant thresholds, and licensing obligations vary by market and by card-network program. Confirm current rules locally and with your acquirer.
• (f) PaymentBrief operator guidance — the contract/implementation checklist and the common-mistakes list are this site’s recommendations, not vendor-published or legal requirements.

Further caveats:

• This is not legal or licensing advice. Do not treat any statement here as a definitive regulatory or licensing obligation. Network rules and licensing differ across markets and programs; confirm with qualified counsel and your acquirer.
• Sub-merchant volume thresholds are described as a concept, not asserted as a current fixed rule. The historical ~USD 1 million annual-volume figure and its exceptions have been revised by the networks; confirm the current Visa/Mastercard thresholds and exceptions before designing around them.
• Providers are named only as documented model examples. Stripe Connect and Adyen for Platforms are publicly documented PayFac-as-a-service / platform offerings, so they are used as examples of that model. No other named vendor is classified as a PayFac or an MoR in this reference, because doing so would require a public source for that specific classification.