Merchant of Record Regulatory Responsibilities
Merchant of Record Regulatory Responsibilities: Who Is Responsible for What? A Merchant of Record can substantially change how a business sells, accepts payment, handles tax, manages refunds and interacts with customers. What it does not do is make the underlying business disappe
Merchant of Record Regulatory Responsibilities: Who Is Responsible for What?
A Merchant of Record can substantially change how a business sells, accepts payment, handles tax, manages refunds and interacts with customers.
What it does not do is make the underlying business disappear.
That distinction is the most important one for companies evaluating a Merchant of Record model.
A Merchant of Record can assume significant payment, tax, transaction and consumer-facing responsibilities when the legal and contractual structure supports it. But using an MoR does not automatically transfer every regulatory, product, privacy, sanctions, intellectual-property or sector-specific obligation away from the underlying seller.
The practical question is therefore not:
Does the Merchant of Record handle compliance?
It is:
For this transaction, in this country, for this product and operating model, which entity is legally and contractually responsible for each obligation?
That allocation can materially affect launch speed.
A business that sells directly may need to establish its own acquiring, tax, payment, consumer, operational and local-market processes across multiple countries. An MoR model can consolidate some of those responsibilities under an intermediary that becomes the customer-facing seller for defined parts of the transaction.
But the precise result depends on:
The contract
What the MoR actually sells or resells
Who contracts with the customer
Who appears on payment records
Who accepts and settles payment
Which country is involved
The type of product or service
Applicable tax and consumer rules
Applicable payment regulation
Privacy roles
Sanctions and export-control rules
Sector-specific regulation
Merchant of Record should therefore be evaluated as an operating and legal structure, not merely as a checkout feature.
What is a Merchant of Record?
A Merchant of Record, or MoR, is an entity that contractually takes the customer-facing merchant role for defined transactions and assumes responsibility for specified commercial and payment obligations associated with those sales.
In a typical structure, the customer may buy through the underlying company's website or application, but the MoR is the entity legally positioned as the seller or reseller for the transaction covered by the agreement.
Conceptually:
Direct merchant model
Customer
↓
Underlying business
↓
PSP / Acquirer
With a Merchant of Record:
Customer
↓
Merchant of Record
↓
Underlying supplier
Payment infrastructure sits around the MoR according to the specific arrangement.
The important difference is not simply which company submits the payment API request.
It is who occupies the merchant role in the commercial transaction.
That can affect:
Payment acceptance
Tax
Invoicing or receipts
Refunds
Chargebacks
Consumer-facing obligations
Acquiring relationships
Transaction reporting
Exact responsibilities depend on the contract and applicable law.
Why the Merchant of Record role matters legally
A conventional PSP usually helps the merchant accept payments.
It does not normally become the seller of the merchant's product merely by processing the transaction.
That distinction matters because payment processing and the underlying commercial sale are different roles.
UK tax guidance for digital services illustrates the point. HMRC distinguishes payment processing from acting as the supplier through a digital platform: an entity whose role is only payment processing is not treated as the platform supplying the digital service, whereas a platform can become responsible for VAT where its role in the sale meets the applicable supplier rules.
An MoR arrangement typically goes further than a PSP relationship because the MoR's role is designed around the underlying sale, not merely transaction processing.
That is why a business evaluating an MoR should inspect:
Who is identified as seller to the customer?
Who contracts with the customer?
Who sets or accepts the commercial terms?
Who authorizes and receives payment?
Who issues the customer-facing payment record or invoice?
Who handles refunds?
Who receives chargebacks?
Who is responsible for relevant indirect tax?
Who handles consumer complaints and withdrawal rights?
Which obligations remain expressly with the product supplier?
The answer should be visible in the contract and the actual transaction flow.
What regulatory responsibilities can a Merchant of Record assume?
There is no globally standardized bundle of “MoR responsibilities.”
A Merchant of Record can assume different obligations depending on the jurisdiction, transaction structure and contract.
The following responsibilities are commonly associated with MoR models where legally and contractually applicable.
Payment acceptance
The MoR may be the merchant entity through which the customer payment is accepted.
That can mean the MoR manages:
PSP relationships
Acquiring relationships
Merchant accounts
Card acceptance
Alternative payment methods
Payment settlement
Payment-method compliance
This can reduce the number of direct payment relationships the underlying business needs to establish in each launch market.
But it does not mean the MoR is necessarily performing every regulated payment service itself.
The MoR may rely on licensed PSPs, acquirers, banks or other regulated institutions for parts of the transaction.
The legal role should be distinguished from the technical infrastructure beneath it.
Acquiring relationships
A direct merchant expanding internationally may need new:
Merchant accounts
Acquiring arrangements
Local payment-method relationships
Entity configurations
Bank or settlement arrangements
An MoR may centralize those relationships for transactions sold through its structure.
That can materially reduce the merchant's launch dependencies.
Instead of:
Merchant
├─ PSP relationship
├─ Acquirer A
├─ Acquirer B
├─ Local method C
└─ Local market configuration
the operating model may look more like:
Underlying business
↓
Merchant of Record
↓
Payment / acquiring infrastructure
This does not necessarily remove every local regulatory requirement affecting the underlying product or business.
It changes which entity manages the payment-merchant side of the transaction.
Payment compliance
Where the MoR is the payment-facing merchant, it can assume responsibilities associated with operating the acceptance relationship, including compliance obligations imposed through its acquiring or payment arrangements.
These can include matters such as:
Card-network operating requirements
Transaction monitoring
Payment-data controls
Refund and dispute processes
Merchant underwriting
Fraud controls related to its merchant relationship
Exactly which responsibilities sit with the MoR, PSP, acquirer and underlying supplier depends on the architecture and contract.
An MoR should therefore not be described as “taking over all payment regulation.”
It takes on the obligations associated with the role it actually occupies.
Refunds
The MoR may become responsible for processing customer refunds for transactions where it is the seller of record.
That can include:
Receiving the refund request
Validating refund eligibility according to agreed policies
Initiating the refund
Returning funds through the relevant payment method
Updating customer-facing records
Consumer law can affect refund and withdrawal rights independently of the payment contract. In the EU, for example, consumer rules impose pre-contract information requirements and rights relating to distance contracts, digital content and withdrawal, subject to applicable exceptions.
The underlying business may still need to provide the MoR with information necessary to determine whether a product or service was delivered correctly.
Chargebacks
Where the MoR sits in the acquiring relationship, chargebacks may arrive against the MoR's merchant account.
The MoR can therefore manage:
Dispute notifications
Evidence submission
Chargeback accounting
Payment-network deadlines
Customer-payment records
But the underlying supplier may still be contractually responsible for:
Supplying fulfillment evidence
Demonstrating customer authorization
Proving product delivery
Bearing some or all financial loss under the MoR agreement
“MoR handles chargebacks” therefore does not necessarily mean:
The underlying seller bears no chargeback responsibility.
The operational workflow and economic allocation are separate questions.
Customer-facing payment records
Because the MoR may be the customer-facing merchant, it can appear on:
Receipts
Payment statements
Invoices
Billing descriptors
Refund records
Payment confirmations
This should be explained clearly to customers.
Poorly designed MoR structures can create confusion when:
the customer thinks they bought from Brand A
but:
their payment statement references Company B.
Customer-facing communication therefore becomes part of the operating model, not merely a payments configuration detail.
Indirect tax collection and remittance
Tax is one of the most commercially important reasons companies evaluate an MoR.
Depending on the jurisdiction and supply structure, the entity treated as the supplier can be responsible for determining, collecting, reporting and remitting VAT, GST, sales tax or similar indirect taxes.
For digital services in the UK context, HMRC's guidance explains that certain digital platforms can be treated as the supplier to the consumer and therefore become responsible for accounting for VAT where the relevant legal criteria are satisfied. It also expressly distinguishes that role from merely providing payment processing.
EU VAT rules also contain “deemed supplier” concepts for particular platform-mediated supplies, and recent EU legislation continues to refine where electronic interfaces are treated as suppliers for VAT purposes. These rules are statutory tax constructs and should not be assumed to apply merely because a company commercially calls itself a Merchant of Record.
A properly structured MoR model may therefore reduce the underlying seller's direct indirect-tax registrations or collection obligations for covered transactions.
But the business must confirm:
Which countries are covered
Which products are covered
Whether the MoR is actually treated as supplier for tax
Whether the business retains corporate, income or other tax obligations
Whether local registrations remain necessary for other activities
Merchant of Record tax responsibility is transaction- and jurisdiction-specific, not a universal global exemption for the underlying business.
Certain fraud and risk responsibilities
The MoR may assume transaction-level fraud and payment-risk responsibilities because it is operating the merchant relationship.
That can include:
Payment fraud screening
Transaction risk rules
Chargeback exposure
Payment-method abuse
Merchant-account monitoring
But an MoR cannot necessarily detect or control every risk associated with the product.
The underlying business may retain responsibility for:
Account takeover within its own product
Product misuse
Abusive users
Fake content
Seller fraud in marketplace models
Fulfillment fraud
Intellectual-property violations
The relevant risk surface is larger than the payment itself.
Consumer-facing obligations
If the MoR is the trader or seller contracting with the consumer, it may assume obligations connected to the consumer transaction.
These can include, depending on applicable law:
Pre-contract information
Price disclosure
Customer receipts
Cancellation or withdrawal handling
Refunds
Complaints
Customer-service obligations
EU consumer law, for example, applies substantial information and withdrawal requirements to many consumer contracts and digital-content transactions.
But consumer responsibilities also depend on the product itself.
An MoR can manage the payment-facing customer relationship while the underlying seller remains responsible for whether the product:
Works
Is legal
Matches its description
Is delivered
Meets sector-specific rules
That division should be explicit.
What responsibilities can remain with the underlying seller?
This is where MoR marketing is most easily misunderstood.
A Merchant of Record can take on a substantial portion of transactional compliance without becoming legally responsible for everything the underlying company does.
Several responsibilities commonly remain wholly or partly with the underlying supplier.
Product legality
The supplier remains responsible for ensuring that the product or service it offers can legally be sold in the relevant market unless the contract and applicable law establish a different allocation.
An MoR does not make an illegal or prohibited product lawful.
Examples may include:
Regulated financial products
Gambling
Pharmaceuticals
Age-restricted goods
Digital content subject to local restrictions
Licensed professional services
The product's regulatory category must still be evaluated.
Product claims and advertising
Statements made by the underlying company about:
Features
Performance
Health outcomes
Financial outcomes
Pricing
Availability
can create legal obligations independently of payment processing.
An MoR normally cannot insulate the product company from liability for misleading product claims merely by becoming the transaction merchant.
Intellectual property
The underlying business generally remains responsible for having the rights required to distribute:
Software
Games
Images
Music
Video
Brands
Licensed content
The MoR can facilitate the sale.
It cannot manufacture intellectual-property rights the supplier does not possess.
Privacy and data protection
A Merchant of Record does not automatically become the only entity responsible for personal data.
Privacy obligations follow the actual processing activity and legal roles.
For example, under UK GDPR concepts, a controller remains responsible for its own compliance and for appropriately governing processors it uses; outsourcing processing does not automatically remove the controller's accountability.
An underlying business might independently determine purposes and means for processing:
Customer accounts
Product analytics
Marketing
Usage data
Support records
while the MoR processes customer/payment information for transaction execution.
The entities may therefore have separate or overlapping privacy roles depending on the data flow.
Sanctions and export restrictions
A business cannot assume that an MoR removes every sanctions or export-control obligation attached to its own conduct.
The U.S. Treasury's OFAC framework emphasizes risk-based sanctions compliance for organizations subject to U.S. jurisdiction and also highlights the role of business activities, customers, counterparties and geography in sanctions risk.
If the underlying company is independently:
Providing a prohibited service
Exporting controlled technology
Dealing with restricted parties
Operating in sanctioned markets
the payment structure alone does not necessarily eliminate that responsibility.
Sector-specific regulation
The MoR handles commerce.
It does not automatically become:
The gaming licensor
The healthcare provider
The financial adviser
The telecom operator
The education provider
The publisher
The employer
If the underlying product is regulated, those sector-specific obligations can remain with the underlying business.
Fulfillment and service delivery
The underlying business usually remains responsible for actually delivering:
Software access
Game content
Digital goods
SaaS functionality
Physical goods
Customer services
If fulfillment fails, the MoR may handle the consumer-facing refund.
But the product failure originated with the supplier.
That is why operational integration between the MoR and the underlying business matters.
Merchant of Record responsibility map
A useful way to evaluate the model is:
Area
MoR may assume
Underlying business may retain
Payment acceptance
Often substantial
Integration obligations
Acquiring
Often managed by MoR
Product/business underwriting information
Payment compliance
Often substantial for MoR merchant relationship
Product-specific controls
Refund processing
Often
Fulfillment facts/policy inputs
Chargebacks
Often operationally
Evidence and financial allocation
Customer payment records
Often
Product account records
Indirect tax
Can be substantial
Other tax obligations / uncovered markets
Fraud
Payment-transaction risk
Product/account abuse
Consumer obligations
Transaction-facing obligations may move
Product performance and claims
Privacy
MoR owns its processing responsibilities
Seller retains its own controller/processor responsibilities
Sanctions/export
Some screening may be performed
Seller's independent obligations can remain
Product legality
Limited
Usually core seller responsibility
IP
Limited
Core seller responsibility
Sector regulation
Limited unless separately structured
Often remains
Fulfillment
Usually not the underlying product operation
Usually remains with seller
This is not a universal legal allocation.
It is a diligence framework.
Merchant of Record vs PSP
The distinction is fundamental.
PSP
A Payment Service Provider typically helps the merchant:
Process transactions
Connect to acquiring
Accept payment methods
Tokenize payment credentials
Manage payment operations
The underlying business normally remains the seller.
Conceptually:
Customer
↓
Merchant / Seller
↓
PSP
Merchant of Record
The MoR typically occupies the customer-facing merchant position for covered transactions.
Customer
↓
Merchant of Record
↓
Underlying supplier
That can move obligations involving:
Payment acceptance
Customer transaction records
Indirect tax
Refunds
Chargebacks
Consumer transaction administration
in ways a conventional PSP relationship normally does not.
HMRC's digital-services guidance neatly demonstrates why the distinction matters: an entity whose role is only payment processing is treated differently from a platform that is legally considered to be making the consumer supply.
Merchant of Record vs payment facilitator
A payment facilitator generally operates within payment/acquiring infrastructure and can help onboard and process payments for sub-merchants.
That does not automatically make the payment facilitator the seller of the underlying products.
Its role is principally part of the payment-processing structure.
An MoR, by contrast, is defined commercially by becoming the merchant/seller for covered transactions.
The same company could potentially participate in several roles, but the concepts should not be conflated.
Merchant of Record vs reseller
An MoR is often implemented through a resale model, but reseller is a broader commercial concept.
A reseller purchases or takes rights to sell another party's products and resells them.
Some resellers are Merchants of Record.
Not every reseller necessarily provides the full payment, tax and regulatory operating layer associated with commercial MoR services.
The contract matters more than the label.
Merchant of Record vs marketplace payment provider
A marketplace payment provider helps a platform handle transactions among:
Buyers
The marketplace
Third-party sellers
but the underlying sellers may remain the legal suppliers to customers.
A Merchant of Record structure can instead position the MoR as the customer-facing seller for defined transactions.
This distinction matters because marketplace structures can trigger separate questions involving:
Seller onboarding
KYC/KYB
Third-party funds
Seller payouts
Platform tax reporting
Marketplace regulation
The separate article Marketplace Payment Licensing should own that regulatory analysis.
How an MoR can simplify international launches
International launch programs often slow down because the merchant must assemble several interdependent components before accepting the first transaction.
A direct launch can require some combination of:
Market analysis
↓
Entity / tax position
↓
PSP
↓
Acquirer
↓
Payment methods
↓
Tax registration
↓
Consumer terms
↓
Refund process
↓
Operational reporting
An MoR can consolidate part of that work.
Instead:
Underlying business
↓
MoR commercial / technical integration
↓
MoR's supported market infrastructure
That can reduce the number of separate payment, acquiring and indirect-tax relationships the underlying business establishes itself.
For digital services, official UK guidance provides a real regulatory example of how platform/supplier structure can affect which party accounts for VAT.
This is how an MoR can help with the larger Compliance Slows Launches problem.
It does not eliminate regulatory work.
It can concentrate specific responsibilities into an operating partner that already maintains relevant infrastructure and compliance processes.
Why MoR can improve launch speed
The commercial advantage is often organizational.
Instead of the merchant coordinating:
Local tax configuration
Payment acceptance
Acquiring
Refund processes
Consumer transaction administration
market by market, the MoR may provide those capabilities through one relationship for supported transactions.
That can shorten the merchant's own dependency chain.
But launch speed depends on the MoR accepting the merchant.
MoRs commonly conduct underwriting and diligence because they are accepting legal, payment and economic exposure.
A merchant should therefore expect questions about:
Product
Markets
Refunds
Fraud
Customer complaints
Fulfillment
Subscription practices
Regulatory status
An MoR model replaces some launch dependencies with a different dependency:
The merchant must fit within the MoR's risk, product, country and contractual framework.
What Merchant of Record does not solve
An MoR is not a universal compliance wrapper.
It does not automatically solve:
Product licensing
A regulated product can remain regulated.
Privacy
The underlying company still has obligations for the personal data it controls or processes.
Sanctions/export control
Independent obligations can continue to apply to the supplier's conduct.
Intellectual property
The company still needs the legal right to sell what it offers.
Fulfillment
Someone still needs to deliver the service or product.
Sector-specific regulation
Gaming, finance, healthcare, telecom and other sectors can have additional legal regimes.
Corporate regulation
An MoR does not automatically eliminate every local corporate, employment, tax or registration requirement created by the company's wider presence in a market.
All consumer risk
The MoR can manage transaction-facing consumer obligations, while product-quality and product-performance responsibilities may remain elsewhere.
Every country
MoR coverage is limited by the provider's own legal, product, acquiring and risk footprint.
Economics and other MoR trade-offs
An MoR can simplify operations because it assumes more responsibility.
That normally means the merchant is purchasing more than payment processing.
Evaluate the trade-offs deliberately.
Economics
The MoR's commercial price may incorporate functions that the merchant would otherwise operate separately, such as:
Payment processing
Tax administration
Acquiring
Fraud
Chargebacks
Refund operations
Customer transaction support
Compare the total operating model, not merely the PSP transaction rate.
Control
The merchant may surrender some control over:
Acquiring
Routing
Payment configuration
Refund operations
Tax logic
Customer-facing transaction policy
A merchant with a sophisticated internal payments organization may value control more than a merchant whose priority is launch simplicity.
Supported markets and products
The MoR decides which:
Markets
Product categories
Payment methods
Business models
it is prepared to support.
A global expansion strategy cannot assume universal MoR coverage.
Underwriting
Because the MoR assumes meaningful exposure, it can impose:
Product restrictions
Reserves
Payout terms
Refund requirements
Chargeback limits
Compliance requirements
Monitoring
The merchant should treat underwriting criteria as part of product-market feasibility.
Data and customer relationship
The MoR may receive important customer and payment data.
Evaluate:
Which party controls which data
What the merchant can export
What analytics remain available
How customer support works
Data-retention obligations
Exit/migration processes
Privacy roles should be established from actual processing rather than presumed from the MoR label.
Contractual dependency
The MoR can become a critical market-access dependency.
Before relying on one, understand:
Termination rights
Data portability
Post-termination refunds
Chargebacks
Historical records
Tax records
Customer communication
Stored credentials
Transition obligations
The easier an operating model is to enter, the more important it can be to understand how to exit.
When businesses consider an MoR model
An MoR can be particularly attractive when the merchant's constraint is the overhead of creating a direct commercial/payment operating model in every market.
Examples include businesses with:
SaaS subscriptions
Digital content
Games
Software
Online services
International consumer sales
especially where international expansion would otherwise require substantial tax, payment, acquiring and transaction-compliance infrastructure.
It can also be useful when:
The company wants to test markets before establishing a heavier local operating model
Internal tax/payment operations are small
The merchant wants one commercial interface for many countries
Expansion speed matters more than maximum payment-stack control
It may be less attractive when:
The merchant requires extensive acquiring control
Payment economics justify building direct infrastructure
Product coverage is incompatible
A marketplace requires a different regulated flow
Customer ownership or data architecture conflicts with the MoR model
The business needs infrastructure the MoR cannot support
There is no universally “better” model.
The question is which obligations the business wants to own directly.
A Merchant of Record responsibility framework
Before signing an MoR agreement, create a responsibility matrix.
Responsibility
MoR
Underlying business
Shared / needs clarification
Customer contract
Payment acceptance
Acquiring
Card/payment compliance
Indirect tax determination
Tax collection
Tax remittance
Customer receipt/invoice
Refund processing
Chargebacks
Fraud
Consumer complaints
Subscription cancellation
Product fulfillment
Product legality
Product claims
Intellectual property
Privacy
Sanctions
Export controls
Sector regulation
Customer support
Data retention
Regulatory reporting
Do not accept:
“We handle compliance.”
as the answer.
Require the allocation to be explicit.
Key questions to ask a Merchant of Record
Before using an MoR to enter a new country, ask:
Who is legally identified as the seller to the customer?
Which entity accepts payment?
Which entity owns the acquiring relationship?
Which taxes does the MoR calculate, collect and remit?
For which products and countries?
Who issues invoices or receipts?
Who handles refunds?
Who receives and defends chargebacks?
Who bears chargeback loss?
Which consumer-protection obligations does the MoR assume?
Which remain with us?
What fraud responsibilities does the MoR own?
What sanctions screening does it conduct?
What sanctions/export duties remain with us?
Who is controller or processor for each major data flow?
Which product categories are prohibited?
What underwriting conditions apply?
What data can we retrieve or export?
What happens when the agreement ends?
How are historical refunds, disputes and tax records handled after termination?
These questions turn “Merchant of Record” from a vendor category into a launch architecture.
Key takeaways
A Merchant of Record can materially reduce the complexity of international payment launches because it can centralize important responsibilities associated with the customer transaction.
Depending on the legal and contractual structure, the MoR can assume significant responsibility for:
Payment acceptance
Acquiring
Customer transaction records
Payment compliance
Refunds
Chargebacks
Indirect tax
Payment fraud
Consumer-facing transaction administration
That can allow the underlying business to launch in supported markets without rebuilding the same payment and tax operating model country by country.
But the boundary matters.
The underlying seller may still remain responsible for:
Product legality
Fulfillment
Product claims
Intellectual property
Privacy obligations
Sanctions/export compliance
Sector-specific regulation
Other tax or corporate obligations outside the MoR transaction
That is why Merchant of Record should not be evaluated as:
Compliance outsourced.
A more accurate description is:
Responsibilities reallocated.
The commercial advantage comes from deciding which responsibilities are more efficiently centralized with an MoR and which responsibilities necessarily remain with the business that creates, delivers and operates the product.
For a company trying to prevent compliance from unnecessarily slowing an international launch, that distinction is decisive.
A well-designed MoR model can shorten the number of regulatory, payment, tax and operational relationships the merchant must establish directly.
A poorly understood MoR model can create the opposite problem: the company launches quickly while assuming that obligations disappeared when they merely moved, remained shared, or never transferred at all.
The final diligence question should therefore be:
For every material obligation created by this transaction, which entity is responsible—and what legal, contractual and operational evidence supports that answer?
That is the standard that makes a Merchant of Record model useful for global expansion rather than merely convenient at checkout.
This article provides general information and does not constitute legal, tax, regulatory, accounting, privacy, sanctions, export-control or compliance advice. Merchant of Record structures, tax treatment, consumer obligations, payment regulation, privacy roles and other requirements vary by jurisdiction, product, transaction structure and contract. Businesses should confirm their specific position with qualified legal, tax and regulatory advisers and relevant payment providers or authorities before launch.
FAQ
What regulatory responsibilities does a Merchant of Record take on?
A Merchant of Record can assume significant responsibilities connected to the customer transaction, including payment acceptance, acquiring, refunds, chargebacks, customer-facing payment records, indirect tax and certain consumer and fraud obligations. The exact allocation depends on the contract, transaction structure, product and jurisdiction.
Does a Merchant of Record handle all compliance?
No. An MoR can take over substantial transaction-related compliance, but responsibilities involving product legality, intellectual property, privacy, sanctions, export controls, fulfillment and sector-specific regulation can remain with the underlying business.
Is a Merchant of Record the same as a payment processor?
No. A PSP primarily provides payment-processing infrastructure while the underlying merchant remains the seller. An MoR typically becomes the customer-facing merchant or seller for covered transactions and therefore can assume broader commercial, tax and consumer responsibilities.
Does a Merchant of Record remove the need for payment licensing?
Not necessarily. An MoR structure can reduce the underlying business's direct payment-regulatory burden where the MoR and its regulated payment partners perform the relevant payment activities. Whether the underlying company needs any authorization still depends on what it actually does, particularly whether it handles funds or provides regulated services independently.
Does a Merchant of Record collect and remit tax?
Many MoR models are designed to assume indirect-tax responsibilities for covered transactions, but tax treatment depends on the jurisdiction and legal supply structure. Businesses should verify exactly which taxes, countries and product categories the MoR covers.
Who handles refunds and chargebacks with a Merchant of Record?
The MoR often handles the payment-side refund and chargeback workflow where it is the merchant in the acquiring relationship. The underlying seller may still need to provide transaction or fulfillment evidence and may bear some financial responsibility under the MoR contract.
Is a Merchant of Record responsible for GDPR or privacy compliance?
Only for the data-processing activities for which it has the applicable legal role. The underlying business can remain independently responsible for customer accounts, analytics, marketing and product data. Privacy responsibilities must be mapped to the actual processing activity.
Can using a Merchant of Record speed up international expansion?
It can. An MoR can consolidate payment acceptance, acquiring, tax and other transaction responsibilities across markets it already supports, reducing the number of direct relationships the merchant must establish. But onboarding, underwriting, product eligibility and remaining local legal requirements can still affect launch timing.
🙂 🙂 🙂 🙂 🙂 🙂 🙂
Recommended title
Merchant of Record Regulatory Responsibilities: Who Is Responsible for What?
Merchant of Record Regulatory Responsibilities Explained
Meta description
Learn which regulatory, payment, tax, consumer, fraud, refund, chargeback, privacy, and product responsibilities a Merchant of Record may assume—and which obligations can remain with the underlying seller.
URL slug
/merchant-of-record-regulatory-responsibilities/
Merchant of Record regulatory responsibilities
Secondary keywords
Merchant of Record compliance
MoR responsibilities
Merchant of Record regulation
Merchant of Record legal responsibilities
MoR payments compliance
Merchant of Record tax responsibilities
Merchant of Record vs PSP
Merchant of Record consumer protection
Merchant of Record payment compliance
Search intent
Informational / commercial investigation.
The reader is trying to determine whether a Merchant of Record structure can reduce the regulatory and operational burden of launching internationally, and which obligations would actually transfer to the MoR versus remain with the underlying business. The editorial brief correctly centers the answer on allocation of responsibilities rather than the simplistic idea that an MoR “handles compliance.”
ARTICLE
Suggested internal links
Does a Merchant Need a Payments Licence?
Use when explaining that the underlying seller may not need the same payment authorization as an entity providing payment services to third parties.
Cross-Border Payment Regulations
Use when discussing how buyer, seller, MoR, acquirer and bank locations can change regulatory analysis.
Consumer Protection Requirements
Use from the customer-contract, refund and withdrawal sections.
Regulatory Requirements by Market
Use when explaining that MoR obligations and coverage must be validated country by country.
Marketplace Payment Licensing
Use from the MoR-versus-marketplace section.
Payment Licensing Explained
Use when distinguishing the commercial merchant role from regulated payment-service activities.
Suggested anchor text
when a merchant may need its own payment licence
how cross-border payment rules change by market
consumer-protection requirements for international payment flows
checking payment regulation market by market
when marketplace payment flows can create licensing issues
how payment licensing depends on the activity being performed
Recommended authoritative external sources
HMRC — VAT rules for digital services
HMRC's official digital-services guidance is particularly useful because it distinguishes between an entity that merely processes payments and a digital platform treated as making the supply to the customer. It also explains when the platform can become responsible for accounting for VAT on consumer digital-service sales.
Use it as a UK tax example, not a universal definition of Merchant of Record.
European Union — VAT deemed-supplier rules
Current EU legislation contains deemed-supplier regimes for specified electronic-interface transactions. Recent legislation continues to refine those rules in defined sectors and transaction types.
Use to demonstrate that “who is the supplier?” can be a statutory tax determination rather than merely a contractual label.
European Commission / EUR-Lex — consumer rights
The Consumer Rights Directive establishes information, cancellation and other consumer-contract rights for covered EU consumer transactions, including digital-content and distance-contract contexts.
Use when discussing why the entity contracting with the customer may acquire substantive consumer obligations.
ICO — controller and processor responsibilities
Current ICO guidance explains that outsourcing processing does not extinguish a controller's responsibility for its own compliance and governance of processors.
This is useful authoritative evidence for the article's central limitation:
commercial outsourcing does not automatically outsource every independent legal responsibility.
U.S. Treasury OFAC
OFAC's compliance framework emphasizes risk-based sanctions compliance based on the organization's business, customers, counterparties and geographic exposure.
Use narrowly when explaining why an MoR cannot necessarily absorb sanctions obligations associated with the underlying supplier's own conduct.
Optional visual and diagram opportunities
Merchant of Record Responsibility Map
CUSTOMER
|
v
MERCHANT OF RECORD
┌───────────────────┼───────────────────┐
v v v
Payments Tax Consumer
Acquiring VAT/GST etc. Transaction
Refunds handling
Chargebacks
|
v
UNDERLYING BUSINESS
┌──────────────┼───────────────┐
v v v
Product Privacy / Fulfillment
legality product data
IP
Sector rules
Sanctions/
export where applicable
Caption: Merchant of Record changes the allocation of transaction responsibilities, but obligations connected to the underlying product and business can remain with the supplier.
Alt text: Merchant of Record responsibility map showing payment, tax and consumer transaction responsibilities potentially handled by the MoR and product, privacy, intellectual property, sanctions, sector regulation and fulfillment responsibilities remaining with the underlying seller.
MoR vs PSP
STANDARD PSP MODEL
Customer
↓
Merchant / Seller
↓
PSP
↓
Acquirer
MERCHANT OF RECORD MODEL
Customer
↓
Merchant of Record
↓
Payment / acquiring infrastructure
↓
Underlying supplier relationship
Add underneath:
PSP: processes the merchant's payments.
MoR: can become the merchant/seller for the covered transaction.
Responsibility Matrix
A two-column or three-column editorial graphic:
Responsibility
Usually evaluated at MoR
Usually evaluated at supplier
Payment acceptance
✓
Acquiring
✓
Indirect tax
✓ / depends
✓ / uncovered obligations
Refunds
✓
Input/evidence
Chargebacks
✓
Evidence/economic allocation
Product legality
✓
Privacy
Shared by actual roles
Shared by actual roles
IP
✓
Sector regulation
✓
Fulfillment
✓
Use “depends” prominently rather than visually implying universal legal allocation.
Direct Expansion vs Merchant of Record
DIRECT MODEL
Market 1 → PSP → Acquirer → Tax → Consumer process
Market 2 → PSP → Acquirer → Tax → Consumer process
Market 3 → PSP → Acquirer → Tax → Consumer process
MoR MODEL
Underlying business
↓
MoR
┌───┼───┐
v v v
Mkt1 Mkt2 Mkt3
Caption: An MoR can reduce the number of payment and transaction-compliance relationships a merchant manages directly, while product and business obligations can remain outside the MoR layer.
SEO / EDITORIAL NOTES
The article should avoid competing with Payment Licensing Explained or Does a Merchant Need a Payments Licence? by keeping licensing analysis subordinate to the responsibility-allocation question.
The strongest SEO differentiator is the explicit distinction between:
responsibilities the MoR can assume
and:
responsibilities that remain with the underlying business.
Most generic Merchant of Record content describes benefits such as tax, payments and compliance. This article should win by explaining the boundary of that promise.
A strong featured-snippet passage is:
A Merchant of Record can assume significant transaction-related responsibilities such as payment acceptance, acquiring, refunds, chargebacks, indirect tax and certain consumer obligations. However, the underlying seller can remain responsible for product legality, intellectual property, privacy, sanctions, sector-specific regulation and fulfillment. The exact allocation depends on the contract, jurisdiction and transaction structure.
Recommended related entities to include naturally:
Merchant of Record
payment service provider
acquirer
indirect tax
VAT
GST
consumer protection
chargebacks
refunds
payment compliance
data controller
sanctions
seller
reseller
marketplace
deemed supplier
acquiring
payment licensing
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