Agentic Commerce Explained: What Merchants Need to Know

Begin with the merchant’s obligation to the buyer

A customer can ask an assistant to research a purchase without authorizing it to spend. The assistant can recommend a product without being able to buy it. Agentic commerce becomes operationally meaningful when you can explain which action the agent performs, on whose authority, through which checkout and with which delivery outcome.

This guide focuses on that intersection of AI agents and financial transactions. A chatbot that rewrites product descriptions is outside the buying flow unless its work changes a purchasable offer. A conventional payment gateway is relevant when its credentials and results are connected to an agent-initiated purchase. The point is to follow the customer's money and the merchant's resulting obligation.

Consider a fictional store called Cedar Research. It sells a downloadable market report for an illustrative $29. A customer named Sam asks an assistant to buy the latest edition for personal use, with a total spending limit of $35. Those details are sufficient to identify several real design questions: which edition is current, what license is included, how the total is calculated and how Sam receives access.

A referral and an agent-completed purchase are different routes

In a referral journey, an AI surface helps the customer discover the report and directs them to Cedar's checkout. The customer may then complete a familiar web form. The assistant influenced the purchase, but the merchant should not describe the transaction as a fully autonomous API checkout without evidence of that behavior.

In a structured agent purchase, the assistant interacts with a documented interface or supported channel flow. It obtains current purchase terms, checks the relevant authority and requests completion. The merchant returns a result that can be traced to the order. The interface can be embedded in a shopping surface or exposed through an API, depending on the integration.

These routes can coexist. Shopify currently describes ChatGPT as a referral channel for its storefronts, while other eligible channels can use Shopify-powered direct checkout. OpenAI's own shopping help also describes Instant Checkout for some eligible products and merchants. Those statements refer to different scopes and should not be flattened into a promise that every merchant can use the same route. [1] [2]

Follow one report from catalog to access

Cedar's catalog should identify the report edition and explain the license. The agent must not infer that “latest report” and a similarly titled archive bundle are interchangeable. A stable product identifier helps maintain the selection when the display title is shortened or when several editions appear in a search result.

The checkout then establishes current terms. Cedar calculates the amount for the selected item, quantity and delivery context. If applicable costs make the final amount $36, Sam's $35 approval no longer covers it. The assistant needs a changed purchase decision rather than quietly treating the catalog's $29 price as the amount to collect.

After the relevant authorization, the payment route processes the attempt. Cedar must verify the actual result through the supported provider or protocol mechanism. A statement in the assistant's chat that the order was paid is not sufficient financial evidence. The order service links the result to Sam's selected report and the delivery service grants the right access.

The last step matters as much as payment. An entitlement for the wrong edition does not fulfil the order even if the amount was correct. A broken download link leaves the merchant with a delivery exception. The customer needs an order reference and a support path that preserves the existing purchase instead of inviting another payment.

Separate customer intent from payment authority

Sam's instruction contains several constraints: the latest edition, personal use, one purchase and a $35 ceiling. A merchant or payment system should not treat the existence of a conversation as unlimited permission. The purchase terms need to remain connected to the authority under which payment is requested.

AP2 v0.2 describes linked checkout and payment mandates with verification responsibilities for participants. It distinguishes direct, human-present activity from autonomous flows. That framework is useful for understanding the evidence problem even when your chosen checkout uses another supported authorization mechanism. Its purpose is not to replace every catalog or store API. [3]

A practical merchant design records enough context to explain why the completed purchase was within scope. Keep the relevant item, merchant, amount, currency and authorization references available to the systems that need them. Avoid copying sensitive credentials or an entire personal conversation into an order note just because the customer used an assistant.

The standards have different jobs

ACP describes a merchant checkout contract, including session creation, updates, completion, cancellation and retrieval. A merchant implementation should use the actual published fields and response behavior. It should not rename internal concepts and present them as an official schema. [4]

UCP describes modular commerce capabilities and integration patterns. AP2 addresses purchase and payment authority. HTTP payment mechanisms such as x402 address paid resource interactions. A merchant can need several of these layers, but adding one acronym to a product page does not prove that the joins between them work.

