Merchant of Record and token portability: why your MRR stays yours?

Most businesses evaluate a Merchant of Record on the questions that are easy to compare: the headline fee, the countries covered, the tax obligations absorbed. Almost nobody asks the question that determines what happens the day they want to leave.

Who owns the payment tokens?

When a customer saves a card with you, the card number itself is never stored on your systems. It is replaced by a token, held by whoever is legally the merchant on that transaction. Under a MoR arrangement, that is the MoR, not you.

The consequence only becomes visible at the exit. If those tokens cannot move to your next provider, every active subscriber has to re-enter their card details to keep their subscription alive. In practice, a meaningful share of them never does. They ignore the email, the renewal fails, and the subscription lapses without any decision being made.

Estimates of the damage vary by business model, but the range commonly cited across the industry sits between 20 and 40% of MRR. For a subscription business, that is not a migration cost. It is a reason never to migrate at all.

Which is precisely what makes it worth examining before you sign rather than after.

Token portability is the ability to have your stored payment credentials transferred to another compliant provider, under a documented process, without forcing your customers to act. Where it exists, switching MoR is an operational project. Where it does not, your provider holds a structural lever over your pricing negotiations, your service expectations and your roadmap.

Three things determine which situation you are in.

The contractual position. Whether portability is written into the agreement, or merely described as possible by a salesperson.

The technical architecture. Network tokenization and PCI-compliant transfer mechanisms make portability feasible; proprietary vaults make it a negotiation.

The adjacent data. Tokens alone are not enough. Customer records, billing history and subscription states have to travel with them, or you arrive at the new provider with cards you cannot attach to anything.

This article walks through how token lock-in actually works, what it costs, and what to verify before committing your recurring revenue to any provider.

What Is a Payment Token, and Who Owns It?

A payment token is a substitute value that stands in for a card number.

When a customer saves a card, the Primary Account Number is not stored on your servers. It is sent to a PCI-compliant environment and replaced by a string that is useless to anyone who intercepts it. That string is what your system keeps and what gets charged on every renewal. This is what makes recurring billing possible without turning your database into a liability.

There are two distinct families of tokens, and the difference matters enormously for portability.

Processor tokens are proprietary. They are created and stored in the vault of your payment provider, and they are meaningful only within that provider’s environment. Outside it, the string references nothing.

Network tokens are issued by the card networks themselves, Visa and Mastercard, through their tokenization services. They carry a real advantage beyond security: when a customer’s card is reissued after expiry, loss or theft, the network token updates automatically. Involuntary churn from expired cards drops, often significantly.

But a network token is provisioned to a specific token requestor. If your provider is the registered requestor, the token is bound to their identifier, not to your business.

This is where the Merchant of Record model introduces a layer that a standard payment processor does not.

With a conventional PSP, you remain the legal merchant. The cardholder agreed to be charged by you. Migrating your vault to another PCI Level 1 provider is a documented, routine operation, and processors perform these transfers regularly.

Under a MoR arrangement, the MoR is the legal seller on every transaction. Your customer consented to recurring charges from that entity, not from yours. The mandate, the tokens and the cardholder relationship all sit with the MoR by design, which is exactly the point of the model and exactly what creates the exit problem.

That is not inherently a flaw. Transferring legal and fiscal liability is why businesses choose a MoR in the first place.

The question is whether that transfer is reversible.

Some providers treat portability as a contractual commitment with a defined process. Others treat it as a commercial lever, where the answer depends on how your renewal conversation is going.

InflowPay ships network tokenization as standard and keeps customer data portable, so the tokens serving your recurring revenue remain usable beyond the relationship.

What Token Lock-In Actually Costs You

The cost is rarely a line item. It shows up as revenue that quietly fails to renew, and as decisions you stop being able to make.

Start with the direct loss. If your tokens cannot move, every active subscriber must re-enter card details to continue. That request arrives by email, competing with everything else in their inbox, and asking them to reconsider a subscription they had stopped thinking about. A share of them simply never act.

Run the arithmetic on a business at $200,000 MRR. A 30% failure to re-authenticate removes $60,000 of monthly recurring revenue, or $720,000 annualized. That is the cost of a migration decision, before counting a single hour of engineering time.

