How Does Agentic Commerce Work? One AI Agent, One Purchase, Six Steps

Agentic commerce is when an AI agent finds, chooses and pays for things on a person's behalf, within limits that person set. One purchase moves through six steps, which work more like stages than a fixed sequence: discover, trust, authorize, checkout, pay and settle. Open protocols and existing payment rails handle different stages. They often overlap, and no single protocol covers the whole journey.

The six stages of agentic commerce, in order:

1. Discover: the agent finds products, stores and tools.
2. Trust: the agent proves to the store that it's a legitimate agent.
3. Authorize: the agent carries proof of what the person approved.
4. Checkout: the agent places the order in a standard format.
5. Pay: money moves, by card token or a machine payment protocol.
6. Settle: the money lands on existing rails.

To see how the pieces fit, picture Sam asking his AI agent, Pip, for running shoes: size 10, under $120. What has to happen between that sentence and a completed purchase? We made a short animated video that follows exactly that purchase.

In the video: 0:00 The request · 0:24 Discover · 0:44 Trust · 1:05 Authorize · 1:30 Checkout · 1:47 Pay · 2:12 Settle · 2:30 The full map · 2:40 Who checks the whole order? · 2:51 The rerun with KYI · 3:23 Up next

Read the video transcript

Sam: Pip, get me running shoes. Size 10. Under $120.
Pip: On it!
Narrator: How does an AI agent actually buy something?
Sam: Wait. How do you even do that?
Pip: Six steps. Each has its own rules.
Narrator: Those rules are called protocols. Shared standards, so agents and businesses understand each other.

Narrator: Step one. Discover.
Sam: How did you find those stores?
Pip: I asked. In languages they speak.
Narrator: MCP plugs an agent into tools and data. A2A lets agents talk to other agents. And UCP lets a store tell agents what it sells, and how to buy it.

Narrator: Step two. Trust.
Sam: They thought you were a bot?
Pip: I AM a bot. A verified one.
Narrator: With Visa's Trusted Agent Protocol, the agent signs its requests, so a store can tell it apart from a bad bot. Onchain, ERC-8004 gives agents a public registry for identity and reputation.

Narrator: Step three. Authorize.
Sam: You carry proof I said yes?
Pip: Signed. So nobody argues later.
Narrator: Google's AP2 records signed mandates: what you asked for, and the exact cart you approved. Visa Intelligent Commerce attaches your spending limits to the agent's card. And the Personal Agent Protocol, from Sierra and Meta, covers consent to act on your account.

Narrator: Step four. Checkout.
Sam: Every store, its own checkout?
Pip: Two standards want to fix that.
Narrator: ACP, from Stripe, OpenAI and Meta, and Google's UCP both standardise how an agent checks out with a store.

Narrator: Step five. Pay.
Sam: You paid a website one cent?
Pip: Machines pay machines. All day.
Narrator: With x402, the server says payment required, the agent pays, and the request goes through. MPP, from Stripe and Tempo, does it with payment requests and sessions. Mastercard's Agent Pay for Machines brings it to card rails.

Narrator: Step six. Settle.
Sam: And how does the store get paid?
Pip: Settling isn't one protocol. It's the rails.
Narrator: This is where the money lands. Stablecoins onchain, card networks, and bank accounts.

Narrator: These protocols don't compete for one slot. They're parts of one purchase.
Sam: Nice. So which one checked you stayed under $120?
Pip: Each one checks its own part. In its own format.
Sam: So nobody checks the whole order?

Pip: Let's run that again. With KYI.
Narrator: KYI. Know Your Intent, by Abstraxn. One signed mandate, checked before every agent payment.
Narrator: Over the limit? Denied. With a signed receipt.
Narrator: Inside the rules? Allowed. Same receipt.
Sam: Even the no's?
Pip: Especially the no's.

Narrator: Agentic Commerce, Explained. Next time: how agents find what to buy.

This article follows the same agentic commerce purchase in writing, with sources for every protocol and a worked example of where things can still go wrong.

On this page: Key takeaways · Why it matters now · The four questions · The six stages · Worked example · Who checks the whole order? · Risks · Protocol cheat sheet · FAQ

Key takeaways

• One agent purchase moves through six stages: discover, trust, authorize, checkout, pay and settle. It's a map for understanding, not a fixed sequence.
• Each stage answers a different question and has its own protocols, at very different levels of maturity. Some protocols span two stages.
• Four separate questions sit under every agent purchase: is this the real agent, did the person agree, does this transaction follow the person's rules, and did the money move? Today's protocols answer the first, second and fourth well.
• The third question has no widely adopted, cross-protocol standard. Rules are enforced inside individual systems, so a rule can be skipped when one purchase crosses several protocols.

