Merchant of Record and Payment Facilitator sound like the same thing. Both involve a third party sitting between the buyer and the seller. Both promise to "handle payments" for software platforms. Both come up in the same conversations about embedded payments and revenue capture.
They are not the same thing. They solve different problems, carry different liabilities, and fit different business models. Picking the wrong one means either leaving money on the table or signing up for tax and compliance obligations you did not understand you were taking on.
This article is the plain-language version. What each one actually is, what they share, where they diverge, and how to choose between them at your platform's stage and vertical.
What Merchant of Record Means
A Merchant of Record (MoR) is the legal entity that sells a product or service to the end customer, takes payment, and carries the legal responsibility for that sale. The MoR shows up on the customer's credit card statement. The MoR collects, files, and remits sales tax or VAT. The MoR handles refunds, chargebacks, and customer disputes from the financial side. The MoR is the regulated entity for tax, anti-fraud, and consumer protection purposes.
In practice, MoR services for software platforms emerged primarily from the digital-goods and SaaS world. Providers like Paddle, FastSpring, Lemon Squeezy, and 2Checkout (now Verifone) act as the MoR for software companies selling globally. The software platform builds the product, sets the price, and runs the customer relationship. The MoR provider handles the payment processing, the tax calculations across hundreds of jurisdictions, the compliance with consumer protection laws in each country, and the chargeback liability.
The MoR model exists because selling software globally creates a hard tax and compliance problem. A SaaS company headquartered in Delaware selling to a customer in Germany has VAT obligations in Germany, consumer protection requirements under EU directives, currency conversion exposure, and potentially digital services tax obligations in the UK or France. Multiply that by 100 jurisdictions and the operational burden is significant. The MoR absorbs all of it in exchange for a percentage of revenue, typically 5 to 9 percent of each transaction.
What Payment Facilitator Means
A Payment Facilitator (PayFac) is an entity registered with the card networks (Visa, Mastercard) that aggregates merchants as sub-merchants under one master merchant identification number (MID). For the full definition and the four arrangements that capture embedded payments economics, see What Is a Payment Facilitator?.
The short version: a PayFac lets a software platform enable card payments for hundreds or thousands of small businesses (sub-merchants) without each one needing an individual merchant account. The platform owns the merchant onboarding experience, sets pricing within negotiated parameters, and shares in the economics of every dollar processed. The sub-merchants are the merchants of record for their own sales. The PayFac sits between the sub-merchants and the card networks.
The PayFac model exists because, before it emerged, individual merchant accounts were slow to underwrite, friction-heavy to set up, and expensive to maintain. The PayFac model lets aggregators (Square, Stripe, Shopify Payments) board small merchants in minutes instead of weeks, accept the risk on the aggregate portfolio, and earn a portion of the basis-point spread on every transaction.
The Core Differences
The two models look similar on the surface (both involve a regulated entity sitting between the merchant and the payment networks) but they solve fundamentally different problems and carry different obligations.
| Dimension | Merchant of Record | Payment Facilitator |
|---|---|---|
| Primary use case | SaaS or digital goods sold globally to end consumers | Software platforms enabling card payments for sub-merchants (typically B2B) |
| Who is the legal seller | The MoR provider | The sub-merchant (the small business) |
| Whose name on card statement | The MoR provider | The sub-merchant's DBA |
| Who handles sales tax / VAT | The MoR provider | The sub-merchant |
| Who handles chargebacks | The MoR provider | The PayFac (with sub-merchant operational support) |
| Typical economics for the platform | Platform pays MoR 5-9% of revenue | Platform earns 30-100+ bps net on volume |
| Card network registration | Not required by the software platform | Required (the PayFac itself or its provider) |
| Right fit | Digital SaaS, global, B2C or low-touch B2B | Vertical SaaS with merchants accepting card payments |
The simplest mental model: MoR is "we sell our product through a third party who handles all the tax and compliance." PayFac is "our merchants sell their products and we capture economics on the payment volume flowing through our platform."
When MoR Makes Sense
The Merchant of Record model fits when the software platform is the one selling the product to the end customer, especially across borders. The classic example: a SaaS company selling subscriptions globally to consumers or small businesses where the SaaS company would otherwise need to register for VAT in 30+ jurisdictions, comply with EU consumer protection law, handle currency conversion, and absorb chargeback risk on small-dollar transactions.
The trade is straightforward. The MoR provider takes a meaningful percentage of revenue (5 to 9 percent is the common range) but absorbs the entire tax, compliance, and chargeback burden. For a SaaS company doing $10M in global revenue, paying 7 percent ($700K per year) to a MoR can be cheaper than building the in-house tax and compliance team to handle global obligations. The math gets less favorable as the company scales, but the alternative (registering, filing, and complying in dozens of jurisdictions internally) carries real fixed cost that does not scale down.
MoR also fits well for indie developers, side-projects, and early-stage SaaS where the founder team would otherwise be spending engineering time on tax integrations instead of product. The simplicity-for-cost trade is correct when the company cannot yet justify dedicated finance and ops headcount.
When PayFac or PFaaS Makes Sense
The Payment Facilitator model fits when the software platform is enabling card payments for other businesses (the sub-merchants) rather than selling its own product directly to consumers. The classic example: a vertical SaaS platform serving 500 small businesses, each of which accepts card payments from their own customers through software embedded in the platform.
In this model, the small businesses are the merchants of record for their own sales. They show up on their own customers' card statements. They collect sales tax on their own sales. The software platform's role is to provide the technology and infrastructure that lets each merchant accept payments efficiently, and to capture economics on the payment volume flowing through.
For most vertical SaaS platforms at $30M to $200M of annual processing volume, PayFac-as-a-Service is the right way to enter this model. Above $200M, full PayFac registration becomes economically justified. For the volume thresholds and the full decision framework, see Should You Become a Payment Facilitator?
The Tax and Compliance Angle Most Platforms Underestimate
The biggest difference between the two models is who carries the tax and consumer-protection compliance burden. This matters more than most platforms realize before they sign the contract.
Under MoR, the provider handles all of it. Sales tax registration and filing in every jurisdiction. VAT in the EU. GST in Australia and Canada. Consumer protection law in each country. Refund policy enforcement under local law. Currency conversion and forex risk. Anti-money-laundering screening. The platform sees a single line item (the MoR fee) and the operational complexity is invisible.
Under PayFac, the platform takes on some of this burden directly, and shifts some to the sub-merchants. Card network compliance and PCI DSS obligations belong to the PayFac. Merchant underwriting and risk management belong to the PayFac. The sub-merchants handle their own sales tax obligations because they are the merchant of record for their own sales. For the full operational scope of PayFac compliance, see PCI Compliance for SaaS Platforms.
Platforms that try to combine the two models (acting as merchant of record for the sub-merchants' sales while also being a PayFac) usually create more compliance risk than either model alone. The clean separation is what makes either model defensible: MoR for "we are the seller," PayFac for "they are the seller, we provide the rails."
Common Misconceptions
"PayFac and MoR are interchangeable terms." They are not. They describe different legal arrangements with different liability allocations. The PayFac model is governed by Visa and Mastercard registration rules. The MoR model is governed by consumer protection, tax, and sales law in each jurisdiction.
"MoR is cheaper than PayFac at scale." Usually false. The 5 to 9 percent MoR fee is a percentage of gross revenue, while PayFac economics are basis points on payment volume. On a $50M-revenue SaaS company processing entirely through a MoR, the fee is $2.5M to $4.5M per year. The same $50M of revenue running through a PFaaS structure (where the platform owns the merchant accounts) would generate $150K to $300K of payments revenue for the platform, not a cost. The two models are not directly comparable because they describe different revenue structures.
"We can use MoR while becoming a PayFac to ease the transition." The two models are not transitional states of each other. They describe different products serving different customer types. Some platforms run both in parallel for different customer segments (MoR for global B2C subscriptions, PayFac for B2B in-person merchant payments), but the architectures are independent.
"MoR providers like Paddle compete with PayFac providers like Stripe Connect." They mostly serve different markets. Paddle and FastSpring serve SaaS companies selling their own products globally. Stripe Connect serves software platforms whose customers are themselves businesses accepting payments. The two models can coexist within the same software platform if it operates both kinds of businesses.
A Decision Framework
The cleanest way to know which model fits is to answer one question: who is the legal seller of the product or service being paid for?
- If your platform is the seller (you sell SaaS subscriptions, digital goods, or services directly to end customers): MoR is likely the right architecture, especially if you sell globally and want to avoid the tax-and-compliance build-out.
- If your customers are the sellers (your platform is software that other businesses use to accept payments from their own customers): PayFac or PayFac-as-a-Service is the right architecture. The economics are basis points on volume, not a percentage of revenue.
- If you operate both kinds of businesses (some lines sell your own product, some lines enable merchant payments): you may need both architectures running in parallel for different revenue streams.
MoR and PayFac are not competing options. They are different answers to different questions. The question is whether your platform is the seller or whether your customers are.
For most vertical SaaS platforms enabling card payments for their merchant customers, the answer is PayFac-as-a-Service first, with Full PayFac at higher volume. The Margin Multiplier models the four embedded payments arrangements at your specific volume. For the broader strategic conversation, see the advisory engagement.