When MoR Stops Making Sense: The Qualitative Thresholds

The decision to move off a Merchant of Record is almost never clean. There is no revenue number that triggers it, no milestone that makes it obviously correct, and no clean before-and-after. The companies that handle it well treat it as a portfolio of qualitative signals that arrive at different times — not as a single decision point — and plan the migration 6-12 months before execution begins.

The companies that handle it badly decide on a revenue heuristic (“we’re past $X ARR so we should own this”), initiate a migration without understanding the subscription re-authorisation cost, and find themselves 18 months into a partial migration that has cost more than the MoR premium would have cost for two more years.

This piece covers the five qualitative triggers that actually drive MoR outgrowth, the false alarms that don’t, the migration arc, and why most companies land on a hybrid rather than a full cutover.

The Five Real Triggers

1. Enterprise B2B Customer Mix

The clearest operational signal that a PSP direct arrangement is needed: your enterprise customers’ accounts-payable teams expect to see invoices issued by your company, not by a third-party MoR.

Enterprise B2B procurement follows a specific invoice workflow. The AP team has a vendor record in their ERP for your company. Invoices must match the purchase order, show your entity as the seller, and often reference a specific vendor ID or contract number. When the invoice shows “Paddle.com” or a similar MoR name as the seller — even with your brand mentioned — it does not match their vendor record. The result: payment delays, AP team enquiries, occasional requests for credit notes and re-invoicing, and for some regulated-industry buyers, outright inability to process a payment to a different legal entity than contracted.

Net-term billing (net-30, net-60, milestone-based invoicing) further compounds this. Most MoRs don’t accommodate net-term billing natively — they collect payment at point of sale. Enterprise contracts with deferred payment terms require direct invoicing relationships that the MoR model structurally cannot support.

If enterprise B2B represents a growing share of your revenue mix, the MoR constraint will surface in the sales cycle before it shows up in the finance numbers. Sales reps encounter AP friction; deals that should close in a quarter slip into the next because the payment workflow doesn’t fit. This is the trigger that causes the most urgency because it has a direct revenue impact.

2. Compliance Team Maturity

The MoR’s core value is absorbing compliance and tax liability that the seller would otherwise carry. When the seller builds the internal capability to carry that liability themselves, the MoR premium becomes a premium for services now duplicated internally.

The trigger is not a hire — it is when the combination of internal finance/legal headcount, tax-automation tooling, and external advisors creates a compliance capability cheaper than the MoR premium. For digital goods sellers with concentrated markets (70%+ of revenue from 5 or fewer jurisdictions), direct registration and an EU OSS filing may be the entire compliance stack in those markets. Add a US sales tax automation provider for post-Wayfair economic nexus, and the per-year cost of the direct-PSP compliance stack may be materially below the MoR premium on the same GMV.

The counter-consideration: compliance team maturity is fragile. A company that migrated to direct PSP on the strength of a specific head of finance who then leaves has to decide whether the migration economics still hold with a different team. The MoR’s value does not go to zero when internal capability grows; it goes to zero when internal capability is both cheaper and resilient.

3. Market Concentration

MoRs earn their compliance value by handling many jurisdictions simultaneously. If your revenue is highly concentrated in a small number of markets — say, 80% from the US, UK, and EU — the compliance value of a global MoR footprint is not fully utilised.

In concentrated markets, direct PSP plus targeted registrations may cover the actual obligation at lower cost:

• EU: EU OSS covers EU B2C digital goods in one quarterly filing
• UK: Single HMRC VAT registration for UK digital services
• US: Economic nexus triggers in specific states; automated via tax-automation tooling (Avalara, TaxJar, Anrok); each state registration is a fixed overhead, not proportional to volume
• Australia: ATO registration for imported digital services above the A$75,000 threshold
• India: OIDAR registration with GST authorities for digital services to Indian consumers
• Japan: NTA registration for cross-border digital services subject to JCT

Each registration is independently manageable. The operational overhead of six registrations and six annual or quarterly filing obligations, handled via tax-automation tooling, may be genuinely cheaper than the MoR premium on a concentrated GMV base. When market concentration is high and GMV is sufficient to fund the compliance stack, the economics favour migration.

4. Payment Method Coverage Gap

MoR providers add local payment method support incrementally, and they do not all add the same methods at the same time. If a specific payment method is critical to your business in a specific market — Pix in Brazil, UPI in India, iDEAL in the Netherlands, BLIK in Poland — and the MoR does not support it, the constraint is structural.

A MoR that does not support the dominant payment method in your largest market is a cap on conversion in that market. This is a harder limit than pricing: no amount of MoR premium negotiation resolves a missing payment method. Direct PSP processing in that market, combined with a separate local acquiring or aggregator relationship, may be the only path to full conversion coverage.

This trigger often presents first as a conversion rate discrepancy: transactions in a specific market underperform expectations, customers report their preferred payment method is unavailable, or the payment step abandonment rate in a market is materially above the average. Diagnosing payment method coverage gaps should be a standard part of market performance review, not just a migration-time consideration.

5. Data and Customer Ownership Limits