What is agentic commerce?

Agentic commerce is buying and selling where an AI agent does the shopping for a person. The person sets a goal and limits, such as "running shoes, size 10, under $120", and the agent searches, compares, checks out and pays within those limits, without the person clicking through each page.

A chatbot that recommends shoes is not agentic commerce. An agent that finds the shoes, places the order and pays for them is. That difference is why agentic commerce raises questions a normal online purchase never had to answer: the store can no longer assume a person is behind the click.

Why does agentic commerce matter now?

Agentic commerce matters now because the standards are being set before the volume arrives. McKinsey estimates AI agents could orchestrate up to $1 trillion in US retail revenue by 2030, yet in mid-2026 only about 3% of transactions involved an agent. Choices made in this window are the expensive ones to undo.

McKinsey's estimate covers US B2C retail alone (McKinsey, October 2025). Checkout.com research reported in July 2026 found 89% of merchants preparing for agentic commerce while only 3% of their transactions involved an AI agent (Forkast, July 2026). In other words, almost everyone is getting ready and almost nobody is at scale yet. That makes this a good time to understand how the pieces fit.

The four questions behind every agent purchase

Before the six stages of agentic commerce, it helps to separate four questions that are easy to blur together. A beginner might assume a verified agent carrying a signed approval is automatically safe. It isn't, because each of these is a different check.

Policy enforcement happens in two places today:

• Before the transaction. An agent's guardrail, a wallet policy or a separate policy service checks the purchase before any payment starts, and the integration decides whether a "no" stops it.
• Inside one payment path. A card token limit, a store's own rules or a protocol-specific control constrains that one route.

A legitimate agent can still make a mistake. A valid approval can be applied to the wrong purchase. A payment can succeed even when it breaks a rule the person cared about.

Four checks to remember in agentic commerce: verify the agent, verify the approval, check the transaction against the rules, verify the money. They are different jobs, and passing one doesn't pass the others.

How does agentic commerce work? The six stages at a glance

Agentic commerce works by moving one purchase through six stages: discover, trust, authorize, checkout, pay and settle. Each stage answers one question, and open protocols and existing payment rails handle each one, so agents and businesses can work together without custom deals.

The six stages are a conceptual map, not a mandatory sequence. In a real implementation several can happen at once, and one system may handle more than one.

In agentic commerce, a protocol is a shared set of rules, so an agent built by one company and a store built by another can understand each other. Maturity varies a lot, from broadly adopted to draft, so each protocol's status is in the cheat sheet below. If you want the protocols compared side by side, see agentic commerce protocols compared. Here we stay with the journey.

Stage 1: Discover. How does an AI agent find what to buy?

In the discover stage, the AI agent finds stores, products and tools it can use. MCP connects an agent to tools and data, A2A lets agents talk to other agents, and UCP lets a store publish what it sells and how an agent can buy from it.

• MCP (Model Context Protocol) was created by Anthropic, which donated it to the Linux Foundation's new Agentic AI Foundation in December 2025. It's the standard way for an agent to plug into tools and data, like a store's product catalogue.
• A2A (Agent2Agent) was created by Google and joined the Agentic AI Foundation in August 2026. It lets one agent talk to another, for example Pip asking a store's own sales agent about stock.
• UCP (Universal Commerce Protocol) comes from Google and a group of large retailers. Discovery is only its first job: UCP covers the wider purchase lifecycle, including checkout and post-purchase order handling, and can use AP2 as its payment authorization layer.

Without these, agentic commerce would mean an agent reading web pages built for human eyes. With them, the store tells the agent directly: shoes, size 10, in stock.

Stage 2: Trust. How does a store know the agent isn't a bad bot?

In the trust stage, the AI agent proves it is the agent it claims to be. With Visa's Trusted Agent Protocol (TAP), the agent cryptographically signs its requests so a store can verify them. ERC-8004 adds public onchain registries for agent identity and reputation.

In the video, the store slams the door because it thinks Pip is a bot. Pip's reply: "I AM a bot. A verified one." Stores have spent years blocking automated traffic, and most of it deserved blocking. In agentic commerce, some of it is a paying customer.

