Agentic Commerce Protocols (UCP, ACP, AP2)

Agentic commerce protocols are the open standards that let an AI agent discover products, fill a cart, check out and pay on a person’s behalf, without scraping a website built for human eyes. Three names dominate the conversation: the Universal Commerce Protocol (UCP), co-developed by Google, Shopify and a large retail coalition; the Agentic Commerce Protocol (ACP), from OpenAI and Stripe; and Google’s Agent Payments Protocol (AP2), now governed by the FIDO Alliance. They are frequently presented as competitors, but they mostly answer different questions: UCP and ACP define how an agent and a merchant talk about a purchase, and AP2 defines how anyone can verify the agent was actually allowed to make it. Together with MCP, A2A and AG-UI, they round out the agent protocol stack with the last mile: money.

Why Agents Need Their Own Commerce Standards

A normal web checkout is a maze of forms, sessions, cookies, bot defenses and pop-ups tuned for a human with a mouse. An agent that has to drive it by clicking is slow and fragile, and every merchant looks different. Two separate problems sit underneath.

The semantics problem. An agent needs a machine-readable way to say “show me what you sell, add these to a cart, tell me the total with tax and shipping, and place the order,” and to get back structured answers, including “I can’t finish this without the buyer.” That is what UCP and ACP standardize.

The trust problem. A card network, a bank or a merchant now receives an order that no human clicked. Did the user really authorize it? For how much? What if the agent hallucinated a quantity, or a malicious product page injected an instruction to buy fifty units? AP2’s documentation states the principle directly: trust in payments is anchored to deterministic, non-repudiable proof of intent from the user. That is a job for cryptography, not for the language model’s judgment.

The Stack at a Glance

%%{init: {'theme': 'base'}}%%
graph TD
    classDef default fill:#ffffff,stroke:#4338CA,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef data    fill:#EEF0F7,stroke:#0D9488,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef process fill:#F7F8FC,stroke:#6366F1,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef output  fill:#4338CA,stroke:#4338CA,stroke-width:2px,color:#ffffff,rx:8px,ry:8px;

    U[User]:::data -->|"signs open mandates on a trusted surface (AP2)"| A[AI agent or shopping platform]:::process
    A -->|"AG-UI: progress and approvals"| U
    A -->|"MCP and A2A: tools and peer agents"| X[Other tools and agents]:::data
    A -->|"UCP or ACP: discover, cart, checkout, order"| M[Merchant or business]:::process
    A -->|"AP2: checkout and payment mandates"| C[Credential provider and payment network]:::process
    M -->|"payment token redeemed through the PSP"| C
    M --> O[Order confirmed and webhooks]:::output

UCP: Discovery, Capabilities, Checkout

The Universal Commerce Protocol was announced by Google on January 11, 2026 at the National Retail Federation’s conference, developed with Shopify, Etsy, Wayfair, Target and Walmart and endorsed at launch by more than twenty partners including Visa, Mastercard, Stripe, American Express, Best Buy, The Home Depot and Zalando. Its published spec is open under the Apache 2.0 license, and Google positioned it to power checkout inside AI Mode in Google Search and the Gemini app.

UCP names three participants: the Platform (the buyer-facing agent or app), the Business (the seller), and the Credential Provider (a bank, processor or wallet that holds payment credentials). A business advertises what it supports in a machine-readable profile at /.well-known/ucp, which contains the protocol version (YYYY-MM-DD format), the transports it offers, its capabilities, its payment handlers, and a set of public signing keys. That document is deliberately also a valid JWK Set (RFC 7517), so signed requests can be verified with standard tooling.

import httpx

# Scenario: a procurement agent has been told to reorder printer toner from
# supplies.example.com. Before it builds a cart, it fetches the merchant's UCP
# profile to learn which capabilities, transports and payment handlers exist.
# Field names follow the spec's profile description; check the current schema
# before relying on the exact shape.
profile = httpx.get("https://supplies.example.com/.well-known/ucp").json()
ucp = profile["ucp"]

print(ucp["version"])            # protocol version, YYYY-MM-DD
print(list(ucp["services"]))     # transports offered: REST, MCP, A2A, embedded
print(ucp["payment_handlers"])   # how this merchant accepts payment tokens
signing_keys = profile["keys"]   # JWK Set used to verify the merchant's signed messages

