Agentic Commerce Protocols
How new protocols allow businesses, AI agents and payment networks to communicate and transact.
The web was designed primarily for people to browse pages, fill in forms and complete purchases through graphical interfaces. AI agents introduce another way to interact with businesses: software can discover products, interpret commercial information, call APIs, negotiate a workflow and initiate actions on behalf of a person or organisation.
Agentic commerce protocols provide common rules for these interactions. Some define how a shopping or checkout workflow operates. Others establish payment authorisation, recognise trusted agents, facilitate machine-to-machine payments or connect AI applications to external tools.
This guide examines seven important technologies and explains how they fit together. Protocol specifications, implementations and commercial availability evolve, so the relevant official documentation should always be checked before implementation.
On this page
Start with the overall architecture, then explore each protocol and its role in the Agentic Web.
Why does agentic commerce need protocols?
A successful transaction requires more than an AI model that understands what a customer wants.
Without shared protocols, every AI platform and merchant could require a different integration. Common interfaces can reduce that duplication, but they do not eliminate the need for correct data, secure implementation, payment processing, fraud controls or explicit authorisation.
The Agentic Commerce Protocol Stack
Think of these protocols as complementary building blocks, not seven competing solutions to exactly the same problem.
Important: the boundaries overlap. UCP can use MCP as a transport, AP2 can complement a commerce workflow, and payment-network mechanisms can provide trust around agent interactions. A merchant does not necessarily need every protocol. The appropriate combination depends on the agents, platforms, customers and payment methods it intends to support.
1. ACP — Agentic Commerce Protocol
A structured way for AI agents, buyers, sellers and payment providers to coordinate a purchase.
The Agentic Commerce Protocol (ACP), developed by Stripe and OpenAI, is an open specification for programmatic commerce flows. It is intended to let compatible AI platforms initiate and manage checkout with merchants without requiring the agent to navigate every step of a conventional website manually.
Instead of relying exclusively on browser automation, an agent can communicate with a seller through defined interfaces to create and update a checkout, provide buyer selections, retrieve totals and proceed towards completion.
How ACP works
What ACP means for merchants
ACP can provide a more deterministic alternative to relying entirely on an agent interpreting page layouts and automating form fields. It is designed to work with existing commerce backends and compatible payment infrastructure.
However, implementing ACP does not automatically list a merchant in every AI shopping application. Platforms can have their own onboarding, eligibility and integration requirements.
ACP is an open specification, but individual integrations still need to implement its requirements correctly. Merchants should check the current specification, compatible payment methods and supported agent platforms before committing to an integration.
Best understood as: a programmatic commerce and checkout interface between an AI agent and a seller, with associated mechanisms for payment credential handling.
2. UCP — Universal Commerce Protocol
A common framework for discovering and coordinating commerce capabilities across businesses and AI platforms.
The Universal Commerce Protocol (UCP) is an open commerce framework developed through Google's commerce work with ecosystem partners. It defines standardised capabilities that businesses and platforms can use to coordinate shopping, checkout and related commerce operations.
UCP uses machine-readable profiles to advertise protocol
information, services, capabilities and payment handlers.
A business can publish its profile at the well-known path
/.well-known/ucp, giving compatible platforms a
standard discovery entry point.
What can UCP describe?
How UCP relates to other protocols
UCP is designed to support more than one transport. Its service definitions can use REST, MCP, A2A or supported embedded interaction patterns. These are different ways of carrying out or exposing the operations defined by the commerce framework.
UCP can also work with payment handlers and complementary authorisation mechanisms. For example, AP2 can provide a framework for cryptographically verifiable payment mandates when the appropriate integration and extensions are supported.
What merchants should understand
Publishing a UCP profile is a discovery and capability declaration step. It does not, on its own, prove that every advertised endpoint works, that product information is accurate, or that a complete transaction can succeed.
A proper implementation needs valid profile data, accessible endpoints, compatible schemas, correct capability negotiation, appropriate authentication and payment handling.
Best understood as: a structured commerce framework that describes capabilities and the interfaces through which compatible platforms can use them.
3. AP2 — Agent Payments Protocol
How can a business establish that an AI agent is authorised to make a particular payment?
The Agent Payments Protocol (AP2) is an open protocol designed to support secure, verifiable agent-led payments. Developed through Google's work with industry partners, AP2 addresses a central difficulty in agentic commerce: an AI agent may be able to initiate a transaction, but its technical ability to do so does not establish that the user authorised it.
Traditional checkout often relies on a person directly interacting with a trusted payment interface. Agentic workflows may involve instructions given earlier, automated actions performed later, or transactions carried out without the user being present at every step.
Mandates and verifiable intent
AP2 uses cryptographically verifiable mandate structures to represent authorisation and relevant constraints. A mandate can record the user's intent and establish limits on what an agent may do.
In an autonomous workflow, an open mandate can express pre-authorised conditions. A transaction-specific, closed mandate can bind that authority to a particular action. The resulting chain of evidence helps a verifier assess whether the transaction falls within the granted authority.
Why AP2 matters
A payment system should not interpret an agent's request as unlimited authority. The request must be evaluated against the permissions and constraints under which the agent operates.
AP2 is intended to complement commerce and connectivity protocols rather than replace every checkout API, payment processor or card network. It can be used with relevant agent and commerce frameworks, including UCP integrations that support the appropriate AP2 mechanisms.
Best understood as: a framework for expressing and verifying payment authorisation and user intent in agent-driven transactions.
4. MPP — Machine Payments Protocol
A way for software agents to pay programmatically for digital services, resources and usage.
The Machine Payments Protocol (MPP), co-authored by Stripe and Tempo, is an open standard for internet-native machine payments. It addresses situations in which an agent needs to obtain a service or resource and pay for it without a conventional human-operated checkout at every interaction.
Examples include paying for API calls, data access, computing resources, model usage and other digital services. Depending on the implementation, the payment model can support usage-based charges, microtransactions or recurring machine-driven activity.
The payment challenge pattern
HTTP already defines status code 402 Payment Required.
MPP can use a payment challenge to let a service communicate
that payment is required and provide information about how
the client can satisfy that requirement.
What makes machine payments different?
MPP is not the same as AP2
The distinction is useful. MPP focuses on the payment interaction between a client and a service. AP2 focuses on representing and verifying the authority behind an agent-led payment. They address related but different questions.
MPP should also not be treated as synonymous with every system that uses HTTP 402. Other payment systems, including x402-based implementations, use the same HTTP status code. The status code alone does not prove that a service implements MPP.
Best understood as: a protocol for programmatic payments between agents and services, particularly where payment can be tied to individual resource requests or usage.
5. Visa Trusted Agent Protocol (TAP)
How can a merchant distinguish a verifiable, trusted commerce agent from an unknown or potentially malicious bot?
Visa's Trusted Agent Protocol provides a framework for recognising trusted agents during commerce-related interactions. It is designed for situations in which a merchant may encounter an agent it does not already know, including agents browsing products or attempting to complete a purchase.
Traditional bot detection often relies on traffic patterns, user-agent strings, IP addresses or allowlists. These signals can be useful, but they do not independently establish the identity of an agent or prove that its request has not been altered.
TAP uses cryptographically signed messages and verifiable credentials to provide stronger evidence about the agent and the purpose of its interaction.
How the trust mechanism works
How merchants can use TAP
A merchant or its site-protection provider can verify supported signatures, resolve the relevant keys and use the resulting evidence to make informed decisions about agent traffic. The merchant can apply appropriate policies to the interaction rather than relying solely on whether a request looks automated.
TAP does not require every merchant to adopt the protocol. Its benefits depend on participation and correct verification. A request that contains an agent-related header is not, by itself, proof of trusted identity.
TAP should also not be confused with a universal permission for an agent to purchase anything. Agent recognition, consumer intent, payment authorisation and the merchant's own acceptance rules remain distinct considerations.
Best understood as: a cryptographic trust framework for recognising participating agents and evaluating their commerce-related requests.
Official Visa Trusted Agent Protocol documentation · TAP specifications
6. Mastercard Agent Pay
Network-backed approaches to secure, traceable and controlled payments initiated by AI agents.
Mastercard Agent Pay is Mastercard's programme and technology offering for agentic payments. It builds on payment-network capabilities, including tokenisation, to support transactions in which an AI agent acts on behalf of a consumer or business.
A central concern is how to let an agent participate in a transaction while preserving meaningful controls over identity, payment credentials, user consent and transaction authority.
Core concepts
Agent Pay and Agent Pay for Machines
Mastercard's wider work now includes Agent Pay for Machines, which addresses machine-to-machine purchases of digital services. It builds on the x402 payment-request pattern and connects programmatic payments with Mastercard's trust and payment infrastructure.
In the machine-payment scenario, a business can give an agent a defined task and budget. When the agent encounters a paid service, a payment request can trigger a payment authorisation flow within the permitted limits.
This is related to, but not identical to, consumer shopping through an AI assistant using network-backed payment credentials. The particular Mastercard product, implementation and availability must be checked rather than assuming that all Agent Pay capabilities use the same transaction flow.
What merchants should consider
Mastercard Agent Pay is not simply a file format that any merchant can enable by adding a line of HTML. Participation depends on the applicable payment infrastructure, partners, eligibility requirements and supported implementations.
Merchants should distinguish general protocol compatibility from actual network participation and payment acceptance. Publishing machine-readable product data does not automatically enable Mastercard Agent Pay transactions.
Best understood as: a payment-network approach to trusted, controlled agentic transactions, including tokenised consumer payments and newer machine-payment use cases.
Official Mastercard Agent Pay information · Mastercard Agent Pay for Machines
7. MCP — Model Context Protocol
A standard way for AI applications to discover and use external tools, resources and capabilities.
The Model Context Protocol (MCP) provides a common interface between AI applications and external systems. An MCP client can connect to an MCP server that exposes supported tools, resources and prompts.
Rather than requiring every AI application to implement a completely different integration for every service, MCP defines common communication patterns and message structures. It is a general-purpose connectivity protocol, not a commerce protocol in itself.
What does an MCP server expose?
MCP in a commerce environment
A merchant might expose tools that allow an authorised agent to search products, retrieve specifications, check stock or obtain delivery information. An MCP server can also act as an interface to an underlying commerce API or, where supported, expose operations associated with a framework such as UCP.
However, an MCP tool that reports a product price is not automatically a checkout system. An MCP server that exposes a purchase tool is not automatically a secure payment authorisation system either.
The server still needs appropriate access controls, validation, error handling, protection against unsafe inputs, and clear limits on the actions that can be performed. Tools that change state or initiate transactions deserve particular scrutiny.
MCP and agentic commerce
MCP can provide the connectivity layer through which an AI application accesses merchant capabilities. A commerce protocol can define the meaning and lifecycle of the business operations, while separate payment and trust mechanisms govern whether a transaction should proceed.
Best understood as: a standard interface for connecting AI applications to tools and data, which can support commerce but does not replace commerce, identity or payment protocols.
Official Model Context Protocol documentation · MCP project on GitHub
Protocol comparison
The quickest way to understand the ecosystem is to identify the primary question each protocol helps answer.
These descriptions summarise each protocol's primary role, not every capability or implementation. Actual features, dependencies and supported transaction flows should be confirmed against the relevant specification.
How might the protocols work together?
Consider a customer who asks an AI agent to find a product, check delivery and make a purchase within an authorised budget.
This is an illustrative architecture, not a claim that all seven protocols are required or directly interoperable in every transaction. The actual combination depends on the merchant's platform, payment provider, agent and integration.
What should merchants implement first?
Protocol support is one part of Agentic Commerce Readiness. A working protocol cannot compensate for inaccurate data or an unreliable checkout.
How Klasker evaluates Protocol Coverage
Klasker AITA examines observable evidence of machine-facing interfaces and relevant agentic commerce protocols.
Protocol detection is not the same as complete protocol validation. A published profile, endpoint or header can indicate that a protocol may be supported, but deeper tests are needed to establish whether the implementation works.
Klasker should distinguish between detected, verified, not detected and unknown states. Failure to discover an endpoint is not conclusive proof that a merchant does not support a protocol. Likewise, detecting a protocol does not establish successful end-to-end commerce.
This distinction is central to meaningful Agentic Readiness analysis: merchants need evidence about what works, what remains uncertain and what should be improved.
Continue learning
Protocols are only one part of the transition towards a machine-readable and agent-ready web.
Official specifications and further reading
These primary sources are the best starting point for implementation details, compatibility requirements and changes to the specifications.
This page is an educational overview, not a certification of protocol compliance or payment security. Specifications and product availability can change. Consult the relevant official documentation and implementation requirements before deploying a production integration.
Klasker Academy AITA
Klasker Academy explores the technologies, protocols and practices that help businesses become more machine-readable, trustworthy and ready for AI-assisted and agentic commerce.