{ "source": "Agentic Commerce Atlas", "url": "https://agenticcommerceatlas.com", "license": "CC BY 4.0: quote or reuse with attribution to Agentic Commerce Atlas.", "updated": "2026-10-05", "protocols": [ { "id": "acp", "name": "ACP", "fullName": "Agentic Commerce Protocol", "layer": "commerce-semantics", "maintainer": "OpenAI and Stripe (founding maintainers); MAINTAINERS.md also lists Meta", "license": "Apache-2.0", "status": "beta", "announced": "2025-09-29", "specUrl": "https://github.com/agentic-commerce-protocol/agentic-commerce-protocol", "atlasUrl": "https://agenticcommerceatlas.com/learn/acp-explained", "summary": "Open standard for agent-to-merchant checkout, and since March 2026 for product discovery as well. It powered the original ChatGPT Instant Checkout. On 24 March 2026 OpenAI said the first version of Instant Checkout did not offer the flexibility it wanted, so it is allowing merchants to use their own checkout experiences while OpenAI focuses on product discovery, and it is expanding ACP to cover discovery as the connective layer between merchants and users. That is a de-emphasis of in-chat checkout rather than a migration of Instant Checkout onto ChatGPT plugins, which merchants already had as an option; and Instant Checkout itself is not retired, OpenAI's own developer documentation describes it as currently available to approved partners, with no published merchant or region list. Payment flows via a Shared Payment Token, which grants one seller scoped access to a payment method under usage limits carrying a maximum amount and an expiry that the agent sets to match the selected cart, rather than a protocol-enforced binding to an exact cart total; Stripe's implementation is available in the US, Canada and select European countries. Spec revisions are date-versioned by directory rather than by GitHub release or tag: 2026-04-17 is the latest stable revision (cart, feed, orders, authentication, and MCP), following 2026-01-30, 2026-01-16, 2025-12-12 and 2025-09-29." }, { "id": "ucp", "name": "UCP", "fullName": "Universal Commerce Protocol", "layer": "commerce-semantics", "maintainer": "Governing Council (Google, Shopify, Stripe, plus two seats open for election) over per-domain Tech Councils: a 16-seat Shopping Tech Council (Google, Shopify, Amazon, Etsy, Meta, Microsoft, Salesforce, Stripe, Target, Wayfair), a Food Tech Council formed July 2026 (Google, Square, Toast, DoorDash, Uber Eats), a Lodging Tech Council seated 11 August 2026 (Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, Trip.com), and a Payments Tech Council seated 2 September 2026 (Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, Stripe)", "license": "Apache-2.0", "status": "launched", "announced": "2026-01-11", "specUrl": "https://ucp.dev/", "atlasUrl": "https://agenticcommerceatlas.com/learn/ucp-explained", "summary": "Google's standard covering the full shopping journey from discovery through checkout to post-purchase. The main rival to ACP at the commerce layer; pairs with AP2 for payments via an opt-in extension. Spec revisions are date-versioned: v2026-08-25 is the current revision, released 25 August 2026, following v2026-04-08, v2026-01-23 and v2026-01-11. UCP's own announcements page describes it as introducing major protocol enhancements, key structural refactorings to support multi-vertical expansion, payments security improvements (3DS2), structured request constraints, independent capability versioning and grocery shopping readiness. The structural change is visible in the published specification: the top level is now the domain verticals Shopping, Payment and Common rather than a shopping-first tree, common primitives are centralized and payment extensions refactored into the dev.ucp.common.payment namespace, a Location capability for finding physical stores was introduced, and the release notes name Payment Terms and Schedules, Split Payments and Loyalty as new extensions. It carries breaking changes, so existing implementers should read the release notes before moving versions. On 25 September 2026 the first draft of the Lodging Booking capability, dev.ucp.lodging.booking, was merged into the repository, the formal expansion of UCP into lodging and the first vertical council to produce specification text; it is a draft merged outside the release cadence, not part of a published revision. Governance runs through a Governing Council sitting over per-domain Tech Councils. On 24 April 2026 Amazon, Meta, Microsoft, Salesforce, and Stripe joined what is now the Shopping Tech Council, taking it to sixteen seats spread across ten companies, and Stripe joined the Governance Council on 28 April 2026. On 16 July 2026 a second domain body, the Food Tech Council, was seated with Block (Square), DoorDash, Google, Toast, and Uber Eats. On 11 August 2026 a third, the Lodging Tech Council, was seated with Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com, covering global distribution, online travel agencies and hotel groups. On 2 September 2026 a fourth, the Payments Tech Council, was seated with Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe, the first council organized around a capability rather than a retail vertical and the governance counterpart to the payment layer that v2026-08-25 lifted out of shopping. Google holds four of the sixteen Shopping seats and six of the ten filled Food seats, so the protocol is open-governed on paper while Google remains its largest single voice. At Google Marketing Live on 20 May 2026, Google extended UCP with named-brand Universal Cart and into new verticals, lodging and food delivery, and said UCP-powered checkout would roll out across Canada and Australia in the coming months and later to the UK. Much of this is announced rather than shipped, and the geography has slipped rather than landed: Google's own blog of 16 September 2026 says the new capabilities are gradually rolling out in the US with Australia and Canada to follow early next year, and there is no first-party evidence of a UK launch. Google's merchant documentation still gates participation, stating that the checkout feature enabled by UCP is available for select merchants at this time, behind an early-access interest form and a native_commerce(checkout_eligibility) product attribute, although its eligibility scope line now names the United States, Canada and Australia while its sibling terms-of-service article is still titled US only. Set that gate against scale rather than instead of it: the same Google post says UCP already enables direct checkout for hundreds of thousands of brands and retailers across Google. UCP semantics have also reached the browser: on 28 September 2026 Shopify added WebMCP support to its checkout, and its developer documentation describes Checkout WebMCP as implementing the UCP checkout capability over browser-registered WebMCP tools instead of server-side JSON-RPC, so browser agents can read, update and submit a Shopify checkout, with the buyer confirming the order before completion; WebMCP is still a proposed web standard and agent support is limited to Chromium-based browsers. UCP's own roadmap still lists the food and lodging capabilities as being developed rather than published, though it now describes the lodging work as going beyond Booking, which concedes the Booking capability has landed." }, { "id": "ap2", "name": "AP2", "fullName": "Agent Payments Protocol", "layer": "payment-authorization", "maintainer": "Google (repository and copyright); future standardization moved to the FIDO Alliance in April 2026", "license": "Apache-2.0", "status": "v0.2, no stable release", "announced": "2025-09-16", "specUrl": "https://ap2-protocol.org/", "atlasUrl": "https://agenticcommerceatlas.com/learn/ap2-explained", "summary": "Payment-authorization and trust standard using signed mandates as verifiable digital credentials. v0.2 defines two mandate types, the Checkout Mandate and the Payment Mandate, each existing in an open and a closed stage, secured with SD-JWTs; there is no Intent Mandate or Cart Mandate in v0.2. Current version is v0.2, released 28 April 2026, the same day Google donated the protocol to the FIDO Alliance for community governance and standardization and the same day FIDO announced the initiatives. AP2 is one of two initial contributions rather than a finished FIDO standard: Mastercard contributed Verifiable Intent, an AP2-compatible layered SD-JWT credential framework it co-developed with Google and had already launched publicly on 5 March 2026, and FIDO states that both contributions will be reviewed and further developed through its collaborative standards process in the Payments Technical Working Group. No FIDO specification has yet been published from that work, and FIDO's own agentic page remains future-tense. The handover is of future standardization rather than of the artifacts: the repository is still google-agentic-commerce/AP2, the documentation still carries a Google copyright, and the project FAQ still describes AP2 in the present tense as an open source project created by Google. Two working groups carry it: the Payments Technical Working Group, chaired by Mastercard and Visa, and a new Agentic Authentication Technical Working Group, chaired at launch by CVS Health, Google and OpenAI and vice-chaired by Amazon, Google and Okta, which puts OpenAI inside FIDO governance while it backs ACP at the commerce layer. Visa and Stripe were both absent from the September 2025 launch partners; Visa has since come inside AP2 governance as a Payments working group co-chair. Stripe is not named in FIDO's announcement or in Google's donation post and backs ACP and MPP at its own layers, but no first-party roster confirms it is outside FIDO's agentic work, so treat its position as unconfirmed rather than settled. AP2 does not allocate liability: its stated objective is to provide supporting evidence that helps payment networks establish accountability and liability principles. It does specify dispute evidence and mandatory dispute verification rules; what sits outside its scope is narrower, namely how that evidence is used for dispute resolution and the retention and retrieval requirements around it. A reader should not conclude that AP2 settles who pays when an agent gets it wrong. Note also that Visa Intelligent Commerce Connect lists Trusted Agent Protocol, MPP, ACP and UCP as the protocols it accepts, and does not list AP2." }, { "id": "mcp", "name": "MCP", "fullName": "Model Context Protocol", "layer": "discovery", "maintainer": "Agentic AI Foundation, a directed fund under the Linux Foundation (originated at Anthropic; donated December 2025)", "license": "open source", "status": "widely adopted", "announced": "2024-11", "specUrl": "https://modelcontextprotocol.io/", "atlasUrl": "https://agenticcommerceatlas.com/learn/mcp-explained", "summary": "General standard for connecting AI agents to tools and data. Not a commerce protocol; in commerce it acts as the discovery layer, and ACP and UCP can use it as a transport. Spec revisions are date-versioned: 2026-07-28 was published as the stable revision on 28 July 2026, replacing 2025-11-25. It is the largest revision since launch. The protocol core is now stateless (the initialize handshake and the Mcp-Session-Id header are retired, with protocol version, client identity and client capabilities carried in _meta on every request, and a server/discover method that servers must implement and clients may call to get capabilities up front). Server-initiated elicitation, sampling and roots calls are replaced by Multi Round-Trip Requests, Mcp-Method and Mcp-Name headers are required on Streamable HTTP, list results are cacheable via ttlMs and cacheScope, the Extensions framework is formalized (MCP Apps, Tasks and Enterprise Managed Authorization were the official extensions named in the release; the official extensions index now lists five, adding Skills over MCP and OAuth Client Credentials), and authorization is hardened against OAuth 2.0 and OpenID Connect practice, with Dynamic Client Registration deprecated in favor of Client ID Metadata Documents. It contains breaking changes for existing servers; Roots, Sampling, Logging and the legacy HTTP+SSE transport are deprecated under a new policy of at least twelve months before removal (ninety days under an expedited-removal exception) but keep working. A second venue question is now open: on 23 July 2026 the IETF held a working-group-forming BoF in Vienna, Agent Communication Protocols (agentproto), on whether agent-to-agent and agent-to-tool communication needs IETF standards. Draft minutes record strong sense-of-the-room support for forming a group (154 to 51) and for the IETF as the venue (158 to 30), but the proposed scope was rejected (38 for, 124 against). The IETF Secretariat announced a non-working-group mailing list, agentproto@ietf.org, on 24 July 2026, for continuing the discussion including updates to the proposed charter. That process has since moved: the Datatracker now records agentproto as a Proposed working group, with its charter in External Review and on the agenda of the 8 October 2026 IESG telechat; the current text is charter-ietf-agentproto-00-04, posted 2 October 2026, by which point two IESG members had recorded Yes positions and the one earlier Block had been cleared. It is not yet a chartered working group. The charter was rewritten after the BoF around a common baseline agentic dialog management protocol and dialog context, with milestones running from a use-cases draft adopted in December 2026 to the protocol submitted to the IESG in March 2028. MCP and A2A appear in it as carriers rather than subjects: the 2 October revision says the dialog context is defined so that existing application-layer agent communication protocols, naming MCP and A2A, can carry it using their own mechanisms, replacing earlier wording about extension points, and any related change to those protocols stays with their own maintainers. Nothing about MCP governance has changed: it remains at the Agentic AI Foundation, which on 17 August 2026 also became the home of A2A. On 22 August 2026 the lead maintainers published a new roadmap for the releases after 2026-07-28, organized into five priority areas: agentic messaging primitives (server-initiated events and webhooks so clients stop polling, and maturing the Tasks extension into the specification), unifying on HTTP-native transport including local servers speaking Streamable HTTP over stdio, agent identity and enterprise-ready security (DPoP, Workload Identity Federation, token exchange, and engagement with the IETF OAuth and WIMSE working groups), improved primitives (one clear contract for tool results, and progressive discovery so a server with a large catalog can expose a small entry point first), and SDK developer experience. Specification Enhancement Proposals inside those areas get expedited review. Two items matter for commerce: progressive discovery speaks directly to large merchant catalogs, and the Server Card Working Group is still working through .well-known metadata conventions so a server can be discovered and reasoned over without connecting to it. That second item has visibly stalled rather than merely continued: its only work item, SEP-2127 (MCP Server Card), is still Draft against a target date of 3 April 2026, its published output is an experimental repository, and both working group lead terms are listed as having ended on 14 August 2026. All of it is direction, not shipped specification." }, { "id": "a2a", "name": "A2A", "fullName": "Agent-to-Agent", "layer": "agent-coordination", "maintainer": "Agentic AI Foundation, a directed fund under the Linux Foundation (originated at Google; donated to the Linux Foundation in 2025 and moved into the Agentic AI Foundation on 17 August 2026)", "license": "open source", "status": "v1.0.1", "announced": "2025-04", "specUrl": "https://a2a-protocol.org/latest/", "atlasUrl": "https://agenticcommerceatlas.com/learn/a2a-explained", "summary": "Standard for how independent agents communicate and delegate tasks. An agent publishes an agent card describing what it can do and how to reach it, and other agents read that card to discover capabilities and delegate work without a human brokering the handoff. v1.0, its first stable specification, shipped on 12 March 2026, adding multi-protocol bindings and version negotiation, enterprise multi-tenancy, and signed agent cards for cryptographic identity verification (the AgentCard signatures field itself predates v1.0, landing in v0.3.0 in July 2025). The current release is the v1.0.1 patch of 28 May 2026; do not confuse it with the SDK version numbers, which run ahead of the specification. On 17 August 2026 A2A became a hosted project of the Agentic AI Foundation, moving out of the Linux Foundation's broader portfolio into the same body that holds MCP, goose, AGENTS.md, agentgateway and Agent Router. A2A's own announcement, on 27 August 2026, describes the governance tier as a Growth Stage project. That puts the two protocols agentic commerce leans on most, MCP for tool access and A2A for agent coordination, under one neutral governance structure, and it is the clearest instance yet of the 2026 consolidation pattern. More than 150 organizations back A2A itself, a figure the Linux Foundation reported at the protocol's one-year mark in April 2026; the Agentic AI Foundation's own membership is larger, 247 organizations as of 12 August 2026. The Foundation cites Google Cloud and PayPal extending A2A into agentic commerce via AP2, with shopping and merchant agents communicating over A2A while AP2 supplies payment authorization. Google describes AP2 as usable as an extension of A2A and of MCP, rather than as built on A2A alone." }, { "id": "x402", "name": "x402", "fullName": "x402", "layer": "settlement", "maintainer": "x402 Foundation, under the Linux Foundation (originated at Coinbase)", "license": "open source", "status": "live", "announced": "2025-05", "specUrl": "https://github.com/x402-foundation/x402", "atlasUrl": "https://agenticcommerceatlas.com/learn/x402-explained", "summary": "Revives the HTTP 402 status for stablecoin payments between software. Aimed at machine-to-machine and micro-transactions rather than consumer checkout. Aligned with AP2 via an x402 extension. The protocol version is 2, published in December 2025. In mid-2026 AWS shipped x402 enforcement at the edge, as an AI traffic monetization capability of AWS WAF Bot Control available at no additional charge wherever a Web ACL is associated with a CloudFront distribution; Cloudflare's Monetization Gateway, announced 1 July 2026, remains waitlist-only with no GA date. On July 14, 2026 the Linux Foundation announced the operational launch of the x402 Foundation under formal open governance with 40 members at launch; the seventeen premier members span the major card networks and payment providers (Visa, Mastercard, American Express, Stripe, Adyen, Fiserv), platforms (Google, Shopify, AWS, Cloudflare), and crypto infrastructure (Coinbase, Circle, Ripple, MoonPay, and the Monad, Solana and Stellar foundations), a notable mainstreaming of a crypto-native rail. Membership has since grown past the launch figure; the foundation's own members page now lists 17 premier, 24 general and 11 associate organizations. On 24 September 2026 Block announced it had joined the foundation and contributed Bitcoin Lightning payments to the protocol." }, { "id": "mpp", "name": "MPP", "fullName": "Machine Payments Protocol", "layer": "settlement", "maintainer": "Tempo Labs and Stripe", "license": "CC0 1.0 (specifications); Apache-2.0 or MIT (tooling)", "status": "live", "announced": "2026-03-18", "specUrl": "https://github.com/tempoxyz/mpp-specs", "atlasUrl": "https://agenticcommerceatlas.com/learn/mpp-explained", "summary": "Open standard co-authored by Stripe and Tempo for agents to pay services programmatically. Aimed at machine-to-machine microtransactions and recurring payments; settles in stablecoins as well as the cards, wallets, and other methods Shared Payment Tokens carry. Sits alongside x402 at the settlement layer. The core is specified as an HTTP authentication scheme and was first submitted to the IETF in March 2026 as draft-ryan-httpauth-payment, authored by Tempo Labs and Stripe engineers. That document has now expired and is archived; the live document is the shorter name without the author prefix, draft-httpauth-payment, whose revision -01 was submitted on 9 September 2026 by the same five authors and expires 13 March 2027. The rename is not an adoption: the Datatracker records the document as an individual Internet-Draft with no RFC stream, no working group, an IESG state of I-D Exists and no formal standing in the IETF standards process, and it assigns no intended RFC status even though the draft header claims Standards Track. No formal replaces relationship is recorded between the two names. The specification is modular: a payment-method-agnostic core (HTTP 402 semantics, the Accept-Payment, Payment-Authorization and Payment-Receipt header fields, and two IANA registries for payment methods and payment intents), intents, methods, and extensions. The repository README describes the intents as charge, authorize and subscription and the methods as Tempo, Stripe and ACH, but the published draft family has moved past that illustration: the charge intent now has eleven method drafts (card, EVM, Hedera, Lightning, NearIntents, Solana, Stellar, Stripe, Tempo, USDC, XRPL), there is a session intent with six, a subscription intent with Stripe and Tempo, and no ACH draft is published. The drafts are published together at paymentauth.org. Two of them moved on 1 October 2026. draft-payment-discovery reached revision -01, by Tempo Labs and Merit Systems rather than Stripe, defining OpenAPI-based service discovery (an /openapi.json document carrying x-service-info and x-payment-info annotations) so agents can find priced endpoints before requesting them; discovery is advisory and the runtime 402 challenge stays authoritative. And a new draft, draft-payment-transport-mcp-00, by two Tempo Labs authors, defines how the Payment scheme operates over JSON-RPC 2.0 and therefore over MCP, mapping payment challenges to JSON-RPC error code -32042 and carrying credentials and receipts in _meta under org.paymentauth keys, with tools/call, resources/read and prompts/get named as the covered MCP operations. That is the settlement layer reaching directly into the discovery layer, and it is the single most commerce-relevant thing in the MPP family; it is also an individual Internet-Draft of intended status Informational, expiring 4 April 2027, and it still cites MCP revision 2025-11-25, two revisions behind current. On 3 August 2026 the mppx SDK added support for relays, an optional external service that takes over payment validation and settlement for an integrating application; MPP neither requires relays nor standardizes their interface." }, { "id": "lcp", "name": "LCP", "fullName": "Legal Context Protocol", "layer": "legal-context", "maintainer": "Integra Ledger and the American Arbitration Association-International Centre for Dispute Resolution (AAA-ICDR), as Founding Maintainers", "license": "Apache-2.0", "status": "draft", "announced": "2026-06-24", "specUrl": "https://github.com/legal-context-protocol/legal-context-protocol", "atlasUrl": "https://agenticcommerceatlas.com/learn/lcp-explained", "summary": "Open standard for making the legal terms behind an agent transaction discoverable and provable: what was agreed, under which law, and with what path to recourse. A service publishes one JSON file at /.well-known/legal-context.json with a single required field, the URL of a standalone terms document, plus optional fields for a SHA-256 hash of those terms and for required signed acceptance. Four advisory levels of trust run from informational discovery through hash-provable terms and cryptographically signed acceptance to integration with dispute resolution and escrow. Launched 24 June 2026 with seventeen founding contributors named by the AAA: Google, IBM, Circle, Wayfair, Stellar Development Foundation, Ava Labs, UiPath, Cardano, Hedera, Crossmint, Pinata, Aptos Foundation, Baselayer, Trinsic, First Person Cooperative, Sei Labs, and Mysten Labs. Weigh the two largest names carefully: fifteen of the seventeen supplied an attributed statement to the launch release, and Google and IBM are the two that did not, with no first-party announcement from either, so their involvement rests on the AAA naming them. It is deliberately complementary rather than competitive: it addresses the recourse layer that ACP, UCP, AP2, MPP, x402, Visa TAP, and Mastercard Verifiable Intent all leave out. Early: the v1.0 specification is published as a draft for community review, adoption is unproven, and none of the protocols it proposes to bind has adopted it. Its own documentation splits integrations into those that work today through existing extension surfaces and those that would require upstream specification changes." } ] }