Merchant of Record Services: A 2026 Guide for Sellers

You probably know the moment already. A founder closes deals in a few countries, then a customer asks for a VAT invoice, a card dispute lands in the inbox, and finance starts asking who is liable for the sale. At that point, merchant of record services stop sounding like an abstract payments term and start sounding like relief, or at least a better way to keep the books straight.

The basic idea is simple. A merchant of record is the legal seller on the transaction, the name on the customer's statement, and the party responsible for the sale, including payment liability, tax handling, and dispute handling in the transaction flow, while you still own the product, the brand, and the customer relationship. That structure has deep roots in digital commerce, and it has become more mainstream as global tax and compliance pressure has grown. The market for merchant of record software has been estimated at USD 11.61 billion in 2024 and USD 13.20 billion in 2025, with forecasts reaching USD 26.29 billion by 2030 and USD 35.43 billion by 2032 Research and Markets.

Table of Contents

• What Merchant of Record Services Actually Mean

  • The plain-English definition

• How a Typical MoR Payment Flow Works

  • From checkout to settlement

• What an MoR Takes On Versus What Stays With You

  • Responsibilities that shift to the MoR

  • Responsibilities that stay with the seller

• Benefits and Trade-Offs of Using an MoR

  • What the model genuinely offloads

  • What the MoR does not solve

• When to Choose an MoR, a Direct Merchant Account, or Payment Infrastructure

  • The three models in one sentence each

  • Where each option tends to fit

• How to Evaluate MoR Vendors Before You Sign

  • Five buckets to score

• Implementation and Onboarding Considerations

• Your Next Steps and Decision Checklist

What Merchant of Record Services Actually Mean

A founder usually meets the MoR model at the exact wrong time, right when operations are already messy. You've got a SaaS customer in the EU asking for a tax invoice, a buyer in Brazil raising a dispute, and your payment stack suddenly looks too simple for the markets you're selling into. That's where merchant of record services enter the picture, they let a third party become the legal seller so you don't have to carry every tax and liability task yourself.

The plain-English definition

The MoR is the company that appears on the card statement, issues the compliant invoice, and owns the transaction from a legal standpoint. In practice, it routes the payment through its own merchant accounts and takes responsibility for authorization, settlement, refunds, and chargebacks Beancount. That's different from a payment service provider, which may help move the money but doesn't become the seller or absorb the same legal burden.

Practical rule: if a vendor says it is an MoR, ask whether it is also the named seller on the receipt and bank statement. If not, you're probably looking at payment infrastructure, not a true MoR.

MoR vendors such as Paddle, Lemon Squeezy, and FastSpring are often used as reference points because they sit closer to the sale than a pure processor. The seller still owns the product roadmap, pricing decisions, and customer experience. The MoR only owns the sale itself.

A lot of confusion comes from mixing up the MoR with a reseller, a processor, or a payment facilitator. A processor moves funds. A PSP connects you to rails. An MoR becomes the seller of record and takes on the transaction liabilities that come with that role. That distinction matters because the operational relief is real, but it is also narrower than many marketing pages imply.

The MoR owns the transaction, not your company's product decisions. If you want control over refund policy, churn strategy, and customer messaging, those still sit with you.

How a Typical MoR Payment Flow Works

A good way to understand the model is to trace one order from click to payout. The customer starts on your site, but the checkout is hosted by or routed through the MoR, so the buyer is transacting with the MoR's commerce layer rather than a bare payment form. That detail matters because it explains why tax, invoicing, and liability sit with one legal entity instead of getting split across five tools.

From checkout to settlement

First, the buyer checks out. The MoR collects the payment through its own merchant account and can apply fraud screening and 3DS where needed. Next, it calculates the applicable tax, which can include sales tax, VAT, or GST, then files and remits that tax under its own registrations rather than yours Stripe resources. The invoice comes out in the MoR's name, because the MoR is the legal seller.

Then comes settlement. The MoR holds funds long enough to handle refunds and chargebacks, then pays out the net amount on its own schedule, often weekly or monthly, depending on the vendor. Currency, FX conversion, and payout thresholds vary by provider, so finance teams need to check those terms before they assume money will move in the same format they collect it. Webhooks and APIs usually let your systems mirror the order, revenue, and tax data back into your CRM, ERP, or accounting stack.

