MCP, A2A, ACP, AP2 and UCP: Check the Contract Behind the Name

A merchant says it supports agentic checkout. A shopping platform says it can connect to merchants. During integration, the first purchase fails because one side sends a payment field that the other no longer accepts.

Both statements can be sincere. Neither establishes a compatible contract. The protocol name leaves several questions unanswered: which version, which operations, which payment handler, which transport and which business outcome the response proves.

This guide examines those interface boundaries using documentation checked on 25 October 2026. For an introductory map of the participants, start with which agent does what. The concern here is narrower: what must two implementations agree before an attempted purchase crosses their boundary?

Separate connection, commerce and authority

MCP, A2A, ACP, AP2 and UCP are not five compulsory steps in every purchase. A merchant may use ordinary APIs behind a commerce interface. An assistant may call a tool without delegating work to another agent. An authority mechanism can constrain a purchase without replacing the merchant's checkout or payment processor.

The final column is an implementation checklist proposed for this article. It is not a claim that these projects share one certification process or automatically interoperate.

Treat versions as part of the interface

The MCP architecture page for version 2026-07-28 describes per-request metadata and server/discover, alongside its tool, resource and prompt primitives. An integration copied from an older lifecycle description needs to be checked against the version actually implemented. A successful tool invocation still requires the application to interpret its business result. MCP architecture, 2026-07-28

A2A's overview describes agent discovery, authentication and message-based interaction, including asynchronous work. The task boundary is useful when another agent owns work over time. The product team must still define what "complete" means for that task. A completed product-comparison task is not a receipt for an order. A2A overview

The distinction affects recovery. If a tool merely reads a catalog, retrying it has a different consequence from repeating a checkout completion. If an agent task is still running, launching another identical task can create overlapping work. Keep the operation's side effects and ownership explicit rather than applying one retry policy to every protocol call.

A concrete ACP compatibility problem

The ACP changelog identifies version 2026-01-30 and a breaking move from simple payment-provider fields to structured payment handlers. It also describes capability negotiation. A merchant supporting that contract cannot safely assume an older client's payment payload means the same thing. ACP changelog

There is a documentation distinction worth preserving. OpenAI's Agentic Checkout Spec describes create, update and complete checkout interactions, merchant order events and use of the existing payment provider. Its header table includes an older example API version. That example should not override the separately agreed version. The page also distinguishes open ACP development from approved-partner access to Instant Checkout in ChatGPT, and describes MCP support as future work on that page. OpenAI Agentic Checkout Spec

For a real integration, record the contracted checkout schema and payment handler together. Validate the payload against them before submission. Do not repair an unknown payment field by asking a model to guess which new field looks similar. A syntactically valid guess can change the payment instruction.

When documentation examples differ, keep the discrepancy in the integration record and resolve it with the supported implementation. A copied example and a current changelog serve different purposes. Neither proves that a particular merchant has deployed the newer version.

UCP discovery does not remove compatibility decisions

UCP's overview separates exact protocol-version selection from capability negotiation. It also distinguishes namespace provenance from trust. Discovering a capability identifies a claim about an interface; it does not oblige a client to accept or execute it. UCP specification, discovery and negotiation

Suppose a shopping platform needs a fulfillment option that the merchant does not advertise in the selected profile. The product decision might be to offer a supported option, hand the customer to a conventional checkout, or stop. It should not be to silently remove the customer's delivery requirement so the transaction can proceed.

Keep the fallback within the customer's actual permission. A different merchant, item, total or delivery condition may require a new decision. Protocol negotiation can establish a common technical subset; it cannot decide that a reduced commercial offer is acceptable to the buyer.

AP2 authority has its own schema boundary

The AP2 v0.2 specification uses Checkout and Payment Mandates, with open and closed forms and exact vct schema-version matching. It requires validation to occur in deterministic code. Catalog and commerce API details remain outside its scope. AP2 v0.2 specification

For an interface review, the practical question is whether the receiving component can verify the exact mandate it receives against the intended checkout and payment. Unknown schema versions should not be interpreted as close enough. Nor should the presence of a signed object be treated as evidence that a payment was authorized by an issuer, captured or settled.

The full authority lifecycle belongs in a separate control design. At this boundary, preserve the verified result and the reason for rejection. Give the customer a supported route to resolve the issue instead of asking an assistant to improvise consent or bypass the failed check.

Follow one purchase through compatibility checks

Consider a fictional purchase of a desk lamp. The customer chooses an item and a delivery option. The merchant returns the current total. The platform discovers that the required payment handler is not in the mutually supported set.

Stop before a payment attempt. Explain that the current route cannot complete the purchase and offer only an explicitly supported alternative. The customer may choose the merchant's normal checkout. That handoff must retain the intended item and make any changed conditions visible; it must not manufacture a completed agent purchase in the reporting.

Discover the actual interface

Record endpoint ownership, supported version, transport and operations.

Compare both implementations

Required capability and handler compatible?

Validate the selected contract rather than relying on protocol names.

No supported matchStop before payment.

Offer an agreed handoff or ask for a new decision if the offer changes.

Supported path only

Current offer and authority valid?

Verify the implemented constraints through deterministic controls.

Stale offer, revoked permission or invalid schemaDo not execute.

Resolve the failed condition and obtain any required new approval.

Permitted original operation

Submit and retain references

Link the checkout, payment attempt, task and merchant order where applicable.

Interpret the actual response

Business outcome confirmed?

Read the authoritative order and payment states separately.

Timeout or conflicting evidenceInvestigate the original operation.

Do not send a new purchase through another protocol merely because the first response was lost.

This is an editorial integration model, not a claim that all five protocols compose into one supported stack.

Keep a small compatibility record

For each partner boundary, retain the selected version, supported operations, handler or extension identifiers, authentication arrangement and recovery owner. Save a representative accepted request and response with sensitive values removed. Keep rejected examples for unsupported versions and capabilities as well.

When a partner changes its profile, compare it with that record. A new optional capability need not change the current purchase path. Removal of a required capability or a breaking schema change does. The team needs to know which difference requires testing before the next release.

After a timeout following a possible side effect, use the original references to establish the business outcome. A fallback transport is not permission to repeat the purchase. The payment inquiry guide covers that uncertainty; the readiness guide covers broader pilot ownership.

The useful release evidence is a tested agreement between named implementations: this version, this operation, this authority check and this recoverable result. A row of protocol logos cannot provide it.

Documentation snapshot: 25 October 2026. MCP's linked page is explicitly versioned; ACP and AP2 versions are identified above. A2A and UCP overview links can evolve and must be pinned to the partner's actual implementation before release. No universal interoperability or provider availability is asserted.