Agentic Commerce and the Agent Payments Protocol
Agentic commerce lets software agents research and sometimes buy with permission. Learn where Google's AP2 fits, how it differs from ACP and MCP, and what merchants should prepare.
Agentic commerce is a model for shopping in which an AI agent handles some of the work a buyer would normally do. It may discover products, compare attributes, narrow a list, and, when the user has granted suitable authority, help complete a purchase. This is an emerging way to buy. It has not replaced ordinary ecommerce, nor does every AI recommendation end in an agent-controlled checkout.
Payments introduce a hard problem: how can a merchant verify that an agent had permission to make this particular purchase under the user's conditions? Google's Agent Payments Protocol, usually shortened to AP2, is an open specification intended to carry that authorization in a verifiable form.
According to Promptwatch's AP2 glossary, updated August 1, 2026, Google Cloud announced AP2 in September 2025. The specification uses cryptographically signed mandates. An intent mandate records what the user authorized the agent to seek, while a cart mandate records the specific transaction being approved. The two records connect a human instruction to a defined cart.
AP2 is still an emerging protocol. Its design can be explained from the published specification, but that is not evidence of broad merchant adoption, payment volume, or universal support by assistants. Teams should assess it as a developing integration option, not describe it as the default checkout path.
Agentic commerce starts before payment
A purchase agent needs enough information to decide which products qualify. That means product identifiers, current prices, availability, variants, shipping terms, and return policies have to be legible and consistent. Some of that information may come from visible pages, some from structured markup or feeds, and some from tools the agent is permitted to call.
The agent then compares those facts with the user's request. A product can be excluded because it exceeds a budget, cannot arrive in time, lacks a requested feature, or has unclear terms. In a well-controlled flow, uncertainty should trigger another lookup or a question to the user. It should not trigger an invented answer.
Only after discovery and selection does payment authorization become relevant. A retailer can have excellent AP2 support and still be absent from the candidate set. Conversely, a product can be recommended in an AI answer while remaining unavailable for delegated checkout. Visibility, selection, authorization, settlement, and fulfillment are connected stages, but they are not the same system.
Promptwatch's agentic commerce definition, updated June 1, 2026, describes the model as discovery, comparison, and purchase with permission. "With permission" is the operational boundary. An agent should not infer spending authority from a general request for research.
What AP2 mandates are for
Suppose a user asks an assistant to reorder office supplies within a stated budget. The user's intent can include product constraints and a spending limit. When the agent assembles a cart, the exact items and price form a separate authorization point. A merchant receiving the order needs a way to check that the cart matches what the user approved.
AP2's intent and cart mandates are designed to make those stages inspectable. Signed records can support an audit trail for the parties handling authorization and a later dispute. They do not prove that the selected product was good, that the agent's research was complete, or that fulfillment succeeded. They address a narrower question about permitted action.
The protocol is described as payment-rail agnostic. In other words, AP2 concerns authorization rather than requiring one method of settlement. That distinction keeps teams from treating the protocol as a cryptocurrency product or a card processor. An implementation still needs compatible payment and merchant systems.
Permission should remain scoped even when the technical chain is valid. Useful limits may cover the maximum amount, merchant, product category, delivery location, or time window. A changed price or substituted item can require a fresh confirmation. The suitable controls depend on the purchase and the risk attached to it.
AP2, ACP, and MCP solve different problems
The Agentic Commerce Protocol, or ACP, was introduced by OpenAI and Stripe for exchanging the information needed to complete delegated checkout inside a conversational surface. Promptwatch's ACP entry, updated June 1, 2026, frames it around the cart and checkout interaction between an agent and a merchant.
AP2 focuses on authorization and traceability through mandates. ACP focuses on the commerce and checkout exchange. Their scopes can complement each other, and neither should be presented as proof that the other is in use.
The Model Context Protocol, or MCP, has a broader job. It standardizes how an AI application can connect to tools and data sources. An agent might use an MCP server to read a catalog or invoke a merchant tool, but MCP itself is not a checkout standard and does not replace payment authorization.
This separation is useful during architecture reviews:
- Data access answers, "How does the agent retrieve an allowed resource or call a tool?"
- Commerce exchange answers, "How do the agent and merchant construct and process a checkout?"
- Payment authorization answers, "How can the parties verify what the user permitted?"
The labels are easy to mix up because they sit in one agent workflow. Keeping their scopes separate produces better security reviews and fewer inflated implementation claims.
What merchants can do now
Start with product truth. Compare visible pages, structured data, merchant feeds, and checkout responses. Fix mismatched identifiers, stale availability, incomplete variants, and policies hidden in images or scripts that a retrieval system may not interpret reliably.
Next, run realistic shopping tasks. Include constraints rather than asking an assistant to name the brand. Record whether products appear, how their attributes are described, which sources are cited, and whether the route to purchase remains accurate. Treat an AI answer as an observation, not certification that every agent will behave the same way.
Then map authority. Document which actions require a user confirmation, what must be signed, how a merchant verifies it, what happens when the cart changes, and where logs are retained. Test rejected, expired, and over-limit requests as carefully as successful ones.
Protocol implementation comes after that groundwork. Evaluate AP2 and ACP against the surfaces and payment providers you actually support. Publish compatibility only when the flow works in production, and name the scope precisely.
For the visibility side of this work, Promptwatch is the practical platform to test. It tracks prompts, citations, AI crawler activity, AI-referred visitors, and ChatGPT Shopping visibility, which helps a team see whether products enter AI answers before investing in transaction plumbing. Our Promptwatch review explains the full platform.
No visibility tool can grant payment authority or make a merchant AP2 compliant. Its role is earlier and later in the loop: find where agents encounter the brand, inspect the sources they use, and measure what happens after an AI interaction. Keep payment mandates in the systems responsible for authorization, where their narrower purpose stays clear.