Agentic Commerce Protocols: ACP vs AP2 vs UCP for AI Agent Payments (2026)

Disclaimer: this is a systems and architecture analysis, not financial, legal or investment advice.

Ask three engineers which of ACP, AP2 and UCP will “win” agentic checkout and you will get three confident answers, and all three will be framed as a competition. That framing is the first mistake. The three agentic commerce protocols are not drop-in substitutes. One standardizes the merchant checkout API and a scoped payment token, one standardizes the cryptographic proof that a human authorized a purchase, and one standardizes how an agent discovers and negotiates with any business at all. They overlap in the middle, and that overlap is where the confusion and the real integration risk live.

This matters now because the specifications are moving quickly. ACP has shipped dated spec releases since September 2025, UCP was announced in January 2026 and already publishes releases through at least August 2026, and AP2 has been revised and handed toward a standards body. If you build a merchant integration or an agent runtime against the wrong layer, you will rebuild it within a year.

You will leave with a layer model that tells you what each protocol actually owns, a request-level walk-through of each flow, a decision matrix, and a list of failure modes that none of the launch announcements mention.

What this covers: the problem agentic commerce creates for payments, a layered reference model, ACP and its delegated payment token, AP2 and its mandate chain, UCP and its discovery and negotiation model, how they compose, a decision matrix, failure modes, and a practical checklist.

Context and Background

Card payments were designed around a human at a browser or a terminal. The merchant presents a page, the cardholder types or taps, and the issuer’s fraud models score a session that looks human: a device fingerprint, a 3-D Secure challenge, a wallet biometric. An autonomous agent breaks each of those assumptions. There is no checkout page to render, no cardholder present to authenticate, and the “device” is a cloud runtime that thousands of other users share.

Three questions fall out of that. First, how does an agent learn what a merchant sells and how to buy it without a bespoke integration per store? Second, how does a merchant, an issuer and a network know that a specific human really authorized this specific purchase, and not a prompt-injected agent acting on a hallucination? Third, how does money move without the agent ever holding a raw card number that could leak into a log or a model context?

Those are three different problems, and the industry produced protocols aimed at different ones. Stripe and OpenAI published the Agentic Commerce Protocol on September 29, 2025, alongside Instant Checkout in ChatGPT; Stripe’s announcement said ChatGPT users in the US could buy from US Etsy sellers at launch, with Shopify merchants listed as coming. Google announced the Agent Payments Protocol in September 2025 with more than 60 collaborating organizations, positioned as an extension of its Agent2Agent protocol and of the Model Context Protocol. Google then announced the Universal Commerce Protocol in January 2026, developed with Shopify, Etsy, Wayfair, Target and Walmart and endorsed by more than 20 partners, according to InfoQ’s report.

All three are open source under Apache 2.0 according to their repositories. Governance differs: the ACP repository describes joint governance by OpenAI and Stripe as founding maintainers with a stated path to neutral foundation stewardship, and the AP2 site references a donation to the FIDO Alliance, whose technical working groups are to continue standardization. We will return to governance, because it affects how much weight you should put on any single spec.

If you build payment backends, the closest prior art is not a commerce protocol at all but the reliability discipline that payment APIs already require. Our deep dive on payment API idempotency keys and exactly-once retries matters here more than most readers expect, because agents retry aggressively and ACP bakes idempotency headers into its core endpoints. For the primary documents, the Stripe ACP documentation and the ACP specification repository are the places to start.

One housekeeping note on evidence. Everything in this article about wire formats comes from the published specs and docs I read while writing it. Where a spec page was truncated or a term appears to have changed between releases, I say so. Treat any field name as “verify against the release you integrate.”

A Layer Model for Agentic Commerce Protocols

The most useful way to compare these specs is to stop comparing them as products and start placing them in a stack. Agentic commerce has five distinct concerns, and each protocol takes a different subset.

Direct answer. Agentic commerce protocols divide the work into discovery, checkout, payment credential delegation, user authorization proof, and identity. ACP is strongest on checkout and a scoped payment token. AP2 is strongest on cryptographic user authorization. UCP is strongest on discovery and capability negotiation, and it can carry AP2 mandates. They compose more than they compete.

Figure 1: The five concerns of agentic commerce, between a buyer’s agent and the merchant and payment provider.