One useful reference point is Suby's documented flow. Its API lets businesses accept card or crypto payments, while the merchant can receive payouts to a bank account or in stablecoins, and the documentation also notes wallet-to-wallet crypto settlement with no holding period or delayed payouts Suby payment infrastructure overview. For a team evaluating MoR-style flows, that kind of visibility into checkout, settlement, and payout logic is what you want to see in the docs.

See also the related stablecoin payout path in Suby's merchant of record and stablecoin payout guide.

What an MoR Takes On Versus What Stays With You

The cleanest way to judge an MoR is to separate what moves off your plate from what doesn't. A lot of founders assume the model is a full outsourcing package. It isn't. It takes over legal sale mechanics, but your team still owns the commercial decisions that drive retention and margin.

Responsibilities that shift to the MoR

The MoR usually handles the parts that create the most compliance drag: payment processing, tax calculation and filing, invoice generation, dispute handling, and reduced PCI scope. In the cross-border world, that also includes registrations or filings that may be needed for specific tax regimes, depending on the provider and the markets covered. A well-run MoR also provides transaction-level reporting, such as gross sales by jurisdiction, tax collected by jurisdiction, refunds, and remittance summaries, so finance can reconcile the books.

Responsibilities that stay with the seller

Your team still owns product delivery, customer support quality, refund policy design, pricing strategy, churn, retention, and the claims you make in marketing. The MoR can execute a refund, but the policy usually starts with you, which is why the approval flow often lives on the seller side even though the money movement happens through the MoR. That grey area is where many teams get confused, because operational control and legal liability are not the same thing.

A SaaS example makes the line obvious. If a customer upgrades an annual plan halfway through the term, the MoR can process the proration and payment side, but your team still decides whether the policy allows upgrade credits, downgrades, or exceptions. An e-commerce example is different. If physical goods ship from the EU to the US, the MoR may handle the transaction mechanics, but it doesn't become the party responsible for warehouse mistakes or product quality.

Benefits and Trade-Offs of Using an MoR

The spreadsheet thinking matters. The value of an MoR is not that it magically makes payments easier in every way. The value is that it takes on specific jobs that are expensive, annoying, or risky to do in-house, especially when you're selling across borders.

What the model genuinely offloads

The clearest benefit is tax handling. MoR services are built to calculate, collect, file, and remit taxes for cross-border digital sales, and they reduce the need for your team to stand up separate tax logic market by market Stripe resources. That matters when your product sells into multiple jurisdictions and the rules aren't identical.

Other practical gains include PCI scope reduction, fraud screening, chargeback handling, multi-currency settlement, and cleaner reconciliation. For a SaaS company selling into ten countries, that can mean fewer internal workflows and fewer external advisors just to keep the billing stack compliant. For a creator or digital download seller, it can also mean less time spent rebuilding tax logic every time a new audience market shows up.

What the MoR does not solve

An MoR does not design your refund policy, lower churn, improve lifetime value, or choose your currency strategy for you. It also doesn't eliminate the commercial cost of higher MoR fees, which are commonly discussed as a premium over raw processing. The core point is simple, you're paying to transfer operational load and liability, not to erase the economics of your business.

Important trade-off: chargeback liability may move to the MoR, but disputes can still affect your reputation and can lead to account review. Liability shifts, customer behavior doesn't vanish.

For an e-commerce brand with healthy volume and a stable domestic market, the fee premium may be hard to justify if you already have tax, support, and fraud operations in place. For a creator selling digital products in several countries, the opposite may be true, because the cost of stitching together tax, invoicing, and dispute handling can exceed the MoR premium very quickly. The right answer depends on how much control you need, and how much compliance pain you're trying to remove.

For a company that wants to move fast across borders, the model can be worth it. For a company that already owns a mature tax stack and wants control over every part of the payment relationship, the math can tilt the other way.

When to Choose an MoR, a Direct Merchant Account, or Payment Infrastructure

The choice gets clearer if you stop treating these as similar products. They solve different problems. An MoR is for selling under someone else's legal umbrella. A direct merchant account is for selling under your own. Payment infrastructure is for teams that want to assemble their own stack and own the merchant role themselves.

The three models in one sentence each

An MoR resells under its own license and owns the buyer relationship for the transaction. A direct merchant account means you hold the merchant account, you are the taxed seller, and you carry the compliance load. Payment infrastructure gives you the rails, but you still remain the merchant of record and keep the liabilities.

Where each option tends to fit

