PayFac vs ISO vs Merchant of Record: Payment Facilitator Architecture, Underwriting and Settlement (2026)

Every software platform that takes payments eventually asks the same question: who is actually the merchant? The answer decides who signs the contract with the bank, who is liable when a seller disappears with customer money, whose name appears on a cardholder statement, and how many months it takes before the first live transaction. Three models dominate the answer, and they are routinely confused with one another: the ISO, the merchant of record, and the payment facilitator.

The confusion is expensive. Teams pick a model from a sales deck, then discover that their risk, compliance and ledger obligations were never in the quote. This article takes a systems view. It maps the roles in card acquiring, shows where liability sits in each model, walks through sub-merchant onboarding, merchant ID structure, settlement and chargeback flows, and ends with a worked economics example and a build-versus-buy ladder.

What this covers: the roles in merchant acquiring, the PayFac vs ISO vs merchant of record distinction, card-brand registration and PCI scope, KYB underwriting and screening files, funds-flow and ledger design, reserves and chargeback liability, an illustrative margin model, regulatory notes and the failure modes that actually hurt platforms.

Disclaimer: this is systems and architecture analysis, not legal, financial or compliance advice. Card-brand rules change; verify current requirements with your acquirer and counsel.

Context and Background

Card acceptance has always required a contract between a seller and an acquiring bank, because only a member of the card network can settle transactions through it. For decades the process of becoming a merchant was slow: an application, a credit and background review, a merchant account with its own merchant ID (MID), and a settlement account. That works for a retailer opening one store. It does not work for a platform that wants to onboard 50,000 sellers, each of whom should be able to take a payment in minutes.

The industry solved this in layers. Independent sales organizations (ISOs) emerged to distribute acquiring services: they find merchants, hand them to a bank, and earn a share of the fees. Payment facilitators emerged to let a platform aggregate many small sellers under its own agreement with an acquirer. Merchants of record emerged from a different direction: instead of onboarding sellers into the card system, the platform simply becomes the seller of record itself and resells the product.

The card brands define the first two explicitly. Visa’s published payment facilitator model describes a payment facilitator as a third-party agent that signs merchant acceptance contracts with sponsored merchants on behalf of an acquirer, can own the merchant relationship directly, and receives and distributes settlement of proceeds from the acquirer for those merchants. The same document states the acquirer-side consequence in one sentence: acquirers are responsible for the acts of both payment facilitators and their sponsored merchants.

That sentence explains almost everything about how the model is built. The acquirer is the regulated, brand-sponsored party, so it constrains and audits the facilitator. The facilitator in turn carries the sub-merchant risk it onboards. If you want the cost side of the same chain, our breakdown of interchange fees and least-cost routing explains where the money in these examples comes from, and our piece on card issuing processors and BIN sponsors covers the mirror-image sponsorship model on the issuing side.

A note on sourcing. Card-brand rulebooks are long and revised several times a year, and some are only available to members. Where this article quotes a threshold, it says where it came from. Where a number comes from secondary commentary rather than the rulebook itself, the text says so, and you should treat it as a pointer to verify, not a specification.

The vocabulary, precisely

Five terms carry most of the weight, and each has a specific meaning in the card rules.

The issuer is the bank that issued the cardholder’s card. The acquirer is the bank (a network member) that holds the merchant relationship and settles to the merchant. The processor is the technical operator that moves authorization and clearing messages for the acquirer, and may or may not be the same company. A sponsor bank or sponsor acquirer is the member that sponsors a non-bank entity into the card network. A sub-merchant, also called a sponsored merchant, is the actual seller behind a facilitator.

Everything else in this article is a recombination of who holds which contract and who holds which risk.

The Three Models: Reference Architecture for Merchant Acquiring

Direct answer. A payment facilitator contracts with an acquirer once, then signs and underwrites many sub-merchants beneath that agreement, receives their settlement and pays them out, and carries their chargeback and compliance risk. An ISO only sells acquiring services and carries no transaction risk. A merchant of record is itself the seller to the card brand and takes all buyer-facing responsibility.

Figure 1 shows where each party sits relative to the money and the contracts.