The diagram shows an agent acting for a buyer and fanning out to four concerns. Discovery tells the agent what exists. Checkout turns a selection into an order with totals, tax and fulfillment. Payment moves a credential or a signed authorization toward a payment service provider and card network. Identity lets the agent act under a buyer’s account without sharing a password. The merchant sits on the receiving end of all of them, and the payment provider is reached both directly by the agent’s credential flow and indirectly through the merchant.

Where each protocol sits

ACP’s own documentation lists its building blocks as agentic checkout, cart and feed, delegate payment, delegate authentication through OAuth 2.0, and orders with webhooks. That is nearly the whole stack from the catalog down to post-purchase events. What ACP does not try to do is prove, to a third party after the fact, that the human consented to a specific cart.

UCP’s repository lists four capabilities: checkout with cart management and tax calculation, identity linking through OAuth 2.0, order updates via webhooks, and payment token exchange between payment service providers and credential providers. Its distinguishing feature is not any one capability but the machinery around them: a discovery profile, namespaced capabilities, and version negotiation.

AP2 is narrower in scope and deeper in cryptography. Its core object is the mandate, a tamper-evident signed record of what the user authorized. The AP2 site describes mandates as verifiable digital credentials and chains them into an audit trail. It is closer to an authorization layer you can mount on top of a checkout protocol than a checkout protocol itself.

Why the layer model beats a feature table

A feature table invites the question “which one has more checkmarks.” A layer model invites the question “which layer is my actual risk in.” If you are a merchant, your biggest decision is the checkout surface, because that is the code you have to run and secure. If you are an issuer or a PSP, your biggest decision is how a credential reaches you and what evidence rides with it. If you are an agent builder, your biggest decision is discovery: how many merchants can you reach without writing an adapter per store.

This is also why the “winner” framing fails. A merchant can implement a UCP discovery profile, expose ACP-style checkout semantics, and accept AP2 mandates, and none of those choices excludes the others. The UCP specification explicitly defines an AP2 mandates extension named dev.ucp.common.payment.ap2_mandate as an optional piece, and the AP2 site links an integration guide for UCP. Interoperability between the layers is a design goal, not an accident.

The trust boundary is the real design axis

There is a second axis that cuts across the layers: who holds the secret. In the most conservative designs the agent platform never touches a raw credential. The UCP overview says a platform “SHOULD NOT touch raw financial credentials” and should handle only tokens, encrypted payloads or mandates. ACP’s delegate payment flow produces a vault token tied to an allowance, so the agent relays a token and not a card number. AP2’s role-based design routes the payment mandate to the credential provider and processor and the checkout mandate to the merchant, so each party sees only what it needs.

Keep this axis in mind. Most of the production incidents you will see in this space will come from credentials or authorizations crossing a boundary they should not have.

Deeper Analysis: How Each Protocol Works on the Wire

ACP: checkout sessions and a scoped payment token

ACP’s checkout API is a small, REST-shaped state machine. From the 2026-04-17 OpenAPI file, the agentic checkout surface has five operations: POST /checkout_sessions to create a session, GET /checkout_sessions/{id} to retrieve it, POST /checkout_sessions/{id} to update it, POST /checkout_sessions/{id}/complete to complete it, and POST /checkout_sessions/{id}/cancel to cancel it. The merchant implements these; the agent platform calls them.

Every state-changing call requires an Idempotency-Key header, and every call requires Authorization and an API-Version header. Optional headers include Signature and Timestamp, which support request signing, plus Request-Id for tracing. The API-Version is date-shaped, which matches the repository’s dated release directories.

The session carries a status. The enum in that spec includes incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress and expired. Two of those deserve attention: requires_escalation and authentication_required are the protocol’s honest acknowledgement that sometimes a human must take over, for example to complete a 3-D Secure step or to resolve a restricted-goods rule. That escape hatch is a feature, not a flaw.

Figure 2: An ACP-style checkout. The agent creates and updates a session, obtains a scoped vault token, then completes the session.

The flow in Figure 2 has a clear shape. The buyer confirms intent inside the agent surface. The agent platform creates a checkout session with the merchant, iterates through updates until the merchant reports ready_for_payment, and then needs a credential. Rather than send a card number to the merchant, it calls a delegated payment endpoint on the payment provider’s vault, receives a vault token, and passes that token in the completion call. The merchant then charges the token within the limits attached to it.