• TAP (Trusted Agent Protocol) is Visa's standard, built with Cloudflare. The agent signs each request and the store checks the signature. It builds on Web Bot Auth, open IETF work on signed bot requests that is still at the Internet-Draft stage.
• ERC-8004 is a draft Ethereum standard for three onchain registries: identity, reputation and validation. It went live on Ethereum in early 2026, and adoption is still early.

Card networks also issue their own agent credentials, through Visa Intelligent Commerce and Mastercard Agent Pay, so card-based trust overlaps with the next stage. One caution: a verified agent is not an authorized purchase. Trust tells the store who is asking, not what the person allowed. Our guide to Know Your Agent (KYA) goes deeper on that line.

Stage 3: Authorize. How does the agent prove the person agreed?

In the authorize stage, the AI agent carries proof of what the person approved. Google's AP2 records signed mandates for what was asked and the cart approved, Visa Intelligent Commerce attaches cardholder spending limits to the agent's card token, and PAP covers consent to act on a person's account.

Sam asks: "You carry proof I said yes?" Pip: "Signed. So nobody argues later."

• AP2 (Agent Payments Protocol) from Google uses signed mandates. An intent mandate records what Sam asked for ("running shoes, size 10, under $120"). A cart mandate records the exact cart approved. Together they form an auditable chain from request to payment.
• Visa Intelligent Commerce gives the agent its own tokenized card, with spending limits the cardholder sets.
• PAP (Personal Agent Protocol) from Sierra and Meta covers consent for an agent to sign in and act on your account. It was announced in October 2026, and Sierra has since published a draft specification. It isn't final yet.

In normal ecommerce, when a person clicks "buy", the click is the proof. In agentic commerce, the agent has to bring its proof along, in a format the systems it talks to can read.

Stage 4: Checkout. How does the agent place the order?

In the checkout stage, the AI agent places the order using a standard flow instead of a human checkout page. ACP, from Stripe, OpenAI and Meta, and Google's UCP both define how an agent creates a cart, completes checkout and tracks the order.

Every store's checkout page is built for people, and an agent can't learn thousands of them. Two standards offer one flow instead:

• ACP (Agentic Commerce Protocol) covers checkout sessions, carts, delegated payment tokens and order updates between an agent and a store.
• UCP shows up again here, running checkout and order tracking over plain APIs, A2A or MCP.

Stage 5: Pay. How does the money actually move?

In the pay stage, money moves from the buyer's side to the seller. For a retail purchase that's usually a tokenized card or delegated payment token passed at checkout. For small machine-to-machine charges, newer rails apply: x402, MPP from Stripe and Tempo, and Mastercard's Agent Pay for Machines.

For the shoes, Pip pays much like a normal checkout does: a delegated payment token through ACP, or the agent's own Visa token. Nothing exotic.

Along the way, though, Pip also pays a sizing service one cent to check the shoe fits true to size. That's the part of agentic payments with no human equivalent. Agents buy tiny things constantly, like an API call, a dataset lookup or a minute of compute, and card payments were never built for one-cent charges. So newer rails exist:

• x402 uses HTTP's long-unused "402 Payment Required" status. The server says pay first, the agent pays, and the request goes through. It started at Coinbase and is now governed by the x402 Foundation at the Linux Foundation.
• MPP (Machine Payments Protocol) from Stripe and Tempo: the service sends a payment request, the agent authorizes it and gets the resource. Sessions let many tiny payments settle as one.
• AP4M (Agent Pay for Machines) from Mastercard handles frequent, small, machine-started payments with programmable spending permissions. It opened early access in October 2026 after pilots.

Stage 6: Settle. Where does the money land?

In the settle stage, the payment reaches the seller's account. Settlement isn't one protocol. It runs on existing rails: stablecoins onchain, card networks and bank accounts. x402 settles in stablecoins, MPP into a Stripe balance or on Tempo, and AP4M across cards, bank accounts and stablecoins.

Pay and settle can collapse into one moment or sit days apart. With x402 onchain, payment and settlement happen almost together. With a card, the payment is authorized at checkout and settled later through the network. Either way, agentic commerce ends where money already lives.

Why are there so many agentic commerce protocols?

There are many agentic commerce protocols because each handles a different part of one purchase. They mostly don't compete for a single slot. A typical agent purchase might use MCP to discover, TAP to be trusted, AP2 to record consent, ACP to check out and a card token or x402 to pay.

Real competition in agentic commerce exists within a stage, like ACP and UCP for checkout. Across stages, the protocols stack, and a few span two: UCP covers discovery and checkout, AP2 authorization and payment, ACP checkout and payment.