Figure 1: Roles in merchant acquiring. The payment facilitator sits between many sub-merchants and one acquirer, the ISO attaches by referral, and the merchant of record replaces the seller entirely.

The diagram is deliberately simple: three ways to put a platform between a buyer and the card system. The differences are about contract, risk and cash, not about the payment message, which looks nearly identical in all three. An authorization request flows from a point of interaction through the acquirer and network to the issuer in every case. What changes is whose MID is in the message, and who owns the consequences of what follows.

Model 1: the ISO (and the ISV referral)

An ISO is a distribution channel. It recruits merchants, packages the acquirer’s services, often supports the merchant with terminals or a gateway, and earns a share of the discount revenue. Critically, the merchant still signs a merchant agreement with the acquiring bank. The ISO is an agent, not a principal, and for most commercial purposes it bears none of the transaction risk.

Software vendors often take the lighter version of this, an ISV referral or ISV partnership. The software vendor integrates a gateway and refers its customers to an acquirer, earning a revenue share. Each customer goes through traditional underwriting and receives its own merchant account. The advantage is that your platform holds no funds and no liability. The disadvantage is friction: sellers wait for approval, and you have no control over their funding, pricing or experience.

The ISO label can also carry registration duties of its own. Card brands require acquirers to register certain third-party agents, and secondary sources report that an ISO terminated for cause can be listed in the brand’s screening files. Treat that as a reason to read your ISO agreement, not as a footnote.

Model 2: the payment facilitator

A payment facilitator inverts the ISO structure. The platform contracts with the acquirer as a single, large, registered entity. It then signs its own contract with every seller, called a sub-merchant agreement, and receives the settlement for all of them in aggregate. It pays each sub-merchant from its own funds after deducting fees. To the card network, the transactions arrive under the facilitator’s registration, with sub-merchant identifying data carried in the message.

The consequences are profound. Because the facilitator owns the sub-merchant relationship, it can onboard in minutes using risk-based automated underwriting rather than a full bank application. It controls pricing, payout timing, and the user experience. In exchange it takes on the obligations that the bank would otherwise have taken in a direct relationship: sub-merchant due diligence, monitoring, chargeback handling, and PCI responsibility for the environment that touches card data.

The wiki-style commentary at private.law cites Visa Core Rules to say a facilitator is financially liable for each transaction it processes for a sponsored merchant and that a sponsored merchant’s acts and omissions are treated as the facilitator’s. I have not been able to check those section numbers against the primary rulebook, so treat the citations as a pointer. The Visa document above supports the underlying principle for the acquirer-facilitator link.

Model 3: the merchant of record

A merchant of record (MoR) approaches the problem from the other side. Rather than onboarding sellers into the card system, the MoR becomes the seller. Customers buy from the MoR, the MoR’s name appears on the statement, the MoR charges and remits sales tax or VAT, handles refunds and disputes, and then pays its upstream vendor or creator a royalty or payout under a commercial agreement.

Only one entity ever appears to the card network as the merchant, and that entity is the MoR. The upstream vendor is not a sub-merchant in the card-scheme sense. It is a supplier. This is why digital-goods platforms and software resellers use MoR models: they absorb tax registration, invoicing and chargeback handling across jurisdictions, at the cost of a higher take rate and tighter category restrictions.

The line between a MoR and a facilitator is a question of substance. Per the secondary summary above, Visa’s test looks at whether the entity actually sells to the cardholder, whether it uses its own name to identify the outlet, and whether it provides recourse for disputes. A platform that calls itself a MoR but does not satisfy those tests may be reclassified, and then the facilitator rules apply to it with retroactive force. Again, verify against the rulebook.

The decision in one table

Dimension	ISO / ISV referral	Payment facilitator	Merchant of record
Who the card brand sees as merchant	The seller	The sub-merchant, under the PayFac registration	The MoR itself
Who signs the acquirer contract	The seller	The PayFac (one master agreement)	The MoR
Seller contract	Directly with the acquirer	Sub-merchant agreement with the PayFac	Supply or reseller agreement
Transaction and chargeback liability	Seller (and acquirer behind it)	PayFac, with acquirer behind it	MoR
Funds flow	Acquirer pays the seller	Acquirer pays PayFac, PayFac pays seller	Acquirer pays MoR, MoR pays supplier
Onboarding speed	Days to weeks	Minutes to hours (risk based)	Not applicable, a commercial deal
Tax and invoicing duty	Seller	Seller	MoR
Typical fit	Software vendors who want no risk	Marketplaces and vertical SaaS	Digital goods, cross-border software

