Merchant of record · aggregator · orchestration

Merchant of record services — three postures, one orchestration platform underneath.

topropay is a payment aggregation and orchestration platform — not a tax-and-legal Merchant of Record. What it does is sit underneath every MoR posture that matters: the aggregator sub-merchant model, dedicated MoR partners like Paddle or FastSpring, and merchants running their own MoR entity.

Book a MoR-fit review Read the API docs
A

Aggregator MoR

Partner acquirer = MoR · sub-merchant fronts brand

B

MoR-partner-backed

Paddle · LemonSqueezy · FastSpring  + topropay routing

C

Merchant-owned MoR

Merchant's own entity · topropay orchestration layer

Three MoR postures · one orchestration platform underneath.
Aggregator
Sub-merchant model — payment-side MoR sits with the licensed partner acquirer
MoR partner
topropay orchestration underneath dedicated MoR providers for SaaS and digital goods
Merchant-owned
The merchant's own entity is MoR; topropay is the payment orchestration layer

What Merchant of Record actually means

The three responsibilities that define merchant of record services

Merchant of Record is a specific role with three responsibilities — payment liability, tax handling, buyer-facing invoicing. Not every payment platform fills all three; being honest about which is which matters.

  1. Payment liability

    Whoever is MoR takes on chargeback liability, refund obligations and settlement into their own bank account before paying the seller. In an aggregator model this sits with the licensed partner acquirer holding the master MID; in a merchant-owned model it sits with the merchant's own entity.

  2. Tax collection & remittance

    The MoR calculates, collects and remits VAT, GST and sales tax to the relevant tax authorities per buyer geography. topropay is NOT a tax-and-legal MoR — full tax collection sits with a dedicated MoR provider (Paddle, LemonSqueezy, FastSpring, Cleverbridge, Digital River) or with the merchant's own entity.

  3. Buyer-facing invoicing

    The MoR is the entity named on the buyer's invoice, statement descriptor and receipts. In an aggregator setup the sub-merchant's brand still fronts the checkout, but statement descriptors carry the aggregator's DBA per scheme rules.

Key benefits

Why merchants pair topropay with merchant of record providers

Four properties that show up when the payment platform stays in its lane (orchestration) and lets the tax-and-legal MoR live where it belongs.

  1. Aggregator sub-merchant path

    topropay's licensed partner acquirers can hold the master MID and onboard the merchant as a sub-merchant. The merchant doesn't need to hold their own MID; the aggregator is the payment-side MoR into which cardholder funds flow before payout.

  2. Orchestration underneath a dedicated MoR partner

    SaaS and digital-goods merchants running with a dedicated MoR provider (Paddle, LemonSqueezy, FastSpring, Cleverbridge, Digital River) can use topropay for the underlying payment orchestration — multi-acquirer routing, vault, reconciliation.

  3. Payment orchestration for merchant-owned MoR

    Merchants operating their own MoR entity — with their own tax registrations and their own invoicing — plug topropay in as the orchestration layer. Payment authorisation, routing, vault, dispute queue and settlement sit with topropay; MoR status is the merchant's.

  4. Honest scope — payments, not tax

    topropay does not calculate, collect or remit VAT / GST / sales tax and is not the buyer-facing tax entity. That's what dedicated MoR providers exist for. Where a merchant needs true MoR, topropay pairs with the MoR partner rather than pretending to fill the role.

How merchant of record solutions plug in

From onboarding to settlement in four steps

The onboarding flow scopes to whichever of the three MoR postures fits — aggregator, MoR-partner-backed, or merchant-owned. The steps below apply across all three.

  1. 01

    Identify the MoR posture

    During onboarding, the merchant declares which of the three models applies — aggregator sub-merchant, MoR-partner-backed, or merchant-owned MoR. Underwriting scopes to the chosen model.

  2. 02

    Configure the platform accordingly

    For the aggregator path, the merchant onboards as a sub-merchant on a topropay partner acquirer's master MID. For MoR-partner or merchant-owned paths, the merchant's own MID / MoR-partner MID is connected as a routing lane.

  3. 03

    Route, capture, settle

    Authorisations run through topropay's routing engine; the vault tokenises card data; settlement flows to whichever entity is MoR — the aggregator's partner acquirer, the MoR provider, or the merchant's own MID.

  4. 04

    Reconcile & reconcile again

    Reconciliation splits are model-specific: aggregator payout minus platform fees for sub-merchants, MoR-partner payout minus MoR fees, or direct-settle for merchant-owned. All variants land in one topropay ledger tagged per model.

Main use cases

Where merchant of record platforms and topropay orchestration fit