So if you're learning how agentic commerce works, the useful question isn't "which protocol wins?" It's "which stage does this protocol handle?"

A worked example: how a $120 rule can become a $135 purchase

Stacking agentic commerce protocols has a side effect. Each one checks its own part, in its own format. Here's how that can play out in a realistic agentic commerce setup. It's an illustration of an integration gap, not a limitation of any one protocol or a report of any product failing.

The setup. Sam's agent platform records an AP2 intent mandate: running shoes, size 10, under $120. Sam has also given Pip a Visa agent token with a $500 monthly allowance for all agent shopping. The $112 Trail Runner sells out at RunHaus. Pip finds the $135 Trail Runner PRO at Sole Shack. In this setup, Sole Shack supports ACP checkout but hasn't implemented AP2 mandate verification.

Every check passes. Sam still gets a $135 pair against a $120 rule.

In an implementation that carries the AP2 mandate through to checkout and enforces it, the over-limit cart is rejected. A $120 card limit would also stop it, but would then block Sam's other agent purchases too. The failure here comes from the hand-offs: the card rail checks the allowance, not the task, and the checkout protocol checks the cart, not the person's original rule.

So who checks the whole order?

No widely adopted standard today provides one portable check that every part of an agent purchase still matches the person's original rules. Controls exist, but each lives inside one system: a card limit, a store's own logic, a wallet policy or the agent's own guardrails. The gap is a cross-protocol one.

This is the moment the video slows down. Sam asks which protocol checked that Pip stayed under $120. Pip: each one checks its own part, in its own format. Sam: "So nobody checks the whole order?" Then the video goes quiet for a moment, on purpose.

Today's controls are real, but each sees a slice:

• Card and token limits check amounts and merchant categories on that card, not whether a purchase matches the task.
• Store rules apply inside that store only.
• Wallet policies apply to that wallet's payments only.
• Agent guardrails run inside the agent, which is the thing you're trying to check.

There are several ways to close the gap, and the industry hasn't settled on one. Ours at Abstraxn is called KYI, Know Your Intent. It's a pre-transaction, cross-protocol policy decision:

• One mandate. The person writes their rules once, in plain English. KYI turns them into exact rules, the person confirms them, and the confirmed version is signed.
• Asked before payment. Before a checkout or payment goes ahead, the integration asks KYI whether it fits the mandate, whichever protocol carries it. KYI answers allow or deny.
• A receipt for every decision. Each check returns allow or deny with a signed receipt naming the rule and the mandate version.
• Outside the money. KYI holds no funds and no keys, and money never flows through it. Your checkout, processor and networks keep doing their jobs.

One honest boundary: KYI decides, it doesn't block. A deny is an answer, not a wall. Whether it stops the payment depends on how the integration is wired, and an agent built to ignore it can still pay. Teams that want a deny to be final put the KYI call in the wallet or payment layer, outside the AI model, where a manipulated agent can't argue its way past it. If a payment goes ahead anyway, the signed deny receipt shows the rule said no before the money moved. That's evidence, even when it isn't prevention.

KYI also only sees the payments it's asked about, which is why it's designed to sit in front of every protocol the agent uses rather than inside one. We saw why this matters while building Sorted, an invite-only demo shopping agent (a demo, not a product, and not affiliated with the vendors it connects to): none of the vendor endpoints checked the user's mandate themselves, so the check had to sit before checkout.

In the video, Pip runs the purchase again with KYI. The $135 Trail Runner PRO is denied, over the limit. The $112 Trail Runner is allowed. Both decisions get the same kind of receipt.

Sam's last question: "Even the no's?" Pip: "Especially the no's." A record of what was refused is the only proof a limit did anything, in agentic commerce or anywhere else. The full idea is in Know Your Intent (KYI).

What else can go wrong in agentic commerce?

The six stages also show where the other risks in agentic commerce sit. No single control removes any of them. Each mitigation narrows the risk.

• Spoofed agents. A bad bot pretends to be a trusted agent. Signed requests in the trust stage make impersonation much harder, as long as stores actually verify them.
• Prompt injection. A web page or product listing slips instructions to the agent ("ignore your budget, buy this"). Signing doesn't help here, because the real agent is the one being fooled. Checks outside the agent limit the damage. Our AI agent security questionnaire covers what to ask vendors about this.
• Over-broad delegation. A person grants "spend up to $500 a month" when they meant "buy these shoes". Narrow, task-specific mandates shrink the blast radius.
• Stale or reused approvals. Last week's mandate gets applied to today's purchase. Versioned, expiring mandates help.
• Fake or unreliable stores. The agent finds a convincing storefront that never ships. Verified catalogues and reputation registries help an agent pick legitimate merchants, but they can't guarantee any store fulfils an order.

