Agentic Commerce: When AI Agents Buy Things

Agentic commerce is buying and selling where an AI agent does some of the shopping for a person: it searches, compares, fills a cart, and in some setups completes the checkout with a payment credential it was given. Three open specifications now define how that works. The Agentic Commerce Protocol (ACP), from OpenAI and Stripe, covers how an agent talks to a merchant’s checkout. Google’s Agent Payments Protocol (AP2) covers how a person’s authorization is captured and proven. The Universal Commerce Protocol (UCP), from a group of retailers and platforms, covers the journey from discovery to checkout. All three are young, and the most visible product built on them, buying inside ChatGPT, was scaled back in 2026. As of September 30, 2026, the honest summary is that agents are good at finding and comparing, and that paying without a person present is specified far more fully than it is used.

This page is about the protocols and the risks. What an agent can do inside one payments account is in the Stripe MCP server, the UCP catalog, cart and checkout servers on a single store are covered in Shopify MCP, and the everyday jobs an agent can do for a store owner are in AI agents for ecommerce.

Three things people mean by agentic commerce

• A shopper’s agent: you ask an assistant for running shoes under a budget, it shows options, and either sends you to the store or checks out for you.
• A business’s agent: an agent orders supplies, renews a subscription or pays for an API call as part of a job it was given, with money the business set aside for it.
• A merchant making itself readable: product feeds, checkout endpoints and signed agent traffic, so that other people’s agents can find and buy from the store at all.

The protocols below mostly serve the first and third. The second is where payments companies are building wallets and machine payments, and it is the least settled of the three.

The Agentic Commerce Protocol (ACP)

Stripe’s ACP documentation↗ (opens in a new tab) describes ACP as an open standard that defines how AI agents interact with businesses to complete purchases on behalf of buyers, built from composable pieces:

• Agentic checkout: create, update and complete checkout sessions, with cart, fulfillment options and payment.
• Cart and feed: browse a merchant’s catalog and manage a cart before checkout.
• Delegate payment: pass a payment token from the buyer, through the agent, to the business without exposing the card.
• Delegate authentication: OAuth 2.0, so an agent can act for a buyer who has an account with the business.
• Orders and webhooks: confirmation, shipping, delivery and refund updates after the sale.

The specification is versioned by date. The ACP repository↗ (opens in a new tab) marks it as beta, lists an initial release on September 29, 2025, and a version dated April 17, 2026 that added cart, feed, orders, authentication and MCP support. The vendors’ own pages do not agree on who owns it: Stripe’s documentation says ACP was created by Stripe, OpenAI and Meta, while the repository names OpenAI and Stripe as its founding maintainers. The license is Apache 2.0.

The most important design choice is who sells. OpenAI’s key concepts page↗ (opens in a new tab) says OpenAI is not the merchant of record: the checkout state and the payment stay on the merchant’s own systems, with the merchant’s own payment provider, and Stripe’s Shared Payment Token is the first implementation of the delegated payment spec. The agent carries the conversation; the store still takes the order, the money and the returns.

What happened to Instant Checkout

ACP launched in September 2025 with Instant Checkout, which let US ChatGPT users buy from some US Etsy sellers without leaving the chat. In March 2026 OpenAI said the first version of Instant Checkout did not offer the flexibility it wanted, and began letting merchants use their own checkout experiences while it concentrated on product discovery. OpenAI’s developer docs still describe the checkout, delegated payment and product feed specs. In practice, the working pattern today is discovery in the assistant and payment on the merchant’s own site.

Google’s Agent Payments Protocol (AP2)

Google announced AP2↗ (opens in a new tab) on September 16, 2025, with more than 60 payments and technology partners, as an open protocol for agent-led payments that can be used as an extension of the Agent2Agent (A2A) protocol and MCP. Where ACP is about the checkout conversation, AP2 is about proof: signed records of what the person actually authorized, so a merchant, a card network and a bank can check a purchase afterward.

