Map the purchase before choosing an acronym
A merchant selling an illustrative $29 report needs to identify the edition, calculate a current total, obtain the buyer's permission, accept a payment and deliver access. Each step has data and an owner. The standards discussion becomes practical when you attach a proposed protocol to one of those boundaries.
For example, a checkout contract can tell an agent how to update buyer information and request completion. That does not establish that the agent is allowed to spend the buyer's money. A payment authorization framework can preserve evidence of permission without publishing your catalog. An HTTP payment mechanism can charge for a resource without defining your store's return policy.
Use the map below as a starting point. It summarizes responsibilities, not a claim that every protocol deployment uses the same architecture. Your chosen version, channel and payment provider determine the exact contract. Read the normative specification when implementing; an explanatory diagram should never become an invented API schema.
Standards by responsibility
Scroll the table to compare all columns.
| Layer | Example standard | Responsible participant | Version or scope to record | Merchant question |
|---|---|---|---|---|
| Commerce session | ACP | Merchant checkout implementation | Implemented API-Version and current checkout contract | How does the agent obtain and complete a current checkout? |
| Commerce capabilities | UCP | Business profile and supporting participants | Negotiated protocol/capability versions | Which operations and extensions do the participants support? |
| Purchase authority | AP2 | Merchant, credential provider and payment verifier | v0.2 and exact mandate type version | What evidence links the approved checkout to payment authority? |
| Agent recognition | Visa Trusted Agent Protocol | Agent signer and merchant verifier | Applicable signature contract and market access | Which merchant-specific signed agent context can be verified? |
| Paid resource | x402 | Resource server, client and selected facilitator | Transport, scheme, network and asset | How does this HTTP resource request and verify payment? |
Commerce contracts describe what can be bought
ACP's merchant checkout specification describes a session API with operations for creating, changing and completing a checkout. The merchant returns calculated information and messages that the calling surface can use. The practical question is whether your existing checkout can supply that information reliably, including after changed inputs or a failed request. [1]
UCP describes a modular commerce interface with capabilities across discovery, cart building, checkout, identity linking and order management. Its capability model helps participants describe the commerce operations they support. A merchant should examine the particular capabilities and extensions required by its route, rather than assuming that the protocol name proves a complete feature set. [2]
For either approach, keep your underlying business rules authoritative. If your store prohibits a license in a particular context, the adapter should communicate that outcome. It should not reinterpret the restriction as a suggestion that an assistant can ignore. Capability negotiation is useful only when the advertised operation corresponds to behavior the merchant can actually deliver.
Authority and agent identity answer separate questions
AP2 v0.2 defines linked checkout and payment mandates and verification responsibilities for the participants. It addresses the evidence connecting an agent-performed purchase to authority to pay. Its specification explicitly leaves detailed catalog and commerce API behavior outside AP2's scope. Use it as the authorization layer it describes, rather than treating it as a replacement storefront. [3]
Agent recognition is a further boundary. A merchant may need to verify that a request came from a particular trusted agent and that its signature applies to this merchant and purpose. Recognition alone does not establish unlimited customer permission. A known shopping agent can still request an item outside a buyer's approval or present a checkout that no longer matches the agreed terms.
Visa's Trusted Agent Protocol page describes merchant- and purpose-specific, time-bounded signatures. It also qualifies the product's development and market availability. That makes it a relevant trust mechanism to investigate, while the merchant still needs current implementation and onboarding evidence for its own route. [4]
Payment mechanisms do not define the whole order
For a paid API resource, x402 provides an HTTP-oriented payment flow. The resource server can communicate payment requirements, and the client can return the required payment material through the supported process. The merchant still has to define what the resource is, what success means and how to handle a paid request that does not produce the promised output. [5]
For a retail checkout, a payment provider can process an authorized credential and return an outcome. Your order system then needs to join that outcome to the purchased item. Compare the provider's concrete token, verification and recovery contract; do not assume that an agent-facing payment label transfers fulfilment or support responsibility to the provider.
Inputs and outputs to inspect
Scroll the table to compare all columns.
| Boundary | Input to validate | Result to preserve |
|---|---|---|
| Catalog to checkout | Product identifier, quantity and chosen terms | Merchant-calculated checkout and unresolved requirements |
| Authority to payment | Approved purchase and supported credential scope | Verifiable authorization evidence tied to the attempt |
| Payment to order | Verified payment result and existing order reference | One consistent financial and fulfilment record |
| Order to delivery | Entitlement or fulfilment instruction | Delivery result and a recoverable exception when needed |
Choose the specification by your implementation task
If your immediate problem is obtaining a valid cart total, read the checkout contract and your commerce service design. If the problem is proving buyer permission, inspect authorization and mandate handling. If the problem is charging for one API response, evaluate the HTTP payment flow and the resource's delivery semantics. These tasks can coexist in a single product without being the same task.
Pin the versions you implement and save the relevant documentation date in your integration record. Public specifications and channel requirements can change independently. A protocol upgrade may require response changes even when your provider account stays the same; a channel policy change may affect distribution even when your server remains technically compatible.
Test the joins between layers. Change the report's price after the buyer approves it and check that the old authority cannot silently fund a different purchase. Interrupt delivery after payment and check that support can locate the original order. Those tests reveal whether the architecture connects the protocols meaningfully, rather than merely displaying several logos on an integration page.