def supports(capabilities, name):
    names = capabilities if isinstance(capabilities, dict) else [c.get("name") for c in capabilities]
    return name in names

if not supports(ucp["capabilities"], "dev.ucp.shopping.checkout"):
    raise SystemExit("merchant does not offer agentic checkout")

Capabilities are named in reverse-domain form, such as dev.ucp.shopping.checkout, and each carries its own version and JSON Schema. Extensions such as dev.ucp.shopping.discount attach to a parent capability through an extends field. When a platform and a business meet, they run a capability intersection: each side lists what it supports, and only what both understand is active for that conversation. The core capabilities are catalog search and lookup, cart, identity linking (OAuth 2.0), checkout and order management. Transport is pluggable: a business can expose UCP over REST, over MCP, over A2A, or as an embedded experience, so an existing MCP-speaking agent can shop without a new client stack.

The checkout capability is a small state machine, and its statuses are the most useful thing to know:

The continue_url is the protocol’s built-in escape hatch: a business must supply it when it returns requires_escalation, so a human can finish in the merchant’s own interface. Designing the agent to hand off gracefully, rather than push through, is the practical lesson of the whole space.

ACP: The Checkout API a Merchant Implements

The Agentic Commerce Protocol was released on September 29, 2025 by OpenAI and Stripe alongside ChatGPT’s Instant Checkout (Stripe’s documentation now also credits Meta as a co-creator). It is an interaction model in which the agent facilitates the purchase but is not the merchant of record: the business keeps its normal role in payments, tax and fulfillment. ACP is open under Apache 2.0 with date-based versions (the initial 2025-09-29 release, then several updates, the current stable spec being 2026-04-17). Its building blocks, per Stripe’s documentation, are agentic checkout, cart and feed, delegated payment, delegated authentication (OAuth 2.0), and orders with webhooks.

A merchant implements five HTTPS endpoints, exactly as in the code example at the top of this entry:

The session’s status moves through not_ready_for_payment, ready_for_payment, completed and canceled, and requests carry an Authorization bearer token, an Idempotency-Key, a Signature (HMAC of the body) and an API-Version. The merchant also sends order webhooks back to the agent platform.

The payment half is the Delegated Payment flow. The agent platform never handles the buyer’s card number: it passes an encrypted token (with Stripe, a Shared Payment Token scoped to a merchant and a basket total), and the merchant redeems it through its own payment processor exactly as it would for a non-agentic payment, for example by creating a PaymentIntent. Merchants that do not use Stripe can accept delegated payment tokens through their own PSP.

The Instant Checkout Reversal

ACP also carries the most instructive story in the space. ChatGPT’s Instant Checkout, the consumer feature that let people buy inside the chat, launched in September 2025 with Etsy as an early merchant and was retired in March 2026, about six months later, after reports of low adoption and inaccurate inventory and shipping data. OpenAI moved to a discovery-first model: shoppers find products in ChatGPT and finish either on the merchant’s site or in a merchant-built app inside ChatGPT. The reasoning, as summarized by Checkout.com, was that checkout depends on merchant-specific logic (inventory, promotions, regional compliance, loyalty) that does not abstract cleanly, and that shoppers already move fluidly between environments.

The protocol survived because it standardized the interface, not the surface. ACP now functions as an enablement layer that extends beyond payments into product discovery, while merchants keep control of the transaction.

AP2: Proving the Agent Was Allowed to Spend

Neither UCP nor ACP answers the question a bank will ask: who authorized this? The Agent Payments Protocol was announced by Google on September 16, 2025, with more than 60 launch partners, including Mastercard, PayPal, American Express, Adyen, Coinbase and Salesforce. On April 28, 2026, Google donated it to the FIDO Alliance and released version 0.2, which added Human Not Present payments: an agent can complete a purchase autonomously based on pre-authorized instructions, such as buying limited-run tickets the moment they release. FIDO has since formed working groups on agentic authentication and payments, building on AP2 and Mastercard’s Verifiable Intent framework, a companion standard that keeps a tamper-proof record of what a user authorized an agent to do.

