Agentic commerce: preparing your store for AI shopping agents

Key takeaways

• Agentic commerce is not one checkout button. It is a set of discovery, comparison, consent, payment and fulfillment steps mediated by software.
• Accurate product data is the first merchant responsibility. Agents cannot compare what a store does not describe clearly.
• ACP, AP2, UCP, x402, MPP and QMP address different parts of the landscape. Do not treat the acronyms as interchangeable certifications.
• Keep price, availability, policies and final order confirmation under explicit merchant rules. A fluent recommendation is not purchase authorization.
• Start with a clean catalog and a safe, testable integration path for your platform before committing to a protocol roadmap.

What is agentic commerce?

Agentic commerce is shopping in which software agents help people discover, compare or buy products through connected merchant systems. A flow may stop at product lookup or continue to order creation and payment. Capabilities depend on the integration, and an agent that answers questions is not automatically authorized to purchase.

For a merchant, the practical model is the two-journey ledger: the human journey explains the product and builds confidence, while the agent journey makes product facts, rules and permitted actions available in machine-readable form. The two must reconcile to the same inventory, prices and policies. If they disagree, the merchant's system of record and explicit checkout confirmation should govern the outcome.

OpenAI and Stripe described the Agentic Commerce Protocol as an open standard for agents, people and businesses to work together on purchases. In the September 2025 ChatGPT Instant Checkout announcement, OpenAI said orders, payment, fulfillment and support remain handled by merchants using existing systems. That is a specific launch description, not a promise that every merchant or assistant can transact through ACP.

How do shopping agents discover and compare products?

An agent needs a path to products and a schema it can interpret. That path may begin with a public product page, a feed, platform catalog access, an API or a commerce protocol. The product record should be stable enough to connect the same item across all of them. It needs a clear title, maker or brand, identifiers where available, category, variant, price, currency, availability, shipping context and a canonical product URL.

Comparison quality depends on the attributes that change a decision. Apparel needs size, color and material. A software subscription needs plans, seats and renewal terms. Furniture may need dimensions, assembly and materials. A generic description copied across every product erases the distinctions that a person and an agent need. Make product variants explicit and avoid using an image as the only carrier of an important fact.

The product page remains a source of context. It should answer fit, use, limitations, compatibility, care, returns and warranty questions in text. Structured data and feeds can improve machine access but must agree with visible details. Build an update process so a price change or discontinued variant propagates to the feed and page, and do not advertise inventory as available after the commerce system has marked it out of stock.

What product data should a store prepare?

First, normalize identity. Give every purchasable variant a durable internal ID and retain standard identifiers when the business has them. Keep the brand and product names consistent across the page, feed and structured data. Separate variant-specific properties from shared product description. A blue medium shirt and a blue large shirt should not collapse into one ambiguous offer.

Second, normalize commercial facts. Store price and currency in machine-readable fields, represent sale dates correctly, and keep stock status connected to the source of truth. Make shipping, returns, tax context and regional availability easy to inspect. Do not assume an agent can infer that a displayed price excludes required fees or that a return policy has a special exception buried in a PDF.

Third, document allowed actions. A search response, signed offer, cart creation and final order are distinct states. Define who can create each one, what evidence of consent is required and when the customer sees a final total. Handle expired prices, rejected payments, duplicate requests and out-of-stock items. A careful fallback to the ordinary storefront is better than an agent guessing the next transaction step.

Which commerce protocols should merchants know?

The protocol landscape covers different layers. OpenAI and Stripe announced ACP in 2025 for agent-to-merchant purchase interaction. Google announced AP2 in September 2025 for agent-led payments and introduced UCP in January 2026 as an open standard spanning shopping from discovery to post-purchase support. Their stated scopes overlap, but the names are not interchangeable and their integrations are not a universal ticket to every assistant.

Other protocol names in Qomvia's e-commerce protocol inventory include x402 and MPP. Their presence in an inventory is not evidence that every agent or merchant has implemented them. Before choosing an integration, inspect the current primary specification and ask which actors implement it, what data it exchanges, how authorization works and which party handles order status, refunds and support. A familiar acronym does not guarantee merchant compatibility.

QMP is Qomvia's protocol within Qomvia Market. Market is available in beta with a merchant backend, agent API and MCP tools for product search and checkout sessions, plus integrations for native QMP, Shopify draft orders, WooCommerce orders and Shopware Store API. This describes Qomvia's product scope from its feature inventory; it does not imply that QMP is an industry standard or that every Qomvia Market feature is generally available.

