Merchant of Record vs Payment Facilitator: Who Holds the Risk in Your Payment Stack

Behind every online checkout, exactly one legal entity is on the hook for the transaction: it owes the sales tax or VAT, eats the chargeback, answers the card networks, and carries the compliance file. Which entity that is defines the difference between a merchant of record, a payment facilitator, a marketplace, and a plain payment processor. The models are routinely confused because, from the buyer's seat, all four produce the same experience: a checkout page and a charge on a statement. From the seller's seat they could hardly be more different. Selling through a merchant of record outsources tax and dispute liability for a premium that typically runs several percentage points above raw processing; becoming a payment facilitator converts a platform into a de facto acquirer with underwriting obligations and a compliance staff; and choosing wrong in either direction quietly costs margin or quietly accumulates liability that surfaces years later as a tax assessment or a network fine. This guide lays out who holds what in each model, when the merchant-of-record premium is worth paying, when the payfac upgrade is worth building, and the migration paths between them as volume grows.

Key Takeaways

• The four models differ on one axis that matters: who is legally the merchant. A processor serves you as the merchant; a payfac aggregates you under its own acquiring relationship but leaves you the merchant of record for tax; a marketplace intermediates the sale; a merchant of record replaces you as the seller entirely, taking tax, chargeback, and compliance liability with it.
• The merchant-of-record premium, commonly several points of revenue above ordinary processing cost, is cheapest global tax infrastructure available to a small team selling digital goods cross-border, and an expensive convenience for a large merchant that could staff the same functions internally for less.
• What the merchant of record buys in liability it charges back in control: checkout experience, customer payment data, payout timing, and pricing flexibility all sit with the entity that owns the transaction. Businesses whose growth depends on owning the customer relationship eventually feel the ceiling.
• Becoming a full payfac is a business-model decision disguised as a payments decision: attractive economics on embedded payments against real underwriting, KYC, and network obligations, with industry rules of thumb putting the crossover well into the tens of millions in annual processed volume. Payfac-as-a-service occupies the middle: most of the economics, a fraction of the obligations.
• Migration between models is normal and should be planned for at contract time: startups commonly begin on a merchant of record or payfac and graduate to direct acquiring as volume justifies staff. The expensive mistake is signing terms, especially around data portability, that make graduation punitive.

The Four Models, and Who Holds What

The cleanest way to separate the models is to follow the liabilities rather than the logos. Five obligations attach to every card transaction: remitting the applicable sales tax or VAT, absorbing chargebacks and their fees (the mechanics of which are covered in how the dispute system works), performing KYC on the entity receiving funds, controlling the funds flow, and holding the registration with the card networks. Each model assigns those five differently.

Payment processor (and gateway). The baseline: the business is the merchant, full stop. It holds its own merchant account, is registered as the merchant with the networks, owes its own taxes everywhere it has obligations, fights its own chargebacks, and carries its own PCI scope. The processor moves money and messages for a fee; the division of labor between the gateway and processing layers is covered in payment gateway versus payment processor. Maximum control, maximum obligation.

Payment facilitator (payfac). A payfac, Square and Stripe being the canonical consumer examples, holds a master acquiring relationship and onboards businesses as sub-merchants beneath it. The payfac performs the KYC, absorbs the network registration, and fronts the acquirer relationship, which is why onboarding takes minutes instead of the weeks a traditional merchant account requires. Crucially, the sub-merchant typically remains the merchant of record for the sale: the tax obligations and, in most arrangements, the ultimate chargeback liability still belong to the business; the payfac guarantees them to the acquirer and recovers from the sub-merchant. The payfac sells speed of onboarding and aggregation, not liability transfer.

