Introduction
In modern e-commerce – and especially in digital payment processing – a fundamental misunderstanding persists:
The terms Merchant of Record (MoR) and Aggregator model (Sub-Merchant structure) are often used interchangeably. Yet in practice, they differ in critical and non-trivial ways.
Both models involve the processing of payments on behalf of third parties, but they are fundamentally distinct when it comes to liability, data ownership, contract structure, and regulatory classification.
This distinction becomes especially important when working with payment providers or acquirers, as a wrong assumption about the underlying model can lead to compliance violations, KYC conflicts, or even data protection breaches.
📌 Note: We’ve published a detailed article on the Merchant of Record model, including its advantages and use cases:
What exactly is a Merchant of Record?
This article focuses on the Aggregator model and how it compares to MoR – because while the two may seem similar on the surface, they are fundamentally different at their core.
What is an Aggregator Model (Sub-Merchant Structure)?
An Aggregator model – also referred to as a Sub-Merchant structure – describes a setup in which multiple individual providers (sub-merchants) process payments through a centralized platform (the aggregator).
This model is especially common in platform-based and marketplace environments, such as ticketing systems, ride-sharing apps, or booking and service intermediaries.
In this structure, the sub-merchant – not the aggregator – is the legal seller to the end customer. The aggregator merely facilitates the transaction and acts as a technical or commercial payment service provider.
Key characteristics of an Aggregator model
Typical examples include
In this model, the sub-merchant is legally autonomous and bears their own risk. Therefore, they are subject to full KYC and AML verification when the platform processes funds on their behalf.
Direct Comparison: Merchant of Record vs. Aggregator Model
The table can be moved left and right by touch.
Criteria | Merchant of Record (MoR) | Aggregator Model (Sub-Merchant) |
Contractual party of the customer | MoR (e.g. NETFIELD) | Sub-Merchant (e.g. creator, vendor) |
Name on customer’s statement | Name of the MoR | Name of the Sub-Merchant or Aggregator |
Liability to end customer | MoR bears full legal and financial responsibility | Sub-Merchant liable; aggregator acts as intermediary |
Payment reception | Funds received directly by the MoR | Funds received by aggregator, then forwarded to sub-merchant |
Acquirer contract | MoR has a direct agreement with the acquirer | Aggregator contracts with acquirer; sub-merchants are onboarded |
KYC requirement for providers (e.g. creators) | ❌ Not required at acquirer level – MoR assumes responsibility | ✅ Full KYC required by the aggregator |
Tax & compliance obligations | Fully handled by the MoR | Handled by sub-merchants, sometimes assisted by aggregator |
Control over content & transactions | MoR manages pricing, offers, and checkout | Aggregator only processes payments; content is managed by sub-merchants |
Typical use cases | Digital platforms with their own MoR structure (e.g. NETFIELD) | Marketplaces, ticketing services, app stores |
📌 This table makes one thing clear:
MoR and Aggregator models may look similar – but they are fundamentally different in structure, liability, and regulatory responsibility.