Merchant of Record vs. Non-MOR: How Agentic Commerce Changes the Decision

Broadly speaking we can say that a Merchant of Record (MoR) is the entity in charge of the purchase transaction: it’s the party that actually takes a consumer’s payment information, runs it across the payments ecosystem and accepts payment. Merchants of Record are legally recognized as the seller, with their name appearing on the consumer’s credit card statement.

Depending on whose statistics you choose to buy into, the e-commerce market alone is now worth at least $4T per year. And as that number grows, there’s a new wrinkle to the industry: agentic commerce, where agents, not just human shoppers, discover, initiate, and complete purchases on behalf of a consumer.

AI is becoming a fundamental feature of consumers’ worlds, and as it does so, agents are rapidly becoming the buyers of the future. While larger modern companies act as their own MOR, there are also options to use platforms like Paddle or Fastspring, which take on the role of Merchant of Record. This results in the merchant effectively receiving processed orders for distribution without having to worry about the actual transaction complexities.

On the other hand, it also means they lose a lot of control over the checkout process, not to mention the option to collect and track consumer information and activity over time.

To be clear, contracting with a full-service payment services provider (PSP) like Stripe does not create a non-MOR environment: the company using those PSP services generally remains the MOR and simply outsources the more complex elements of the transaction process.

That said, even the PSPs are forming or acquiring non-MOR platforms in order to offer low-impact solutions to, generally, digital merchants: essentially, instead of the platform being the intermediary to move money between buyer and seller, it actually purchases the good from the merchant and instantly resells it to the consumer.

How does agentic commerce impact Merchant of Record models? 

The rise of agentic commerce has added a layer of complexity to the decision on whether to consider a non-MOR model because the interaction between merchant and consumer is different when an agent actually makes the purchase. There are two fundamental ways in which agentic commerce occurs:

1. Consumer led. The agent finds the goods to be purchased and the consumer makes the purchase; this is the lion’s share of all activity today. Because consumers generally are not quite ready to tell AI to just take their credit card and go buy whatever they think is right, there is still a heavy ‘Human in the Loop’ element to the process.
2. Agent-led. Decisions and actions are deferred or triggered to an agent. The trigger tells the AI to go make a purchase on their behalf, and effectively accepts the result. While this is a vanishingly small proportion of the volume today, the industry expectation is that it will grow.

There are very different technical needs to support the two types of commerce, and they may drive the need to consider whether remaining the Merchant of Record is preferable.

Return to Top

What does consumer-led agentic commerce need? 

When the consumer is going to make the final decision, and, likely complete the actual order on their own, the two most important elements are:

1. Easy API or MCP access for agents to be able to rapidly discover what they need in order to make an appropriate recommendation to the user.
2. Human-friendly checkout processes and interfaces to ensure the sale recommended by the agent is reliably completed.

Because the actual purchase is human-initiated, nothing really changes here at the point of purchase. It still makes sense to build a reliable, human-friendly interface that also tracks consumer activity and loyalty. It also means that ownership of the consumer data should absolutely remain with the merchant, as they will be relying upon easy access in order to facilitate subscription payments and subsequent purchases.

Unless a merchant has already selected, for whatever reason, a non-MOR strategy, it makes limited sense to shift gears.

Return to Top

What does agent-led agentic commerce need? 

Once it is the agent initiating the purchase, the requirements change substantially. Not only does the merchant need to have the API/MCP access to ensure the agent can see enough detail to select the right goods or services, they must now open up their checkout process to be agent-usable.

And because an agent is simply a sophisticated piece of code, building human-friendly interfaces is far less important than efficiency: the agent expects a simple API that simply gets the job done.

However, because the agent may come from anywhere, and may want to use one of a growing number of possible protocols to make the purchase, the complexities of providing the right interface compound. Chief among the challenges is ensuring that opening up the payment system to agentic purchasing does not put payment information in jeopardy

Or, at least, that it does not become the responsibility of the merchant.

While the agentic system that the consumer has entrusted with their cardholder data of necessity can see the details in plain text, the merchant must ensure that their interfaces move the information securely through their systems, preferably without bringing the whole payment system into PCI-DSS scope.

Return to Top

How can a payment vault support MOR agentic commerce? 

Merchants today using multiple payment providers to process their transactions ensure they own their own customer data, arbitrage processing fees, and have the flexibility to adjust their roster of partners at will. As agentic commerce becomes more common, this structure is certain to grow in popularity, as the risks of plain-text payment data flowing through an agentically enabled payment system increase.

Allowing that PCI-covered information to rattle around inside a home-grown payments decisioning engine could very well bring the whole system into scope, and open the merchant up to hacks and data leaks.

A well-conceived payment system that uses a programmable payment vault to manage its payment data should be able to ensure that its API and MCP endpoints sequester sensitive payment data and route it through the endpoints of the vault. Essentially, when a purchase request is made, the agentic system should.

• Check whether this is a returning customer whose payment details are already stored in the vault; if it is, it can direct the agent not to provide any data, but confirm the use of the existing details.
• If this is a new customer, the merchant agent can direct the agent to deliver its secure payload directly to the vault, receive the token, and pass that to the payments system
• Submit the transaction to the selected downstream payment gateway using the token, having therefore never touched the plaintext cardholder data.

The key will be in creating API and MCP endpoints that provide no way to pass payment data through, but rather clearly communicate upfront to the vault endpoint that it should be directed to.

As agents proliferate, and customers become more comfortable with allowing them to make purchasing decisions, merchants who intend to retain the Merchant of Record position must guard against allowing plaintext credit card data from being pushed into their systems.

Integrating a programmable token vault into the API and MCP interfaces ensures that all requests made by agents are properly routed, reducing the risk of data leaks and expanding PCI scope. This makes the option of moving agentic commerce to a non-MOR platform (with its disadvantages of lost data ownership, higher costs, and unpredictable revenue flow) one that can be confidently rejected.

Return to Top