What Is the Merchant of Record in a Marketplace?

The question sounds like a formality, and it is the most common place where a project comes apart: legal promises one thing, IT configures another, and the bank shows a third. Leave it unsettled, and you will learn the answer at the first chargeback or the first inspection.

By then the answer is no longer yours to give.

The previous article showed that "who sells" is four independent roles. This one is about what happens when you assemble them differently from what your model assumes.

Some combinations simply do not work, and every one of them can be spotted before you build it.

This article breaks down:

• What decides who the merchant of record is?
• Which 2 money setups can a marketplace run?
• When does tax law make you the supplier?
• How do you check who your merchant of record is?

Key insights

• The merchant of record is the entity whose name is on the account the buyer pays into, and whose name appears on the card statement.
• Payments, tax, and civil law each use the term for a different thing, and one order can put them in three different places.
• Holding the buyer's money before you pay the seller is payment activity in most jurisdictions, and the commercial agent exemption only covers acting for one side.
• A deemed supplier rule can make you the taxable person even where your seller sells under civil law.
• The chargeback test settles the argument in thirty seconds: whose account does the money come out of?

What decides who the merchant of record is?

You choose the model. Merchant of record is not chosen: you acquire it at the moment the buyer's money touches someone's account.

A definition that never lets you down: the merchant of record is the entity in whose name the account with the payment provider is held. Its name is what shows up on the buyer's card statement, and it is the one that loses the money when a transaction is disputed.

That gives you a test that settles the argument in thirty seconds.

The chargeback test. A buyer pays €1,000 by card.

Three months later, they dispute it with the card issuer. The money goes back to them almost immediately, and a dispute handling fee comes on top.

The question is: out of whose account? The answer to that question is the answer to "who is the merchant of record." It does not depend on what you wrote in your terms or on what you call your role in the deck.

Why do payments, tax, and legal mean different things by merchant of record?

When someone in your company says "we want to be the merchant of record," it is worth asking: in which sense? The same term covers three independent things.

1. The payments sense. Whose account sits with the payment provider, who goes through verification there, who carries the cost of a chargeback. This is how the payments person uses the term, and it is the only meaning with a sharp technical criterion.
2. The tax sense. Who accounts for VAT on the supply to the buyer. This is how the tax advisor uses the term.
3. The civil law sense. Who is a party to the contract: who answers for faulty goods, who handles withdrawal from the contract, who the customer goes to with a complaint. This is how the lawyer uses the term.

The most common misunderstanding goes like this: the speaker means the first sense, because that is what their payment provider calls it, and expects the consequences of the third. These are not the same thing, and the three roles can fall to three different parties within a single order.

There is a fourth, informal use to watch out for. In some industry material, a "merchant of record marketplace" simply means a platform that buys the goods from the seller and resells them onward.

That is a completely different business model. The payment setup alone does not create it.

When you read about MoR in a vendor's material, check which of the four meanings is in play.

And the part that surprises people most: your civil law role can be settled by what your interface looks like. Suppose the average buyer comes away from your site convinced that they are buying from you.

They accept your terms, they see your brand at every step, and the seller's name appears only in the order confirmation. A court can then treat you as the seller, whatever you and the seller wrote into your contract.

Case law is moving in that direction, and this is the one place in this article where a UX design decision has direct legal consequences. It is worth having your lawyer look at the mockups as well as the terms.

Which 2 money setups can a marketplace run?

In practice, the choice is binary, and it settles the rest.

Setup A: The split happens at the payment provider

The seller has their own settlement account with your payment provider. The buyer pays once and the provider splits the money on its own side: on a €1,000 cart at a 12% commission the seller gets €880 and you get €120, and it is the provider that performs the split.

The merchant of record here is the seller. The chargeback lands on them.

You are not holding anyone else's money, so your regulatory exposure is as small as it can be.

You pay for that in two ways. Seller verification is done by the payment provider, so you control neither that experience nor how long it takes.

That is a recruitment bottleneck: a seller stuck in verification is not selling. The second cost is that changing payment provider means re-verifying your entire seller base.

That is a real cost of exit, and it is better known before you sign than three years later.

Setup B: You collect everything and pay out in cycles

Everything lands in your account, and payouts to sellers go out on a fixed cycle. You are the merchant of record.

The chargeback is yours.

And here comes the question that matters more than all three meanings put together: for a stretch of time you are holding money that is not yours. In most jurisdictions, that is payment activity.

There are three ways out: your own license, leaning on a licensed partner who runs segregated accounts, or showing that the exemption written for commercial agents applies to you.

Most operators count on the third route, and most of them are wrong. The exemption works only when you act clearly for one side, either the buyer or the seller, and not for both at once.

