AI can find it.
Who approves the purchase?

“Agentic commerce” describes several different shopping flows.

In a browser flow, an assistant finds an item and sends the person to the seller’s site to pay. In an embedded checkout, the product list and checkout appear inside the AI interface, where the person can review and approve the order. In a headless flow, software uses structured services and may act under previously defined limits. The word “agentic” alone does not tell you which steps are automated or which decisions the person still sees.

These designs connect four separate jobs: discovering a seller and product, confirming the actual basket, authorizing the purchase, and processing payment. A smooth conversation can hide those boundaries; a trustworthy flow makes them legible.

Stripe’s current guide describes browser, conversational, and headless modes. It also distinguishes discovery, fraud controls, checkout, and payment as separate parts of the system. Read the agentic commerce guide ↗

Product details, permission, and payment are different layers.

The Universal Commerce Protocol (UCP) describes how a business can publish capabilities and manage a structured checkout. Its checkout specification says the person completes payment through a trusted interface unless the AP2 mandate extension is supported. UCP answers how a checkout can be represented and carried through a commerce flow; it does not by itself grant an agent permission to spend.

The Agent Payments Protocol (AP2) focuses on delegated authority. Its current specification defines a Checkout Mandate for what is being bought and a linked Payment Mandate for paying for that checkout. In a human-present flow, the person approves the closed, specific purchase. In an autonomous flow, the person approves constraints first; the agent can then assemble a matching checkout within those limits. These are different consent models, not the same “buy” button with a different label.

Payment tokens solve another problem: they can let a system request payment without handing the model the buyer’s raw card number. Stripe describes Shared Payment Tokens limited to a seller, amount, and time window. That limits the credential’s use; it does not determine whether the selected item is the right one or whether the user’s instruction was understood correctly.

The merchant remains responsible for the offer and order in the protocols and flows described by UCP and Stripe. The buyer should be able to see who is selling, what the final total covers, who handles fulfillment and returns, and where the order record lives. See the UCP checkout specification ↗, the AP2 specification ↗, and Stripe’s notes on checkout and scoped payment tokens ↗.

An agent’s shortlist can shift before anyone reaches checkout.

A 2026 study in the ACM Web Conference tested shopping agents in a controlled marketplace where researchers could vary product position, price, ratings, sponsored labels, and endorsements. The agents showed position effects, and different models could prefer different products. Sponsored labels and endorsements also changed selection. These results describe the study’s simulated shopping environment; they are not a measure of what every real shopper or production agent will do.

The practical point is that product discovery is a decision-making system, not a neutral window. Ask the agent to show its comparison criteria and source links. Check whether it considered more than the first few results, and compare the shortlist with the seller’s own listing and independent evidence. Sellers and marketplaces should test how rankings, descriptions, and model updates alter which products are surfaced.

A September 2026 preprint formally models several agent-payment protocols and examines how authorization, payment, and service delivery stay connected across roles and stages. It is a protocol-model analysis, not an audit of every deployed checkout. Its questions are useful nonetheless: does the final cart match the approved intent, does the payment match that cart, and can the resulting order be traced back to both?

For related risks involving external instructions and agent permissions, see how prompt injection works ↗ and why permissions belong at the tool boundary ↗.

Make the authority concrete enough to check.

The more open-ended the task, the more important it is to ask the agent to stop at the checkout summary. For recurring orders, raise the bar: name the merchant and product, cap the amount and frequency, define the end date, and make cancellation easy to find.

For a broader look at how shopping models can influence choices, read what financial-advice research can—and cannot—show ↗ and how to read AI benchmark results ↗.