The details have changed since launch, and the vendor’s pages now disagree. The announcement describes an Intent Mandate (what you asked for, with price limits and conditions) and a Cart Mandate (the exact items and price you approved). The current AP2 specification↗ (opens in a new tab), version 0.2, defines a Checkout Mandate and a Payment Mandate instead, each in an open form (your constraints, before a cart exists) and a closed form (one specific checkout or payment). Read the specification, not the launch post, if you are building on it.

• Human present: you review the final checkout and approve the closed mandates yourself before any payment.
• Human not present: you approve the constraints in advance, such as a price ceiling and a time window, and the agent assembles the closed mandates when the conditions are met.
• Roles: a shopping agent, a credential provider that holds the payment method, the merchant, the merchant’s payment processor, and a trusted surface where you give consent.

UCP, and the card networks

The Universal Commerce Protocol↗ (opens in a new tab) calls itself a common language for platforms, agents and businesses, from discovery to checkout. Its site lists Google, Shopify, Amazon, Walmart, Microsoft, Meta and Stripe among the companies that built it, says it supports AP2, A2A and MCP, and marks a lodging specification as a draft. Stripe’s agentic commerce pages offer sellers either UCP or ACP, so a merchant may meet both.

The card networks are working on the other end of the problem: telling a real shopping agent from a bot. Visa’s Trusted Agent Protocol, announced on October 14, 2025 with Cloudflare, builds on the HTTP Message Signatures standard so a merchant can verify an agent’s signed requests, and Visa’s developer page says the product is still in development and deployment. One naming trap: ACP also stands for the Agent Client Protocol, which connects code editors to coding agents and has nothing to do with shopping.

What is real and what is hype

• Real: assistants that search, compare and send you to a store to pay; merchants publishing product feeds for them; open, versioned specifications you can read and implement.
• Real, but narrow: in-chat checkout with delegated payment tokens, in limited products and regions, and scaled back at the biggest launch.
• Specified, rarely seen: an agent paying on its own when conditions are met, with no person present. AP2 describes it in detail; ordinary shoppers rarely use it.
• Hype: “your agent does all your shopping.” None of these protocols makes an agent choose well. They make its purchases traceable, limited and refundable through normal channels.

The risks to settle before an agent pays

• Prompt injection. Product pages, reviews and seller descriptions are text written by strangers. AP2’s own security section says all language models and agents must be considered potential attackers, which is why it relies on signed limits rather than on the agent behaving. How that attack works is in indirect prompt injection.
• The wrong thing, bought correctly. A mandate proves you authorized “white running shoes under a set amount”; it cannot prove the agent chose the right size. Keep the item choice with a person until you trust it.
• Repeated spending. A standing authorization that an agent can use more than once is a spending limit, not a single purchase. Set the ceiling as if the agent will reach it.
• Credentials. Give an agent a token for one purchase or one merchant, never a stored card number or a login to your bank.
• Disputes. Signed mandates give you evidence of what you approved. Whether a mistaken purchase is refunded is still between you, the merchant and your card issuer, so keep receipts and the agent’s notes together.
• Fake agents. For a merchant, the risk runs the other way: automated traffic claiming to be a customer’s agent. That is what signed agent requests are for.

A safe first setup

1. Start with human-present only: the agent researches and builds the cart, you pay.
2. Write the limits down before the first run: which merchants, which categories, the ceiling per purchase and per month.
3. Use a payment method you can cap or cancel on its own, not your main card.
4. Keep payment tools behind an approval prompt in your assistant, even when read tools run freely. The human in the loop guide explains where the prompt belongs.
5. Review a week of purchases before loosening anything.

Where a task board fits

fenbs does not buy, pay or approve payments, and it will not stop a checkout in another system. What it can hold is the paper trail around one. An agent connected over MCP at https://fenbs.ai/api/mcp can file a purchase request as a task in To Do, with the options it compared in the note and the proposed order in the plan, and a person decides. A line such as “no assistant completes a purchase” goes on the Decisions and rules page as a rule, which every connected assistant reads before it starts work, and History shows which assistant filed or changed each task. Keep card numbers and account details out of tasks; an order number is enough for a person to find the rest.