A marketplace by its nature stands between the two, so regulators in Europe consistently hold that a platform running its own payments cannot invoke that exemption. If you act for both sides, the only way to avoid a license is an arrangement where the funds are controlled not by you but by a licensed partner.

This is a test you can run in five minutes in a meeting, and it is better run before you build than after.

The market defaults to setup B because it is more convenient operationally, and it gives you control over the moment of payout. Very often it picks that setup without realizing it.

What is the difference between escrow, segregated accounts, seller reserve, and rolling reserve?

These words get used interchangeably, and that costs money, because each of them means something different:

• Escrow. Funds locked at a third party until a condition is met. In marketplaces, it comes up less often than people talk about it.
• Segregated accounts. Client money kept apart from the operator's own assets. Segregated accounts are required by the payments regime.
• Seller reserve. A withheld part of the seller's balance covering future refunds. This is not escrow. It is your own risk buffer.
• Rolling reserve. A percentage of every transaction held back for a set period, standard at payment providers for risky profiles.

If "escrow" comes up in a conversation with a vendor, ask which of the four they mean. Usually the third.

Can you issue the invoice without being the seller?

This is one of the few places where the law gives you room. You can issue invoices in the seller's name: technically your system does it, formally, the seller issues it.

That makes you neither a party to the contract nor the taxable person.

There are two catches, and both are expensive.

The first: e-invoicing. If you operate in a country where invoices pass through a mandatory national system, issuing in the seller's name means you become the technical issuer in that system.

Someone has to hold the permissions and the certificates, someone has to handle rejections, someone has to know what a correction looks like and who archives the document. This can blow up a project schedule, so the question gets asked in the first meeting.

The second, and the exact opposite: if you issue the invoice in your own name, you stop being an intermediary. That is the cleanest known way to become a seller by accident, and it comes with the product liability and the VAT you never planned for.

When does tax law make you the supplier?

The rules can treat the platform as the supplier for VAT purposes even when, under civil law, it is your seller who sells. In the EU, this covers two typical arrangements: sales to consumers made by sellers not established in the EU, and imported goods in low-value consignments.

The effect is as if you had bought the goods from the seller and resold them to the customer, for VAT and for nothing else. Thresholds and details differ, and they change faster than documents like this one, so this article does not give them.

It gives the consequence. It is also worth knowing that the regulatory direction is toward widening platform liability rather than narrowing it.

When you plan a model several years out, assume more obligations rather than fewer.

The consequence is this: you can be an intermediary commercially and under civil law, and at the same time the taxable person on part of the flows. If that is so, your data model has to answer two questions on every order line: where is the seller established, and did the goods come from an import?

If you are not collecting that information from day one, it cannot be reconstructed after the fact.

A client who did not check this finds out at an inspection. At that point, the problem is not the software. It is the arrears.

What does a refund reveal about your merchant of record setup?

Take the same order: €1,000, a 12% commission, €880 already paid out to the seller. The customer returns the goods after forty days.

Four questions you have to settle once, in writing, before you build:

1. Does the commission come back? Do you hand the seller that €120, or does it stay with you? And if the return comes down to obvious fault on the seller's side, do you still hand it over? In many systems, the refund to the customer and the return of the commission are one inseparable action. If you want to separate them by fault, you have to design for it.
2. Where do you find the €1,000 if the seller's balance is empty? A reserve, an offset against future payouts, a demand for payment. Each of these routes is a different process and a different clause in the seller agreement.
3. What do you do when the balance goes below zero? And who makes the phone call about it?
4. What if the refund window at the payment provider has expired? After a certain time, you cannot refund to the card, and you need a fallback rail. That is usually a bank transfer, and it comes with a different accounting path and a different document.

This looks like an operational detail. In reality, the arrangement in the first question can move your real margin by percentage points, because it applies to every return.

How do the 2 setups compare on risk, cost, and control?

Which merchant of record arrangements break in practice?

These combinations of roles always fall apart. They are worth knowing, because every one of them can be caught in a single meeting, and every one caught later means rewriting.

You collect the gross amount, and you have neither a license nor a licensed partner. You are conducting payment activity with no basis for it.

Everything else on the list is a design risk. This one is a legal risk.

You declare an intermediary model, but you invoice in your own name. You have just become the seller.

You cannot be an intermediary "just a little."

You assume the refund will always travel back the way the payment came in. The window expires.

Without a fallback rail, you are left with an obligation you have no way to discharge.

You have foreign sellers or goods from imports, and you have not checked whether the law will treat you as the supplier. This inconsistency does not surface in the system.

It surfaces at an inspection.

The balance in the seller dashboard does not match the transfer, and your team treats that as cosmetic. It is not cosmetic.

A seller who has twice received an amount different from the one they saw stops trusting the settlements, and your team starts spending days explaining differences instead of recruiting.

