ACP, UCP and AP2: Which Commerce Protocols Do You Need?
Compare ACP checkout, UCP commerce capabilities and AP2 authorization. Choose a supported integration around your channels, systems and payment partners.
AI-generated editorial illustration
Article contents
ACP, UCP and AP2 are not three interchangeable shopping engines. ACP describes programmatic checkout and secure payment credential relay. UCP provides a capability-based commerce interface, including negotiation of supported functions. AP2 addresses verifiable authority for checkout and payment. Your choice begins with the channel and transaction you need to support, then the interfaces your platform and payment partners actually accept.
For a UAE business with an existing store, ERP and payment processor, implementing all three immediately can create unnecessary adapters and unclear accountability. PRO71 starts with the transaction boundary and source systems, then scopes the protocol work needed to connect them. The decision is which interface enables a supported journey, with authority and recovery preserved.
What problem does each protocol solve?
ACP gives agents and merchants a defined way to exchange checkout state instead of relying on navigation through website screens. Its documentation covers checkout interfaces, credential relay and related lifecycle behavior. It does not turn an inaccurate catalog into accurate inventory or make every processor available to every merchant. ACP documentation.
UCP organizes commerce around advertised capabilities and negotiated support. Participants must agree on compatible versions and functions before using them. The practical value is a common commercial contract across supported integrations; the merchant still needs to implement the underlying decisions. UCP specification.
AP2 supplies a model for verifiable checkout and payment authority. Current documentation describes open and closed checkout and payment mandates, including human-present and human-not-present flows. A signed mandate is evidence for a bounded action, not a substitute for inventory, fulfilment or the rules agreed with the payment participants. AP2 documentation.
Where do the roles overlap?
They overlap around the purchase but operate at different boundaries. A checkout interface needs to know how to accept payment information, and a payment authorization needs a defined purchase to refer to. UCP documents an AP2 integration, illustrating that commerce capabilities and authority evidence can work together.
Scroll horizontally to view the full table
| Interface | Principal question | Merchant work that remains |
|---|---|---|
| ACP | How does the agent manage this checkout? | Basket validation, totals, stock, payment integration and order recovery |
| UCP | Which commerce capabilities can both participants use? | Supported profiles, versions, operations and capability implementation |
| AP2 | What checkout and payment action was authorized? | Verification, bounded execution, supported payment partners and dispute evidence |
The comparison should not become a ranking of “best protocol.” A channel may require one interface; your processor may support a specific credential flow; an authorization requirement may add another layer. Select the combination against a real transaction, not the largest number of standards listed in a proposal.
How do you select a protocol for an existing commerce stack?
First name the intended channel, user location, product set and completion route. Ask whether the journey ends at your store's checkout or completes through a supported programmatic interface. Obtain current eligibility and integration requirements from the channel and platform.
Next trace the merchant stack. Which system owns variants? Which owns stock? Where are totals calculated? Who creates the order and reconciles payment? Place the protocol adapter at the commercial boundary without duplicating pricing or availability logic inside it.
Then confirm the payment route with the processor and relevant partners. An open specification does not guarantee merchant onboarding, supported instruments or regional availability. Written confirmation of the supported flow is a stronger procurement input than a demonstration using unrelated test credentials.
What should an adapter do when the systems disagree?
Return an explicit state that prevents unsupported execution. Suppose the agent requests two units, the store displays two and ERP can reserve only one. The adapter should expose the authoritative availability result and allow a revised checkout or human handoff. It should not invent stock to satisfy the request.
The same principle applies to a changed total or an expired authorization. Preserve the relationship between the customer's approved purchase and the current basket. Define when a fresh confirmation is required. Separate errors that can be retried from conditions that require a new business decision.
Record checkout, reservation, payment and order references so an operator can reconstruct the sequence. If a request times out after submission, retrieve the existing state before executing again. Protocol conformance is valuable only when the merchant implementation preserves those transaction guarantees.
What version and security questions belong in the contract?
Specify the version tested, supported capabilities, authentication method and change process. Current specifications evolve. An integration that merely claims compatibility without a version and acceptance evidence leaves the merchant unable to assess an upstream change.
Require least-privilege access. Catalog reading, basket mutation, order submission and payment actions need distinct permission boundaries. Treat external catalog text as untrusted input. Logs should expose decisions and references without becoming a store of payment secrets.
Ask who monitors compatibility, how breaking changes are evaluated and how a failed capability negotiation appears to the customer. Define ownership of certificates or verification material, credential rotation and the switch back to ordinary checkout. These details are part of support scope, not optional documentation.
How should buyers assess the implementation proposal?
Request a transaction sequence showing the agent, adapter, commerce platform, ERP and processor. Every transition should identify an owner, input, response and failure behavior. Require evidence of a changed price, declined payment, repeated request and lost response after order creation.
Separate adapter development from source-data repair and processor enablement. Reusing a platform integration may be sensible; a custom adapter may be justified when existing operations require it. The proposal should explain which route avoids duplicating business logic and how that decision was verified.
For PRO71, a scoped systems review establishes the interfaces and accountability before implementation. A useful deliverable is a protocol selection record, agreed transaction contract and testable release boundary. No supplier should imply that implementing a public specification establishes universal channel access or automatically settles payment liability.
Buyer FAQs
Do we need all three protocols?
Only if the supported journey requires their combined roles. Start from channel requirements and processor support; add interfaces when they solve an identified boundary.
Can MCP replace a commerce protocol?
MCP is a tool connectivity surface. It does not by itself define your basket semantics, purchase authority, fulfilment promises or reconciliation rules.
Can we keep the existing payment processor?
Possibly. Confirm that it supports the intended credential and execution flow for your merchant account. The answer depends on the actual integration, not the protocol name alone.
What evidence should precede a fixed implementation quote?
Channel eligibility, source-system interfaces, representative variants, payment support and the critical exception cases. Missing evidence should become a scoped diagnostic task.
What should you do next?
Bring one intended purchase journey and your current system map to a systems integration review. Establish the required protocol surface and the authoritative commercial decisions before commissioning adapters.
Continue the series
Definition: Agentic AI.
About the author
PRO71 Team
Turn the reading into a decision
We can review the context and define the next move clearly.