The table hides one more distinction that matters in practice. A facilitator’s economics scale with payment volume and are rich in float and risk-based pricing. A MoR’s economics scale with its role as a reseller and are rich in tax and compliance handling. They are different businesses wearing similar vocabulary.

What makes the facilitator model special: contract aggregation

Think of the facilitator as a contract-aggregation layer. The acquirer underwrites one entity, the facilitator, with its balance sheet, risk controls, and compliance program. The facilitator then subdivides that single approval into thousands of sub-merchant approvals, each smaller and faster than a bank would grant.

This is only safe because the facilitator replicates, at small scale and with software, the controls the bank would have run: identity verification, screening against brand files, category review, limits, monitoring and termination. The registration process in the Visa document confirms that the acquirer must complete a comprehensive risk and financial review of the facilitator, under the card brand’s third-party agent due diligence standards, before the facilitator may operate. The facilitator is not a loophole in underwriting. It is underwriting delegated to a party that has been underwritten itself.

Deeper Analysis: Sub-Merchant Onboarding, MIDs and Compliance

The facilitator model lives or dies on the onboarding pipeline. A slow pipeline destroys the reason to be a facilitator, and a careless one invites the exact fraud and chargeback losses the acquirer is watching for. This section walks through the pipeline, the MID structure that sits underneath it, and the compliance obligations that follow.

Sub-merchant onboarding as a decision pipeline

Sub-merchant onboarding is a staged risk decision, not a form. Each stage either collects evidence, scores it, or applies a control. Figure 2 shows the pipeline.

Figure 2: Sub-merchant onboarding. Risk scoring routes applications to auto-approval, manual review with reserves, or decline, and monitoring continues after approval.

Stage one is application and know-your-business (KYB) data: legal name, registration number, address, website or app, expected volume and average ticket, business description and the principals. Stage two verifies identity and beneficial ownership, usually against registry and document checks. The same continuous-risk thinking used in perpetual KYC architectures applies here: onboarding is the first data point on a risk profile, not a one-time gate.

Stage three is screening. Sanctions and watchlist screening are the obvious part. The card-specific part is checking the applicant against the card brands’ terminated-merchant files. Mastercard operates MATCH, and Visa operates a comparable service often referenced as VMSS. Per the Visa model document, a sponsored merchant cannot be listed on the VMSS or similar files. For MATCH, secondary sources report that records are retained for five years, that listing reason codes include account data compromise, excessive chargebacks, excessive fraud, bankruptcy, illegal transactions and PCI non-compliance, and that an acquirer must list a merchant within a short window of terminating it for a listed reason. I could not retrieve Mastercard’s own security rules page in this research, so these MATCH details are secondary-source and should be verified in the current Mastercard Security Rules and Procedures.

Stage four is category and business-model review. The merchant category code (MCC) assigned to the sub-merchant drives interchange, risk appetite, and eligibility. Some categories are excluded from the facilitator model entirely or require special registration. The Visa model document refers to high-integrity risk MCCs being treated differently, and to a facilitator being barred from sponsoring another facilitator, a staged digital wallet, or person-to-person or money-transfer activity. Whether a given business is facilitator-eligible is a question for your acquirer’s policy, which is usually stricter than the brand minimum.

Stage five is the risk score and limit assignment. A practical design turns the evidence into three decisions, and each decision sets a bundle of controls rather than a yes/no:

Low risk: approve automatically, with conservative per-transaction and monthly volume caps and a short payout delay.
Medium risk: route to manual review, apply a rolling reserve and a longer payout delay, and lower the caps.
High risk: decline, or refer the seller to a direct merchant agreement with the acquirer so the risk stays with the bank.

Stage six is the one most teams under-invest in: ongoing monitoring. Velocity (transactions per minute and per day), ticket-size drift, refund ratio, chargeback ratio, new-geography spikes, and card-testing patterns should feed a rule engine that can hold payouts and escalate. Approval at onboarding is only a prediction. Monitoring is where the prediction is tested against reality.