Google describes UCP as compatible with AP2, A2A and MCP. OpenAI's ACP announcement describes its own purchase protocol and merchant responsibilities. Do not imply that compatibility between some components makes every agent, payment provider and commerce platform interoperable. Read the announcements directly: ACP and Instant Checkout, AP2, and UCP.

How can Shopify, WooCommerce and Shopware merchants prepare?

For Shopify, check that product titles, variants, identifiers, prices and availability are clean in the admin and represented consistently on the live page. Validate theme-generated product structured data and make important descriptions available as text. If testing a draft-order or marketplace integration, use a test shop and confirm whether the agent is allowed to create a draft, reserve inventory or place a confirmed order. Those are materially different permissions.

For WooCommerce, review product and variation records, currency settings, stock management, tax and shipping rules, and the API permissions granted to any integration. Test simple and variable products, subscriptions if relevant, coupon behavior and failed payment handling. Keep credentials out of public configuration and grant an integration only the capabilities it needs. Revoke test credentials when the sandbox exercise ends.

For Shopware, validate catalog attributes, variant behavior, sales-channel price and inventory, API access scopes and order state transitions. Test how the integration handles a product whose stock or price changes between recommendation and checkout. In any platform, exercise duplicate requests and interruption after payment authorization. Operations should be able to reconcile the resulting order and explain who will contact the customer.

Across all three platforms, establish one owner for each critical field. A product manager may own titles and specifications, merchandising may own category and assortment, finance may own price rules, and operations may own stock and delivery estimates. The exact allocation depends on the business. The important point is that an agent integration should read maintained values rather than introduce a second spreadsheet that drifts from the storefront.

Check whether variants and bundles are represented in the way a shopper expects. If a product is sold only as a set, do not expose each component as an independently purchasable offer unless that is actually possible. If a variant changes the price, weight or compatibility, make the difference machine-readable. Test the feed after a catalog update and inspect the response an agent-facing API returns for both a normal item and an edge case.

Test the same product from page to order

Choose a representative item with variants, a discount and a shipping constraint. Compare the storefront page, product feed, structured data and agent-facing response. Then walk through a user-authorized test transaction in the platform's sandbox or a non-production store. Verify the final price, address, inventory, confirmation and cancellation paths. An implementation is not ready because a search response looked correct; the order lifecycle is part of the test.

Qomvia's E-commerce add-on evaluates public product signals and protocol evidence. Qomvia Market and the QMP specification describe a separate beta commerce integration. Review the precise product coverage before choosing a deployment, and keep ordinary storefront checkout available while any agent connection is experimental.

How should a merchant launch safely?

Begin with a catalog sample, not the whole inventory. Pick products across categories and edge cases. Build a field-level data quality review for title, identifier, variant, price, stock, shipping and return policy. Assign an owner to each source of truth. If page and feed disagree, resolve the ownership question before connecting a new buyer surface.

Next, define consent and authority. Which actions can the agent take without another prompt? Does an order require a user confirmation step that shows the merchant, product, final price and fulfillment terms? Can the user cancel or change it? How are fraud checks applied? If an integration cannot answer those questions clearly, limit it to discovery or comparison until the control path is established.

Roll out with a small eligible cohort and monitor product mismatches, abandoned handoffs, duplicate orders, support contacts and refunds. Keep a kill switch for the integration and a documented incident owner. Tell customer service how the agent journey is represented in order records. Review privacy notices and data retention with legal and security teams before passing personal information to a third party.

Define the operational contract before launch. Who handles the buyer's question when the agent cannot find an item? Which system is authoritative for a quoted price? What happens when the payment succeeds but an order confirmation fails? How will a merchant recognize an agent-generated order in support tools? The answers should be clear to store operations, not only to the engineer who built the endpoint.

Make the handoff transparent to customers. Identify the seller, show the final total and delivery terms before a payment action, and explain whether the user is leaving the assistant for the merchant's checkout. Avoid implying that an assistant has completed an order when it has only opened a cart or generated a checkout link. State where order tracking and returns are managed.

Use an integration checklist for every release: supported product types, markets, currencies, tax rules, fulfillment options, credentials, authorization, confirmation, cancellation and customer support. Mark unavailable combinations clearly. A staged launch can begin with product discovery, then add a handoff to the existing checkout, and only later automate an order path if the controls and operations are ready.