The buyer requires one invoice, and you are building a classic marketplace. Incompatible.

It calls for a different model rather than a workaround.

A commission in a model where you set the price. It is either a margin or a commission.

Both at once means someone is counting twice.

What does your merchant of record choice decide?

Choosing a payment provider stops being a technical decision. Setup A requires a provider that will handle seller accounts and verification in your geographies and at your scale.

If it will not, you do not have setup A. You have setup B and everything that comes with it.

The data model has to know the seller's country of establishment and the origin of the goods on every order line. This requirement comes out of tax rather than logistics, which is why it gets skipped at the design stage.

The commission refund policy stops being a parameter and becomes a document. It has to sit in the seller agreement, in the terms, and in the system, all in the same version.

Revenue recognition follows the role. If you are an intermediary, your books show the commission.

If you are the seller, they show the whole GMV. Agree this with finance before you choose the model, because the decision has sometimes already been made elsewhere in the organization.

How do you check who your merchant of record is? 5 questions

1. Whose name will appear on the buyer's card statement? If you do not know, you do not know who the merchant of record is.
2. Who will pay for a chargeback, and literally out of which account?
3. Does the buyer's money land in your account, even for a moment? If it does, that question goes to a lawyer rather than a software vendor.
4. Who issues the invoice to the buyer, and in whose name? And if it is issued in the seller's name, who is responsible for compliance with the national e-invoicing system?
5. Will you have sellers from outside your country, or goods from imports? If so, your tax role can differ from your civil law role, and that has to be confirmed before you design the data.

If the answer to any of these is "probably," you have an open item, and it had better have an owner and a date.

Which mistakes do companies make about merchant of record?

Putting this question to your software vendor. The vendor will tell you what the system can handle.

It will not tell you what you are allowed to do in your country, because it does not know and it does not take responsibility for it.

"Our payment provider takes care of that." It may take care of splitting the money, verifying sellers, handling disputes, and paying out in several currencies. It may also cover only some of that.

These are four different things, and it is worth knowing which of them are in the contract.

Settling this after the seller agreements are signed. The seller agreement contains the split of roles.

If that split changes after signing, you amend the entire base.

Confusing escrow, segregated accounts, and a reserve. Three different mechanisms, three different regimes, three different costs.

Used interchangeably, they can leave the board thinking something is secured when it is not.

Assuming one setup will serve every flow. Domestic sales, cross-border sales, imported goods, and digital goods can fall under different rules inside the same company.

That does not mean you need four models. It means you need to know where the boundaries run.

Do you need a lawyer to settle merchant of record?

This is a map of mechanisms and questions. Confirm three things with a lawyer and a tax advisor, for the specific country, year, and model: whether your setup requires a payment license, whether the law will treat you as the supplier for VAT purposes, and what obligations the national e-invoicing system places on you.

This article deliberately gives no thresholds and no dates on which rules take effect, because they change faster than this text does.

It also does not settle what to do when the answers point to two different setups for two different flows. That is a real case and it needs a separate conversation, but at least you will know that you have it.

Summary: Which setup should you run?

If the payment provider splits the money and settles sellers directly, the seller is the merchant of record and your regulatory exposure stays small. If you collect everything and pay out in cycles, you are the merchant of record, the chargeback is yours, and you are holding money that is not.

Settle it in writing before you build, because the answer decides your payment contract, your data model and your refund process. Talk to a marketplace expert if you want to check your own setup against these questions.

Frequently asked questions

What is the merchant of record?

The merchant of record is the entity in whose name the account with the payment provider is held. Its name shows on the buyer's card statement, and it is the entity a chargeback is taken from.

The term is also used loosely in tax and in civil law, where it means something different each time.

Is the marketplace or the seller the merchant of record?

It depends on where the money lands rather than on what the contract calls you. If the payment provider splits the payment and pays the seller directly, the seller is the merchant of record.

If the whole amount arrives in your account first, you are.

Do you need a licence to hold seller money?

Usually yes, unless an exemption clearly applies. Collecting the buyer's money and paying sellers later is payment activity under PSD2.

The commercial agent exemption covers acting for one side only, and the EBA has said that settling the buyer's debt is not, on its own, enough to fall outside the regime. Check it with a lawyer in your country.

Sources

• Directive (EU) 2015/2366 (PSD2) - payment services, the commercial agent exclusion and safeguarding of client funds
• European Banking Authority - Single Rulebook Q&A 2020_5354 on the commercial agent exclusion for e-commerce platforms
• Council Directive (EU) 2017/2455 - VAT obligations for distance sales of goods (deemed supplier)
• European Commission - VAT in the Digital Age (ViDA), adopted 11 March 2025
• Directive (EU) 2019/2161 - information duties for online marketplaces