Underwriting what matters: delivery risk and the exposure window

Underwriting a sub-merchant is mostly about estimating how much you could lose if it vanished. The key number is exposure, which depends on how long after payment the goods or services are delivered and how long a cardholder may dispute.

Consider a seller who sells event tickets for events held 60 days after purchase. If it takes in 200,000 dollars a month and then collapses, the facilitator holds refund and chargeback exposure on roughly two months of sales, about 400,000 dollars, because cardholders will dispute undelivered tickets. A seller of same-day food delivery taking the same 200,000 dollars a month has an exposure window of days. The same volume, a ten-fold difference in loss potential. This is why mature facilitators underwrite on delivery lag and refund policy, not only on monthly volume, and why advance-payment businesses are treated cautiously in the brand rules. The Visa model document itself carves advance-payment merchants out of one of its standard treatments, which is a signal of how the brands view that risk.

Card dispute windows are long. Many chargeback rights run for 120 days from the transaction or from the expected delivery date, with exceptions that run longer. Those windows are brand and reason-code specific, so confirm the specifics for your case, but the architectural point holds: your liability tail outlives the payout by months. Any model that assumes risk ends when the money is paid out will lose money on its first bad seller.

MID structure: one master, many sub-merchants

Merchant IDs are how the acquiring system tells accounts apart, and the MID design of a facilitator is one of its least discussed architectural choices. Three patterns appear.

In the pooled MID pattern, all sub-merchants transact under one facilitator MID. It is the simplest, and the lowest cost, and it works well for large numbers of tiny sellers. The cost is visibility: dispute rates, fraud rates and brand-program thresholds are measured against the pooled MID, so one bad seller can push the entire platform toward a monitoring program.

In the per-sub-merchant MID pattern, each seller gets its own MID or identifier under the facilitator’s umbrella. Risk, chargeback ratios and reporting are separated per seller, which makes monitoring and termination cleaner. The cost is operational overhead and, with some acquirers, fees.

In the tiered pattern, small sellers share pooled MIDs grouped by risk class or MCC, while larger or riskier sellers get dedicated ones. Most scaled platforms converge here. A “graduation” rule moves a seller to its own MID when its volume crosses a threshold, which also helps with the next topic.

Whatever the pattern, the card network messages must carry sub-merchant identification: the facilitator name and the sub-merchant name or descriptor, so that the cardholder statement is recognizable and the issuer and brand can see who the real seller was. Descriptor quality is a quiet driver of chargebacks. A cardholder who cannot recognize a statement line disputes it as fraud, and a “friendly fraud” dispute costs the same as a real one.

When the sub-merchant must get its own contract

The facilitator model is meant for small sellers. Once a sub-merchant is large, the brands expect it to contract directly with the acquirer. The Visa model document confirms this in principle: depending on annual Visa sales volume, a sponsored merchant may be required to sign a direct merchant agreement with the acquirer, though it can keep its facilitator relationship for acceptance and settlement. The document does not state the threshold.

Secondary commentary cites 1 million dollars of annual Visa volume as the Visa threshold and 10 million dollars of combined Mastercard and Maestro volume as the Mastercard one, with carve-outs for certain categories. These are the figures widely quoted in the industry, but I did not verify them against the rulebooks in this research, and thresholds have changed over time. Design your platform so the threshold is configurable per brand and region, and so sellers can be flagged and migrated to a direct agreement without rebuilding their integration. A hard-coded threshold is a compliance defect waiting for a rule change.

PCI DSS scope and who owns it

Under the Payment Card Industry Data Security Standard, a facilitator is a service provider. The current version of the standard is PCI DSS v4.0.1, and the future-dated requirements that arrived with version 4.0 became mandatory in March 2025. Service providers are assessed more heavily than merchants. The commonly cited rule is that a service provider above roughly 300,000 transactions per year needs a full assessment by a Qualified Security Assessor, while smaller ones may self-assess with the longest self-assessment questionnaire. Brand programs can still require a QSA report for registry listing regardless of volume. Check the current requirements with your acquirer.

