Agentic commerce protocols, compared.
Several protocols, backed by different camps, now define how agents shop, pay, and get recognized online. This page maps what each one standardizes, what it leaves open, and where a neutral authorization and evidence layer fits. Statuses reflect public information as of October 2026.
What each one covers.
AP2
The Agent Payments Protocol (Google, now at the FIDO Alliance; current version v0.2) defines the roles, mandate formats, and verification duties for agent-initiated payments. Mandates are signed verifiable credentials that carry exact bounds: amount, payee, instruments, recurrence, budget. User intent travels as the signed artifact rather than as platform state. Evidence retrieval and storage are out of scope, and issued mandates have no revocation or status protocol.
UCP
The Universal Commerce Protocol (Google, with Shopify and a council spanning Stripe, Amazon, Meta, Microsoft, and Salesforce) standardizes how agents discover, cart, and check out across merchants: capabilities, discovery, message signing, and payment handlers. It has no mandate concept of its own; where provable user authorization is needed, it delegates to AP2 through a negotiated extension.
ACP
The Agentic Commerce Protocol (OpenAI and Stripe) is the checkout layer behind ChatGPT-style commerce: a checkout session API, delegated payment through allowance-scoped tokens, payment handlers, and 3DS2 delegate authentication. Authorization is a token the platform issues for one session and merchant. There is no portable, user-signed authorization artifact, and the evidence is order and webhook records inside that flow.
Visa Trusted Agent Protocol
Part of Visa Intelligent Commerce (introduced October 2025, with Cloudflare), the Trusted Agent Protocol standardizes how a merchant or its CDN recognizes an agent: RFC 9421 signed requests with published keys, consumer recognition, and payment containers, including 402-style browsing IOUs. It carries no user-signed constraint object, so TAP alone does not prove what the user authorized; cross-scheme key discovery is still emerging.
Mastercard Agent Pay and Verifiable Intent
Mastercard Agent Pay registers agents on the network and issues agentic tokens under user-defined limits. Verifiable Intent (Mastercard with Google, contributed to FIDO; draft v0.1) is its evidence layer: cryptographic proof of who the user is, what they intended, and what the agent did, with selective disclosure, verifiable independently by issuers, networks, and merchants. The wire-level specifications are gated, the Verifiable Intent integration is still in progress, and revocation is deferred to a later version.
x402
x402 (started by Coinbase, now a Linux Foundation project) turns HTTP 402 into a payment flow: a request carries a signed payment payload, a facilitator verifies and settles it, with exact, upto, and batch-settlement schemes. It authorizes one specific transfer between a payer and a resource. It has no identity layer and no mandate concept, and its evidence is the settlement record.
The slice none of them covers.
Read across all of them and the artifacts that exist are signatures, tokens, mandates, receipts, and orders. Each one lives inside its own ecosystem: a mandate is checked by the parties AP2 names, an allowance token means something inside a single platform, a network token is validated by the issuer, and an x402 payment settles on its rail. What none of these defines, as of October 2026, is a neutral, PSP-agnostic layer for the authorization itself and for evidence that verifies across all of them.
That neutral slice is what Attesso builds, and it requires none of these protocols:
- A mandate the user approves with a passkey: one exact set of bounds, signed, and immutable.
- A deterministic decision for each proposed action (ALLOW, DENY, or INDETERMINATE), failing closed when eligibility cannot be established.
- Signed evidence for every step, verifiable without trusting Attesso.
- No credential custody and no execution: Attesso authorizes and records; your systems execute.
Whichever of these protocols your side adopts stays where it belongs. Attesso claims no conformance with any of them; the one compatibility path being explored is AP2, with Attesso as the verifier and no conformance claimed yet. Read the AP2 position.
Building on one of these protocols?
Discuss which part Attesso covers in your flow, and what your side needs to prove.