Six merchant shapes across the three MoR postures — SaaS, digital goods, aggregator sub-merchants, merchant-owned MoR at scale, marketplaces and regulated verticals.

  • SaaS

    SaaS running MoR-partner + topropay

    SaaS uses Paddle / LemonSqueezy / FastSpring as tax-and-legal MoR; topropay handles the underlying multi-acquirer orchestration when the merchant scales beyond the MoR partner's default rails.

  • Digital

    Digital goods on dedicated MoR

    Downloadable software, courses, games, digital templates — MoR provider handles VAT / GST across regions; topropay is the routing engine behind card acceptance.

  • Sub

    Sub-merchant aggregator setup

    Merchants without their own MID onboard as sub-merchants on a topropay partner acquirer's master MID. The partner acquirer is payment-side MoR; the sub-merchant fronts the checkout in their brand.

  • Own

    Merchant-owned MoR at scale

    Larger merchants with their own tax registrations, VAT numbers and invoicing entities run topropay as the orchestration layer; MoR status stays with the merchant.

  • MP

    Marketplaces with per-seller MoR mix

    Marketplaces where different sellers have different MoR postures — some sub-merchants, some MoR-partner-backed, some direct — route through topropay with per-seller reconciliation.

  • Reg

    Regulated verticals with mixed MoR

    Licensed gaming, regulated fintech and other compliance-bound verticals with their own operator licences typically run merchant-owned MoR with topropay orchestration underneath rather than aggregator MoR.

Platform features

Capabilities behind the merchant of record payment processor role

Twelve capabilities grouped into aggregator / sub-merchant, MoR-partner integration and merchant-owned MoR — each cluster shows what topropay handles inside that model.

Aggregator / sub-merchant capabilities

  • Sub-merchant onboarding

    Onboard sub-merchants under a licensed partner acquirer's master MID; underwriting done through the platform.

  • Sub-merchant reconciliation

    Payouts to sub-merchants minus platform fees; per-sub-merchant ledger and payout schedule.

  • Scheme-compliant descriptors

    Statement descriptors follow scheme rules for aggregators (DBA plus sub-merchant identifier).

  • Per-sub-merchant risk controls

    Velocity rules and dispute queues scoped per sub-merchant; aggregator-level programme monitoring on top.

MoR-partner integration

  • Orchestration underneath MoR

    topropay routes card authorisations across acquirers underneath dedicated MoR provider integrations.

  • Vault portability

    PCI L1 vault tokens usable across MoR-partner-side and topropay-side flows without re-vaulting.

  • Unified dispute queue

    Chargebacks from MoR-partner-side receipts surface in the same queue as direct-settle receipts.

  • Reconciliation splits per model

    Ledger rows tagged with MoR-partner ID and settlement path per receipt.

Merchant-owned MoR support

  • Direct-MID routing

    The merchant's own MID on each connected acquirer surfaces as a routing lane.

  • Per-entity settlement

    Settlement into the merchant's own bank account per acquirer, per currency.

  • Own-brand statement descriptors

    Descriptors carry the merchant's own DBA — no aggregator-imposed override.

  • Own-entity dispute defence

    Dispute evidence-pack templates in the merchant's own name and invoice numbering.

Trust & compliance

Compliance posture across every MoR model

One audited environment underpins the orchestration layer; MoR-specific scheme registration and tax handling stay with whichever entity is MoR in each model.

PCI DSS Level 1
Vault and tokenisation posture inherited by every merchant regardless of MoR model — aggregator, MoR-partner-backed or merchant-owned.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per master MID and per sub-merchant where relevant.
Aggregator scheme registration
Where the aggregator sub-merchant model is used, the partner acquirer's scheme registration and payment aggregator programme rules apply.
Sanctions & AML alignment
Sanctions screening at onboarding for every merchant and sub-merchant; AML monitoring tuned per vertical, volume and MoR model.
Honest tax scope
topropay is NOT the buyer-facing tax entity. VAT / GST / sales tax calculation, collection and remittance sit with the merchant's chosen MoR provider or the merchant's own entity.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of MoR model.

Ready to pick the MoR posture

Pair the right MoR posture with the right payment orchestration.

A 30-minute MoR-fit review covers your buyer geographies, existing tax posture and MID situation — and maps them to the aggregator / MoR-partner / merchant-owned path that fits, followed by a sandbox on topropay's orchestration underneath.

Book a MoR-fit review Read the API docs

Frequently asked

Buyer questions about merchant of record services on topropay