Watch data quality as an operational metric

Track the share of catalog items with a stable identifier, complete key attributes, current price and valid canonical product page. Monitor mismatches between feed and storefront, rejected offers, stock-related cancellations and customer reports of incorrect product details. These are merchant operations metrics, not proof that an agent will recommend the catalog. They help maintain the facts an agent might use.

Review a sample of both successful and unsuccessful sessions. A search that returns no products may mean the query is too narrow, the catalog taxonomy is incomplete or the product is genuinely unavailable. A successful order can still be wrong if a variant or delivery condition was misunderstood. Include operations and support in the review, and use customer feedback to prioritize repairs.

Run a scenario review before expanding the cohort. Include an item that is out of stock, a variant with a different price, a delivery restriction, a declined payment, a user who changes their mind and an agent that repeats a request. Confirm the storefront and order system converge on one state for each case. Record who can resolve a mismatch and how the customer will be notified.

Measure the quality of the handoff as well as the number of successful sessions. Look for product-detail mismatches, unexpected checkout abandonment, duplicate orders and support contacts that indicate the user misunderstood who was selling or fulfilling the item. A low completion rate does not automatically mean the assistant failed; it may reflect price, shipping, product fit or the user's choice to compare further.

Review the security and privacy boundary whenever a new tool or commerce protocol is added. Identify which party receives customer or order information, what authorization permits an action, how credentials are rotated and how an incident is reported. The minimum useful integration may be product discovery or a user-approved checkout link. More automation is justified only when the merchant can support its additional authority and failure modes.

Write down the rollback path before exposing the journey to customers. Decide who can disable the integration, how open checkout sessions are handled and how a user can complete the purchase through the ordinary storefront. If the agent service becomes unavailable, the catalog should not show an offer that cannot be fulfilled. Operations should know where to find the affected sessions and what response to give a customer.

A pilot review should include exceptions, not only successful demonstrations. Test a missing address, invalid promotion, duplicate submission, changed inventory, timeout and cancellation. Check that the final state is understandable in merchant records. If the protocol does not represent a business rule, keep that rule in the existing checkout rather than assuming the assistant will infer it.

Keep a written record of the pilot's boundaries. List supported markets, product types, payment methods and fulfillment modes, along with known exclusions and the person who can approve a change. If a support team cannot tell whether an order originated in the agent flow, improve order annotations before widening access. A well-bounded pilot is easier to troubleshoot and gives the merchant a clear basis for deciding whether to extend it.

Treat agentic commerce as an additional customer channel, not a reason to weaken existing safeguards. Apply the same refund, fulfillment, accessibility and customer-service expectations as other orders. Explain which party is the seller and retain a human support path. A new interface can reduce friction for some shoppers while creating new failure modes that the merchant remains responsible for resolving.

For a general site readiness view, the AI agent readiness pillar connects discovery, extraction and action. The AI search checklist helps find technical barriers, while the visibility measurement guide keeps answer sampling distinct from transaction outcomes.

Sources and further reading

• OpenAI: Buy it in ChatGPT, Instant Checkout and ACP
• Google Cloud: Agent Payments Protocol
• Google: Universal Commerce Protocol

Questions

What is agentic commerce?

Agentic commerce is shopping where software agents help people discover, compare or purchase products through connected merchant systems. Specific capabilities depend on the agent and merchant integration.

How do I sell products through ChatGPT?

Prepare accurate product information and follow the current integration requirements published by OpenAI and its commerce partners. Eligibility and checkout capabilities vary; a feed or protocol announcement alone does not guarantee that a store can transact in ChatGPT.

What is the difference between ACP, AP2 and UCP?

They are separate protocols announced by different organizations with overlapping but distinct scopes. Check their current specifications and supported integrations rather than treating them as equivalent commerce certifications.

Do AI shopping agents need product schema?

Structured product information can make product facts easier to interpret, but it must match the visible page and current catalog. Keep price, availability, variants and policies consistent across sources.

Can an AI agent place an order without approval?

That depends on the agent and merchant integration. Merchants should define permitted actions, user consent, final price confirmation, payment authorization and cancellation before enabling transactions.

Does Qomvia Market support Shopify and WooCommerce?

Qomvia Market is available in beta with a merchant backend, agent API and MCP tools, plus integrations for Shopify draft orders and WooCommerce orders. Review current setup documentation before relying on a production workflow.