Payment Orchestration for Agentic Commerce
Background
Agentic commerce is gaining serious traction in the payments space. It’s making headlines, featured in payment provider announcements, and at nearly every merchant event we’ve attended.
It refers to a new paradigm in online buying and selling, where AI-powered agents act autonomously on behalf of users (both consumers and businesses) to discover, compare, negotiate, and ultimately purchase products or services.
Essentially, the dream is that you can task an “AI Agent” to go shopping for you, find the best price, check stock availability, and then make that purchase on your behalf. Of course, like all things AI, we tend to focus on worst-case scenarios where an uncontrolled agent drains your bank account or makes unwanted purchases. Still, for everyday purchases, this could make our lives easier by removing mundane tasks or even saving us time on market research, allowing us to make quicker decisions about what to buy and where.
Like all technology, this raises the question of how it will work. We have seen several announcements from organizations such as Visa, Mastercard, PayPal, and Stripe regarding payment processes. Still, one core component has so far been overlooked: the merchants who ultimately sell the products and bear the cost of this commerce.
At Gr4vy, we are on a mission to empower our clients to own their payment strategy. In our view, that includes how agentic commerce will interact with their payment systems, without limiting the choices they can make around payment and anti-fraud suppliers, and without locking them into another walled garden. Therefore, we have developed our vision for an orchestrated agentic commerce payment process and built a solution that is currently in alpha and is on its way to Beta for deployment. Let’s begin by identifying some of the problems we aim to solve.
The Problem/s
Not all Payment systems will be the same
We have seen several announcements from Visa and Mastercard about their vision of agentic commerce, as well as from PayPal and Stripe. A common theme is that they do not share the same vision or processes and mainly focus on how the AI platform will communicate with them, rather than how merchants can accept payments. It’s clear that they are different and will likely use separate mechanisms or even technologies to enable agentic commerce. Unfortunately, as usual, this pushes the problem onto the merchant and feels like a quick flashback to the early days of internet payments, which still cause issues today when it comes to multiple integrations and are essentially part of what orchestrators aim to solve. We recommend not repeating the same mistakes, and if a standard can’t be agreed upon, then it’s necessary to simplify managing multiple payment mechanisms by outsourcing it to an orchestrator like Gr4vy or reverting to relying on a single PSP.
Are you an Agent or a Bot?
When viewed from an anti-fraud perspective, agents resemble a Bot because they essentially are, and merchants are already dealing with an influx of AI-driven fraud attacks. They must deploy their own AI tools to stay competitive in the ongoing arms race against card-not-present fraud. As a result, most commerce agents will be blocked by anti-fraud systems today, and they should be, since there is currently no reliable way to distinguish them.
Permissioning and Authentication
For Agentic commerce to function without significant fraud, every part of the process must be authenticated with each other. The payment company needs to identify the agent, and the consumer must have permitted the agent to make payments on their behalf, as well as inform the payment company that they have granted this permission. The merchant must authenticate the agent, and the merchant needs to have approved the agent to transact. The consumer must prove to the merchant that they have authorized the agent to make purchases on their behalf. Finally, the merchant needs to authenticate themselves to the agent, confirming they are indeed the merchant.
Merchant Fraud and Pretenders
There has been a significant rise in fake e-commerce shops over the past few years, and unfortunately, some social media platforms appear to be unconcerned about impostors posting counterfeit ads that pretend to be branded e-commerce sites, to steal financial information and deceive consumers. This situation worsens with agentic, as a fraudster could set up multiple detectable fake shops to trap agents and ultimately scam consumers and financial institutions. Typing in “buy me a Nintendo Switch” could lead to numerous fake deals that seem too good to be true. Without intuition or a registry of verified merchants, an agent won’t be able to distinguish what is real from what is fake, increasing the risk of making the wrong decision.
Regulation and PCI
I hope someone is thinking about this? Unfortunately, this usually happens after the problems occur, and deciding who is responsible in the event of a fraud at any stage in the process is often a few years behind the technology. Sadly, the buck in the meantime will mostly fall on the merchant, and there are no rules yet on what happens in the case of fraud. Therefore, we recommend that merchants start slowly and in a controlled manner, until it’s clear who is responsible and how this could affect their overall business. Increased chargebacks will raise your costs across all channels and, in the worst case, could lead to losing your merchant accounts and being unable to trade at all. So, for now, consider including the potential losses in your cost of experimentation.
Where should this sit
A question we’ve been wrestling with is where the solution should sit to keep merchants independent and empowered to control their strategy. Our opinion, on whether it should be a PSP solution versus an agnostic orchestrator’s solution is clear, but more importantly, should it sit at the payment stage or the shopping cart stage in the commerce process? If it sits in the shopping cart, then you’re locked into the shopping cart provider, or you build your own. If it sits at the payment stage, then the solution needs to understand inventory and have a way to notify the cart/ERP/backend of a completed order. We sit at the payment layer, so, of course, that’s what we’ve built. However, a great solution would be having the payment layer and shopping layer working in tandem.
The Gr4vy Solution
The Gr4vy solution we are currently testing and improving involves deploying an MCP server within the Gr4vy instance of a merchant. For those who don’t know, Gr4vy operates differently from other orchestrators and payment solutions in that we deploy single-tenant instances of Gr4vy for our clients. This includes multiple servers such as frontend servers, databases, and more. This approach enables us to deploy an MCP server for each merchant instance, offering several advantages over a shared solution, which will be discussed below. However, it currently limits the use of the system by AI platforms, as some notable players do not utilize MCP.
What are MCP Servers?
Gemini defines an MCP as:
“MCP is a standard framework that defines how AI systems can interact with external tools, services, and data sources. Instead of having to create custom integrations for every service, MCP defines the basics of how they should interoperate, how requests are structured, what features are available, and how they can be discovered. It enables developers to easily and reliably build secure, two-way connections between AI tools and external data sources, apps, and other services.”
The way we like to look at it is that an MCP is the equivalent of a front-end, but for agents rather than humans. This MCP will serve as an integration layer between the agents and agentic payment systems, as well as the Gr4vy Orchestration Layer. Our merchants today are already using Gr4vy Embed (hosted checkout), Secure Fields (hosted fileds), or our SDK/API to communicate from their website to our Orchestration Layer, or they use our payment links in their call centres or invoicing products. This Gr4vy MCP will do the same for Agents.
The Agentic Shopping Layer
The first layer to address is the Agentic Shopping Layer, which we define as the layer that enables an AI agent to communicate with the Wallet Layer, the Buyer, and the Merchants Layer (whether or not it utilizes an orchestrator). This layer has been extensively discussed, and various examples of how it could work have been proposed by Visa, Mastercard, Stripe, PayPal, and others. For this Alpha, we used Anthropic’s “Claude” and implemented operational transactions between a dummy wallet, our Merchant MCP Server, and the orchestration layers. The video of the working Alpha demo can be viewed here.
The MCP servers need to be registered as a Claude extension today to be discoverable by the agent. For the demo, we registered several different MCPs to simulate a real shopping scenario where multiple merchants sell the same product. Therefore, searching for “Aloe Vera” will display the shops or stores that have this product in stock.
Inventory Management
This is one of the more challenging aspects from a design perspective, as the merchants’ inventory management systems manage inventory data in most merchant environments. This data could be supplied by the shopping cart software or be part of an ERP system. Naturally, this means shopping cart providers will need to start developing agentic commerce tools, as has already been widely suspected due to the partnership between Shopify and OpenAI. However, having this at the shopping cart level implies that shopping carts must evolve into payment companies or orchestrators to handle the variety of payment mechanisms, and to send data in the correct format to Payment Service Providers (PSPs) and Acquirers.
Our solution was to create a bridge layer in our MCP server that allows merchants to either periodically upload inventory and stock information or, in the future, enable a two-way data pipeline between the merchant’s inventory system and the Gr4vy MCP server. The limitation of the demo’s periodic upload system is the lag between uploads, which may cause items that are shown as in stock to become unavailable between updates.
This also requires that the merchant can process a webhook (for demo purposes) or expose an API to handle a paid order after a successful transaction. This is necessary because the order occurs in isolation on the Gr4vy MCP and will only be committed to the merchant’s Order Management system once the webhook has been received.
The Wallet Layer
The Wallet layer is where buyer’s payment credentials are stored. This could be at the Banking Level supported by the Card Schemes, as seen in recent announcements. In this case, the Agentic Shopping Layer will communicate with a Card Scheme with the buyer’s permission and be given a token that can be used to make a purchase. Although details are limited, this is expected to be a Card Scheme Network Token, and there may be differences between the card schemes in terms of formats and data sent, which we believe will be handled by the Agentic Orchestration Layer.
The Wallet could also be one of the existing options, such as PayPal, Apple Pay, Google Pay, or PIX in Brazil. We fully expect these wallets to provide some form of token to facilitate the payment.
Due to the lack of workable public solutions today, we decided to build our version of a wallet for the demo. One advantage of using Gr4vy as an orchestrator is its Vaulting solution, which can store and take payment methods and return a token to our clients. This means you can tokenize not only cards but any other payment method that allows recurring payments. We used this feature to create our demo wallet, enabling a buyer to add their payment methods securely and verify them. The wallet can generate a one-time token or have the Agentic Shopping Layer request a token that the buyer authorizes using Multi-Factor Authentication (MFA). We also believe consumers will want to use Agentic carefully, so we added the ability to limit the amount that can be spent with a token, as well as enable buyers to add additional layers of MFA.
The Agentic Orchestrator Layer
The Agentic Orchestration Layer can identify which payment method the Buyer’s Agent is using, whether it’s a card-specific Network Token or another type of token. This layer should be able to process this payment method, format it, and send it to the backend Orchestration Layer, which then forwards it to the appropriate Payment Processor. Currently, this process is wrapped in a Gr4vy MCP, but since some AI platforms, like OpenAI, don’t support MCP, this layer will need to expand to communicate using the standards these platforms utilize and correctly orchestrate the payment methods. In our demo, we are using an MCP and a token generated by the Wallet described earlier. The design also allows us to accept either a Network Token or any other brand-specific token.
This Agentic Orchestration Layer communicates with the Gr4vy backend Orchestration Layer to complete transactions, allowing the merchant to route payments to their preferred providers, perform anti-fraud operations, and seamlessly integrate these agentic payments into their routine reporting and operations.
Backend Orchestration
As discussed earlier, it is very important to be able to identify agentic transactions so they can be managed thoughtfully. In our Alpha, we mark all these transactions as coming from and being initiated by an agent before passing them to the Gr4vy Backend Orchestration Layer. This unlocks the full potential of the Gr4vy Flow rules engine (our workflow automation tool). Transactions marked as agentic can then be identified and routed through a custom set of rules, or even sent to separate processes or tools that handle ecommerce transactions. For example, you might opt to use a more agentic forward anti-fraud provider for these transactions instead of the one you typically use for ecommerce transactions. You could also set limits on the amount processed by an agent or decide to process agentic transactions through a different PSP or acquirer than usual. We believe this approach will allow merchants to gradually adapt and learn what works best for them regarding agentic payments while minimizing exposure to fraud or errors.
Authentication
As stated earlier, authentication and permissioning are essential for preventing agentic commerce from becoming a major fraud risk. We have implemented authentication and permissioning between the MCP server and the Gr4vy Backend. We have also demonstrated how this could work with the wallet and the buyer. However, who is responsible for onboarding MCP servers to the Directory, given that they will need to perform some form of KYB to prevent rogue agents from being created? Additionally, payment companies (wallets) will need to determine how to authenticate with the agent platforms and vice versa. We would love to see standards being developed for authentication across agentic platforms so that the systems can be kept safe.
Numerous Gaps and Questions
Of course, there are several gaps and questions that remain unanswered, such as authentication and permissioning as mentioned above, and where inventory management fits in. More importantly, if the agentic companies decide to follow OpenAI’s lead and create walled gardens, the ultimate choice will be taken away from the merchant.
There is a desperate need and an opportunity for a organization to take the initiative in creating a verified directory of Merchant and Payment MCP’s. The current solutions today require registration with each of the AI platforms and lack strong KYB verifications. Someone needs to link this all up either as a commercial opportunity or as a standards body.
We also don’t know how consumers will use agents for shopping. I can’t imagine agents being used to buy high-value products or even treat items, as many people enjoy the shopping process. So, initially, it’s likely to be more about the commodity items we purchase regularly. This could then lead to agentic shopping being concentrated among larger retailers like Amazon and Walmart.
We also don’t know if consumers will use their own agents or simply go to an e-commerce site and interact with the merchant’s own agent, or in a more distant future, have their agent talk directly to a merchant’s agent.
Conclusions
Whatever the future holds, the fact is that agentic commerce is here to stay, and payments are necessary for commerce to occur. We hope that our demo shows one vision of the near future. We are now actively looking for Merchants and payment companies, as well as shopping carts, that are interested in exploring the concept further and bringing it to life.
By John Lunn (CEO) and Ali Minaei (CTO) at Gr4vy