The second cost is the one most teams underestimate. Those customers were already paid for. Their acquisition cost was spent months or years ago, and the return on that spend comes from retention. Losing them at migration does not just remove future revenue: it retroactively destroys the economics of the campaigns that acquired them, and replacing them means paying CAC a second time for customers you already had.

The third cost never appears in any model, because it is a cost of inaction.

A provider holding your tokens knows you cannot leave cheaply. That knowledge sits in the room during every renewal conversation. Fee increases become difficult to contest. Degraded support becomes something you absorb. A feature you need and they will not build becomes a constraint on your roadmap rather than a reason to switch.

You are not paying a fee at that point. You are paying for the absence of alternatives.

The fourth cost surfaces at the worst possible moment: due diligence.

An acquirer or an investor examining a subscription business looks closely at the durability of its recurring revenue. A revenue base that cannot be moved without destroying a third of itself is structurally weaker than one that can. It signals dependency on a third party whose pricing, risk appetite and continuity are outside your control. Buyers price that in, and they price it in on the multiple rather than on a single line.

The underlying point is simple. Token lock-in does not cost you when you leave. It costs you every month you stay for the wrong reason.

InflowPay keeps customer data portable precisely so that staying remains a commercial decision rather than a technical obligation.

How to Verify Token Portability Before You Sign?

Portability is easy to promise in a sales call and hard to produce under contract. These are the checks that separate the two.

1. Ask for the clause, not the answer. Request the specific contractual language covering what happens to stored payment credentials on termination. If portability exists, it is written down. If the response is that it has never been a problem, you already have your answer.
2. Identify the token requestor. Network tokens are provisioned to a registered identifier. Ask which entity holds it on your traffic, and what becomes of those tokens if the relationship ends. A provider unable to answer this clearly has not thought about your exit, which tells you how it will go.
3. Check the vault architecture. Proprietary processor tokens are meaningless outside the environment that issued them. Network tokenization, by contrast, is built on infrastructure the card networks own rather than your provider. Ask which one sits behind your recurring charges.
4. Confirm what travels alongside the tokens. Credentials alone are useless. Customer records, subscription states, billing history, renewal dates and consent records all have to move together, or you arrive at your next provider holding cards you cannot attach to anything.
5. Establish the destination requirements. Transfers happen between PCI DSS Level 1 environments under a documented process. Ask which providers your current one has already transferred to, and whether the process is standard or negotiated case by case.
6. Pin down the timeline and the format. A commitment to portability with no stated delay is not a commitment. Ask how long a full transfer takes, in what format data is delivered, and who bears the cost.
7. Read the exit terms for hostage clauses. Extended notice periods, termination penalties and data retention fees achieve the same result as token lock-in through contractual means rather than technical ones.
8. Ask for a reference who left. This is the single most revealing question of the list. A provider confident in its process can name a merchant who migrated away cleanly. One that cannot is telling you something it will never put in writing.

Run these eight checks before signing and the conversation changes entirely. You stop evaluating a provider on what it charges, and start evaluating it on what it costs to stop using.

InflowPay answers all eight in writing, because an infrastructure partner should retain clients on performance rather than on exit friction.

Conclusion

Token portability is not a technical detail buried in an appendix. It is the clause that determines whether your recurring revenue belongs to your business or to your provider.

The mechanism is straightforward once you see it. Your subscribers’ stored cards are the asset that makes MRR recurring. If those credentials cannot move, your revenue cannot move either, and every commercial conversation with your provider happens on their terms rather than yours.

What makes this worth examining early is that the cost never appears when you expect it. You do not pay at the moment of migration. You pay every month you remain with a provider whose pricing has drifted, whose support has slipped or whose roadmap has diverged from yours, because leaving would cost a third of your revenue base.

That is a strategic constraint disguised as an operational one.

None of this is an argument against the Merchant of Record model. Transferring legal and fiscal liability on cross-border transactions remains one of the highest-leverage infrastructure decisions a digital business can make. VAT determination, remittance, invoicing and chargeback liability are genuine burdens, and handing them to a specialist is sound.

The argument is for choosing a MoR that treats your data as yours.

Ask the eight questions before you sign. Get the answers in writing. And treat any reluctance to document the exit process as information about what the relationship will look like in three years.

InflowPay was built on that premise: portable customer data, network tokenization as standard, multi-acquirer routing rather than single-bank dependency, and no contractual friction engineered into the exit.

Your MRR should stay yours, whoever processes it.

Start today at inflowpay.com.