# Agentic commerce

Agentic commerce is shopping and payment carried out by AI agents for people. Learn mandates, agent payment protocols, merchant catalogues, fraud and liability.

## Overview

Agentic commerce is shopping done by software agents for people. Instead of a person searching, comparing, filling a basket and typing card details, they tell an agent what they want: "a waterproof hiking jacket, size medium, under 150 pounds, delivered by Friday". The agent searches catalogues, compares options, builds a basket and, with the person's approval or within limits set in advance, pays. The merchant, the payment provider and the bank all need to trust that this purchase is what the person really wanted.

That trust is the hard part. Card payments were designed for a human at a checkout page. Fraud systems look for human patterns, and disputes rely on a person saying "I did or did not authorise this". When an agent is in the middle, new questions appear. Did the user really approve this exact basket? Was the agent tricked by a fake listing? If the item is wrong, who pays? Agentic commerce is the set of protocols, credentials and practices designed to answer those questions.

An everyday comparison is sending a trusted assistant to buy a gift with a signed note: "Buy one blue scarf, up to 40 pounds, from a reputable shop, and keep the receipt." The note limits what the assistant can spend, the shop can see who authorised it, and the receipt proves what happened. Agent payment protocols turn that note into a digitally signed record. This page explains the moving parts and connects to [e-commerce](/tools/e-commerce), [fintech](/tools/fintech), [OAuth for tool access](/tools/oauth-for-tool-access) and [human-in-the-loop](/tools/human-in-the-loop) design.

## What it is

Agentic commerce involves several parties and artefacts.

| Part | Role |
|---|---|
| User | The person whose money and preferences are involved |
| Shopping agent | The AI that searches, compares, builds the basket and initiates payment |
| Merchant | The business selling the goods or services |
| Catalogue or feed | Machine-readable product, price and availability data the agent can query |
| Checkout interface | An API or protocol through which the agent creates and completes an order |
| Mandate | A signed record of what the user authorised: limits, items, price, merchant |
| Payment credential | A token that lets the agent pay without seeing raw card details |
| Credential or payment provider | Issues and scopes payment credentials and checks authorisation |
| Network and issuer | Card networks and banks that authorise, settle and handle disputes |
| Agent verification | Ways for merchants to tell a registered agent from a malicious bot |

It helps to think in three stages: discovery (finding and comparing), decision (choosing and getting user authorisation) and payment (moving money with evidence). Each stage needs different technology.

## Where it came from

Automated buying is not new. Price-comparison sites, scheduled reorders and stored-card "one-click" checkouts all removed steps from human shopping. What changed in 2024 and 2025 was that language models with [function calling](/tools/function-calling) and [browser use](/tools/browser-agents) could carry out a whole purchase from a plain-language request. Early agents often worked by driving the merchant's website like a person, which was fragile and hard for merchants and fraud systems to distinguish from abuse.

In 2025 several protocols were proposed so that agents could transact through designed interfaces instead.

- In May 2025 Coinbase introduced x402, which revives the HTTP 402 "Payment Required" status code so a website or API can ask for payment within an ordinary web request. In April 2026 Coinbase contributed x402 to the Linux Foundation, which formed the x402 Foundation with participants including Google, Stripe, Visa, Mastercard, Shopify and Cloudflare.
- In September 2025 Google announced the Agent Payments Protocol (AP2), an open protocol built as an extension of the [Agent2Agent protocol](/tools/a2a) and designed to work with [MCP](/tools/mcp), with more than 60 organisations named as partners. Its central idea is the mandate: a cryptographically signed record of user authorisation.
- On 29 September 2025 OpenAI and Stripe released the Agentic Commerce Protocol (ACP), an open standard under the Apache 2.0 licence, alongside Instant Checkout in ChatGPT. Stripe's Shared Payment Token let the agent start a payment scoped to one merchant and one cart total without exposing the buyer's card details.
- By October 2025 Visa and Mastercard had both published agent verification schemes, Visa's Trusted Agent Protocol and Mastercard's Agent Pay, which use Web Bot Auth, a method of signing agent HTTP requests.
- In January 2026 Google launched the Universal Commerce Protocol (UCP) at the National Retail Federation conference, co-developed with Shopify, Etsy, Wayfair, Target and Walmart, covering discovery, basket, checkout and post-purchase steps.