The architecture matters more than the paperwork. The way to shrink scope is to keep card numbers out of your systems:

Use hosted fields or a redirect so the card number goes from the browser straight to a tokenization service.
Store only tokens and the last four digits and expiry in your own database.
Run the vault and tokenization in a separate network segment with its own access controls.

A facilitator that tokenizes at the edge often has a very small card-data environment. One that lets card numbers flow through its application servers has put the whole stack in scope. Sub-merchants have their own PCI duties too, scoped to how they take payments, and the facilitator is responsible for making sure they meet them. In practice, a facilitator offering hosted payment pages makes most sub-merchants eligible for the lightest self-assessment, which is itself a product benefit.

Funds Flow, Ledger Design and Chargebacks

Moving card money is a sequence of promises across several parties, and each promise has a different timing. The ledger of a facilitator is the system that keeps those promises consistent.

The money path

Figure 3 follows a 50 dollar card purchase from authorization to payout, and then follows a chargeback back down the chain.

Figure 3: Funds flow from cardholder to sub-merchant, and the chargeback path back. The facilitator pays out before the dispute window closes, so it funds the risk.

Authorization is a promise by the issuer to pay, not a movement of money. Clearing and settlement happen afterward, typically in batches, and the acquirer funds the facilitator’s settlement account net of interchange and scheme fees according to its agreement. Funding timing varies by acquirer and contract, commonly one or two business days after capture, but it is contractual and you should not assume a figure.

The facilitator then pays the sub-merchant. This is where the model’s economics and risk meet. If the facilitator pays out on day two and the cardholder disputes on day forty, the facilitator has already paid the seller. The chargeback flows from the issuer through the network to the acquirer, the acquirer debits the facilitator’s account, and the facilitator must recover from the seller. If the seller’s balance is gone, the facilitator absorbs the loss.

Why the ledger is the product

A facilitator needs a ledger that models money it holds but does not own. At any moment, the platform holds cash in its settlement account that belongs to many sub-merchants, to itself as fee revenue, and to reserves that belong to neither. A single “balance” column cannot represent that. The design that works is double-entry with separate accounts per sub-merchant and per purpose.

A minimal account structure per sub-merchant looks like this:

Pending: funds authorized and captured but not yet settled by the acquirer.
Available: settled funds that can be paid out.
Reserve: funds withheld against risk, with a release schedule.
Disputed: amounts frozen because a chargeback or retrieval request is open.

Platform-level accounts sit alongside: the acquirer settlement account, fee revenue, interchange and scheme cost, chargeback loss, and a suspense account for settlement items that cannot yet be matched. Every movement is a balanced journal entry, and the sum of all sub-merchant liability accounts must always reconcile to the cash actually held, daily. This is the same discipline as in a banking ledger, and the practical rules from stablecoin settlement designs apply: immutable entries, idempotent posting keys, and reconciliation against an external source of truth.

A concrete idempotency example. A settlement file from the acquirer arrives twice, because of a retry. If the posting key is the acquirer’s settlement batch ID plus the transaction reference, the second load is a no-op. If the key is a timestamp, the second load doubles every seller’s available balance and you will find out when the bank account runs short. Reconciliation is not a nightly nicety. It is the control that tells you the ledger is true.

Payout design

Payout timing is a risk control disguised as a product feature. Faster payouts delight sellers and raise exposure. A sensible design assigns payout schedules by risk tier: next-day for established sellers with clean history, a rolling delay for new ones, and holds on anomalies. Instant payout products exist but shift the funding cost onto the facilitator, which must pre-fund them from its own balance sheet.

Payouts themselves ride other rails: bank transfers over an ACH-like or real-time rail, push-to-card, or a wallet balance. Each has its own return and reversal behavior. An ACH-style payout can fail days later because of a wrong account number, which means a payout is not final at submission. Your ledger needs a payout state machine with explicit failure and return states, and a rule for what happens to funds that bounce back.

Chargebacks, reserves and liability

When an issuer disputes a transaction, the sequence is: the issuer files a chargeback, the network routes it to the acquirer, the acquirer debits the facilitator, and the facilitator decides whether to represent (contest) the dispute with evidence or accept it and debit the sub-merchant. Each step has deadlines set by the brand, and a missed deadline is a lost dispute by default.