The architecture question is concrete: which component supplies current terms, which checks authority, which processes money and which confirms delivery? Write down those owners before choosing adapters. Reuse authoritative business services so the assistant-facing route does not quote a different price or bypass inventory rules enforced on the ordinary website.

A product appearing in AI is an early event

Catalog exposure is useful evidence of distribution, but it does not measure completed commerce. An agent may read the report and decide it is unsuitable. A customer may inspect the checkout and decline the total. A payment can succeed while access remains pending. Count these outcomes separately so the team can find the actual constraint.

For Cedar, a discovery event records the report identifier returned to the agent. A checkout event records that the merchant supplied valid current terms. A payment event records the verified financial outcome. A fulfilment event records that Sam received the purchased access. The records should be linked through appropriate identifiers, without exposing unnecessary personal data.

If most attempts stop before a valid checkout, investigate catalog ambiguity, unsupported items or missing inputs. If they stop at authorization, examine whether the buyer can understand and approve the terms. If they stop after payment, prioritize delivery and exception handling. More search traffic does not resolve a broken paid-order path.

For the synthetic cohort in the table, 40 valid quotes from 80 discovery attempts gives a 50% quote rate. Thirty confirmed payments from 40 valid quotes gives a 75% payment rate at that boundary. Twenty-eight delivered orders from 30 confirmed payments leaves two paid orders to investigate. These denominators answer different questions; none is a measured result for Cedar or Agentify.

Merchant responsibilities continue after the assistant stops

The buyer may return later with a refund request or an access problem. Support needs to find the order without relying on the original assistant session still being open. Store the authoritative references and provide the customer a durable way to identify the purchase.

Refund and dispute handling depends on the payment route and commercial terms. Avoid assuming that every agent purchase has a card chargeback process or that a stablecoin payment removes the merchant's delivery obligation. Design a support playbook around the actual rails and the product's disclosed policy. Use the disputes guide for the distinction between cancellation, refund and a formal payment dispute.

There is also an operational cost to unresolved attempts. Someone must decide whether to retry delivery, request new information or refund an order. Estimate that work from observed cases in your pilot rather than a vendor's general automation claim. A small set of readable records can be more valuable than a large conversational transcript that no support operator can interpret quickly.

Start with a bounded merchant pilot

Choose a single product whose fulfilment can be verified. The Cedar report is a reasonable teaching example because its edition and entitlement are explicit. Your real product may be physical, digital or service-based, but its delivery promise should be equally clear before you invite an assistant to complete purchases.

Define success and failure cases before running the pilot. Include a normal purchase, a price change, an unsupported variant, a lost completion response and paid-but-undelivered recovery. Use provider-supported test mechanisms where available and safe authorized transactions where appropriate. This is a recommended method; the examples in this guide are not records of tests we conducted.

Assign an operational owner to each boundary. The catalog owner resolves ambiguous offers, the checkout owner maintains current terms, the payment owner investigates financial outcomes and the delivery owner handles fulfilment. A single person may hold several roles, but the responsibilities should still be visible.

Add distribution after the route has an observable result

A wider channel launch is easier to evaluate when one purchase already produces a traceable result. Check current merchant, country, currency and product eligibility for each additional channel. Public standards do not automatically grant access, and a provider's general geographic coverage does not establish eligibility for a particular agentic product.

Agentify Commerce gives merchants a catalog of digital offers and a direct-to-merchant USDC/x402 payment route linked to digital order delivery. It is an affiliated product: the owner of this guide is also connected to the product. Evaluate it against the same merchant scenario and evidence requirements used for other routes. The relevant decision is how it connects to the purchase you need to support, not whether the portal has placed a product link nearby.

Use the checkout and implementation guides to turn the pilot into a maintained system. Keep your protocol contract, source dates and acceptance scenarios together. Agentic commerce is useful to a merchant when a customer's assistant can reach a clear outcome with a real offer, valid authority, consistent financial records and delivery that support can explain afterward.