E-commerce
August 26, 2026
In 2026, the question is no longer whether a software agent can make a purchase, but what protocol it speaks and what payment authorization it presents. Google published its merchant tools in January, Rezolve commented on the emergence of competing standards in late January, and Adyen launched Adyen Agentic in mid-June as a translation layer between agents and checkout flows. All of these announcements come from vendors or consulting firms, so they indicate a direction rather than massive adoption. This article details the four essential building blocks required for a purchase to take place without a physical person at the moment of checkout, then examines each proposed protocol and what it implies for you, the e-commerce merchant. You will also discover how an in-house conversational agent like Qstomy positions itself against these external rails.
Summary
What is an agentic commerce rail and what must it guarantee?
An agentic commerce rail refers to a purchasing journey designed for a software buyer, not a human. It requires four elements that a traditional funnel takes for granted: a structured, machine-readable catalog, proof that the automated customer is legitimate, a delegated mandate authorizing the agent to spend within set limits, and an authorization history that can be legally enforced in the event of a dispute.
A public product API, whether REST or GraphQL, is not enough. It returns data but establishes neither the identity of the requester, nor their spending limit, nor a record that can be used months later during a dispute. The missing pieces are authority and identity, not endpoints. The key commercial difference lies between the agent that recommends and the agent that transacts: the former delivers a short-list to a person who buys normally, while the latter validates the order itself, retrieves structured offers, filters according to customer constraints, presents a verifiable identity to the merchant firewall, then submits the order against a card-on-file mandate and receives the confirmation in JSON rather than HTML.
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
What was actually published in the first half of 2026
Between January and June 2026, payment actors and platforms released so-called agentic infrastructures, plus research previews. Google published merchant tooling and a protocol on January 11 on its official blog. Rezolve, itself an agentic provider, commented on January 29 on the importance of emerging protocols, an assertion that is only justified if multiple protocols coexist. Adyen announced Adyen Agentic on June 16, described as a universal translator for the new era of commerce, thus placing a payment actor between the external agent and the merchant journey.
The common motif in these releases is that the agent lives outside the merchant site and requires brokerage: protocol, accreditation, or an intermediate translator. None of them assume that the merchant builds their own purchasing agent. What the whole does not demonstrate is scale: no transaction volumes, no adoption rates, no independent measurement of order accuracy. Consulting firm publications cover the ground without filling this gap: McKinsey in October 2025 then on May 29, 2026, Deloitte on Asia-Pacific agentic retail on January 30, Mirakl surveying e-commerce leaders on June 4. All these sources are published by vendors or consultants, so this article treats them as directional signals.
Which agentic protocols exist and how do they differ?
Proposals for agentic protocols diverge on a central question: who holds the payment credential at the time of purchase. This location then determines where validation takes place, what the merchant exposes publicly, and who bears the loss in the event of a dispute. No source names a specification or sponsor, so the three families below are described by mechanism.
Merchant-hosted validation, delegated mandate: the customer's issuer credentials the card by mandate, validation runs at the merchant who exposes a documented endpoint and item-by-item offers; the merchant bears the dispute as with any card-not-present transaction.
Credential held by the agent: the agent platform, often via a network token, performs the validation and pushes the order to the merchant; who bears the dispute depends on the card network's processing and remains unresolved.
Cart assembled by the agent, human confirmation: the customer confirms in a browser, the merchant's classic validation applies, and the merchant bears the dispute as with any web order.
A translation layer only generates revenue as long as the incompatibility persists. Adyen's positioning in June 2026 as a translator proves that no single standard has won.
Structured catalog: the non-negotiable foundation of any agentic transaction
An agent can only compare offers if they are formatted in a predictable manner. This means exposing your products with schema.org Product and Offer tags, including price, availability, variants, and delivery terms. A separate JSON product feed from your standard HTML rendering simplifies integration.
This structured data also benefits your search engine optimization: Google Shopping and e-commerce SEO strategies rely on the same tags. Publishing a machine-readable catalog is therefore not a gamble on a single agentic protocol, it is a reusable foundation regardless of which rail becomes the standard. You simultaneously improve your organic visibility and your future compatibility with purchasing agents.
Identity and legitimacy: proving that the agent is acting on behalf of a real client
When a person connects, a session cookie and an IP address are often sufficient. A software agent must present a signed cryptographic token proving that it represents an authenticated client account. This token can take the form of a JWT including the client identifier, authorization limits, and a signature verifiable by your application firewall or your CDN.
Without this identity layer, you cannot distinguish a legitimate agent from a malicious bot. Most proposed protocols include a pre-registration mechanism: the agent registers with your API, receives a key, and then signs each request. This mechanism resembles OAuth2 client credentials but adds the concept of a spending limit and validity duration, two constraints absent from classic OAuth flows.
Delegated mandate: authorize the agent to spend within clear limits
The delegated mandate is the equivalent of a bank proxy: the client authorizes the agent to charge up to a set amount, over a given period, for a specific category of products. Technically, this relies on a card registered with the issuer or payment processor, referenced by an identifier without exposing the full number.
During validation, the agent presents this identifier and the amount; the processor verifies that the sum remains within the limits, then authorizes the transaction. The log of who authorized what, when, and for how much must be kept on both the merchant and issuer sides, as it will serve as proof in the event of a dispute. This mechanism also protects the client: if the agent is compromised, the ceiling limits the damage.
Authorization trail: keep a legally binding history in case of dispute
When a customer disputes an order six months later, you must prove that they indeed authorized the purchase. With an agent, this proof cannot be a checked box in a browser. It takes the form of a timestamped record of the mandate creation, the accepted limits, and the signed request that triggered the order.
Concretely, you log the mandate identifier, the agent's identity token, the submitted shopping cart, and the payment processor's response. These logs must be immutable and encrypted, as they will be produced during a chargeback. If the agentic protocol you adopt does not specify the format of these traces, define it yourself in collaboration with your legal counsel and your payment processor.
Where does validation take place and who bears the risk of fraud?
The location of the validation determines the liability. If the validation runs on your infrastructure with a delegated mandate, you bear the risk exactly as with a classic card-not-present transaction: you benefit from the usual fraud scoring tools and negotiate chargeback rates with your acquirer.
If the agent platform holds the accreditation and pushes the completed order, it acts as a payment intermediary. Who bears the dispute then depends on the contract between the platform, the card network, and you. This ambiguity explains why many merchants prefer to keep the validation in-house: liability remains clear and existing fraud prevention tools continue to work. The model with final human confirmation remains the closest to the current customer journey and dilutes the new risk.
Concurrent protocols: what level of commitment for the merchant
The three protocol families require different levels of commitment. Publishing structured offers, line-by-line accuracy, and a documented validation entry point is reusable regardless of the winning rail. Accepting accreditation held by an agent platform also means accepting its dispute process and liability position, which changes your contractual counterparty.
The practical advice is to start with the common foundation: a schema.org structured catalog, a documented validation API, token-based identity, and a delegated mandate on the processor side. These building blocks also serve your integration with Google Shopping and improve your e-commerce SEO. Next, test a protocol with a pilot partner on a limited volume before generalizing.
Difference between a recommending agent and a transacting agent
A recommending agent assembles a selection and hands it over to a person who validates the purchase in a standard browser. No agentic guardrails are necessary: the agent calls your product API, filters according to preferences, and then generates a pre-filled cart link or a list for the customer to browse. The checkout tunnel remains unchanged.
A transacting agent validates the order itself without human intervention at the time of submission. It requires the four building blocks described above: structured catalog, verifiable identity, delegated mandate, and legally binding audit trail. The difference in technical and legal complexity is considerable. If you are starting out, begin with a recommending agent: you capitalize on your existing product recommendation engine and learn about behaviors before automating validation.
How Qstomy positions itself against external agentic guardrails
Qstomy is a conversational AI agent integrated into your Shopify store, not an external platform that pushes orders. It guides your visitors to purchase through product recommendations, upselling, package tracking, account access, and answers regarding your return and delivery policies. More than a hundred merchants use it to improve conversion and reduce the customer service workload.
Because Qstomy lives within your site, it does not need an agentic protocol to trigger a purchase: it prepares the cart and invites the customer to checkout in the classic Shopify funnel, just like a recommender agent. You thus retain full control over validation, payment methods, and dispute management. Qstomy complements your human-automation customer support strategy by automating repetitive questions while leaving complex cases to your teams. If an external agentic protocol becomes necessary tomorrow, you can decide separately to open it, but your internal conversational foundation remains operational and independent.
Checklist, summary and frequently asked questions
Checklist before adopting an agentic rail:
Structured catalog: add schema.org Product and Offer to your pages, publish a product JSON feed.
Documented validation API: specify endpoints, request format, error handling.
Token-based identity: define agent registration, request signature, firewall verification.
Delegated mandate: negotiate with your processor for card registration, limits, and duration.
Enforceable logs: log mandate, token, cart, processor response; encrypt and timestamp.
In short: Agentic rails require a structured catalog, verifiable identity, delegated mandate, and an enforceable log. Several protocols coexist; no single standard has won by mid-2026. Start with the reusable foundation, test with limited volume, keep validation internal as long as legal liability remains unclear with external platforms.
Frequently Asked Questions
Can an agent place an order without the customer validating each time?
Yes, if the customer has created a delegated mandate with a spending limit and duration. The agent then submits the order against this mandate; the customer receives a notification but does not intervene unless there is an overage or anomaly.
Who bears responsibility if the agent orders the wrong product?
This depends on the protocol. If the validation is merchant-hosted with a mandate, you bear the risk as with any card-not-present transaction. If the agent platform holds the accreditation, liability depends on the contract between the platform, network, and merchant.
Should we choose an agentic protocol right now?
No. First publish a structured catalog and a documented validation API: these blocks also serve your SEO and merchant feeds. Then test a protocol in a pilot phase before rolling it out widely.
Can Qstomy become an agent that transacts instead of recommending?
Qstomy prepares the cart and invites the customer to check out in the Shopify funnel. Transforming this invitation into automatic validation would require a delegated mandate on the customer side. For now, the recommender model offers the best balance of conversion and control for the majority of merchants.
To go further: How to help a customer blocked by 3D Secure during payment - Qstomy.
Enzo
August 26, 2026