A facilitator typically controls loss in three layers. The first layer is the sub-merchant’s own available balance, offset against each chargeback. The second is a reserve, a percentage of volume held for a period, often rolling. Secondary sources describe reserve norms of 5 to 10 percent of volume for platforms, but this is an unattributed market observation, not a rule, and varies by risk. The third layer is the facilitator’s own capital and any guarantee or indemnity from the platform owner. Anything beyond these falls to the facilitator, and ultimately to the acquirer behind it.

Brands also monitor dispute and fraud ratios against programs with escalating assessments. Visa’s acquirer monitoring regime has been consolidated under a program called VAMP, and Mastercard runs excessive chargeback programs. Secondary sources quote thresholds in basis points and chargeback counts, and note that merchant thresholds were tightened in 2026. I could not confirm the current numbers from primary documents, so this article does not reproduce them. The architectural conclusion is stable regardless of the numbers: keep per-seller and per-MID ratios visible in real time, because a ratio you only see monthly is a penalty you only see after it has been assessed.

Economics: A Worked Margin Example (Illustrative)

The following numbers are illustrative round figures chosen to make the arithmetic easy to follow. They are not quotes, benchmarks or market averages, and real interchange, scheme and processor fees vary by card type, region, MCC and contract. The goal is to show the structure of facilitator margin, not to predict yours.

Assume a platform with 10 million dollars of monthly card volume across its sub-merchants, at an average ticket of 50 dollars. That is 200,000 transactions a month.

Revenue. The platform charges sub-merchants a blended 2.9 percent plus 30 cents per transaction. Percentage revenue is 0.029 x 10,000,000 = 290,000 dollars. Fixed revenue is 0.30 x 200,000 = 60,000 dollars. Total gross revenue is 350,000 dollars, which is 3.5 percent of volume.

Pass-through cost. Assume interchange plus scheme assessments blend to 1.80 percent: 180,000 dollars. Assume the acquirer and processor charge a markup of 0.10 percent plus 5 cents per transaction: 10,000 + 10,000 = 20,000 dollars. Total cost of acquiring is 200,000 dollars.

Gross spread. 350,000 – 200,000 = 150,000 dollars, or 1.50 percent of volume. This is the number the platform actually earns for carrying the risk and the operations.

Operating items. Assume chargeback and fraud losses average 0.05 percent of volume: 5,000 dollars. Assume KYB vendors, monitoring tools, PCI assessment amortization and dispute handling cost 15,000 dollars a month. Contribution before engineering and staff is 150,000 – 5,000 – 15,000 = 130,000 dollars, or 1.30 percent of volume.

Now compare three models on the same volume, still illustratively.

Model	Platform revenue after acquiring cost	Risk carried	Illustrative monthly contribution
ISO / ISV referral	Revenue share, assume 0.20 percent of volume	None	20,000 dollars
PayFac-as-a-service	Spread less provider fee, assume provider keeps 0.25 percent + 5 cents	Shared, platform still liable to its users	150,000 – 35,000 – 5,000 = 110,000 dollars
Full PayFac	Full spread, own operations	All	130,000 dollars

The full PayFac earns more than the as-a-service model only if it can run its operations for less than the provider fee, which at this volume it nearly can, and the gap grows with scale. The ISO model earns an order of magnitude less but also holds essentially no tail risk.

The tail is what the average hides

Averages understate the risk. The 5,000 dollars of monthly loss in the example assumes the world is boring. Recall the event-ticket seller with 400,000 dollars of undelivered-event exposure. If that one seller fails and every ticket is refunded or charged back, the platform loses 400,000 dollars in a month, which is roughly three months of the 130,000 dollar contribution in the example. A single concentrated failure erases a quarter of profit.

This is why reserves, payout delays and exposure caps are not obstacles to growth. They are the price of keeping the margin. A platform that sets the cap on any one seller’s undelivered-goods exposure at, say, two months of its contribution has made a decision it can explain to its acquirer and its board.

Float is the other economic lever. Facilitators hold sub-merchant funds between settlement and payout, and some earn interest on balances where law and contract allow. The rules on who may earn interest on customer funds, and whether those balances must be segregated or safeguarded, depend on jurisdiction and are discussed next.

