E-commerce
August 26, 2026
Several agentic commerce protocols are emerging in 2026, and their differences lie less in how they read the catalog than in two commercial points: who holds the payment details, and who owns the official order. Adyen announced Adyen Agentic on June 16, 2026, as a universal translator between AI agents and merchant payments. Google released its tools for agentic shopping on January 11, 2026. This article compares these protocols across four concrete dimensions: custody of the payment method, order registration, proof of agent authorization, and catalog access. Each of these choices contractually binds the merchant, well beyond a simple technical integration. Understanding these differences helps you weigh the commercial commitments hidden behind each protocol.
Summary
What is an agentic commerce protocol, and why do several of them exist?
An agentic commerce protocol defines how a software agent, acting on behalf of a buyer, reads your catalog, selects an item, submits an order, and pays without human intervention in front of a browser. Several protocols coexist because the parties designing them each want to place the payment method with a different actor. AI model providers, banking networks, payment processors, and marketplace platforms all defend their own vision.
Every protocol must specify at least five elements: product discovery, selection of an item and variant, order submission, payment authorization, and confirmation return. A traditional payment API only covers a portion, as web commerce assumes a human enters their card, consents to terms, and validates a 3-D Secure authentication challenge on their phone. Remove the human and each step requires a delegated substitute. What is established is the form of the exchange: ordinary HTTP against structured product data rather than rendered pages. What remains open is which protocol will prevail, and what each truly asks you to accept.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
Four questions separate one protocol from another
Each agentic commerce protocol answers four questions, and these answers are what truly distinguish them: who holds the payment method, who owns the official order, how the agent proves its authorization, and where it reads the catalog. Compare the protocols along these four axes and the rest becomes implementation detail.
The custody of the payment method determines whether you receive a billable card or if an intermediary keeps it and passes you a token or an already settled payment. The order registration establishes which system holds the authoritative order. The agent's identity specifies what proof it presents to demonstrate that it is acting on behalf of a named buyer on a named platform. Catalog access indicates where the agent reads price, availability, and attributes, and how fresh they are. The first two axes carry the business consequence, because they shift something you currently hold to a third party and are written in a contract rather than a configuration. The last two are largely independent of the protocol: identity is a policy question of which bots to trust, catalog access is a data job that all protocols require in a similar form.
Who holds the payment method: the biggest difference
Protocols split between those where you receive a card you can charge and those where an intermediary keeps the card and hands you a restricted token or a settled payment. This divide decides who carries the dispute, who sets the spending limit, and whether you can charge this customer again later.
The authorization journey starts with a delegated authority: the buyer grants the agent permission to spend, normally bounded by amount, merchant scope, and time window. A limit constrains what the agent can present, not what you can capture. Holding a billable card therefore puts you in a different position than holding a single-use network token restricted to an amount.
Under merchant custody, you authorize through your acquirer as usual. The step where a human would have passed a 3-D Secure challenge is replaced by the proof of delegation carried by the protocol. Under intermediary custody, the intermediary authorizes against the buyer, and you see a payment you did not initiate. Liability remains unclear: card network rules assumed a cardholder present or having previously accepted a merchant-initiated transaction. No public source indicates how networks currently handle an agent-initiated purchase. Treat this issue as a question to ask your acquirer rather than an assumption. To learn more about how to build a payment gateway for an e-commerce website, consult our dedicated guide.
Who owns the official command: where your customer data lives
Order registration refers to the system that holds the authoritative order. This decision determines who the customer contacts by email, who issues the refund, and who keeps the customer record. Some protocols leave the order with you, while others place it with the intermediary, who then notifies you.
When the order lives with you, you manage returns, exchanges, and after-sales service as usual. When it lives with the intermediary, you must synchronize statuses, resolve discrepancies between systems, and contractually clarify who responds to the dissatisfied customer. The location of the order also determines whether you can offer an easy repurchase, apply your loyalty rules, or personalize the subsequent experience.
For a merchant, this question is often more critical than the payment protocol itself, as it directly affects the customer relationship and the ability to retain customers. Your e-commerce analytical tracking stack also depends on this location: if the order never enters your system, you lose visibility and behavioral data.
How the agent proves their authorization: who you let in
Each protocol must solve the same question: how an agent demonstrates that it is acting on behalf of an identified buyer on an identified platform. The usual answer involves a signed token, a platform identifier, and a time window. This proof replaces human presence in front of the payment form.
From the merchant's perspective, this is a policy issue: which automated customers do you allow, and based on what proof. Accepting an agent token is equivalent to accepting a purchase order issued by software. You must decide which platforms you trust, what level of signature you require, and how you revoke access if necessary. This decision is largely independent of the chosen protocol, as it is based on your own risk assessment.
The agent's identity also influences your ability to block abuse or detect suspicious behavior. Unlike a human browser, an agent can submit hundreds of requests per second. Setting rate limits, monitoring access patterns, and requiring robust proof of identity become essential. To optimize your store in the face of these challenges, consult our step-by-step guide for Google, which is applicable to agents.
Where the agent reads the catalog: feed, freshness, and availability
All protocols require the agent to access price, availability, and product attributes. The difference lies in the format (structured feed, real-time API, standard schema) and the freshness of the data. A daily feed is sufficient for a stable catalog but fails if your prices or stock change multiple times a day.
Most protocols recommend a structured feed conforming to a schema like Schema.org Product or Google Merchant Center. This data work is identical to what you would do for Google Shopping: clear titles, complete descriptions, quality images, precise variants. The only new element is the update frequency: an agent acts in real-time and expects your availability to be truly current.
If your backend cannot publish a fresh feed every hour, consider an inventory API that the agent queries at the time of purchase. This adds complexity but prevents orders on out-of-stock items. Catalog access is therefore less a choice of protocol and more a common operational prerequisite: structuring your product data and ensuring its freshness.
Contractual implications: what you are really agreeing to
Adopting an agentic commerce protocol is not just a simple technical integration. It is a contractual commitment that affects payment, liability, customer ownership, and data sharing. Every protocol shifts a portion of your current business relationship to a third party, and this shift must be weighed beyond the advertised benefits.
Carefully read who bears the risk of fraud, who issues refunds, who retains the customer email address, and who can reuse order data. Some contracts reserve the right for the intermediary to offer competing products to the same customers. Others require exclusivity on a catalog segment. Still others impose API response times or penalties for downtime.
Before signing, simulate a customer dispute scenario, a product return, and a GDPR request to verify that you retain the necessary control. Also, check whether the protocol allows you to collect behavioral data that powers your product recommendation engine and your loyalty campaigns. A protocol that cuts you off from this data can permanently harm your growth.
What impact on customer experience and conversion
From the buyer's perspective, agentic commerce promises ultra-fast ordering without form entry or page navigation. The agent compares price and availability, selects the best merchant, and finalizes the purchase in seconds. For the merchant, this promise hides several conversion risks.
First, you lose the entire discovery journey: the agent does not see your banners, your cross-recommendations, or your cart offers. You can no longer rely on traditional e-commerce marketing and advertising to increase cart value. Second, the purchase decision is based on criteria optimized by the agent, not the human: lowest price, fastest delivery, highest rating. If you do not dominate any of these axes, you lose the sale.
Third, you no longer control the confirmation interface or the post-purchase message. It is the agent, or the platform hosting it, that presents the receipt and proposes the next steps. Your brand becomes invisible or interchangeable. To measure the real impact, track your advertising efficiency and your conversion rates before and after activating the protocol.
Technical prerequisites: feeds, API, and availability
Before activating an agentic commerce protocol, ensure that your infrastructure meets the minimum requirements: a structured and fresh product feed, a compatible payment API, real-time inventory, and high availability. An agent is not forgiving of an error page or a timeout: it simply moves on to the next competitor.
Your product feed must include titles, descriptions, images, prices, variants, availability, and delivery times for each SKU. A standard schema like Schema.org or Google Merchant Center facilitates integration. Your payment API must support delegated authorization, meaning it accepts a token or proof of agent identity in place of human card entry.
Your inventory must be queryable in real-time or updated at least every hour. Publishing a daily feed is sufficient for Google Shopping but will fail with agents that expect real-time availability. Finally, your infrastructure must handle query spikes: an agent can query hundreds of catalogs in parallel. Plan for caching, rate limiting, and active monitoring. To understand how Google ranks Shopping ads, read our detailed analysis.
Operational risks: fraud, litigation and synchronization
Agentic commerce introduces new fraud vectors and new operational challenges. A compromised agent can place orders without the buyer's real consent. A misconfigured agent can place duplicate orders or ignore your stock limits. A failing intermediary can delay order notification or lose track of the payment.
On the fraud side, the usual behavioral analysis rules (time spent on site, mouse movement, IP address) no longer apply. You must rely on the agent's identity, the platform's reputation, and the buyer account history. Some protocols delegate this verification entirely to the intermediary, depriving you of visibility and leverage in the event of a dispute.
On the synchronization side, you must manage discrepancies between your ordering system and that of the intermediary. A product return must be registered on both sides. A refund must go back to the original payment method, which may no longer be visible to you. A cancellation must release stock immediately. Plan for webhooks, daily reconciliations, and discrepancy alerts. Test your processes end-to-end before opening production access.
How Qstomy positions itself against agentic protocols
Qstomy is a Shopify AI agent that guides your visitors toward buying, manages recommendations, upselling, and cross-selling, tracks packages, and runs customer service. Already deployed with over 100 merchants, Qstomy acts inside your store, not as an external intermediary between you and your customer.
Unlike agentic protocols that shift the payment method or order registration to a third party, Qstomy keeps the order within your Shopify and uses your usual payment gateway. You maintain the customer relationship, behavioral data, and control over sales policies. Qstomy enriches the experience without cutting you off from your buyers or inserting an intermediary into the payment flow.
Qstomy also addresses the four central questions of protocols: you hold the payment method, you own the order, the agent proves its authorization via native Shopify integration, and it reads your catalog directly from your product database in real time. This architecture preserves your margins, your customer relationship, and your ability to customize the post-purchase experience, all while offering you the power of a conversational AI assistant.
Checklist, summary, and frequently asked questions
Before adopting an agentic commerce protocol, check these points:
Payment Custody: Who holds the billable card, you or an intermediary?
Order Registration: Who owns the official order and handles returns?
Proof of Authorization: What agent identity do you accept, and how do you revoke it?
Catalog Access: Is your product feed structured, fresh, and complete?
Infrastructure: Does your API handle the load and respond in real time?
In short: Agentic commerce protocols differ mainly in who holds the payment and who owns the order. These two choices carry the heaviest commercial, contractual, and operational consequences. Agent identity and catalog access are common prerequisites. Weigh each commitment against your customer relationship, your data, and your margin before signing.
Frequently Asked Questions
Are agentic protocols widely adopted in 2026?
Announcements exist (Adyen June 2026, Google January 2026), but no public source quantifies actual adoption. Treat them as emerging, not established.
Do I have to choose a single protocol?
No. You can support multiple ones if your infrastructure allows it. Each engages your customer relationship and payment flow differently.
Does an agentic protocol replace my current payment system?
No. It overlays or integrates with it. Depending on the protocol, you receive either a billable card or an already settled payment.
Is Qstomy compatible with these protocols?
Qstomy runs inside your Shopify, without moving payments or orders. It complements your existing journey rather than replacing it.
Enzo
August 26, 2026