The delegate payment allowance

The delegated payment spec is the most interesting piece of ACP from a security standpoint. The endpoint in the 2026-04-17 file is POST /agentic_commerce/delegate_payment, using bearer authentication. Its request must include a payment_method, an allowance, risk_signals and metadata.

The allowance is the scoping mechanism. Its required fields are reason (only one_time is supported), max_amount as an integer in minor units, currency as a lowercase ISO 4217 code, checkout_session_id, merchant_id and expires_at. In plain terms, the token is minted for one session, one merchant, a ceiling amount and a deadline. A leaked token that is bound to a specific session and merchant is far less valuable than a leaked card number.

The payment_method object describes a card, distinguishing a full primary account number from a network token via card_number_type (fpan or network_token), and optionally carrying a cryptogram and ECI value for network-tokenized flows. The response is a 201 with an id that is a vault token (prefix vt_), and the spec defines an Idempotent-Replayed header so a retry is distinguishable from a first call. Error codes include idempotency_conflict, idempotency_in_flight and duplicate_request. These read like they were written by people who have been paged about double charges, and they connect directly to the patterns in our article on idempotency keys for payment APIs.

A small caveat I noticed while reading: the spec file’s info version is 2026-04-17 while the API-Version example is 2025-09-29, and some error examples use values missing from the enums. That is the normal texture of a beta spec; the repository itself labels the specification as in beta. Do not generate a strict client from an example value.

A minimal ACP-style request sequence

The following sketch is illustrative, not a normative client. It shows the header discipline ACP expects: an idempotency key per logical operation, reused on retry, and a version header on every call. Field names in the body are simplified; check the JSON Schema for the release you target.

import uuid, requests

BASE = "https://merchant.example.com"
HEADERS = {
    "Authorization": "Bearer <agent-platform-token>",
    "API-Version": "2026-04-17",
    "Content-Type": "application/json",
}

def post(path, body, idem_key):
    # Same idem_key on retry => the merchant must replay, not re-execute
    h = {**HEADERS, "Idempotency-Key": idem_key, "Request-Id": str(uuid.uuid4())}
    r = requests.post(BASE + path, json=body, headers=h, timeout=15)
    r.raise_for_status()
    return r.json()

create_key = str(uuid.uuid4())
session = post("/checkout_sessions",
               {"items": [{"id": "sku_123", "quantity": 1}]}, create_key)

# ... update calls until session["status"] == "ready_for_payment" ...

complete_key = str(uuid.uuid4())   # persist this BEFORE sending
result = post(f"/checkout_sessions/{session['id']}/complete",
              {"payment": {"token": "vt_from_delegate_payment"}}, complete_key)

The one line that matters is the comment on complete_key: persist the key before the network call. An agent that crashes between sending and recording will otherwise mint a new key on restart and risk a second charge.

AP2: proving the human said yes

AP2 solves a different problem, and it is worth being precise about its vocabulary because it has shifted. The September 2025 announcement coverage described an Intent Mandate, a Cart Mandate and a Payment Mandate. A coverage page I fetched described Intent Mandates and Cart Mandates as cryptographically signed digital contracts, with two modes: real-time purchases where a human is present, and delegated tasks where the user pre-signs rules such as price limits and timing.

The current AP2 site uses somewhat different terms. It describes a Checkout Mandate and a Payment Mandate, each with an Open stage and a Closed stage, chained into an audit trail, and it references an AP2 v0.2 release. I could not retrieve the field-level schema or the signing format from the pages I read, so I will not state whether it uses SD-JWT or another credential format. The site says only that these digital credentials are tamper-evident and cryptographically signed. Treat the Intent and Cart terminology as the earlier naming and the Checkout and Payment Open and Closed terminology as the current one, and verify against the repository’s docs before you build.

The logic is clear even without the byte layout. An Open mandate captures constraints before a cart exists: a budget, allowed instruments, a time window. A Closed mandate binds to a specific finalized checkout and amount. The Closed checkout mandate goes to the merchant. The Closed payment mandate goes to the credential provider, networks and the merchant’s payment processor. Each party gets evidence scoped to its role.

Figure 3: An AP2-style authorization flow. The open mandate bounds what the agent may do; closed mandates bind to the final cart.