AP2’s core object is the mandate: a signed digital credential proving that “this agent may spend this amount, under these conditions, on behalf of this user.” Google’s original write-up described three (an Intent Mandate, a Cart Mandate and a Payment Mandate). The v0.2 specification organizes them as two types, each with an open and a closed stage:

Mandates are encoded as SD-JWTs (selective-disclosure JWTs), so each party sees only the fields it needs, and each names its schema with a vct claim (for example mandate.payment.1). In the human-present flow, the user signs the closed mandates for the exact cart. In the human-not-present flow, the user signs open mandates once, on a trusted surface, and embeds the agent’s public key in a cnf claim; the agent can then sign closed mandates itself, but only within the constraints the user set.

# Scenario: what the user's one-time approval of "reorder toner, up to $150" could
# produce: an OPEN payment mandate with constraints, plus the agent's public key
# in `cnf` so the agent can later sign the CLOSED mandate for one exact checkout.
# The constraint field names below are illustrative; see the AP2 spec for the schema.
open_payment_mandate = {
    "vct": "mandate.payment.1",          # schema id; the numeric suffix is its version
    "cnf": {"jwk": agent_public_jwk},    # binds the mandate to the agent's signing key
    "constraints": {
        "max_amount": {"currency": "USD", "value": "150.00"},
        "allowed_instruments": ["card"],
    },
}
# The user signs this once (for example with a passkey prompt). At purchase time
# the agent presents it alongside a closed, agent-signed mandate for the exact
# total; the merchant and the payment network can each verify the chain.

AP2 is payment-method agnostic: its human-not-present flows can use cards or the x402 protocol, an open standard that revives the long-dormant HTTP 402 Payment Required status code so an agent can pay for an API call or a paywalled resource with stablecoins and no account or API key.

# Scenario: an agent buys a single data lookup from a pay-per-request API.
# x402 turns "pay for this request" into a normal HTTP round trip. This is a
# sketch: the payload and header names come from the x402 spec and its client
# libraries, so use those rather than the placeholders below.
url = "https://api.example.com/price-feed?sku=toner_xl"
resp = client.get(url)
if resp.status_code == 402:                        # server says what to pay and in which asset
    proof = wallet.pay(resp.json())                # agent pays, e.g. in a stablecoin
    resp = client.get(url, headers=payment_headers(proof))   # retry with proof of payment
print(resp.status_code)                            # 200, data returned

Interactive: Would This Purchase Need a Human?

The value of an open mandate is that it turns “should the agent be trusted with this?” into a check that runs outside the model. The widget below is a simplified policy check in the spirit of AP2’s constraints (budgets and allowed instruments), joined to UCP’s checkout statuses. It is a teaching model, not the spec’s schema.

Drag the quantity up until the total crosses the cap and the flow flips from autonomous to escalated. Switch the payment instrument to a stablecoin and it flips again, even though the amount is fine, because the user’s mandate never authorized that instrument. The point is that the boundary is enforced by a signed, checkable constraint, not by the model deciding it feels confident.

Putting the Layers Together

A complete purchase touches all of them. The agent below is the toner-reordering procurement agent from the examples above.

# Scenario: the full loop for one purchase. The agent shops with UCP, checks the
# user's mandate (AP2), and falls back to a human whenever the protocol or the
# mandate says it must. `client` is whichever UCP binding you use (REST, MCP or
# A2A); `mandate` wraps the user-signed open mandates.
def buy_toner(client, mandate, items):
    checkout = client.create_checkout(line_items=items)

    while checkout["status"] == "incomplete":          # missing info: read messages, fix, retry
        checkout = client.update_checkout(checkout["id"], resolve(checkout["messages"]))

    if checkout["status"] == "requires_escalation":    # the API can't finish this by itself
        return hand_off_to_user(checkout["continue_url"])

    if checkout["status"] == "ready_for_complete":
        if not mandate.permits(checkout):              # over budget, wrong merchant or instrument
            return hand_off_to_user(checkout["continue_url"])
        closed = mandate.close(checkout)               # agent-signed, bound to this exact total
        payment = credential_provider.tokenize(closed) # payment handler returns a scoped token
        checkout = client.complete_checkout(checkout["id"], payment=payment)

    return checkout                                     # completed: track the order

