TL;DR
Agentic commerce is buying and selling where an AI agent finds, picks, and pays for something on a person's or a company's behalf, inside limits that person set. It differs from e-commerce in who reads the storefront: software reads structured catalogs and APIs instead of product pages. Four kinds of standards hold it together. ACP (OpenAI and Stripe) covers checkout with merchants, AP2 (Google) covers proof that the user authorized the purchase, Visa Intelligent Commerce and Mastercard Agent Pay give agents tokenized card credentials, and x402 and MPP let agents pay for APIs and data per request in stablecoins. Agents pay in one of two ways: a card credential issued to the agent, or a wallet the agent controls. Either way, the spending limit has to be enforced outside the model, at the point where the payment is signed.
Last updated: October 13, 2026.
Agentic commerce is buying and selling where an AI agent finds, compares, and pays for something on behalf of a person or a business, inside limits that person set in advance. The human states the goal ("restock printer paper, under 200 USD a month"). The agent does the searching, the checkout, and the payment.
It's already live. Since September 2025, ChatGPT users in the US can buy from merchants without leaving the chat through Instant Checkout, built on the Agentic Commerce Protocol that OpenAI and Stripe published as an open standard. McKinsey estimates that agents could orchestrate 900 billion to 1 trillion USD of US B2C retail revenue by 2030, and 3 to 5 trillion USD globally.
This guide covers what agentic commerce is, how a purchase works step by step, the protocols involved, and the part most explainers skip: how the agent actually pays, and who stops it from overspending.
What is agentic commerce?
Agentic commerce is commerce where the buyer is software acting for a human. The agent reads catalogs and prices, decides within the rules it was given, and completes the purchase itself.
How much the agent decides varies. At one end, the agent proposes a cart and the person taps "approve." At the other, the person signs off once ("buy concert tickets the moment they go on sale, up to 150 USD each") and the agent buys later with nobody watching. Google's AP2 names these two cases "human present" and "human not present," and they need different safeguards.
Agentic commerce is broader than agentic payments. Payments is one step. Commerce is the whole loop: discovery, comparison, checkout, payment, and fulfillment.
How agentic commerce works
A typical purchase has five steps:
- Intent. The user gives the agent a goal and constraints: budget, approved merchants, delivery date.
- Discovery. The agent queries product feeds and merchant APIs instead of reading web pages built for people.
- Checkout. The agent builds a cart and submits it through a checkout API. ACP standardizes this exchange between agent and merchant.
- Authorization and payment. The agent proves the user approved this purchase (AP2 calls the signed approval a mandate), then pays with a credential issued to the agent or from a wallet it controls.
- Fulfillment. The merchant confirms the order through an API response or a webhook, and the agent tracks delivery and handles returns.
Steps 3 and 4 are where agentic commerce breaks from e-commerce. A checkout form and a 3-D Secure challenge assume a human at a screen, and an agent has neither eyes nor a phone to receive the code.
Agentic commerce vs. e-commerce
| E-commerce | Agentic commerce | |
|---|---|---|
| Who browses | A person | An AI agent |
| What the store exposes | Product pages, images, reviews | Structured catalogs, prices, and inventory via API |
| Checkout | Hosted form | Checkout API (ACP) |
| Proof of consent | The person clicked "buy" | Signed mandate (AP2) or limits set in advance |
| Payment method | The person's card | Agent-specific card token or an agent wallet |
| Fraud question | Is this the cardholder? | Is this a trusted agent, and did the user authorize this purchase? |
The protocols behind agentic commerce
No single standard covers the whole purchase. Each of these covers one step:
- ACP (Agentic Commerce Protocol). Built by OpenAI and Stripe and open-sourced. It defines how an agent and a merchant agree on a cart and complete checkout. It powers Instant Checkout in ChatGPT.
- AP2 (Agent Payments Protocol). Google's standard for proving consent. The user signs an Intent Mandate with the rules, and an approved cart becomes a Cart Mandate, a tamper-proof record of the exact items and price.
- Visa Intelligent Commerce and Mastercard Agent Pay. The card networks' programs for agents. They issue tokenized card credentials to agents, and Visa's Trusted Agent Protocol lets merchants tell a registered shopping agent from a scraper bot.
- x402 and MPP. These make payment part of an HTTP request. A server answers
402 Payment Requiredwith a price, the agent pays in stablecoins, and the server returns the resource. They fit API calls, data, and compute that cost cents. How x402 works covers the request flow.
These standards mostly stack rather than compete. One purchase can use AP2 for consent, ACP for checkout, and a card token or x402 for payment. The agentic payments comparison goes through them layer by layer.
How AI agents pay: cards or wallets
Agents pay in one of two ways, and vendors are splitting along that line. On October 8, 2026, Crossmint launched an Agent Commerce Toolkit that bundles Visa Intelligent Commerce and Mastercard Agent Pay credentials with merchant checkout behind one API. That's a bet on cards.
Card credentials suit purchases from existing online stores. The merchant already accepts cards, chargebacks still work, and the user keeps the protections they're used to. The cost is the card fee on every transaction, which rules out paying 0.002 USD for one API call.
Agent wallets suit machine-to-machine purchases: per-request API pricing, data, compute, and payments between agents. The agent holds stablecoins in a wallet it can sign with, settles over x402 or MPP, and pays fractions of a cent without a card fee eating the whole amount. There's no chargeback, so limits have to hold before the payment, not after.
Many products will need both: a card token for buying from stores, and a wallet for the long tail of small machine payments.
Where the spending limit lives
An agent that can be talked into something will eventually be talked into something. Prompt injection in a product listing, a bad tool result, or a plain reasoning error can all push an agent toward a purchase the user never wanted. A limit written into the system prompt is a request, not a control.
The limit has to live where the money moves:
- With cards, the issuer enforces it: a per-agent token with a spending cap and a merchant restriction.
- With wallets, the signer enforces it. The key that authorizes the payment sits outside the model, and a policy decides what it will sign.
This is how Openfort's agentic wallets work. The agent gets its own backend wallet, and you attach a signing policy that lists the chains, contracts, and operations it may use. Openfort checks that policy server-side and fails closed: if policies exist and no rule matches, the request is rejected. For backend sends, call policies_evaluate as a pre-flight check before submitting, as the docs describe. The x402 and MPP recipes show an agent paying for an HTTP resource from one of these wallets.
What to build if you sell to agents
If agents are going to buy from you, they need to read your catalog and complete checkout without a browser:
- Publish a structured catalog. Prices, stock, variants, and shipping times as data, not only as HTML.
- Offer a checkout API. Support ACP if you want to appear in ChatGPT's Instant Checkout. A clean REST checkout is the minimum otherwise.
- Recognize trusted agents. Use Visa's Trusted Agent Protocol or equivalent signatures, so you don't block legitimate agents along with scrapers.
- Price per request where it fits. If you sell API calls or data, an x402 or MPP endpoint lets agents pay per call without an account or a subscription.
- Return machine-readable results. Order status, receipts, and errors as structured responses or webhooks, not emails.
If you're building the agent instead, give it a payment method you control the limits on: a card token with caps, or a policy-bound wallet for the agent. Never give it the user's own card number or a raw private key.