In the human-present path of Figure 3, the user approves the final cart and the closed mandates are signed on the spot. In the human-not-present path, the user signs the open mandate ahead of time, the agent monitors conditions, and the closed mandate is produced when the rules are satisfied. The second path is where a signed audit trail is most valuable, because nobody is watching when the purchase happens.

Why mandates matter for liability

Card networks allocate dispute liability based on evidence of authentication and authorization. A purchase an agent made “on behalf of” a user is an ambiguous object under today’s rules: was it authorized, or was it a merchant-side error, or a compromised agent? A signed chain that says “this user, with this key, authorized spend of at most this amount with this merchant before this time, and then approved this exact cart” converts an argument into a verifiable artifact. I want to be careful here. Whether networks, issuers and regulators will treat AP2 mandates as sufficient evidence is a policy outcome, not a property of the spec, and I found no published statement that settles it. That is an open question, not a feature.

The AP2 site also mentions a “Human Not Present x402” sample, which points at the stablecoin and HTTP 402 payment path, and coverage of the original launch described an A2A x402 extension built with Coinbase and others. I will not go deeper because I did not verify its current status.

UCP: discovery, negotiation and handlers

UCP’s most distinctive idea is that the merchant publishes a machine-readable profile at /.well-known/ucp. From the 2026-08-25 overview, the profile has a required ucp object with version, services and payment_handlers, plus an optional capabilities object, and may include a keys[] JWK Set (RFC 7517) of public keys. It must be served over HTTPS without redirects.

Platforms announce themselves by sending their profile URI with every request, in a UCP-Agent header over HTTP or a meta.ucp-agent object over MCP. Versions are date strings. The platform selects one exact version; the business determines the active capabilities.

Capabilities are named with reverse-domain notation, such as dev.ucp.shopping.checkout. The dev.ucp.* namespace is reserved for the governing body, and vendors use their own domains. The spec describes “authority binding”: a schema URL’s host must match the namespace authority in the capability name, which prevents one party from publishing a schema that claims to be another’s.

Figure 4: UCP’s negotiation model. Profile fetch, intersection of capabilities, extensions pruned if their parent is absent, handler chosen by identifier.

Negotiation is deterministic. Matching capabilities are intersected by name. For each, the highest mutually supported version is chosen. Extensions whose parent capability is absent are pruned. If negotiation fails, the business returns capabilities_incompatible with a continue_url fallback, which lets a human finish in a browser. That last detail echoes ACP’s requires_escalation status: both protocols plan for the human fallback.

Payment handlers are listed in the profile under payment_handlers, keyed by reverse-domain name, and may include an id, version, spec, schema, available_instruments and config. A handler_id in the payload tells the business which provider’s credentials to use. This is UCP’s answer to the “payment instrument versus payment provider” problem: the checkout request names a handler, and the handler’s own spec defines the credential format.

Transport is pluralistic. The overview lists REST (OpenAPI 3.x), MCP (OpenRPC over JSON-RPC), A2A (an Agent Card) and an embedded binding (OpenRPC). Request signatures use HTTP Message Signatures (RFC 9421), business-to-platform webhooks must be signed, and keys are EC (P-256, P-384) or OKP (Ed25519). Optional Web Bot Auth interoperability uses a Signature-Agent header.

For readers coming from industrial and PLM integration, this is familiar. A discovery document plus versioned, negotiable capability contracts is the same architectural move that OPC UA information models and standards-based exchange formats make. We drew the same comparison in our piece on lightweight CAD formats for digital twins and PLM, where the real question is also which layer owns which semantics, and in our analysis of STEP AP242, JT and QIF for model-based definition, where capability negotiation versus fixed schema is again the central tension.

A discovery profile sketch

Below is an illustrative profile shape consistent with the fields named above. It is a sketch for orientation, not a copy of the spec’s example; consult the overview for the exact schema.

{
  "ucp": {
    "version": "2026-08-25",
    "services": { "dev.ucp.shopping": { "rest": { "endpoint": "https://shop.example.com/ucp" } } },
    "payment_handlers": { "com.example.psp": { "id": "psp_1", "available_instruments": ["card"] } },
    "capabilities": { "dev.ucp.shopping.checkout": [ { "version": "2026-08-25" } ] }
  },
  "keys": [ { "kty": "OKP", "crv": "Ed25519", "kid": "k1", "x": "<public key>" } ]
}