A pre-seed SaaS launching in many countries on day one usually has the strongest case for an MoR, because speed and tax offload matter more than custom control. A mature e-commerce brand with high volume and a largely domestic customer base often does better with direct merchant ownership, especially if the tax stack is already in place. A marketplace with split payouts usually needs infrastructure and custom controls, because the payment logic is more complex than a standard seller flow.

For creators and small subscription businesses, the question is usually volume and overhead. If the business is still small and cross-border complexity keeps showing up, an MoR can be the simpler decision. If the team has enough internal finance and engineering capacity to own the stack, infrastructure may make more sense.

The practical rule is straightforward. If your revenue is still small, your markets are fragmented, and your team doesn't want to build tax and compliance systems, an MoR usually wins. If you have scale, control needs, and an established back office, a direct merchant account can be better. If the product is payment-heavy and custom, you'll probably want infrastructure.

A useful comparison for software founders is this Paddle versus FastSpring breakdown for software sales, which shows how vendor choice often comes down to workflow fit rather than slogans.

How to Evaluate MoR Vendors Before You Sign

The best vendor is usually the one whose operating details match your finance team's tolerance for friction. Pricing pages matter, but day-to-day operations matter more. If a vendor can't explain settlement, disputes, reporting, and support in plain language, the contract will probably be painful later.

Five buckets to score

Settlement mechanics should cover payout currency, hold periods, payout schedules, and FX margin. Ask the vendor what happens when you sell in one currency and settle in another, and watch for hidden spreads or unclear conversion terms. Refund and chargeback workflow should spell out timing, evidence requirements, and who initiates each action. Reporting should give you tax invoices by country, reconciliation exports, and file formats your finance stack can use.

Payout flexibility matters more than most founders expect. Suby's documentation shows that payout methods can include bank account, Venmo, PayPal, or stablecoins, while pricing depends on the payin method used rather than a single flat rate Suby fees documentation. Human support matters too, because you'll eventually need a named contact, a response path, and an escalation route when a payout or dispute gets stuck.

A few due-diligence checks are easy to skip and hard to fix later. Read the MSA termination clause, confirm who owns customer data after offboarding, and verify that tax registrations in your key markets are live, not just promised. If the vendor can't answer those cleanly, don't assume the rest of the stack is better than the paperwork.

Ask for the ugly case, not the demo case. A vendor that handles one refund well but can't explain a chargeback review is a risk, not a solution.

For vendor homework, it also helps to review Suby's merchant of record overview alongside any vendor docs you're comparing, so you can keep the model itself separate from the product claims.

Implementation and Onboarding Considerations

Going live with an MoR is less about signing and more about wiring. The first step is usually entity checks, bank detail collection, and contract review, which can take a short onboarding cycle before the first sale is processed. If you sell regulated goods, expect the compliance side to take longer because extra KYC checks may be needed.

Hosted checkout can go live quickly because the vendor controls the front end. Full API or subscription integrations take longer because your team has to map SKUs, tax categories, webhook events, refund states, and dunning behavior into your own systems. If you already have a finance stack, decide early whether payouts will reconcile into it cleanly or whether the MoR ledger will sit as a separate source of truth.

Operational rule: launch one market first, verify the reports and refund flow, then expand. The pilot should prove the money movement before it proves the commercial model.

It's also worth checking how VAT invoice numbering, renewal events, and failed payment recovery appear in your admin flow. Those details are boring until month-end, then they're the only things finance wants to know. A good onboarding plan makes those boring details visible from day one.

Your Next Steps and Decision Checklist

Start with the product, not the vendor. Write down what you sell, which countries you're targeting, whether the transaction is one-time or subscription-based, and what payment methods your customers use. Then sketch the desired flow, who pays, who receives, in what currency, and where you want the money to land.

Use that sketch to score candidates on five things, tax coverage, settlement speed, pricing transparency, reporting quality, and support quality. Request sandbox access, process a test transaction in two currencies, trigger a refund, and run a chargeback scenario so you can see how the vendor behaves under pressure. Review the resulting reports with finance, not just with sales or product.

If the vendor can't show you clean evidence for those steps, keep looking. The right MoR should reduce friction without hiding the operating details you still need to run the business. Make the decision this week with live tests, not assumptions, because the difference shows up later in reconciliation, disputes, and month-end close.

If you want a single payment stack that lets customers pay by card or crypto while your business settles to a bank account or in stablecoins, Suby is built for that flow. It also supports native integrations for Discord and Telegram, plus API-first checkout and invoicing for global sellers. Visit Suby to review the docs and see whether its payment and settlement model fits the way you sell.