The field is moving quickly. In March 2026 OpenAI said Instant Checkout would move into merchants' apps inside ChatGPT, with ACP continuing as the connecting infrastructure. AP2's specification has also evolved: the original announcement described Intent, Cart and Payment Mandates, while version 0.2 of the specification, current at the time of writing, describes Checkout and Payment Mandates with open and closed forms. Expect further change.

## How it works

### Discovery: how merchants expose catalogues to agents

Agents need structured, current data: product attributes, prices, stock, delivery options and policies. Scraping web pages is slow and error-prone. Merchants therefore publish product feeds and agent-facing APIs. ACP describes publishing checkout configuration through an API or MCP. UCP has merchants publish business profiles that describe their capabilities and accepted payment options, and supports API, A2A and MCP bindings. Good catalogue data uses consistent identifiers, explicit units, clear variant structure and machine-readable return and delivery terms. Structured data also helps the agent's [recommendation](/tools/recommendation) and ranking logic choose fairly.

### Decision: mandates and user authorisation

The core problem is proving what the user wanted. Protocols separate two situations.

- Human present: the user reviews the final basket and approves it on a trusted screen. The approval is signed and bound to that exact basket.
- Human not present: the user signs, in advance, a mandate with constraints, such as "running shoes, size 43, under 120 pounds, from these merchants, before 1 December". The agent may later buy only within those limits, and each purchase carries proof that it fits the earlier mandate.

AP2 version 0.2 represents these as open mandates (constraints signed by the user) and closed mandates (a specific checkout and payment, signed by the agent within those constraints), secured as selective-disclosure JWTs. The merchant signs the checkout so the basket cannot be changed after approval, and receipts close the loop. The logic is easy to state:

```text
allowed(purchase) ⇔ signed_by_user(M) ∧ now < M.expiry
                     ∧ purchase.merchant ∈ M.merchants
                     ∧ purchase.items ⊆ M.item_constraints
                     ∧ purchase.total ≤ M.max_amount
                     ∧ hash(purchase.checkout) = closed_mandate.checkout_hash

expected_loss ≈ P(fraud or error) × average_amount × (1 − recovery_rate)
```

`M` is the user's open mandate, with its expiry, allowed merchants, item constraints and maximum amount; `purchase` is the order the agent wants to make; and the final condition checks that the checkout the agent signed is exactly the one the merchant presented. In the second line, `P(fraud or error)` is the chance a transaction is fraudulent or wrong, `average_amount` is the typical order value, and `recovery_rate` is the share recovered through refunds or disputes. Mandates aim to lower the probability and raise the recovery rate by providing evidence.

### Payment: credentials the agent never sees

Agents should not hold raw card numbers. Instead a credential provider issues a scoped token. Stripe's Shared Payment Token, used with ACP, is limited to a specific merchant and cart total. Card networks issue network tokens that stand in for the card. AP2 describes a credential provider that checks the agent is authorised and scopes the credential to the checkout. x402 takes a different route for small, machine-to-machine payments: the server replies 402 with payment terms, and the client pays, for example with a stablecoin, then retries the request.

### Verification: telling good agents from bad bots

Merchants already block bots. Agent verification lets them allow good ones. With Web Bot Auth, an agent signs each HTTP request using HTTP Message Signatures (RFC 9421) with a key listed in a public directory. Visa's and Mastercard's schemes add tags saying whether the agent is browsing or paying and require a fresh nonce in each signature to stop replay. Merchants or their network edge can verify the signature before serving the request.

### Risk, fraud and liability

New risks appear alongside old ones. Prompt injection in product pages can steer an agent to a scam merchant. Fake listings can be written to attract agents. An agent can misunderstand a size or quantity. Stolen agent credentials can be used to buy at scale. Defences include allow-listed merchants, strict mandates, merchant-signed checkouts, verified agent identities, velocity limits, signals to the issuer that an agent was involved, and step-up confirmation for unusual orders.

