Technical references consulted on October 18, 2026. This article considers the AP2 v0.2 specification and distinguishes open standards from the capabilities actually available in each channel.
MCP, ACP, UCP, and AP2 are not four names for the same technology. MCP standardizes how AI applications access tools and context. ACP and UCP define contracts for commercial interactions, with overlapping capabilities such as checkout. AP2 adds mechanisms to prove and verify authorization for purchases and payments executed by agents. These differences appear in the respective documentation for MCP (opens in a new tab ↗), ACP (opens in a new tab ↗), UCP (opens in a new tab ↗), and AP2 (opens in a new tab ↗).
The useful question, therefore, is not which acronym will replace all the others. It is which responsibility your integration needs to address: providing access to a capability, representing a purchase, verifying delegation, or executing payment.
Imagine a store that already has a catalog, inventory, shipping calculations, and a financial integration. Connecting an agent to that store's API is one problem. Enabling the agent to understand the checkout state is another. Demonstrating that the buyer authorized that amount is a third. Knowing whether payment was actually completed requires yet another answer.
A project can combine protocols, but there is no mandatory sequence called MCP → ACP → UCP → AP2. Treating these acronyms as four universal stages hides the very boundaries we need to design.
MCP: how does the agent access tools and context?
MCP stands for Model Context Protocol. It organizes communication between an AI application and servers that expose tools, resources, and prompts. Its architecture distinguishes the host application, MCP clients, and servers; communication uses structured messages with protocol-defined transports. This is the role described in the MCP architecture (opens in a new tab ↗).
In a commerce example, a server could expose tools to look up a product, calculate a delivery option, or retrieve an order. The client discovers these tools and invokes them according to their input and output contracts. The names of these operations in this example are application choices, not universal commerce tools imposed by MCP.
This distinction matters: MCP can carry a tool call that creates a purchase, but it does not, by itself, define the commercial meaning of every purchase. A tool called “complete order” needs its own rules for price, availability, payment, and repetition.
It would also be incorrect to say that MCP does not address security. The specification establishes precautions such as input validation, access controls, call limits, and confirmation for sensitive operations. What it does not do is turn technical permission to invoke a tool into unrestricted authorization to spend money. See the security requirements for MCP tools (opens in a new tab ↗).
To assess an integration, first ask: does the server provide information, execute actions, or both? Then ask: which actions can have commercial or financial effects, and who authorizes them?
An AZPay example: consulting documentation is not executing payments
AZPay's documentation describes an MCP server that lets AI assistants and development tools consult platform references. The documented access is read-only: it does not replace API keys or grant access to the payments API. That separation is explicit in the AZPay MCP server reference.
It is a concrete example of why the protocol's name alone does not reveal an integration's power.
An assistant can consult documentation to explain a status or help a developer understand a field. That differs from querying a merchant's private transactions. And both situations differ from submitting a charge.
That is why “we have MCP” is incomplete information in a discussion of agentic commerce. You need to explain what the server exposes, to whom, under which permissions, and with which effects. In the case described by AZPay's documentation, it provides access to technical knowledge, not financial delegation.
ACP: what is the contract between the agent and checkout?
In this article, ACP stands for Agentic Commerce Protocol. The project is maintained by OpenAI and Stripe and defines an open standard for interactions among buyers, agents, and businesses. Its architecture separates the responsibilities of the buyer, agent, seller, and payment provider. The seller remains responsible for its commercial operation, including pricing, inventory, and order fulfillment. See the ACP overview (opens in a new tab ↗) and its architecture (opens in a new tab ↗).
The Agentic Checkout component organizes operations such as creating, retrieving, updating, completing, and canceling a session. The session represents the purchase's commercial state: what was selected, what information is still missing, and whether it can proceed. The documented lifecycle (opens in a new tab ↗) distinguishes preparation, processing, completion, and cancellation states.
Consider an agent that found a product at a particular price. When creating checkout, it needs to receive the state calculated by the seller, not simply impose the price held in the conversation. If the address changes shipping costs, the session needs to reflect that change before completion.
This contract reduces ambiguity between “the agent intends to buy” and “the store is ready to accept this purchase.” The implementation still needs to ensure that the reported state corresponds to the actual operation.
ACP also does not necessarily end with the response to the first request. Its reference includes order webhooks (opens in a new tab ↗), allowing later changes to be communicated. Describing it only as a payment button therefore leaves out important parts of the contract.
How does ACP limit use of the payment credential?
The Delegate Payment component handles delivery of a payment credential with controlled scope. The reference consulted includes restrictions associated with a maximum amount, currency, seller, checkout session, and expiration, as well as single use within the documented scope. The agent participates in the journey without needing a credential reusable for any purchase. The fields are described in the ACP delegated payment reference (opens in a new tab ↗).
Consider the difference between handing over an unrestricted payment method and providing a credential valid for a bounded situation. The second option lets participants check whether that attempt matches the authorized use.
But a restricted credential should not be treated as a promise of universal portability. The team needs to confirm who issues it, who can process it, which restrictions are checked, and what happens when it expires.
This mechanism should not be equated with AP2 mandates either. Both help control agent payments, but the integration must respect the objects and checks of each contract. Without an explicitly supported mapping, a token from one flow should not be presumed equivalent to the evidence required by another.
UCP: how are commerce capabilities discovered and combined?
UCP stands for Universal Commerce Protocol. It organizes interaction between platforms consuming capabilities and businesses offering them. The documentation covers catalog, cart, checkout, order, and identity-linking capabilities, as well as extensions that add specific behaviors. This organization appears in the UCP core concepts (opens in a new tab ↗).
An important element is the profile published at /.well-known/ucp. The profile lets a business announce services, capabilities, versions, and integration information. Negotiation identifies the compatible set among participants; it does not mean every platform automatically understands everything a store advertises. The UCP overview specification (opens in a new tab ↗) details this model.
In practical terms, publishing “I support checkout” is only the beginning. You still need to know which version, which extensions, how the operation will be called, and which payment conditions are available.
Payment handlers also take part in discovery. They describe mechanisms for collecting or preparing payment instruments and the information needed for processing. Their mere presence in a profile does not make them a new settlement network or prove that any credential works with any processor. See the payment handlers guide (opens in a new tab ↗).
The architectural value is making explicit questions that would otherwise depend on implicit agreements. Does my store offer this capability? Does the channel understand the required extension? Is there a compatible way to present and process payment?
Can MCP and UCP be part of the same integration?
Yes. UCP documents an MCP binding—a way to express its operations through MCP. For checkout, the specification presents tools such as create_checkout, get_checkout, update_checkout, complete_checkout, and cancel_checkout. The MCP call provides the invocation mechanism; the UCP contract defines the data and commercial meaning of the operation. See the UCP checkout MCP binding (opens in a new tab ↗).
This composition helps separate two questions. “How does the client invoke the tool?” belongs to the MCP integration. “What does completing this checkout mean, with which data and in which state?” belongs to the commercial contract.
Similarly, not every UCP integration needs MCP. The specification also documents other integration methods. The choice depends on participants' available capabilities, not an obligation to put every technology in the same diagram.
A good understanding test is to remove the transport's name from the diagram. The rules for price, order, and completion should remain clear. Then, when MCP or another supported option is added back, it should be clear how those operations will be accessed.
Do ACP and UCP compete or complement each other?
There is genuine overlap. Both can help organize a commerce journey and its checkout. They are not simply independent layers that every purchase needs to pass through in sequence.
It is also incorrect to claim that only UCP has capability negotiation. ACP documents negotiation among participants, extensions, and payment handlers; its history records the introduction of these mechanisms in the January 30, 2026 version. The comparison needs to consider the ACP negotiation model (opens in a new tab ↗) and its changelog (opens in a new tab ↗), not just launch descriptions.
The useful difference for a team lies in the concrete contracts: objects, states, discovery, extensions, integration methods, and requirements of the channel consuming those capabilities. Two protocols addressing checkout does not make their formats interchangeable.
A store may decide to serve channels that use different contracts. For that scenario, we propose preserving a shared commercial domain and building adapters at the boundaries, rather than maintaining two inventories, two pricing rules, or two interpretations of the same order.
An open standard must also be distinguished from commercial access to a platform. Implementing a specification does not guarantee distribution, certification, or availability of every flow in a specific product. The OpenAI commerce documentation consulted, for example, emphasizes structured catalog ingestion for product discovery. Current channel requirements must be checked separately from the general specification. See the OpenAI commerce documentation (opens in a new tab ↗).
AP2: how can you demonstrate that the agent was authorized?
AP2, Agent Payments Protocol, addresses verifiable authorization of transactions performed by agents. It does not replace catalog APIs or the checkout update lifecycle: it operates as a security mechanism within a commerce journey. In specification v0.2, the core consists of two mandate types: Checkout Mandate and Payment Mandate. See the AP2 specification (opens in a new tab ↗).
A mandate is an object that represents an authorization and its conditions in a verifiable form. The goal is not to rely solely on the agent's statement that “the user allowed it.” It is to let participants check the authorization's origin, its link to the action, and the limits that must be respected.
The AP2 authorization framework (opens in a new tab ↗) distinguishes obtaining the user's authorization from subsequently verifying the action. This separation is fundamental: the component intending to buy should not be able to expand its own permission.
AP2 also distinguishes purchases with direct user participation from autonomous execution under previously approved conditions. Its documented flows (opens in a new tab ↗) show both forms of use. Autonomy in this context does not mean no authorization; it means executing without asking for a new approval at every step, provided the action stays within what was authorized.
Checkout Mandate and Payment Mandate: what does each prove?
The Checkout Mandate demonstrates to the seller the authorization to complete a particular purchase. In its closed form, it is bound to the seller-signed checkout through a cryptographic digest. That connection helps verify whether the purchase presented for completion matches the authorized state. The Checkout Mandate specification (opens in a new tab ↗) details this binding.
The Payment Mandate addresses authorization to pay for that checkout. It represents financial conditions such as amount, currency, recipient, and payment instrument, and also establishes the link to the purchase. Its fields and restrictions appear in the Payment Mandate specification (opens in a new tab ↗).
This separation is useful because authorizing a purchase's contents and authorizing its payment are related but different responsibilities. A store needs to know what was approved for purchase; payment participants need to verify whether the credential can be used to pay for that transaction.
In v0.2, mandates can be open or closed. A closed mandate corresponds to a concrete purchase or payment. An open mandate establishes conditions for future execution. In autonomous mode, the concrete operation must demonstrably comply with the previously approved limits, according to the checkout (opens in a new tab ↗) and payment (opens in a new tab ↗) models.
“Up to R$ 500” does not mean “any R$ 500 purchase.” Seller, items, quantity, validity, and instrument may be as important as the monetary limit. Each condition must be represented by mechanisms supported in the implementation; leaving it in natural language in the conversation is not enough.
Identifying the version matters. This text uses AP2 v0.2 terminology. When reusing examples from another revision, the team should check the corresponding schemas and validation rules rather than combining incompatible structures under the same name.
API access, purchase authorization, and financial approval are different things
A practical way to review the architecture is to separate three questions that often receive the same word: authorization.
The first is technical: can this client access this resource or invoke this operation? MCP's authorization model addresses resource access, scopes, and permissions. A valid access credential should not be interpreted as unlimited economic authorization. See the MCP authorization specification (opens in a new tab ↗).
The second is commercial: did the user authorize this purchase, under these conditions, through this agent? This is the boundary where AP2 mandate verification becomes relevant.
The third concerns financial execution: did the payment participants accept and process the operation? AP2 distinguishes the responsibilities of the seller, credential provider, and processor. Verifying permission is part of the work; processing payment is another. This division appears in the AP2 implementation considerations (opens in a new tab ↗).
The application's design should keep these answers separate. Permitted access does not mean an authorized purchase. An authorized purchase does not mean an approved payment. And the commercial record should reflect evidence actually received, not an optimistic inference about the previous step.
A purchase up to R$ 500: how do the protocols meet?
Consider a hypothetical example: someone authorizes their agent to buy one of two previously selected headphone models, from specified stores, for up to R$ 500 including shipping, within 48 hours.
These amounts and conditions are illustrative. Each restriction would need to be represented by a supported mechanism or an explicit application check. We are not describing a single universal payload accepted by all four protocols.
The agent finds an offer for R$ 460 with R$ 25 shipping. The total is R$ 485. The first task is to obtain the store's correct state: product, quantity, availability, and current conditions. The second is to check whether the purchase fits the authorization received.
In a UCP-based implementation, discovery identifies compatible capabilities and payment mechanisms. MCP can be the way to invoke operations when that binding is available. The AP2 extension adds mandates and their checks. This composition is documented in UCP and AP2 (opens in a new tab ↗).
There is an important condition: the UCP checkout specification requires manual completion by the user in a trusted interface unless the AP2 Mandates extension is supported. Advertising UCP checkout alone should therefore not be understood as authorization for a fully autonomous purchase. See the checkout capability (opens in a new tab ↗).
Now suppose that before completion, the total changes to R$ 515. In this example, the agent cannot treat the difference as irrelevant. The purchase no longer fits the authorized budget. The implementation must stop completion, update the state, and obtain new authorization if the user wants to proceed.
If the change keeps the total below R$ 500, the other conditions still need to be checked and the authorization bound to the correct checkout. Being within budget does not turn an old state into valid evidence for any later purchase.
A channel using ACP will have its own checkout and delegated payment contract. There is no reason to introduce UCP merely to complete a collection of acronyms. The implementation should follow the flow actually supported by its participants.
Verification cannot depend on the model's goodwill
AP2's threat model considers that an agent may be manipulated or behave maliciously. Protection therefore cannot depend exclusively on instructions such as “never exceed the budget.” The security and privacy considerations (opens in a new tab ↗) address independent verification and limits on the agent's power.
AP2 calls the trusted interface that presents authorization contents to the user, obtains consent, and participates in creating signed mandates a Trusted Surface. It can be a deterministic part of the application, a wallet, or another trusted interface. It is not merely the agent's message claiming permission was received. Responsibilities appear in the implementation considerations (opens in a new tab ↗).
In the architecture proposed here, the model interprets intent and searches for options. Verification components check authorization, state, and conditions before permitting an action with financial effects. The acceptance decision must not be replaced by another natural-language response saying “everything looks fine.”
This also changes the test plan. Testing a valid purchase is not enough. Test a different seller, an altered checkout, an expired authorization, a repeated action, and an attempt to use a credential outside its scope.
For every scenario, record which component should reject the operation and which evidence needs to be preserved. This exercise turns security into verifiable behavior rather than relying on an interpretation of a diagram.
A multiprotocol integration needs a single commercial source of truth
For a store intending to serve more than one channel, we recommend separating the commercial domain from protocol adapters.
The domain represents products, pricing, availability, orders, payment intents, and business rules. Adapters translate that domain into the contracts each channel understands. This is an architectural proposal, not a universal requirement of MCP, ACP, UCP, or AP2.
The care lies in the translation. If a contract distinguishes “ready to complete” from “completion in progress,” the adapter cannot compress both into “paid.” In UCP, for example, ready_for_complete, complete_in_progress, and completed represent different situations. An order does not necessarily exist when completion has only been accepted for processing, according to the checkout lifecycle (opens in a new tab ↗).
An operation-level compatibility matrix makes this decision verifiable. It should record the channel, protocol version, required extensions, accepted credentials, and need for human intervention. “Supported” needs to mean a tested combination, not just a responding endpoint.
This design connects with payment orchestration: preserve a business intent and control how it will be executed without scattering the details of every integration throughout the application.
A valid mandate does not mean a completed payment
Verifiable authorization demonstrates permission within a particular context. It does not prove that money moved. The AP2 specification distinguishes mandates and receipts; receipts record results and can contribute to later evidence. An authorization format does not replace the response from financial execution. The AP2 flows (opens in a new tab ↗) show authorization being obtained and results returned by participants.
When designing customer support, we recommend separating “authorized by the user,” “submitted for processing,” “confirmed outcome,” and “outcome still unknown,” using each integration's actual states. The interface should not present a completion the backend cannot yet demonstrate.
The same caution applies to disputes. Mandates and receipts can contribute transaction evidence, but AP2 does not itself define procedures for resolving disputes or retaining and retrieving that evidence. Nor does it guarantee a favorable dispute outcome. The dispute evidence (opens in a new tab ↗) section defines that scope.
The architectural lesson is simple: permission, execution, and subsequent proof deserve related but distinct records. This separation also helps explain payment transaction states.
What happens when the response is lost?
Suppose the agent requested completion of a purchase and received no response. It is not safe to assume nothing happened. Communication errors can leave the outcome of a financial operation indeterminate; Stripe's low-level error documentation (opens in a new tab ↗) describes this kind of situation.
The commerce protocol and authorization mechanisms do not remove the need for repetition control. A new call must respect idempotency guarantees and the state of the previous operation. Those guarantees have scope: Stripe's idempotency reference (opens in a new tab ↗), for example, describes its own service's rules, not protection automatically shared among all processors.
For the architecture in this article, we recommend letting the agent query the existing purchase instead of blindly creating another. The backend should correlate intent, attempt, and subsequent notifications. The goal is to resolve uncertainty without producing an unwanted second purchase.
This is a different deep dive from comparing protocols. The guide to idempotency in payment APIs explains the controls that remain necessary after selecting the integration contract.
Pix, installments, and Brazilian operations do not appear by magic
When designing an integration for Brazil, filling in a line called “supported payments” is not enough. You need to specify which journeys the channel and providers can execute end to end.
For a Pix journey, we recommend defining how the charge will be created, how the user can pay, where confirmation will come from, and how the application will handle expiration or refunds. For an installment journey, the proposal needs to clearly represent the total and conditions that the buyer will actually authorize.
These are implementation questions. A protocol's extensibility is not confirmation that a particular channel, wallet, or processor already supports that combination. The extensible design of UCP payment handlers (opens in a new tab ↗) needs to result in compatible participants and credentials, not just a capability announcement.
The same reasoning applies to delivery, discounts, and local business rules. We recommend preserving the existing operation's logic and explicitly mapping what each channel can represent. When a necessary step lacks support, the solution should provide for human intervention or an alternative journey, not invent a silent equivalence.
Where should implementation begin?
Start with the use case and channel. “I want an assistant to consult documentation” requires a very different set of permissions from “I want an agent to buy without the user present.” Based on that decision, identify the contracts actually accepted by participants.
Then record versions and capabilities. Even MCP evolves structurally: the architecture consulted in the July 28, 2026 revision describes communication without a mandatory protocol session, with version and capabilities per request. Copying a tutorial from another revision without checking compatibility can introduce incorrect assumptions. See the current MCP architecture (opens in a new tab ↗).
Next, design the authority boundary. Who supplies the commercial state? Who obtains user approval? Who validates limits? Who issues the credential? Who processes and confirms payment? In which situations must the agent stop?
Finally, test the full contract: unsupported capability, changed total, incompatible credential, expired authorization, pending completion, and lost response. Expand autonomy only when these paths have defined behavior and verifiable evidence.
The decision does not need to predict which protocol will see the greatest adoption. It needs to choose a combination that works for a concrete journey and leave room for new integrations without rebuilding the whole business.
Compatibility is the start. Operational control is the goal
Comparing MCP, ACP, UCP, and AP2 becomes more useful when it stops being a contest of acronyms and becomes a design of responsibilities.
Tool access, commercial contracts, delegation, and financial execution need to be connected, but not confused. The architecture should be able to explain what the agent was allowed to do, which purchase was presented, which action was executed, and how its result was confirmed.
The perspective guiding this article is that of building: new channels should expand an operation's capabilities, not create parallel versions of the same business that are difficult to reconcile. At AZPay, the documented MCP example already shows why capabilities must be described precisely, without confusing information with execution.
To explore the relationship between these contracts and payment operations further, continue with Payments by AI agents: what changes when checkout stops being a screen.
The decisive question is not how many protocols appear in the diagram. It is whether each purchase can be authorized, executed, and explained without losing control of the operation.