Gaspard LEZIN
What Is Merchant of Record and How Does It Work
Learn what is merchant of record, how it handles tax and compliance, and how it compares to PSPs and marketplaces. Clear guide for SaaS and e‑commerce.
A merchant of record is the legal seller in a transaction, and it owns payment acceptance, tax collection, and chargeback liability on behalf of the underlying business. In practice, that means the customer buys from the MoR, while the product company keeps building and selling its product.
If you've ever tried to sell a subscription outside your home country, you already know why this model exists. The problem isn't just taking a card payment, it's deciding whose name appears on the statement, who files VAT or sales tax, and who answers the dispute when a customer says, “I don't recognize this charge.”
Table of Contents
What Merchant of Record Means in Plain Language
A founder selling a SaaS plan to customers in 40 countries can get buried fast. The product is simple, the billing isn't, because every new market can mean tax registration, invoice rules, refund handling, and chargeback disputes the team didn't plan for.
A merchant of record steps in as the named seller for that transaction. It becomes the entity that accepts payment, calculates and collects tax, issues the invoice, and carries the chargeback and compliance burden, while the original company still owns the product, the brand, the customer relationship, and the price.
The easiest way to think about it
The MoR is not buying your product and stocking inventory like a classic reseller. It's selling the product in its own name for that transaction, then passing the net proceeds back to you after it handles the money flow and the obligations attached to the sale.
That distinction matters because the legal seller is the one that must register, collect, remit, and defend the transaction where required. In cross-border digital commerce, that's what turns a messy operations problem into a defined responsibility chain.
Practical rule: if your team wants one entity to stand between your business and the tax, payment, and dispute stack, you're talking about a merchant of record.
A reusable internal definition is simple, the merchant of record is the legal seller that owns the transaction from checkout through payout.
How a Merchant of Record Transaction Actually Flows
A customer lands on checkout, enters card details, and sees the MoR's name appear on the payment experience and, later, on the bank statement. That's the first clue that the MoR, not the original product seller, is the legal seller of record for that purchase.
The payment then moves into the MoR's merchant account or balance, not directly into the seller's. From there, the MoR handles the tax logic, the customer-facing receipt, and the operational record around the sale.
From checkout to payout
The MoR calculates VAT, GST, or sales tax based on the customer's location and the product type, then collects that amount at checkout. Because the MoR is the seller on the transaction, it's also the party that remits that tax to the right authority on its own filing cycle.
Refunds and disputes sit in the same chain. If the buyer requests a refund or files a chargeback, the MoR fields the case and pulls supporting evidence from the seller when needed, then resolves the outcome through its own process.
By the end of the cycle, the seller receives a payout that is net of the fees, tax remittance, and any other charges the MoR applies. That's why reconciliation can be much simpler, one ledger line for payout instead of a pile of country-by-country receipts, tax filings, and processor reports.
The big operational shift is that the seller never has to touch gross customer funds. The MoR collects, routes, remits, and pays out.
For a visual reference on the payment-side terminology, what a PSP is and how it differs from an MoR helps explain why the money flow changes so much once the seller role moves.
Merchant of Record Compared to PSPs and Payment Facilitators
A founder comparing payment models usually starts with the same question. Who is the seller on the transaction?
A PSP helps move the payment. It gives you the rails for card acceptance and connects to the wider payments stack, but the seller still carries tax registration, filings, chargebacks, and most legal obligations. A payment facilitator sits one layer closer to the merchant. It lets sub-merchants operate under a master account and simplifies underwriting, yet the seller still retains much of the tax and legal burden. An MoR changes the setup more completely, because the provider becomes the legal seller and takes on the transaction liability and compliance work that follows the sale.
Responsibility | Merchant of Record | Payment Service Provider | Payment Facilitator |
|---|---|---|---|
Payment acceptance | Handles it as legal seller | Provides processing rails | Supports sub-merchant acceptance under its master account |
Tax collection and remittance | Handles it | Seller handles it | Seller usually handles it |
Chargeback liability | MoR absorbs it | Seller absorbs it | Shared structure, but seller still carries much of the operational burden |
Invoicing and receipts | MoR issues them as seller | Seller issues them | Seller usually issues them |
Seller effort | Lower on compliance operations | Higher | Medium, but still hands-on |
A useful way to compare the models is to ask where the work lands after checkout. With an MoR, the seller's load shifts away from tax administration and transaction liability. With a PSP or payment facilitator, the seller still has more of that work on its own books.
For founders comparing the route options, a practical directory like find merchant facilities in Australia can help when you are mapping who sits in the merchant layer and how that choice changes your operational load.
If you want a deeper breakdown of the MoR seller role, a deeper breakdown of the MoR seller role is a helpful companion read.
Marketplaces sit in a slightly different place. They often look like an MoR to the buyer because the platform name appears on checkout and statements, but they also bring marketplace rules, seller standards, and discoverability trade-offs that do not match a normal SaaS MoR setup.
For the payment-side terminology, what a PSP is and how it differs from an MoR helps explain why the money flow changes so much once the seller role moves.
Tax, Legal, and Reconciliation Responsibilities Under MoR
A merchant of record shifts the checkout burden onto one named seller, and that changes the back office too. Tax, receipts, disputes, and payout records all start from that seller role, so the model works best when you want one party to carry the transaction paperwork instead of splitting it across several providers.
What moves to the MoR, and what doesn't
Tax is the clearest example. When the MoR is the named seller, it has to calculate, collect, and remit consumption taxes such as sales tax, VAT, or GST in the places where it sells.
The same pattern applies to the customer-facing paperwork. The MoR name appears on the receipt, the sale terms, and the refund policy, so the buyer sees one accountable seller even if another company owns the product behind the scenes.
Chargebacks follow that same logic. The MoR handles the dispute, submits evidence, and carries the transaction liability through the outcome, while the underlying seller may still need to provide order history, fulfillment proof, or account-level context.
Responsibility Domain | Handled by MoR | Stays with Seller |
|---|---|---|
Sales tax, VAT, GST | Registration, collection, remittance in covered jurisdictions | Income tax on net revenue |
Consumer-facing seller name | Named seller on receipt and transaction records | Brand ownership and customer relationship |
Chargebacks and refunds | Dispute handling, provisional recovery, payout adjustments | Product support evidence and operational inputs |
Reconciliation | Net payouts, fee and tax deduction logic | Internal revenue accounting |
Regulatory support | Transaction-level compliance handling | AML cooperation and product liability for physical goods |
For finance teams, Snyp helps you master ecommerce accounting is a useful companion when mapping payouts, fees, and tax treatment across systems.
For a more formal service definition, the seller-of-record mechanics explained shows how the model is usually described in product terms.
The boundary matters. The MoR handles the transaction compliance stack, but the business still keeps income tax on its own revenue, cooperation on anti-money-laundering checks where relevant, and any product liability tied to the goods themselves. That is the part founders sometimes miss. The MoR can carry the sale, but it does not erase every obligation around the business.
When Merchant of Record Is the Right Fit
The MoR model fits best when the business has to sell across borders but doesn't have the appetite to build tax ops country by country. That's why it shows up so often in SaaS subscriptions, digital products, and creator-led businesses that need a compliant global checkout without building a finance team first.
Three situations where the model tends to make sense
For SaaS, recurring billing makes the case stronger. A subscription business has to deal with renewals, failed payments, churn, invoices, and tax treatment that can change with the buyer's location, so the MoR can remove a lot of administrative overhead.
For cross-border e-commerce, the challenge is different. Physical goods can trigger import-related tax and consumer-duty questions, and every new market adds more variation to the checkout and post-sale process.
For creators, indie developers, and digital product sellers, the problem is usually bandwidth. They want one checkout, one payment stack, and a path to global sales without spending their time on registrations, filings, and dispute administration.
Suby is one option in that category. It provides an API for card and crypto payments, native integrations with Discord and Telegram, and a way to let customers pay by card, wallet, bank, or crypto while the business receives funds in a bank account or in stablecoins like USDC. Pricing depends on the payment method used, so the exact figures need to be checked on the pricing page.
Decision rule: if compliance work is slowing launch more than product work is growing revenue, the MoR model deserves serious consideration.
The fit is strongest when you have a high country count, a small finance team, mostly digital or low-fulfillment products, and a willingness to trade some margin for speed and simplicity. If you need deep checkout control, local entity control, or very custom settlement logic, the model can feel restrictive.
Pros and Cons of Using a Merchant of Record
The strongest pro is speed. An MoR lets a founder get into new markets without setting up separate tax registrations, payment relationships, and filing processes in each country.
The upside first
It also simplifies dispute handling. Because the MoR owns the transaction, it can bundle fraud checks, refunds, and chargeback defense into one operational flow instead of making the seller stitch those pieces together.
Another practical gain is geographic reach. For teams with a small operations bench, that can mean launching internationally with far less setup friction than direct payment integration.
The trade-offs that matter
The downside is control. An MoR usually means less freedom over checkout branding, customer payment data, and the exact payment experience, because the provider is carrying the seller role and the liability that comes with it.
Settlement can also feel slower or less flexible than a direct PSP setup, and the provider's banking relationships become part of your own operating risk. Margin compression matters too, because the provider is doing more work than a plain processor.
Pros | Cons |
|---|---|
Instant global sales | Transaction fees are usually higher than a raw PSP setup |
No need for foreign tax registrations | Less direct access to customer payment data |
Compliance is handled | Branding and checkout controls can be narrower |
Chargeback and fraud support is bundled | Settlement timing may be less flexible |
For founders evaluating the trade-off, the question is not whether the MoR is simpler. It is whether the time saved on compliance and operations is worth the loss of margin and control.
Implementation Checklist Before You Sign With an MoR
Signing an MoR contract is not just a checkout decision. It binds revenue flow, tax filing logic, customer support routing, and data handling, so the contract review matters before the first transaction goes live.
The checks that save teams later
Start with the agreement itself. Review termination terms, exclusivity, indemnity, and how liability shifts if a transaction goes wrong.
Then confirm the money flow. Check payout currency, payout schedule, reserve policy, and how fees are described so finance knows what lands, when it lands, and what gets held back.
After that, verify the tax footprint. The MoR's registrations need to cover the countries where your customers live, not just the places where your company is based.
Set up product catalogs carefully, because physical goods, SaaS, and digital downloads can need different tax treatment. Then test refunds, dispute workflows, and the sandbox flow before you accept live money.
Contract review first: Make sure legal sees termination, indemnity, and exclusivity before operations signs off.
Payout details next: Confirm currency, cadence, reserves, and how fee deductions show up.
Tax settings third: Map each product type to the right tax code and jurisdiction logic.
Test before launch: Run a sandbox transaction, then reconcile the expected payout against the test settlement.
Roll out in stages: Start with a small geographic segment, then expand after the first clean cycle.
For a broader buyer's checklist, best merchant of record guidance is a useful companion when you're comparing providers and not just models.
Document who owns the relationship internally too. Finance, legal, and product should each know who escalates issues, who reviews reports, and who approves changes with the MoR.
Merchant of Record Questions Readers Ask Next
Question | Short Answer | Next Action |
|---|---|---|
Can I still issue branded invoices if the MoR is the legal seller? | Yes, many teams keep their brand in the customer-facing experience while the MoR remains the legal seller on the transaction documents. The key is making sure the invoice format and tax fields match the MoR's rules. | Ask the provider how branded documents are handled in its dashboard. |
What about VAT IDs, tax exemption certificates, or reseller certificates? | Those documents usually need to flow through the MoR's tax setup, because the MoR is the entity collecting and remitting tax. The exact handling depends on how the provider supports exemption logic. | Confirm the exemption workflow before launch. |
Does multi-currency settlement affect revenue recognition? | Yes, it can, because foreign exchange can change the net amount you recognize in your books. Finance should decide how to map settlement currency, reporting currency, and any FX impact. | Align the MoR payout view with your accounting policy. |
What happens in a chargeback if the MoR is liable? | The MoR usually submits the response, gathers evidence, and carries the liability through the outcome. Your team still needs to provide order records, account activity, or delivery proof when asked. | Set a clear evidence handoff process before going live. |
How do you switch back from an MoR to a direct PSP? | You need a clean data export, customer communication, and a transition plan for active subscriptions so renewals don't break. It's a migration project, not a simple toggle. | Plan the cutover by cohort and subscription cycle. |
The questions above are the ones founders usually ask after they understand the headline definition. They're also the ones that decide whether the model will work in real operations, not just in a pitch deck.
If you're weighing whether an MoR is the right fit for your stack, Suby gives you one API to accept card and crypto payments, native Discord and Telegram integrations, and settlement choices that include bank payout or USDC. Visit Suby to see how the model fits your checkout, subscriptions, and global payout flow.