In a MoR arrangement, the legal seller is the MoR — and the customer relationship, for billing purposes, is with the MoR. Access to customer billing data, payment method details, and transaction history may be constrained by what the MoR exposes via API and what its standard agreement permits.

This creates practical limits for marketing, customer success, and product teams:

• Lifecycle email tied to billing events (upcoming renewals, failed payments, expiry warnings) may be managed by the MoR, not by the seller’s own email infrastructure
• Payment method data is not portable to a different MoR or direct PSP without customer re-authorisation
• Customer purchase history and lifetime value may live in the MoR’s data model rather than the seller’s own data warehouse
• Subscription modification (mid-cycle upgrades, promotional discounts, one-off credits) may require the MoR’s UI or API rather than the seller’s internal tools

These limits tend to surface gradually, as the marketing or product team hits a wall trying to build a capability the MoR’s data access doesn’t support. The trigger is usually not a single blocker but an accumulating friction: workarounds built on top of workarounds until the cost of the limitations exceeds the cost of migration.

False Alarms

Revenue milestones. A company reaching a specific ARR figure does not trigger MoR outgrowth unless the compliance economics simultaneously tip. Many mature software companies with significant scale continue to use MoR because their market mix, customer archetype, and internal compliance capability make it the right call at their scale.

Competitor behaviour. If a peer company announces it migrated off MoR, it reveals nothing about your situation. Their customer mix, market concentration, compliance team, and payment method requirements may be entirely different. Migrations driven primarily by competitive benchmarking rather than internal economics frequently underdeliver on expected savings.

Dissatisfaction with MoR service quality. If the issue is bad developer experience, slow support, or a specific product limitation, evaluating a different MoR (see provider comparison) is usually a lower-cost intervention than full migration to direct PSP.

The Migration Arc

Once the triggers are real and the decision is made, the migration is a 6-12 month project. Treating it as a shorter project almost always produces a rougher outcome.

Months 1-3: registration and infrastructure. Tax registrations initiated in target jurisdictions — EU OSS, UK HMRC, US state registrations via tax automation, and any other markets in scope. Legal entity confirmation: who is the new seller of record? New PSP or acquirer contracted and integrated. New billing and subscription management system selected (if the MoR was the billing layer). Invoice templates and numbering sequences established.

Months 3-6: parallel operation. New customers onboarded directly to the new stack. Existing customers remain on MoR. This parallel phase tests the new stack under real conditions before the re-authorisation campaign begins. Chargeback management processes established and tested with real volume.

Months 6-12: subscriber migration. Re-authorisation campaign for existing subscribers. The campaign design matters significantly for the churn outcome: clear communication of the change, simple re-authorisation flow, appropriate notification timing (typically 30-60 days before the transition), and a support path for subscribers who have questions. Expect a subset of subscribers not to complete re-authorisation — plan for this in the migration economics model.

Post-migration: MoR retained for some scope. This is the typical landing point. The full migration to direct PSP often resolves to direct PSP for primary markets and the B2B segment, with MoR retained for markets where the compliance overhead of direct registration is not yet cost-effective or where a payment method gap exists on the direct PSP side. This hybrid is not a failure of the migration; it is usually the economically correct outcome.

The Reverse Case: Moving Back

Companies migrate back to MoR more often than is publicly discussed. The most common trigger: rapid new-market expansion outpacing the compliance team’s capacity to register and file in each new jurisdiction. A company that migrated to direct PSP for its established markets may find, when it expands into ten new countries in 18 months, that direct registration in each new market is slower and more expensive than using MoR for the new-market cohort.

The resulting state is typically: direct PSP for established markets where scale justifies the compliance infrastructure; MoR for new markets as an entry mechanism, with migration to direct PSP planned once the market reaches a threshold that justifies the registration overhead.

Treating MoR as the permanent entry-point and direct PSP as the established-market state — rather than making a binary choice — is how most mature operators run their payment stack after the first few migration cycles. It is not an admission that the first migration was wrong; it is a recognition that the right tool changes as the market changes.

The Decision Checklist

Before initiating any migration off MoR, validate:

1. Is enterprise B2B a current or near-term majority of revenue? If yes, direct PSP for the B2B segment is a near-term operational necessity.
2. What is the all-in cost of the compliance stack in your actual market set? Count registrations, filings, headcount, and tooling — not the theoretical global compliance burden.
3. Does the MoR support every critical payment method in every material market? A coverage gap that cannot be bridged within the MoR makes the migration argument for that market straightforward.
4. What is the re-authorisation churn estimate? Model conservatively — a 10-15% subscriber drop in the migration cohort is a common outcome in migrations that are not well-designed.
5. Does the new stack require a net-new compliance capability that is not yet in place? The migration should not precede the registration; the registration must precede the first sale under the new arrangement.
6. What is the hybrid landing? Almost no migration ends in full MoR elimination; plan the hybrid from the start rather than discovering it during the migration.

The MoR decision — whether to use it, which one to use, and when to outgrow it — is one of the most consequential infrastructure choices a digital software company makes. The companies that navigate it well treat it as a dynamic portfolio decision, not a one-time vendor selection.