The structure expresses the whole philosophy: who I am, which services and handlers I run, which capabilities and versions I support, and which keys sign my messages.

Side by side

Dimension	ACP	AP2	UCP
Primary job	Merchant checkout API and delegated payment token	Cryptographic proof of user authorization	Discovery, negotiation and commerce capabilities
Origin	Stripe and OpenAI (Sept 2025)	Google with 60+ partners (Sept 2025)	Google with Shopify, Etsy, Wayfair, Target, Walmart (Jan 2026)
License	Apache 2.0	Apache 2.0	Apache 2.0
Core object	Checkout session, vault token with allowance	Mandates, open and closed	Business profile, capability, handler
Discovery	Product feed and cart building blocks	Not its focus	/.well-known/ucp profile
Human fallback	requires_escalation, authentication_required	Human-present mode	continue_url on failed negotiation
Transports	HTTP REST, MCP in latest release	A2A and MCP extension	REST, MCP, A2A, embedded
Signing	Optional Signature header	Signed credentials	RFC 9421 HTTP Message Signatures, JWKS

How the Protocols Compose in Practice

If the table suggests the protocols are interchangeable, the composition view corrects it. Consider three realistic stacks.

Stack A: an assistant with built-in checkout. An AI assistant surface wants its users to buy from many merchants. It adopts ACP’s checkout and delegate payment endpoints because the merchant integration and the vault token are well defined and PSP support exists. The merchant stays merchant of record, which Stripe’s announcement emphasizes, retaining control over products, presentation, processing and fulfillment. Authorization evidence is whatever the platform records itself.

Stack B: a marketplace-scale discovery model. An agent platform wants to reach thousands of long-tail storefronts without writing adapters. It fetches /.well-known/ucp, negotiates capabilities, selects a payment handler by id and uses checkout. Because UCP is transport-agnostic, the same capability can be reached over REST from a server or MCP from a tool-calling model. The agent platform never touches raw credentials.

Stack C: unattended purchasing. A procurement or replenishment agent buys on a schedule or a price trigger with no human watching. Here the audit trail is the product. The stack layers AP2 mandates over whichever checkout is available: the user signs an open mandate with a budget and a window, and the closed mandates are produced when conditions are met. UCP’s optional ap2_mandate extension is the documented attachment point.

Overlap and where it bites

The overlap is checkout. ACP and UCP both define a checkout surface with cart, fulfillment, discount and order concepts. ACP’s version history shows capability negotiation arrived in its 2026-01-16 release and extensions, discounts and payment handlers in 2026-01-30, which are concepts UCP also centers on. A merchant who supports both must either map two schemas onto one internal order model or run two adapters. The pragmatic answer is an internal canonical order model with thin protocol adapters at the edge, which is also how mature merchants handle multiple marketplaces.

The second overlap is payment credential delegation. ACP has delegate payment; UCP has payment token exchange and handlers; AP2 has payment mandates. They answer slightly different questions (token minting, handler selection, authorization evidence) but a naive integrator can end up with three credential paths in one checkout. Draw the credential path on a whiteboard before you code, and make sure only one component ever sees a raw primary account number.

Decision matrix

Your situation	Lean toward	Why	Watch out for
Merchant already on Stripe, wants chat-surface sales	ACP	Defined checkout endpoints, vault token, PSP tooling	Beta spec churn; dated versions
Merchant wants broad agent reach with one profile	UCP	Discovery profile, negotiation, many transports	Younger ecosystem, newer releases
Unattended or delegated buying	AP2 layered on a checkout protocol	Signed mandates and audit chain	Liability treatment still unsettled
Agent platform integrating many stores	UCP discovery plus ACP-compatible adapters	Avoid per-store adapters	Two checkout schemas to normalize
Issuer or PSP evaluating evidence	AP2 mandates	Role-scoped signed evidence	Verification and key management
Regulated or high-value purchases	Any, with human-present AP2 mode	Explicit approval step	Latency and abandonment

Security, Cost and Capacity Considerations

Threat model in one paragraph