Liability is less settled. Card schemes have long-standing rules for who bears losses in disputes, but how those rules apply when an agent made the purchase is still being worked out by networks, providers and regulators, and sources differ. What the protocols contribute is evidence: signed mandates and receipts that show what the user authorised and what the merchant presented, which makes disputes easier to resolve whichever party bears the loss.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Mandate | A signed record of what a user authorised an agent to buy |
| Open mandate | A user-signed set of constraints for future purchases |
| Closed mandate | A signed authorisation for one specific checkout or payment |
| Human present | The user approves the final purchase in real time |
| Human not present | The agent buys later within limits the user set in advance |
| Shared Payment Token | Stripe's token scoped to one merchant and cart total |
| Network token | A card-network token that replaces the real card number |
| Product feed | A structured file or API describing products, prices and stock |
| Web Bot Auth | A method for agents to sign HTTP requests so sites can verify them |
| x402 | A protocol using HTTP 402 to request and settle payments within web requests |
| Merchant of record | The party legally responsible for the sale |
| Step-up confirmation | Asking the user to approve when an order looks unusual |

## A worked example

This is an illustrative scenario, not a description of any real company or protocol implementation.

A user asks their assistant: "Reorder coffee beans when we run low. Same roaster, 1 kg bags, never more than 30 pounds per order, no more than twice a month." The assistant shows these limits on a confirmation screen, and the user approves, creating an open mandate valid for six months, for one merchant, with a 30-pound ceiling and a frequency limit.

Three weeks later the smart scale reports 150 grams left. The agent:

1. Queries the roaster's product feed: the usual 1 kg bag is 24 pounds, in stock, delivery in two days.
2. Requests a checkout through the roaster's agent-facing API. The roaster returns a signed checkout: one bag, 24 pounds, plus 3.50 pounds delivery, total 27.50 pounds.
3. Checks the mandate: correct merchant, 27.50 is below 30, one order this month. All conditions pass.
4. Creates a closed mandate bound to the hash of that signed checkout and asks the credential provider for a payment token scoped to this merchant and 27.50 pounds.
5. The roaster charges the token; the payment request carries a signal that an agent made it, under a user-signed mandate.
6. The agent sends the user a receipt.

The next month a sale page offers a 2 kg bag for 38 pounds. The agent's ranking logic flags it as better value, but the mandate check fails because 38 exceeds 30. The agent does not buy; it asks the user, who can approve once or raise the limit. Later a look-alike site injects text claiming to be "the roaster's new store". It is not on the mandate's merchant list, so no checkout is attempted. The signed records from each step would let the user, roaster and bank resolve any dispute quickly.

## Strengths and limitations

**Strengths:**

- Saves users time on routine and complex purchases.
- Mandates give clear, signed evidence of what was authorised.
- Scoped tokens keep card details away from agents and merchants that do not need them.
- Structured catalogues and checkouts are faster and more reliable than screen-scraping.
- Agent verification lets merchants welcome good agents while blocking abuse.
- Open protocols reduce the need for one-off integrations with each AI platform.

**Limitations:**

- Several competing protocols exist and are still changing; integrations may need rework.
- Liability rules for agent-initiated purchases are not settled.
- Agents can be manipulated by injected content, fake listings or biased rankings.
- Users may over-delegate, setting broad mandates they later regret.
- Merchants must invest in clean data and new APIs before agents can buy from them.
- Merchants lose some direct customer contact when an agent sits between them and the buyer.

## How it compares with alternatives

| Approach | How purchases happen | Trust evidence | Main drawback |
|---|---|---|---|
| Protocol-based agentic commerce (AP2, ACP, UCP) | Agent uses structured catalogue and checkout APIs with mandates | Signed mandates, scoped tokens, receipts | Immature, fragmented standards |
| Agent driving a website ([browser agent](/tools/browser-agents)) | Agent clicks through pages like a person | Little beyond normal checkout | Fragile, hard to distinguish from bots |
| Traditional [e-commerce](/tools/e-commerce) checkout | Person browses and pays | Card authentication, user present | Slow for routine or complex buying |
| Subscription or auto-replenishment | Merchant charges on a schedule | Stored card and terms of service | Rigid; no comparison across merchants |
| Machine payments with x402 | Server returns 402; client pays per request | On-chain or facilitator receipt | Mainly suited to small, API-style payments |