Note that the decision to hand off is never the model’s: it comes from the protocol’s own status values and from a mandate check that runs as ordinary code.

Security and Failure Modes

An April 2026 systematization paper, SoK: Security of Autonomous LLM Agents in Agentic Commerce, organizes the threats into five dimensions (agent integrity, transaction authorization, inter-agent trust, market manipulation and regulatory compliance) and identifies twelve cross-layer attack vectors, arguing that securing agentic commerce is inherently a cross-layer problem. The protocols address parts of it:

• Injected instructions. A product page, review or email can carry text that redirects a shopping agent. Constraints in a signed mandate do not care what the model was persuaded of: an over-budget order fails the check regardless. Keep the check outside the model, and keep human-in-the-loop confirmation for anything the mandate does not clearly cover.
• Price and quantity drift. Totals can change between cart and completion. Bind the closed mandate to the exact total, and re-read the checkout state before signing, not before the last update.
• Merchant and platform impersonation. UCP’s profile publishes signing keys as a JWK Set so requests can be authenticated; validate them rather than trusting the domain alone.
• Credential exposure. Delegated payment tokens exist so the agent never sees a card number. Do not log them, and prefer tokens scoped to one merchant and one amount.
• Accountability. Verifiable, signed records of what the user authorized are what makes chargebacks and disputes tractable once an agent, not a person, pressed the button.

What’s New (2025-2026)

• Convergence, not a standards war. Processors are supporting more than one layer at once: Stripe’s documentation covers ACP and lists Stripe as a member of UCP’s Tech Council with a UCP payment handler. UCP, for its part, explicitly supports AP2, A2A and MCP as bindings.
• Neutral governance for the trust layer. Moving AP2 to FIDO is a bet that payment authorization for agents should be a shared, vendor-neutral standard, in the same way passkeys became one.
• Merchant control wins. The Instant Checkout retreat pushed the ecosystem toward protocols that keep merchants in charge of checkout logic, with agents doing discovery and handing off cleanly.

Practical Guidance

Agentic commerce protocols do not make an agent a better shopper. What they do is turn a purchase into something structured enough to automate and accountable enough to trust: an agent that can be handed a budget, a merchant that can prove what it was asked for, and a bank that can check who said yes.

from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
import uuid

# Scenario: a small office-supplies shop lets AI agents buy toner. It exposes
# the ACP checkout-session endpoints; the agent (for example ChatGPT) calls
# them, and the shop stays the merchant of record. Field shapes are
# abbreviated here: see the ACP OpenAPI spec for the full schemas.
app = FastAPI()
CATALOG = {"toner_xl": {"name": "Black toner XL", "unit_amount": 8900}}  # cents
SESSIONS: dict[str, dict] = {}

class Item(BaseModel):
    id: str
    quantity: int

class CreateSession(BaseModel):
    items: list[Item]
    fulfillment_address: dict | None = None

def cart_state(sid: str, items: list[Item], address: dict | None) -> dict:
    line_items = [
        {"item": i.id, "quantity": i.quantity,
         "total": CATALOG[i.id]["unit_amount"] * i.quantity}
        for i in items
    ]
    return {
        "id": sid,
        "status": "ready_for_payment" if address else "not_ready_for_payment",
        "line_items": line_items,
        "totals": [{"type": "total", "amount": sum(l["total"] for l in line_items)}],
        "messages": [] if address else [{"type": "info", "text": "Shipping address needed"}],
    }

@app.post("/checkout_sessions")
def create_session(body: CreateSession, idempotency_key: str = Header(None)):
    sid = f"cs_{uuid.uuid4().hex[:8]}"
    SESSIONS[sid] = cart_state(sid, body.items, body.fulfillment_address)
    return SESSIONS[sid]                      # always returns a session id + full cart

@app.post("/checkout_sessions/{sid}/complete")
def complete_session(sid: str, payment_data: dict):
    session = SESSIONS.get(sid)
    if not session or session["status"] != "ready_for_payment":
        raise HTTPException(409, "session not ready for payment")
    # Redeem the delegated payment token through your PSP (with Stripe, this
    # is a PaymentIntent created from the Shared Payment Token), then confirm.
    session["status"] = "completed"
    return session