Definitions, scope boundaries, when to pick each MoR posture, tax scope, chargeback liability and the migration path from aggregator to merchant-owned MoR.

  1. 01

    Does topropay provide merchant of record services directly?

    topropay is a payment aggregation and orchestration platform, not a tax-and-legal Merchant of Record. What topropay provides adjacent to merchant of record services is: (a) the aggregator / sub-merchant model where the licensed partner acquirer is the payment-side MoR, and (b) the payment orchestration underneath merchants running their own MoR entity or partnered with dedicated MoR providers.

  2. 02

    Which merchant of record companies does topropay work with?

    topropay pairs with the established merchant of record companies for SaaS and digital goods — Paddle, LemonSqueezy, FastSpring, Cleverbridge and Digital River are the common ones — as the payment orchestration layer underneath their tax-and-legal MoR wrapping. Which specific MoR provider a merchant picks depends on their buyer geographies, product mix and pricing model.

  3. 03

    How do merchant of record providers differ from payment aggregators like topropay?

    Merchant of record providers take on the tax-and-legal role — they're the entity named on the buyer's invoice, they calculate and remit VAT / GST / sales tax, and they carry the seller-side liability. Payment aggregators like topropay handle the payment-side orchestration — routing, vault, reconciliation — under the master MID. In an aggregator model, the aggregator's licensed partner acquirer is payment-side MoR but doesn't do buyer-facing tax.

  4. 04

    What merchant of record solutions are actually available on topropay?

    Merchant of record solutions on topropay are three: (a) aggregator sub-merchant model where topropay's licensed partner acquirer holds the master MID and is payment-side MoR, (b) topropay as orchestration underneath a dedicated MoR provider, and (c) topropay as orchestration for a merchant operating their own MoR entity. Onboarding scopes to whichever model applies.

  5. 05

    Is topropay a good merchant of record for saas?

    For SaaS specifically, merchant of record for saas is most often best served by a dedicated MoR provider (Paddle, LemonSqueezy, FastSpring) because SaaS sells globally and needs digital-services VAT / GST calculation across dozens of tax jurisdictions. topropay is not that provider — but topropay is a good fit as the payment orchestration layer underneath the MoR provider, or as the direct-MID processor for larger SaaS merchants running their own MoR entity at scale.

  6. 06

    Could topropay be described as a merchant of record payment processor?

    In the aggregator model, topropay functions as a merchant of record payment processor for its sub-merchants — the licensed partner acquirer is the payment-side MoR and topropay is the technical processor / orchestrator. In the merchant-owned or MoR-partner models, topropay is a payment processor but not the MoR — the merchant's own entity or the MoR partner fills that role.

  7. 07

    How do merchant of record platforms compare to using topropay directly?

    Merchant of record platforms (Paddle, LemonSqueezy, FastSpring et al.) bundle payment acceptance, tax handling and buyer-facing invoicing into a single service — convenient at smaller scale but with a per-transaction cost premium over direct processing. Using topropay directly gives finer control over routing, vault ownership and reconciliation for merchants that already have their own tax posture in place.

  8. 08

    Does topropay handle merchant of record payment processing at scale?

    Yes — merchant of record payment processing at scale works through topropay's multi-acquirer routing engine, PCI L1 vault, unified dispute queue and one reconciliation feed. Whether the MoR is the aggregator's partner acquirer, a dedicated MoR provider, or the merchant's own entity, the platform-side processing capabilities are identical.

  9. 09

    What are the trade-offs of the aggregator sub-merchant MoR model on topropay?

    The aggregator sub-merchant model trades speed-to-live and no-MID-required onboarding against tighter scheme programme rules (aggregator merchants share the master MID's dispute programme posture), less flexibility on statement descriptors, and a shared underwriting envelope. For merchants who need their own tax registration and their own invoicing entity, the merchant-owned model is the right fit instead.

  10. 10

    Can a merchant move from aggregator MoR to merchant-owned MoR later?

    Yes. Merchants routinely start on the aggregator sub-merchant model for speed-to-live, then migrate to a merchant-owned MoR with their own MID as volume, geography and tax requirements grow. Because topropay's vault and integration surface is the same in both models, the migration is a routing-policy change and a new MID connection rather than a full re-integration.

  11. 11

    Does topropay collect VAT, GST or sales tax on behalf of merchants?

    No. topropay does not calculate, collect or remit VAT, GST or sales tax. Tax-and-legal MoR responsibilities sit with the merchant's chosen MoR provider (for MoR-partner-backed setups) or with the merchant's own entity (for merchant-owned MoR). topropay is a payment orchestration platform, not a tax service.

  12. 12

    Who is responsible for chargebacks under each MoR model?

    Under aggregator MoR the licensed partner acquirer carries the primary chargeback liability with contractual recourse against the sub-merchant. Under merchant-owned MoR the merchant's own entity carries the liability directly. Under MoR-partner-backed setups the MoR provider carries the buyer-facing liability with recourse against the seller per their contract. topropay's dispute queue surfaces the workflow across all three.

  13. 13

    What's the fit for high-risk verticals?

    High-risk verticals (licensed gaming, regulated fintech, subscription models with elevated chargeback rates) are usually a poor fit for aggregator sub-merchant MoR because the master MID's dispute programme posture doesn't tolerate elevated ratios well. Merchant-owned MoR with dedicated high-risk acquirers, orchestrated through topropay, is the more common posture.

  14. 14

    Are grey-market or unlicensed operators supported under any MoR model?

    No. topropay does not onboard grey-market or unlicensed operators regardless of MoR model. Licensed gaming, regulated financial services and other compliance-bound verticals are supported only where current operating licences exist. Underwriting filters unlicensed activity at onboarding.

  15. 15

    How does the topropay onboarding process choose the MoR model?

    Onboarding starts with the merchant declaring their existing tax posture and whether they hold their own MIDs. If they don't hold their own MIDs and are comfortable with the aggregator posture, sub-merchant MoR applies. If they run their own MoR entity, the direct-MID model applies. If they use a dedicated MoR partner, topropay integrates underneath that partner. The choice is captured in the underwriting record.

Related

Related on the topropay platform