## Practical guidance and best practices

1. For agents: show the user mandate limits in plain language and require explicit approval before signing.
2. Keep mandates narrow: specific merchants, item constraints, a maximum amount, a frequency limit and an expiry.
3. Bind each payment to a merchant-signed checkout so the basket cannot change after approval.
4. Never give the model raw payment credentials; use scoped tokens obtained outside the model.
5. Treat all web content as untrusted and defend against [prompt injection](/tools/prompt-injection-defense) in product pages.
6. Ask for step-up confirmation for new merchants, unusual amounts or changes from the user's habits.
7. For merchants: publish accurate, structured feeds with stock, prices, delivery and return terms.
8. Verify agent identity with signed requests and keep the ability to set your own rules for agents.
9. Keep mandates, checkouts and receipts so disputes can be resolved with evidence.
10. Watch the protocols you adopt; note versions and plan for change.

## Common mistakes

- Treating "the user said buy it" in a chat log as enough proof of authorisation.
- Letting the agent hold card numbers or long-lived payment credentials.
- Writing mandates so broadly ("anything under 1,000 pounds") that they offer little protection.
- Blocking all automated traffic, including verified agents, and losing legitimate sales.
- Publishing feeds with stale prices or stock, so agent orders fail or disappoint.
- Assuming liability will fall on someone else without checking scheme rules and contracts.

## Frequently asked questions

### What is the difference between AP2, ACP and UCP?

All three aim to let agents transact through designed interfaces. AP2, from Google, focuses on mandates and verifiable proof of user authorisation, and is payment-method agnostic. ACP, from OpenAI and Stripe, focuses on agent checkout with merchants and scoped payment tokens. UCP, from Google with retail partners, covers the wider journey from discovery to post-purchase. They overlap, and their relationship is still evolving.

### Can an agent buy something without me watching?

Yes, if you sign a mandate in advance that sets limits. The agent may then buy only within those limits, and each purchase must prove it fits. For anything outside the limits, a well-designed agent asks you first.

### Does the agent see my card number?

It should not. Agent payment designs use tokens scoped to a merchant and amount, issued by a payment or credential provider outside the model.

### How do merchants know an agent is legitimate?

Through agent verification, such as signed HTTP requests whose keys are listed in public directories run by networks or platforms. Merchants can then decide what verified agents may do.

### Who is liable if the agent buys the wrong thing?

It depends on the scheme rules, the contracts between the parties and local law, and these are still being worked out for agent purchases. Signed mandates and receipts help show whether the agent stayed within what the user authorised.

### What is x402 for?

It is aimed at payments embedded in web requests, such as paying per API call or per article. A server answers with HTTP 402 and payment terms, and the client pays and retries. It suits small, automated payments more than full retail checkout.

## Glossary

- Agentic commerce: buying and selling carried out by AI agents for people.
- Shopping agent: the AI that searches, decides and initiates payment.
- Mandate: signed proof of what the user authorised.
- Intent mandate: in AP2's original design, the user's pre-signed constraints.
- Cart mandate: in AP2's original design, the user's approval of an exact basket.
- Scoped payment token: a payment credential limited to a merchant and amount.
- Product feed: structured product data for agents.
- Agent verification: proving an agent's identity to a merchant.
- Web Bot Auth: signing agent HTTP requests with published keys.
- Step-up: extra user confirmation for risky purchases.
- Chargeback: a disputed card payment reversed through the issuer.

## Summary

Agentic commerce lets AI agents find products, decide and pay for people. Making it safe depends on three things: structured catalogues and checkouts so agents act on accurate data, mandates that give signed proof of what the user authorised, and payment tokens that let agents pay without ever seeing card details. Protocols such as Google's AP2, OpenAI and Stripe's ACP, Google's UCP, Coinbase's x402 and the card networks' agent verification schemes address different parts of this, and at the time of writing they are still evolving and overlapping. Keep mandates narrow, bind payments to signed checkouts, verify agents, defend against injected content and keep the evidence. This page is general information, not legal advice.