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

  • The sub-merchant (e.g. seller, creator) is the direct legal counterparty to the customer.
  • The aggregator handles payment processing for multiple sub-merchants simultaneously.
  • The sub-merchant’s name often appears (but not always) on the customer’s payment receipt.
  • The aggregator is required to collect, verify, and store KYC data for all participating sub-merchants.
  • The model carries stricter requirements regarding identity verification and risk evaluation, especially in relation to acquirer compliance.

Typical examples include

  • Online marketplaces with multiple independent sellers
  • Ticketing platforms processing third-party events
  • Aggregated service portals with individualized billing

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.