Regulatory and Licensing Notes

Card-brand rules are only one layer. Moving money for others is regulated activity in most countries, and the facilitator model sits near the line.

In the United States, a platform that holds and transmits funds on behalf of others can fall under money-transmitter licensing at the state level and registration with the federal financial crimes enforcement network as a money services business. The payment-processor exemption in several state laws can apply to entities that process payments through a bank on behalf of merchants under a contract with the payee, but its scope varies by state, and platforms often rely on it with legal advice. I did not verify state-by-state positions in this research; treat the point as a reason to ask counsel, not as an answer.

In the European Union and the United Kingdom, holding funds for others typically requires authorization as a payment institution or an electronic money institution, or operating as an agent of one. The commercial-agent exclusion in payment-services law is narrow, and platforms that rely on it have been challenged. Safeguarding rules require customer funds to be segregated or covered by insurance, and that affects the float economics above.

Anti-money-laundering duties apply on top. The facilitator performs customer due diligence on sub-merchants and monitors transactions for suspicious activity, and the sub-merchant’s own customers are screened by the card ecosystem. A platform that onboards businesses fast but files no suspicious-activity reports has shifted risk to its sponsor, who will notice.

Tax is a separate axis. A merchant of record is typically the party that collects and remits sales tax or VAT on the sale. A facilitator usually is not, though payments reporting rules in some countries make platforms report seller income to tax authorities. Which side of this line a business is on is exactly the reason many cross-border digital sellers choose a MoR.

The common thread: the brand rules tell you whether you may sit in the card network, and regulators tell you whether you may hold other people’s money. You need both answers.

Trade-offs, Gotchas, and What Goes Wrong

The facilitator model is not a free upgrade from an ISO referral. Figure 4 shows the ladder of options and what each rung buys and costs.

Figure 4: The build-versus-buy ladder. Each rung up adds control and margin and also adds liability, regulated surface and operating cost.

Where the model hurts

Underwriting you cannot staff. A full facilitator needs risk analysts, a dispute team, a compliance owner and on-call engineering for the ledger. Platforms that treat it as a feature, not an operating business, tend to find out through a loss event. Secondary sources quote 12 to 18 months and seven-figure budgets for a full build; these are market estimates, not verified, but the order of magnitude matches the staffing reality.

Concentration and the single large seller. One seller growing from small to 40 percent of volume changes your risk profile without any single decision. Without concentration limits and the direct-agreement migration discussed earlier, the facilitator is writing a very large credit line it never priced.

Pooled-MID contamination. On a pooled MID, one bad seller’s dispute ratio becomes everyone’s. A fraud ring card-testing through a single sub-merchant can trip monitoring thresholds on the whole platform. Separate high-risk sellers and set per-seller velocity caps.

Ledger drift. The most common operational failure is not fraud. It is a ledger that no longer matches the bank: missed settlement files, double-posted returns, a payout that failed but was marked paid. Small drift compounds. Daily three-way reconciliation between the ledger, the acquirer settlement report and the bank statement is the control.

Descriptor and support failures. Unrecognizable statement descriptors and slow customer support turn honest cardholders into chargebacks. These are product issues that show up as risk metrics.

Misclassified MoR. Calling a model “merchant of record” does not make it one. If the entity does not behave as the seller, a brand or regulator can reclassify it and apply facilitator, marketplace or other rules to it. Align the contract, the checkout, the statement name and the dispute handling.

Acquirer dependency. A facilitator is registered through one sponsor acquirer. If that acquirer changes terms, exits the market or suffers its own program problems, the facilitator has to migrate. Multi-acquirer routing is a resilience play, but each acquirer needs its own registration and contract, and sub-merchant identifiers have to be portable across them.

Anti-patterns

Paying out instantly to brand-new sellers with no limit. Using one blended reserve percentage for every category. Treating KYB as a one-time event. Letting engineers hard-code brand thresholds. Storing full card numbers because “we might need them.” Building the ledger as a balance column and a log table. Each is a decision that looks like a shortcut and becomes an incident.

Practical Recommendations

