Merchant of Record is the broadest business model in this set because the MoR becomes the commercial counterparty for the end-customer transaction. The model can simplify market access for underlying sellers, while shifting substantial payment and financial operations to the MoR.
What this business model means
This page explains Merchant of Record in plain English: who the legal seller is, what the MoR typically manages, a practical SaaS example, how MoR differs from PayFac, and why the model requires strong reconciliation and financial operations.
What is a Merchant of Record?
A Merchant of Record (MoR) is the company that legally sells a product or service to the end customer in its own name and takes responsibility for the commercial transaction. From the customer’s legal transaction perspective, the MoR is the seller — not merely the company that processes the card payment.
MoR provides the highest level of commercial transaction control among these business models.
The model requires strong ledger, reconciliation, refund, dispute, fee, settlement, and reporting operations.
Multi-provider orchestration helps an MoR manage geography, resilience, payment methods, and processor economics without fragmenting financial truth.
Why companies use a Merchant of Record model
For software, digital goods, marketplaces, and cross-border businesses, an MoR can centralize the commercial transaction and reduce payment complexity for underlying sellers or business units.
The trade-off is greater responsibility: the MoR must maintain a reliable record of what was sold, what was paid, what fees were applied, what was refunded or disputed, and what amounts are ultimately owed to each party.
Merchant of Record (MoR)
A Merchant of Record is the legal or commercial seller in the end-customer transaction. Depending on the contractual model and jurisdiction, it can be responsible for payment acceptance, transaction taxes, refunds, chargebacks, financial records, and other obligations associated with the sale.
Think of a MoR as the company that steps into the sale as the seller.
A PSP helps you accept a payment. A Merchant of Record goes further: the MoR becomes the seller for the transaction and handles a broader set of commercial and payment responsibilities on behalf of the underlying software company or supplier.
A software company sells a €100 subscription to a customer in Germany
Without a MoR, the software company sells directly to the customer and remains responsible for the commercial transaction. With a MoR model, the Merchant of Record sells the subscription to the customer, collects the €100, manages the responsibilities defined in the arrangement, and later settles the contractual proceeds to the software company.
What does a Merchant of Record actually do?
- Payment acceptance for the sale
- Applicable transaction tax operations
- Refunds, disputes, and chargebacks
- Transaction records, reconciliation, and settlement
- Product or service delivery
- Product roadmap and customer value
- Commercial relationship with the MoR
- Support responsibilities defined by the agreement
Exact responsibilities depend on contracts, geography, acquiring arrangements, and the services included in the operating model.
Merchant of Record vs PayFac
The platform enables sub-merchants to accept payments and manages a broader payment operating layer. The sub-merchant remains the seller to its customer.
The key concept is enabling and operating payments for merchants.The MoR itself becomes the seller for the end-customer transaction and assumes a broader commercial role.
The key concept is ownership of the sale, not just payment processing.Why this matters for Amaryllis: Because the MoR sits inside the commercial transaction, it must reconcile more than a payment status. Sales, taxes, processor fees, refunds, chargebacks, adjustments, settlements, and amounts owed to underlying suppliers all have to resolve to one financial truth.
The MoR needs one financial source of truth
Because the MoR sits between the buyer, payment providers, and underlying sellers, transaction events cannot be reconciled in isolation. Amaryllis provides a control layer that can connect provider activity with ledger records, fees, adjustments, refunds, and downstream settlement.
One control layer across payment models.
Centralize merchant operations, routing, transaction records, reconciliation, and payouts while keeping underlying providers flexible.
A practical operating path
Accept the end-customer transaction under the MoR commercial relationship.
Connect payment events, processor fees, refunds, disputes, and adjustments to a unified ledger.
Calculate balances, reporting, and downstream settlement obligations to underlying parties.
When this model fits
An MoR structure should be evaluated as an operating model, not merely a payments integration. Leadership must assess commercial ownership, geographic scope, customer support, refunds and disputes, tax and regulatory responsibilities, treasury, reconciliation, provider strategy, and the level of control required over downstream settlement.
Questions decision-makers ask
What is the difference between Merchant of Record and PayFac?
A PayFac enables and manages sub-merchants within a sponsored acquiring structure, while a Merchant of Record is itself the commercial seller for the end-customer transaction. The two models therefore carry different commercial and operational responsibilities.
Does an MoR need payment orchestration?
Not always, but orchestration becomes valuable when the MoR operates across multiple providers, geographies, currencies, or payment methods. It centralizes routing and operational control while keeping provider-specific complexity below the business layer.
Why is reconciliation especially important for MoR operations?
The MoR must connect customer payments with fees, refunds, disputes, processor settlements, internal ledger entries, and amounts owed to underlying parties. Reconciliation provides the traceability required to explain each balance and movement of funds.
Capabilities that support this model
Reviewed for payment architecture clarity
Payments strategy, architecture, and operations.
Reviewed for technical and operational consistency.
Update when product, market, or regulatory context changes.