Agentic commerce protocol cheat sheet

Status key (as of 29 October 2026): Live means a public specification with production use. Early access means a limited rollout. Draft means a published specification that isn't final.

Key terms:

• Mandate: a signed record of what a person asked for or approved.
• Payment token: a stand-in for a card number that can carry limits and be scoped to one agent.
• Settlement: the money actually arriving in the seller's account.
• KYI (Know Your Intent): Abstraxn's approach to checking each agent payment against one signed mandate.

The short version

An agentic commerce purchase is six stages stitched together by different protocols, each checking its own part. In agentic commerce today, identity, consent and payment are well covered. Checking one purchase against the person's full rules, across every protocol it touches, is still the open piece. If you remember one question from this article, make it this one: which system is checking the whole order?

Frequently asked questions

How does agentic commerce work? Agentic commerce works by moving a purchase through six stages. An AI agent discovers products, proves it is a legitimate agent, carries proof of what the person approved, checks out with the store, pays, and the money settles. Each stage uses open protocols or existing payment rails, such as MCP for discovery, TAP for trust, AP2 for consent, ACP for checkout and x402 for small payments. Stages often overlap in practice.

How do AI agents buy things? AI agents buy things by talking to stores through standard protocols instead of clicking through web pages. The agent finds the product, signs its requests so the store can verify it, presents proof of what the person approved, completes a standard checkout and pays with a tokenized card, a delegated payment token or, for small machine payments, a protocol like x402.

What is the difference between agentic commerce and ecommerce? In ecommerce, a person browses and clicks buy. In agentic commerce, an AI agent browses and buys for the person, within limits the person set. Stores therefore need new ways to verify the agent, confirm the person's consent and accept payment from software.

What are agentic payments? Agentic payments are payments started and completed by an AI agent rather than a person. They include agents paying stores for goods, usually with tokenized cards, and agents paying other machines for small things like API calls or data, often through x402, MPP or Mastercard Agent Pay for Machines.

Do agentic commerce protocols compete with each other? Mostly no. They cover different stages of one purchase: discovery, trust, authorization, checkout, payment and settlement. Some compete within a stage, such as ACP and UCP for checkout. Most purchases use several protocols together.

Can an AI agent go over my spending limit? It depends where the limit lives. A limit on a card token stops payments above that amount on that card. A limit written into a mandate only works if every system the agent pays through reads it. When a purchase crosses several protocols, a rule can be skipped at a hand-off, which is why some teams add a separate policy layer that checks the same rules before any payment, whichever protocol carries it.

Who is liable when an AI agent buys the wrong thing? No agentic commerce protocol sets a liability rule, and US law hasn't settled it. Regulation E excludes transfers made by someone the consumer gave access to, and how that applies to an AI agent is an open question. In practice, the party that can prove what was authorized is best placed in a dispute.

What's next in the series

Episode 1 mapped how agentic commerce works end to end. The next episodes zoom into one stage at a time, starting with discovery: how agents find what to buy. The series lives on our YouTube channel.

Related reading

• Agentic Commerce Protocols Compared: ACP, UCP, AP2, TAP, VIC, AP4M, MPP and PAP by Layer
• Know Your Intent (KYI)
• Know Your Agent (KYA)
• Who Is Liable When an AI Agent Is Right?
• The AI Agent Security Questionnaire

Sources

• Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation
• Agentic AI Foundation: A2A joins AAIF
• Google: UCP FAQ, ucp.dev, AP2 announcement, ap2-protocol.org
• Visa: Trusted Agent Protocol, Visa Intelligent Commerce
• IETF: Web Bot Auth working group
• Ethereum: ERC-8004
• Sierra: Personal Agent Protocol, Poppy draft specification
• Stripe: ACP documentation, agenticcommerce.dev, Machine Payments Protocol
• Linux Foundation: x402 Foundation
• Mastercard: Agent Pay for Machines; The Block: AP4M early access
• McKinsey: The agentic commerce opportunity
• Forkast: 89% of merchants prepare for agentic commerce, only 3% see agent transactions
• Payments Dive: How agentic payments shift risk