The adversaries are a prompt-injected agent, a malicious merchant profile, a compromised platform, a replayed request and a leaked token. Each protocol addresses a subset. Tokens bound to a session, merchant, amount and expiry limit blast radius. Signed requests prevent forgery and replay when implemented. Mandates limit what a compromised agent can authorize, since the closed mandate binds to one cart. Authority binding limits spoofed schemas. None of these helps if the agent’s own reasoning is hijacked into producing a perfectly valid, perfectly signed but unwanted request, which is why open mandates need tight constraints.

Idempotency, retries and the double-charge problem

Agents retry. A language-model-driven client that sees a timeout may resubmit, or a planner may decide to “try again” with a regenerated request body. ACP’s mandatory Idempotency-Key on creates, updates, completes and cancels makes retries safe only if the client reuses the key and the server stores the original response. A fresh key per retry defeats the entire mechanism. Make key generation a deterministic function of the logical operation (for example, a hash of session id and operation) rather than a random value minted inside the retry loop.

On the merchant side, the Idempotent-Replayed response header and the idempotency_in_flight code in the delegated payment spec imply that concurrent duplicates must be detected and serialized. Budget for a keyed store with a retention window longer than your longest retry horizon.

Capacity and cost

I have no verified published benchmarks for any of these protocols, so I will not quote throughput numbers. What you can reason about from first principles is where load lands. UCP discovery adds a profile fetch per platform-business pair, which is cacheable and, per the spec, must be served over HTTPS without redirects; cache aggressively and honor version changes. Request signing under RFC 9421 adds a signature verification per call, which is small compared with a payment authorization but not free at scale. Mandate verification adds credential and chain validation to the authorization path, and it is the part most likely to add latency, so measure it in your own environment before committing it to a synchronous checkout.

Cost is mostly engineering and risk, not infrastructure. The expensive item is maintaining two or three checkout adapters against specs that are still releasing every few months. The ACP repository lists dated releases on 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30 and 2026-04-17, roughly one every one to three months. Plan an upgrade budget.

Trade-offs, Gotchas, and What Goes Wrong

The specs are young and moving. ACP is labeled beta. UCP’s own overview shows a 2026-08-25 version in its examples. AP2 has changed its vocabulary between its first announcement and its current site. Pin a version, write contract tests against the published JSON Schema or OpenAPI, and expect to revisit.

Governance is not yet neutral. ACP is jointly governed by OpenAI and Stripe with a stated intent to move to a foundation. AP2 has a stated FIDO Alliance relationship. UCP is run in the open with a public roadmap, but the originating company is a large platform. If a spec’s maintainers are also your competitor or your platform, a roadmap decision can become a business decision. This is an assessment, not a claim of bad faith.

Fragmentation tax. Supporting all three is possible and may be necessary for reach, but each adapter has its own state machine, error vocabulary and webhooks. The failure pattern is a merchant whose order state diverges between adapters because each maps “pending approval” differently.

The escalation path is a conversion cliff. Both ACP’s escalation statuses and UCP’s continue_url push the buyer to a human flow. If your fraud rules or 3-D Secure triggers fire too often, the agent experience degrades into a link to a normal checkout, which defeats the purpose. Tune risk rules for agent traffic deliberately rather than inheriting browser-oriented rules.

Risk signals are thin. The delegated payment spec’s risk_signals accepts a card_testing type with a score and an action. That is a start, but fraud models trained on human sessions will see agent sessions as anomalous. Expect false positives and plan a feedback loop with your PSP.

Mandates do not stop a bad cart. A user can sign an open mandate that is too generous. The cryptography proves what was authorized; it does not judge whether that was wise. Build product guardrails (default low limits, short windows, merchant allowlists) around the protocol.

Prompt injection reaches commerce. A product description that tells an agent to “add the premium upgrade” is untrusted input flowing into a purchasing decision. No protocol in this article fixes that. The mitigation is architectural: separate the model that reads untrusted content from the component that holds authority to sign, and require human approval above a threshold.

Webhook ordering and replays. ACP and UCP both use webhooks for order lifecycle events. Webhooks arrive late, twice, or out of order. Treat them as hints to refetch authoritative state, and verify signatures. UCP requires business-to-platform webhooks to be signed.

Anti-pattern: letting the agent hold the card. If your design has the language model or its tool runtime see a primary account number, you have left the protocols’ intended trust boundary and moved a large amount of scope into your PCI assessment. Keep credentials in the vault and pass tokens.

Practical Recommendations