Choose the model from the constraints, not the aspiration. If your platform sells software and payments are an add-on you do not want to underwrite, the ISV referral costs the least and carries no tail. If payments are the product and your sellers are many and small, a facilitator is the structural fit, but start on a PayFac-as-a-service platform and move to a full build only when volume and operations justify it. If you sell digital goods across borders and want tax and dispute handling off your sellers, a true merchant of record is the model, and you should accept the category and take-rate limits that come with it.

Start with the exposure, not the volume. For each business type you will onboard, estimate the delivery lag and refund window, compute the worst-case exposure, and decide in advance what cap, reserve and payout delay that justifies. Put these in configuration so the risk team can change them without a release.

Design the ledger first. A facilitator with a weak ledger will fail on reconciliation long before it fails on fraud. Use double-entry accounts per sub-merchant and purpose, idempotent posting keys, a payout state machine and a daily reconciliation job that blocks payouts when it fails.

Keep card data out of your systems with hosted fields and tokenization, and make PCI scope an architecture decision rather than an annual surprise.

A short checklist you can adapt:

Decide model: ISV referral, PayFac-as-a-service, full PayFac or MoR, with the liability written down.
Confirm sponsor acquirer terms: registration, reserve requirements, funding timing, direct-agreement thresholds.
Build onboarding as a scored pipeline with auto-approve, review and decline paths.
Screen against sanctions and the brand terminated-merchant files at onboarding and periodically.
Choose a MID structure and a graduation rule to dedicated MIDs.
Make thresholds and limits configuration, per brand and region.
Model exposure per category; set reserves and payout delays accordingly.
Run a double-entry ledger with daily reconciliation and a payout state machine.
Monitor dispute and fraud ratios per seller and per MID in real time.
Get legal advice on money-transmission or payment-institution status before launch.

Frequently Asked Questions

What is a payment facilitator?

A payment facilitator is a registered third party that signs a master agreement with an acquirer and then onboards many sub-merchants beneath it. It contracts with each seller, receives their settlement from the acquirer, pays them out, and carries chargeback and compliance responsibility. To the card network, transactions arrive under the facilitator’s registration with sub-merchant data attached. Visa describes it as an agent that signs merchant acceptance contracts on behalf of an acquirer.

What is the difference between a PayFac and an ISO?

An ISO sells and supports acquiring services but does not take on transaction risk: the merchant signs its own agreement with the acquiring bank and the ISO earns a share of the fees. A payment facilitator is a principal that owns the sub-merchant contract, receives the funds and carries chargeback liability. The practical difference is who underwrites, who holds the money, and who pays when a seller disappears.

Is a merchant of record the same as a payment facilitator?

No. A merchant of record is the seller from the card network’s point of view: its name is on the statement, it handles disputes, and it usually handles sales tax or VAT. It then pays its suppliers under commercial agreements. A facilitator keeps the sellers as sub-merchants and does not resell their goods. A company that calls itself a merchant of record without behaving as the seller risks being treated under the facilitator rules instead.

Do I need a PCI assessment as a payment facilitator?

A facilitator is a PCI DSS service provider and generally faces a heavier assessment than a merchant. Commonly cited guidance is that service providers above about 300,000 transactions a year need a Qualified Security Assessor report, while smaller ones may self-assess, and brand registry listings can require a QSA report regardless. Tokenizing at the edge and using hosted fields can sharply reduce the card-data environment. Confirm current requirements with your acquirer.

How long does it take to become a payment facilitator?

It depends on whether you build or rent. Using a PayFac-as-a-service provider can get a platform live in weeks to a few months because the registration, risk stack and ledger already exist. A full build requires acquirer sponsorship, brand registration, a risk and compliance program, and a production ledger. Secondary sources quote 12 to 18 months for that path, but that figure is an unattributed market estimate.

Who is liable for a sub-merchant’s chargebacks?

In the facilitator model the facilitator is first in line, recovering from the sub-merchant’s balance or reserve, and the acquirer stands behind the facilitator. Visa’s published model document states that acquirers are responsible for the acts of both facilitators and sponsored merchants, which is why acquirers impose reserves, monitoring and reporting duties. The facilitator’s contract with its sub-merchants should pass the loss down, but it can only recover what the seller still has.