Marketplace. A marketplace (Amazon's third-party business, app stores, ride platforms) intermediates the transaction: the buyer's contract is often with the marketplace, funds flow through it, and legislation in many jurisdictions, marketplace-facilitator laws in most US states, deemed-supplier rules in the EU, now forces the marketplace to collect and remit tax on sellers' behalf. Marketplaces sit closest to merchant-of-record status without the label, and the label matters less than the statute.

Merchant of record (MoR). The MoR, Paddle, Fastspring, and the app stores in their MoR capacity being familiar examples, is legally the seller. The customer buys from the MoR; the MoR buys from you, in effect, as a reseller. It calculates, collects, and remits tax in every jurisdiction it sells into; it is the entity the issuer's chargeback lands on; its name anchors the statement descriptor; its compliance certifications cover the transaction. The business ships the product and receives a payout net of the MoR's fee.

When the Merchant-of-Record Premium Is Worth Paying

The MoR fee looks expensive against a processing statement, several percentage points of revenue against the interchange-plus baseline dissected in the interchange fee guide, until it is priced against what it replaces. The honest comparison is not fee versus fee; it is fee versus the fully loaded cost of global tax compliance, dispute operations, and payment-stack maintenance.

The case for paying it is strongest under three conditions, and they compound. Cross-border tax complexity: the moment a business sells digital goods into dozens of jurisdictions, it accumulates registration and remittance obligations, EU VAT with its one-stop-shop filings, UK VAT, a growing list of countries taxing foreign digital services, US states with post-Wayfair economic-nexus thresholds. An MoR converts that entire surface into someone else's problem, and for a ten-person software company the alternative is not doing it internally, it is a six-figure annual relationship with advisors plus engineering time. Digital goods: no logistics footprint means the MoR's reseller construction fits cleanly; physical goods complicate it. Small teams: the MoR replaces headcount the company does not want to hire, which is why the model is the default in indie software, games, and increasingly in AI-app distribution.

The case against is the ceiling. The MoR owns the checkout, so conversion optimization happens within its templates. It owns the customer payment relationship and the descriptor, so the buyer's statement says the MoR's name, renewal and dunning flows run on its rails, and the customer payment data, the vaulted cards, the subscription states, lives with the MoR, a portability question to settle in writing before signing, not after. Payout timing follows the MoR's schedule, a working-capital consideration. And the premium is charged on every unit of scale: at low volume the MoR is cheaper than the infrastructure it replaces, and at some revenue line those curves cross, at which point the business is paying a growing tax for a convenience it has outgrown. The practical failure pattern is not choosing an MoR wrongly at the start; it is failing to notice, years later, that the crossover happened.

The Payfac Decision: Embedding Payments Without Becoming a Bank Examiner's Project

For platforms, vertical SaaS above all, the question inverts: not "who should hold my risk" but "should I hold my customers' risk, and get paid for it." A platform whose customers process payments through it can monetize the payment flow, and payments revenue is a major reason vertical software companies now routinely earn more from fintech features than from subscriptions, a dynamic covered in the guide to embedded finance.

The full-payfac path means registering with the networks under an acquiring bank, underwriting and KYC-ing every sub-merchant, monitoring their transactions for fraud and credit risk, managing funds flow and settlement, and carrying the liability when a sub-merchant generates chargebacks and vanishes. The reward is the economics: the platform sets its customers' blended rate and keeps the spread over its own cost of processing, on every transaction, forever. The cost is that the platform has become a small financial institution: compliance staff, risk tooling, capital reserves against sub-merchant losses, and network audits. Industry rules of thumb place the volume at which the fixed costs pencil out well into the tens of millions of USD in annual processed volume, often quoted around fifty million and up, below which the spread cannot carry the overhead.

Payfac-as-a-service is the middle path that has made the full build a minority choice: providers such as Stripe Connect, Adyen for Platforms, and the payfac-enablement vendors let a platform price payments to its customers and keep a spread while the provider carries the registration, underwriting machinery, and most of the compliance load. The platform gives up a slice of the economics and some control over risk policy; it avoids the compliance organization entirely. For most platforms below very large volume this is simply the correct answer, and the honest decision is between payfac-as-a-service now and a possible graduation to full payfac later, not between payfac-as-a-service and nothing.

The risk to respect in either variant: the platform now sits in the flow of funds reputationally even where it does not legally. When a sub-merchant defrauds buyers, the platform's brand absorbs the damage before the liability allocation is litigated. Underwriting is not paperwork; it is the product.

Choosing, and Changing Your Mind

Two forward-looking notes belong in the decision. First, agentic commerce stresses the models unevenly: when software agents initiate purchases, disputes about authorization multiply, and the entity holding chargeback liability, the MoR or the payfac guaranteeing its sub-merchants, is the one underwriting a new and unpriced fraud category; expect MoR and payfac pricing to start distinguishing agent-initiated flows. Second, cross-border rail shifts, real-time A2A schemes and stablecoin settlement, reduce the card-specific compliance surface but not the tax surface; an MoR's tax value survives a world with fewer cards, while its chargeback value shrinks with them.

Migration paths, finally, are where contracts earn their review. The normal arc, MoR or payfac sub-merchant at launch, direct acquiring at scale, or payfac-as-a-service graduating to full payfac, is only smooth if the exit was negotiated at entry: portability of vaulted payment credentials and subscription state, no exclusivity that outlives its usefulness, and payout and reserve terms that do not tighten at precisely the moment the business grows. The model you choose this year matters less than whether you can leave it on schedule.

FAQ

What is the difference between a merchant of record and a payment facilitator?

A merchant of record is legally the seller: it owes the sales tax or VAT everywhere it sells, absorbs chargebacks, and the customer's contract and statement descriptor are with it; the actual product company gets a net payout. A payment facilitator aggregates businesses as sub-merchants under its own acquiring relationship, absorbing onboarding, KYC, and network registration, but its sub-merchants typically remain the merchant of record for the sale, keeping their own tax obligations and ultimate chargeback liability.

Who is liable for chargebacks in each payment model?

Under a plain processor relationship the business is fully liable. Under a payfac, the payfac guarantees sub-merchant chargebacks to the acquirer and recovers the money from the sub-merchant, so economic liability stays with the business. On a marketplace, allocation varies with who is deemed the seller. Under a merchant of record, the dispute lands on the MoR as the legal seller, and the product company's exposure is defined by its contract with the MoR rather than by network rules.

When is a merchant of record worth the fee?

When the tax surface it absorbs would otherwise require staff and advisors: digital goods sold cross-border into many jurisdictions, small teams without finance operations, and products where checkout control matters less than compliance coverage. The premium, commonly several percentage points above ordinary processing, is cheaper than internal global compliance up to a substantial revenue level. It stops being worth it when volume grows enough that the crossover flips, or when owning checkout, payment data, and payout timing becomes strategically necessary.

What does it take to become a payment facilitator?

Full payfac status means registering with the card networks under a sponsoring acquirer, underwriting and KYC-ing every sub-merchant, monitoring transactions, managing funds flow, and reserving against sub-merchant losses: in effect, operating a small financial institution. Industry rules of thumb put the annual processed volume needed to justify that overhead in the tens of millions of USD, often around fifty million and up. Below that, payfac-as-a-service platforms deliver most of the payments revenue with a fraction of the obligations.

Can a business switch between these models as it grows?

Yes, and the common arc is exactly that: launch on a merchant of record or as a payfac sub-merchant for speed, then graduate to direct acquiring, or from payfac-as-a-service to full payfac, when volume justifies owning the stack. The switch is only cheap if the original contract preserved it: portability of vaulted customer payment credentials and subscription state is the decisive term, because losing the vault means re-acquiring every recurring customer. Negotiate the exit at entry.

Related reading on FinTekCafe

• Payment Gateway vs Payment Processor: What's the Difference
• Interchange Fees Explained: Who Really Pays for Card Payments
• Chargebacks Explained: The Dispute System Behind Card Payments
• What Is Embedded Finance: The Complete Guide for Business Leaders