Start from your role, not from the protocol list. A merchant should publish a clean internal order model first, then add adapters in order of demand. An agent builder should abstract the checkout behind a single internal interface so a protocol can be swapped without rewriting the planner. A PSP should expose scoped tokens and prepare to verify mandates.

For most merchants today, the least risky sequence is to adopt whichever checkout protocol your PSP and your target agent surfaces already support, implement idempotency and webhook handling to production standard, and only then add discovery and authorization layers. If you are building an unattended-purchase product, design the mandate and audit story first, because retrofitting evidence is harder than building it in.

Do not choose on hype. Choose on three tests: which agent surfaces will actually send you traffic, which PSP relationships you already have, and how much of the evidence chain your own risk team requires.

Practical checklist:

• Pin the spec release (for example ACP API-Version, UCP profile version) and record it in your runbook.
• Generate idempotency keys deterministically and persist them before the network call.
• Keep raw card data out of agent runtimes, logs and prompts; pass vault tokens or handler payloads only.
• Bind tokens to session, merchant, amount and expiry wherever the protocol allows.
• Verify request and webhook signatures; rotate keys and publish them via a JWK Set where UCP applies.
• Normalize all protocol orders into one internal order model before business logic runs.
• Tune fraud and 3-D Secure rules for agent traffic, and measure the escalation rate.
• Set conservative default mandate limits and short validity windows.
• Add contract tests against the published OpenAPI or JSON Schema and run them on every spec bump.
• Track governance announcements, including any foundation transfer, as part of vendor risk.

Frequently Asked Questions

What are agentic commerce protocols?

Agentic commerce protocols are open specifications that let AI agents discover products, build carts, pay and track orders on a buyer’s behalf. The main ones are the Agentic Commerce Protocol (ACP) from Stripe and OpenAI, the Agent Payments Protocol (AP2) from Google, and the Universal Commerce Protocol (UCP) from Google with retail partners. Each covers a different layer: checkout, authorization proof, or discovery and negotiation.

What is the difference between ACP and AP2?

ACP defines how an agent talks to a merchant to create, update and complete a checkout session, plus a delegated payment endpoint that issues a scoped vault token. AP2 defines signed mandates that prove what the user authorized, shared with the merchant, credential provider and processor. ACP is a transaction interface; AP2 is an authorization evidence layer. They address different problems and can be combined.

What is the Universal Commerce Protocol?

The Universal Commerce Protocol is an open-source standard, announced by Google in January 2026 with Shopify, Etsy, Wayfair, Target and Walmart, that gives agents a common language for discovery, checkout and order management. Businesses publish a profile at /.well-known/ucp, and platforms negotiate versions and capabilities. It supports REST, MCP and A2A transports and can carry AP2 mandates through an optional extension.

Are ACP, AP2 and UCP competing standards?

Partly. ACP and UCP overlap on checkout, so a merchant may need to support both or pick by traffic. AP2 is mostly complementary because it adds authorization evidence and is designed to work with UCP and A2A. The practical answer is to treat them as layers, put an internal canonical model behind them, and adopt the ones your PSP and target agent surfaces support.

How do AI agent payments avoid exposing card numbers?

By delegating credentials. In ACP, the agent calls a delegated payment endpoint and receives a vault token bound to a session, merchant, maximum amount and expiry, then passes that token to the merchant. UCP says platforms should handle only tokens, encrypted payloads or mandates, not raw credentials. AP2 routes payment mandates to the credential provider and processor rather than the merchant.

Are these protocols production-ready?

They are in active use but still evolving. The ACP repository labels its specification as beta and has shipped several dated releases since September 2025. UCP publishes versioned releases and a public roadmap. AP2 has revised terminology and is moving toward standards-body stewardship. Production use is realistic, but pin versions, test against schemas, and expect upgrades every few months.

Further Reading

Internal:

• Payment API idempotency keys and exactly-once retries for the retry discipline agent checkout depends on.
• 3MF vs STEP AP242 vs glTF vs JT for digital twin and PLM for a parallel layered-standards comparison.
• STEP AP242 vs JT vs QIF for MBD and PMI for capability versus fixed-schema trade-offs.

External:

• Stripe documentation: Agentic Commerce Protocol and the ACP GitHub repository.
• UCP specification overview and the AP2 site.

By Riju — about