# Agentic Commerce Atlas: full reference > The neutral reference for agentic commerce: the protocols (ACP, AP2, UCP, MCP, A2A, x402, MPP), the players, the payments, and what it all means for merchants, builders, and decision-makers. Source: https://agenticcommerceatlas.com. Independent, vendor-neutral. You may quote this content with attribution to Agentic Commerce Atlas. Each section below is one page; the canonical URL and primary sources are included. --- # A2A Explained: The Agent-to-Agent Protocol URL: https://agenticcommerceatlas.com/learn/a2a-explained Markdown URL: https://agenticcommerceatlas.com/learn/a2a-explained.md Section: learn Updated: 2026-10-01 A2A, the **Agent-to-Agent protocol**, is an open standard for AI agents to communicate and delegate tasks to one another. It originated at Google and, since **17 August 2026**, is a hosted project of the **Agentic AI Foundation**, the Linux Foundation body that also holds MCP. In the context of agentic commerce it is best understood as a **coordination layer**: it is not a commerce protocol in itself, but the substrate that buyer and merchant agents use to talk, and that payment standards build on. ## Where it stands The mechanism is an **agent card**: a structured description of what an agent can do and how to reach it, which an agent publishes and other agents read to discover capabilities and delegate work without a human brokering the handoff. A2A reached **v1.0**, its first stable specification, on **12 March 2026**, adding multi-protocol bindings and version negotiation, enterprise multi-tenancy, signed agent cards for cryptographic identity verification, and a migration path for early adopters. (The `signatures` field on the AgentCard itself predates v1.0, landing in v0.3.0 in July 2025, so v1.0 stabilized it rather than introduced it.) The current specification release is the **v1.0.1** patch of **28 May 2026**, a set of spec bug fixes; the language SDKs carry higher version numbers of their own, which are not specification versions. At the protocol's one-year mark in April 2026 the Linux Foundation reported more than **150 supporting organizations**, up from around 50 a year earlier, including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow, with the protocol embedded in Azure AI Foundry, Copilot Studio, and Amazon Bedrock AgentCore. ## Who governs it, and why the August move matters A2A launched at Google in April 2025 and was donated to the **Linux Foundation** the same year. On **17 August 2026** it moved again, out of the Linux Foundation's broader portfolio and into the **Agentic AI Foundation (AAIF)** as a hosted project, alongside MCP, Block's goose, AGENTS.md, agentgateway, and Agent Router. Each project keeps its own maintainers, specification process, and release cadence. A2A's own announcement, published on 27 August 2026, describes the governance tier as a Growth Stage project at AAIF. The practical significance is narrow but real. The two protocols agentic commerce leans on most, **MCP for tool and data access** and **A2A for agent-to-agent coordination**, are now governed in the same place under the same neutral structure. That removes a category of vendor risk for anyone building multi-agent systems, and it is the clearest instance so far of the pattern the rest of 2026 has followed: standards moving out of their sponsors and into neutral bodies. What it does not do is change the specification, the maintainers, or anything a builder integrates against today. The Linux Foundation is explicit that A2A and [MCP](/learn/mcp-explained) are **complementary rather than competing**: A2A defines how agents communicate and coordinate across organizational boundaries, while MCP defines how an agent connects to tools and data sources. Now that both sit under AAIF, that division of labor is a governance position as well as a technical one. ## Its role in commerce A2A shows up underneath the payment layer rather than at the checkout. Two connections matter. First, [AP2](/learn/ap2-explained), the payment-authorization standard, is designed to be used as an **extension of A2A** (and of MCP), so the signed-mandate machinery can ride on top of agent-to-agent messaging. Second, an **A2A x402 extension** brings [x402](/learn/x402-explained)-style stablecoin payments to agent-to-agent interactions, built by Google with Coinbase, the Ethereum Foundation, and MetaMask. In both cases A2A handles how the agents coordinate, and the commerce or payment specifics live in an extension on top. ## How to hold it in your head Keep the layers separate: A2A is **how agents talk and delegate**, [MCP](/learn/mcp-explained) is **how an agent discovers tools**, and the commerce and payment protocols ([ACP](/learn/acp-explained), [UCP](/learn/ucp-explained), AP2, [x402](/learn/x402-explained), [MPP](/learn/mpp-explained)) run the actual transaction on top. A2A is the most behind-the-scenes of the agentic commerce acronyms, which is why it usually appears as a foundation other protocols extend rather than something a merchant integrates directly. For the full map, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **What is A2A?** An open standard for agents to communicate and delegate to one another, originated at Google, donated to the Linux Foundation in 2025, and a hosted project of the Agentic AI Foundation since 17 August 2026. Its first stable specification, v1.0, shipped on 12 March 2026, and the current release is the v1.0.1 patch of 28 May 2026; more than 150 organizations backed it as of April 2026. It is a coordination layer, not a commerce protocol. **Who governs A2A?** The Agentic AI Foundation, a Linux Foundation body, as of 17 August 2026. It sits there alongside MCP, goose, AGENTS.md, agentgateway, and Agent Router, which puts agent coordination and tool access under the same neutral governance. **What does it have to do with agentic commerce?** It is the substrate payment extensions build on: AP2 is designed to be used as an A2A extension (and as an MCP extension), and an A2A x402 extension adds stablecoin payments. A2A handles agent coordination; commerce rides on top. **Is A2A a payment protocol?** No. Payments ride on top of A2A through extensions like AP2 and the A2A x402 extension, rather than being part of A2A itself. Primary sources: - A2A Project: https://github.com/a2aproject/A2A - A2A joins AAIF's open agentic stack: https://aaif.io/blog/a2a-joins-aaif - Where A2A fits in the open agent ecosystem: https://aaif.io/blog/where-a2a-fits-in-the-open-agent-ecosystem - UCP checkout over A2A (specification): https://ucp.dev/latest/specification/shopping/checkout/a2a/ - A2A x402 extension (GitHub): https://github.com/google-agentic-commerce/a2a-x402 - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - A2A protocol surpasses 150 organizations in its first year: https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year - A2A protocol releases (v1.0.1): https://github.com/a2aproject/A2A/releases - Agentic AI Foundation welcomes 57 new members (247 total): https://aaif.io/news/agentic-ai-foundation-welcomes-57-new-members --- # ACP Explained: The Agentic Commerce Protocol URL: https://agenticcommerceatlas.com/learn/acp-explained Markdown URL: https://agenticcommerceatlas.com/learn/acp-explained.md Section: learn Updated: 2026-10-01 The Agentic Commerce Protocol (ACP) is an open standard for letting an AI agent complete a purchase with a merchant. Its purpose is narrow and practical: give agents and stores a shared language for checkout so a merchant builds one integration instead of a different one for every AI platform. ## Who is behind it ACP was launched on 29 September 2025 by **OpenAI and Stripe**, and it powered the original "buy it in ChatGPT" Instant Checkout experience. The project's README describes **OpenAI and Stripe** as the founding maintainers that jointly govern the project, while `MAINTAINERS.md` lists **OpenAI, Stripe, and Meta** as lead maintainers. Stripe's own ACP documentation now also describes the standard as created by Stripe, OpenAI, and Meta, which is the clearest first-party confirmation of Meta's role. **Meta** is also a member of the rival UCP Tech Council, so it remains tied to both commerce-layer efforts. ACP is licensed under **Apache 2.0**, requires a contributor license agreement, and is governed through a public proposal process, with a stated future path of "neutral foundation stewardship as ecosystem matures." ## What ACP actually does ACP standardizes the checkout conversation between a buyer's agent and a merchant. The specification covers agentic checkout (creating, updating, and completing a checkout session), cart and product feed, delegated payment, delegated authentication via OAuth 2.0, and orders and webhooks for confirmation, shipping, delivery, and refunds. Crucially, the merchant stays in control. They remain the merchant of record and keep the customer relationship, fulfillment, returns, tax, and support. ACP is the handshake at the checkout, not a takeover of the store. It is just as important to be clear about what ACP is **not**. It is not a tool-discovery protocol, that job belongs to MCP. It is not an agent-identity or attestation layer. And it is not a crypto-settlement protocol. ACP describes itself as compatible with both plain REST and MCP, and it deliberately leaves those adjacent layers to other standards. ## How payment flows This is the part most people get wrong, so it is worth being precise. When a buyer checks out, the payment service provider (Stripe in the reference implementation) issues a **Shared Payment Token**: a single-use credential scoped to one specific seller, under usage limits that carry a maximum chargeable amount, a currency, and an expiry. OpenAI's own description is that it "prepares a one-time delegated payment request and sets a maximum chargeable amount and expiry based on what the user has selected to buy," so in practice the ceiling is set to the cart the buyer approved rather than bound by the protocol to an exact total. The agent, for example ChatGPT, passes that token to the merchant through the ACP interface, and the merchant charges it through their own processor. Stripe's Shared Payment Token is the first Delegated Payment Spec-compatible implementation and is available in the US, Canada, and select European countries; OpenAI says more payment service providers are coming. The point of the design is that the agent never sees the buyer's actual card details, and the token cannot be reused for a different amount or a different merchant. Merchants already on Stripe can enable it with minimal code; merchants on other processors can adopt it through the Shared Payment Token API or the protocol's Delegated Payments specification.
  1. 1BuyerPay

    The buyer pays through the inline checkout.

  2. 2ProviderTokenize

    The payment provider issues a token, scoped to one merchant and one total.

  3. 3AgentHand off

    The agent passes the token on, never the card.

  4. 4MerchantCharge

    The merchant charges it; the token cannot be reused.

A single-use token moves instead of the card, locked to one merchant and one amount.
## What is actually live Here the gap between announcement and reality matters, and it is the single most misreported part of ACP's story. **Etsy** was genuinely live from day one for US buyers. **Walmart** announced a partnership with OpenAI on 14 October 2025 under which customers and Sam's Club members would "soon" be able to shop Walmart through ChatGPT using Instant Checkout. **PayPal** announced on 28 October 2025 that it would adopt ACP to bring its merchant network into ChatGPT, using the delegated payments API. Note that both were announcements of intent, not confirmations of a live integration. The widely repeated claim that "over a million Shopify merchants" went live is not accurate. Both OpenAI's and Stripe's launch announcements described those merchants as "coming soon," and only a small number of Shopify merchants actually integrated. What happened next is widely reported in a stronger form than OpenAI's own words support, so it is worth separating the two. In its own post of **24 March 2026**, OpenAI said that "the initial version of Instant Checkout did not offer the level of flexibility that we aspire to provide, so we're allowing merchants to use their own checkout experiences while we focus our efforts on product discovery," that merchants wanting deeper native experiences "continue to have the option to develop ChatGPT apps" (OpenAI now calls these **plugins**), and that it was "expanding the Agentic Commerce Protocol (ACP) to support product discovery." The flatter line widely quoted in trade press, that "Instant Checkout is moving to Apps," came from an OpenAI spokesperson rather than that post, and reads as more of a migration than OpenAI described. Two things follow. The center of gravity in ChatGPT did move from in-chat buying to discovery that hands the shopper to the merchant's own checkout. But **Instant Checkout was not retired**: OpenAI's current developer documentation states that "Instant Checkout in ChatGPT is currently available to approved partners," still documents a checkout experience "embedded in ChatGPT's UI," and carries an application form for merchants, with no published merchant or region list. The lesson is that adoption of a standard depends as much on the host surface promoting it as on the standard itself. The specification is officially in **beta**. ACP uses date-based versioning, and the latest stable version is **2026-04-17**. The released versions to date are `2025-09-29` (initial release), `2025-12-12` (fulfillment enhancements), `2026-01-16` (capability negotiation), `2026-01-30` (extensions, discounts, payment handlers), and `2026-04-17` (cart, feed, orders, authentication, and MCP), with current work staged in an `unreleased` directory. Note that ACP's own documentation site has not always kept pace with the repository, so the `spec/` directory on GitHub is the authoritative record of what is current. ## Where it sits in the wider landscape ACP is the checkout layer. Around it sit several other standards that mostly compose with it rather than replace it: [AP2](/learn/ap2-explained) handles payment authorization and trust, MCP handles discovery, and x402 handles machine-native stablecoin settlement. The one genuine rival at the commerce-semantics layer is Google's **Universal Commerce Protocol (UCP)**, launched in January 2026 with backers including Shopify, Etsy, Target, Wayfair, and Walmart, which aims at the broader shopping journey rather than checkout alone. In April 2026 its Tech Council doubled to ten members as Amazon, Meta, Microsoft, Salesforce, and Stripe joined, and on 28 April 2026 Stripe also joined UCP's Governing Council alongside permanent members Google and Shopify. So Stripe now co-maintains ACP and sits on both of UCP's governing bodies, and Meta is a lead maintainer of ACP and a member of the UCP Tech Council. That is a clear sign the standards are still settling and that the largest players are hedging rather than picking a side. For a side-by-side, see [ACP vs UCP](/learn/acp-vs-ucp); for the full map, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## What it means for you If you are a merchant, ACP is one of the two checkout-layer standards worth tracking, alongside UCP. Adopting it is what makes your products buyable from an agent surface that supports it; for a step-by-step integration, see [how to implement ACP](/learn/implement-acp). If you are a builder, treat ACP as the checkout handshake and pair it with a discovery layer and a payment-authorization layer rather than expecting it to do everything. And whatever you read about adoption numbers, check whether a partner is actually live or merely announced. ## FAQ **Who maintains ACP?** ACP's README describes OpenAI and Stripe as founding maintainers, while `MAINTAINERS.md` lists OpenAI, Stripe, and Meta as lead maintainers. Meta also sits on the rival UCP Tech Council. It is Apache 2.0 licensed. **Did a million Shopify merchants go live on ACP?** No. Both launch announcements described those merchants as "coming soon," not live. Only a handful integrated, and on 24 March 2026 OpenAI said it would let merchants use their own checkout experiences while it focused on product discovery, expanding ACP to cover discovery. Etsy was genuinely live from launch, and Instant Checkout itself remains available to approved partners. **How does payment work without sharing card details?** A Shared Payment Token, scoped to one merchant and one cart total, is issued and passed to the merchant. The agent never touches the raw card credentials. Primary sources: - OpenAI: Buy it in ChatGPT: https://openai.com/index/buy-it-in-chatgpt/ - Stripe and OpenAI launch Instant Checkout: https://stripe.com/newsroom/news/stripe-openai-instant-checkout - Agentic Commerce Protocol documentation: https://docs.stripe.com/agentic-commerce/acp - Agentic Commerce Protocol specification: https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - OpenAI and PayPal team up for Instant Checkout: https://newsroom.paypal-corp.com/2025-10-28-OpenAI-and-PayPal-Team-Up-to-Power-Instant-Checkout-and-Agentic-Commerce-in-ChatGPT - OpenAI retreats on Instant Checkout: https://www.modernretail.co/technology/shopify-says-purchases-are-coming-inside-chatgpt-through-agentic-storefronts-as-openai-retreats-on-instant-checkout/ - Amazon, Meta, Microsoft, Salesforce, and Stripe join the UCP Tech Council: https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council - ACP MAINTAINERS.md (lead maintainers): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md - Walmart partners with OpenAI to create AI-first shopping experiences: https://corporate.walmart.com/news/2025/10/14/walmart-partners-with-openai-to-create-ai-first-shopping-experiences - UCP announcements (Tech Council and Governing Council): https://ucp.dev/documentation/announcements/ - Agentic Commerce key concepts (Instant Checkout availability, Delegated Payment Spec): https://developers.openai.com/commerce/guides/key-concepts - Shared payment tokens: https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ --- # ACP vs UCP: Comparing the Two Agentic Commerce Checkout Standards URL: https://agenticcommerceatlas.com/learn/acp-vs-ucp Markdown URL: https://agenticcommerceatlas.com/learn/acp-vs-ucp.md Section: learn Updated: 2026-10-01 ACP and UCP are the two open standards for letting an AI agent complete a purchase. They are often cast as rivals, and at the checkout step they do overlap, but they are not the same shape. The **Agentic Commerce Protocol (ACP)** is the narrower one: an OpenAI and Stripe standard for the agent-to-merchant checkout handshake, live on ChatGPT surfaces. The **Universal Commerce Protocol (UCP)** is Google's broader standard for the whole shopping journey, from discovery through checkout to post-purchase, live in Google Search's AI Mode and the Gemini app. Both are licensed Apache 2.0, and several large companies back both, so for many merchants the real question is not which to pick but whether to support both. ## At a glance | | ACP | UCP | |---|---|---| | Full name | Agentic Commerce Protocol | Universal Commerce Protocol | | Led by | OpenAI and Stripe founding governance; OpenAI, Stripe, and Meta listed as lead maintainers | Google, with a Governing Council (Google, Shopify, Stripe) over per-domain Tech Councils: Shopping (16 seats, 10 companies), Food (seated July 2026), Lodging (seated August 2026), and Payments (seated September 2026) | | Launched | September 2025 | January 2026 | | Current revision | `2026-04-17`, status beta | `v2026-08-25` | | Scope | The agent-to-merchant checkout, and since March 2026 product discovery too | The whole shopping journey, and now beyond retail into lodging (first draft capability merged 25 September 2026) and food | | Primary surface | ChatGPT | Google Search (AI Mode), Gemini | | Payment | Shared Payment Token | Open payment-handler model; pairs with AP2; Google Pay in Google's implementation | | License | Apache 2.0 | Apache 2.0 | | What is live | Etsy from launch; in-chat checkout de-emphasized in March 2026 in favor of discovery, and Instant Checkout still open to approved partners | Checkout in AI Mode and Gemini for eligible US retailers; Universal Cart checkout and Canada, Australia and UK expansion announced May 2026 | ## What each one is ACP standardizes the conversation at checkout between a buyer's agent and a merchant: creating, updating, and completing a checkout session, passing a payment token, and confirming the order. Its purpose is narrow and practical, so a merchant builds one integration instead of a different one for every agent surface. For the detail, see [ACP explained](/learn/acp-explained). UCP is wider by design. Where ACP begins at checkout, UCP aims to standardize the entire shopping journey: catalog search, cart building, checkout, identity linking, the order lifecycle, and a payment-token exchange. It treats payment as one composable piece rather than something baked in. For the detail, see [UCP explained](/learn/ucp-explained). ## Scope: a narrow handshake versus the whole journey This is the central difference. ACP is a checkout handshake; UCP is a journey. If you only need agents to be able to buy from you, ACP does that one job well. If you want agents to discover, compare, buy, and handle post-purchase through a single standard, that is the broader ground UCP is trying to occupy. The two meet, and compete, precisely at the checkout step, which is why they are described as rivals even though most of UCP's surface area has no ACP equivalent. ## Who is behind each ACP was launched by **OpenAI and Stripe** in September 2025. Its README describes OpenAI and Stripe as founding maintainers, while `MAINTAINERS.md` lists **OpenAI, Stripe, and Meta** as lead maintainers. **Meta** also sits on the rival UCP Tech Council, so it backs both. ACP is governed with a stated path toward broader, more neutral stewardship. UCP is **Google-led**, launched in January 2026, and governed in two layers. Per-domain **Tech Councils** steward the specification. The **Shopping Tech Council** went to sixteen seats on 24 April 2026 when Amazon, Meta, Microsoft, Salesforce, and Stripe joined the founding group of Google, Shopify, Etsy, Target, and Wayfair; all sixteen are filled, across those ten companies. A **Food Tech Council** followed on 16 July 2026 with Block (Square), DoorDash, Google, Toast, and Uber Eats, and a **Lodging Tech Council** on 11 August 2026 with Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com. A fourth, the **Payments Tech Council**, was seated on 2 September 2026 with Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe; unlike the other three it governs a capability rather than a retail vertical, matching the payment layer that `v2026-08-25` lifted out from under shopping. Above them sits a **Governing Council**: Google and Shopify, joined by Stripe on 28 April 2026, with two further seats still open for election. Google holds four of the sixteen Shopping seats and six of the ten filled Food seats, so the largest single voice inside UCP governance is still Google's. The detail worth noting is the overlap, and it has deepened. **Stripe** is a founding maintainer of ACP and now sits on both UCP councils, and it documents integrations for both protocols. **Meta** is a lead maintainer of ACP and a member of the UCP Tech Council. That is a clear signal that the field is still settling and that the big players are hedging rather than picking a winner. The full picture is in [the landscape](/landscape/agentic-commerce-landscape). ## What is actually live Adoption is where the two diverge most, and a neutral reference should be plain about it. On the ACP side, Etsy was live from launch for US buyers, but only a small number of merchants integrated, and on 24 March 2026 OpenAI said the first version of Instant Checkout had not offered the flexibility it wanted, so it would let merchants use their own checkout experiences while it focused on product discovery, expanding ACP to cover discovery too. That is a repositioning toward discovery that hands shoppers to the merchant's own checkout rather than a shutdown: OpenAI's developer documentation still describes Instant Checkout as available to approved partners. On the UCP side, Google's protocol powers checkout inside AI Mode in Search and the Gemini app for eligible US retailers, paying through Google Pay. At Google Marketing Live on 20 May 2026 Google said its Universal Cart checkout would reach retailers including Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair, and Shopify merchants "soon," and that UCP-powered checkout would roll out in Canada and Australia in the coming months and later the UK. Read that carefully: much of the UCP news is announced rather than shipped, and this part has slipped, with Google saying on 16 September 2026 that Australia and Canada will "follow early next year." Both standards are real, but they are live on different surfaces reaching different audiences, which matters more for planning than any feature comparison. ## How payment works in each ACP carries its own payment mechanism. At checkout, the payment provider issues a **Shared Payment Token**, a single-use credential scoped to one specific merchant and one specific cart total, which the agent passes to the merchant to charge. The agent never sees the raw card, and the token cannot be reused. UCP leans on the rest of the stack rather than bundling payment. It defines an open payment-handler model, pairs with [AP2](/learn/ap2-explained) for payment authorization (the signed mandate that proves the user approved the purchase), and, in Google's own implementation, settles through Google Pay, with PayPal named at launch as a coming option and Affirm and Klarna buy-now-pay-later options announced for Google Pay in May 2026. So ACP packages the token; UCP composes with separate authorization and payment layers. For the mechanics underneath both, see [how AI agents pay](/learn/how-ai-agents-pay). ## Do they compete or compose? Both. They compete at the commerce-and-checkout layer, which is the one genuine rivalry in the agentic commerce stack. But they also compose with everything around them, and to a degree with each other: a merchant can implement both, and the platforms many merchants sell through are moving to syndicate to multiple agent surfaces at once. Stripe now documents integrations for both protocols side by side, which is the clearest practical sign that this is not yet a winner-take-all contest. For where both sit among the other standards, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## Which should a merchant support? The honest answer is to follow your customers, not the standards. If ChatGPT is a meaningful surface for your audience, ACP is what makes your products buyable there. If Google Search and Gemini are where your customers are, UCP does the same for those surfaces. Because the two reach different audiences, and because supporting both is increasingly a platform feature rather than two separate builds, many merchants should plan for both and weigh the economics of each surface (including any per-sale fees) rather than betting on a single winner. The wider decision of whether and how fast to move is worked through in [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business). ## FAQ **What is the difference between ACP and UCP?** ACP is the narrower OpenAI and Stripe standard for the agent-to-merchant checkout, live on ChatGPT. UCP is Google's broader standard for the whole shopping journey, live in Google Search's AI Mode and Gemini. They overlap, and compete, at the checkout step. **Are they rivals?** At the checkout layer, yes, the one genuine rivalry in the stack. But both are Apache 2.0, several companies back both, and a merchant can implement both, so it is two overlapping standards still settling rather than a winner-take-all fight. **Should a merchant support ACP or UCP?** Follow your customers. ChatGPT audience points to ACP; Google Search and Gemini audience points to UCP. Many merchants should plan to support both. **How does payment differ?** ACP carries its own Shared Payment Token, scoped to one merchant and one total. UCP pairs with AP2 for authorization and settles through Google Pay in Google's implementation. Primary sources: - Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - New agentic commerce tools and a protocol for retailers and platforms: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Amazon, Meta, Microsoft, Salesforce, and Stripe Join the Universal Commerce Protocol Tech Council: https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council - UCP announcements (releases, Tech Council, Governing Council): https://ucp.dev/documentation/announcements/ - UCP protocol release v2026-08-25: https://github.com/Universal-Commerce-Protocol/ucp/releases/tag/v2026-08-25 - Universal Commerce Protocol official site: https://ucp.dev/ - New UCP features and AI tools (Google Marketing Live 2026): https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - Stripe: agentic commerce (UCP and ACP): https://docs.stripe.com/agentic-commerce - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ --- # Agentic Commerce by Business Type: Playbooks for Retailers, Brands, Marketplaces, and Services URL: https://agenticcommerceatlas.com/learn/agentic-commerce-by-business-type Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-by-business-type.md Section: learn Updated: 2026-10-01 Agentic commerce changes the job differently depending on where you sit. A retailer, a brand, a marketplace, and a services business face the same shift but a different version of it, with different leverage and different risks. This page is the deeper companion to the short "first steps by business type" summary in [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business): where that gives the headline, this gives the playbook, for each type the distinct opportunity, the specific risk, the concrete first moves, what to measure, and which protocols and surfaces matter most. One thing is common to all four, so it is worth stating once. Every type needs clean, structured, accurate data that matches its live systems; an API-driven way to transact, because agents cannot see information rendered only as page elements; and a deliberate choice to keep the customer relationship rather than cede it to the agent surface. The differences below are in emphasis. ## If you are a retailer Your leverage is breadth of catalog and the buying moment. When a shopper asks an agent to find and buy something, you want your products in the consideration set and buyable on the spot. The opportunity is reach: being present and transactable wherever shoppers delegate buying. That means getting your full catalog into a complete, structured feed and onto the live surfaces your customers use, and, where you sell through a platform that syndicates to agent surfaces, switching that on and verifying what actually appears. Because the two checkout standards overlap, being reachable through both [ACP](/learn/acp-explained) and Google's [UCP](/learn/ucp-explained) widens the set of surfaces you can be bought from. For most retailers that means asking a platform or commerce provider to carry the integration, not commissioning two builds; Google has said partners including Commerce Inc, Salesforce, and Stripe will implement UCP on their platforms. Check what is live before you plan around it. A large share of the agentic checkout news of the past year is an announcement of intent rather than a shipped consumer channel, and the shape of the surfaces has already moved once: OpenAI said on 24 March 2026 that it would let merchants use their own checkout experiences while it focused on product discovery, with ACP expanded to serve as the infrastructure connecting users to merchants across discovery rather than as a single in-chat buy button. Instant Checkout itself is still open to approved partners, so read this as a change of emphasis rather than a withdrawal. The specific risk is margin and commoditization. Some agent surfaces charge a fee on each completed sale, which OpenAI stated plainly when it launched Instant Checkout: merchants pay a small fee on completed purchases, while shoppers pay nothing extra and the fee does not affect ChatGPT's product results. Model the unit economics before you scale rather than after, and watch for being pushed into price-only competition when an agent lines you up against substitutes. The concrete first moves are a feed audit for completeness and exact agreement with your live store, one real pilot on a live surface, and an economic model that includes any per-sale fees. What to measure: how often your products appear in agent answers, agent-referred traffic and its conversion, and the margin on agent-channel sales. For the integration detail, see [how to implement ACP](/learn/implement-acp); for the fuller retailer playbook, see [agentic commerce for retailers](/learn/agentic-commerce-for-retailers). ## If you are a brand or manufacturer Your leverage is authority over your own product information, and your central risk is commoditization. When an agent compares options, the brand with the richest, most accurate, most structured data tends to be surfaced and described well, and the one with thin data is either invisible or summarized by someone else. The opportunity is to be the canonical source of truth for your products' attributes, so that however a shopper reaches you, through your own channel or a retail partner, the agent represents you accurately. The specific risk is twofold: losing the discovery moment to a retailer or platform that sits between you and the buyer, and channel conflict between your direct sales and your partners' once an agent exposes both side by side. The concrete first moves are to invest in complete, structured, canonical product data; to decide deliberately where you want to be bought and to make that strategy explicit; and to ensure your direct channel is itself agent-ready so it is a real option in the comparison. What to measure: the accuracy and completeness of how agents describe and attribute your products, and your share of the agent-surfaced consideration set in your category. ## If you are a marketplace or platform You are both a participant and a piece of infrastructure, which makes your decisions larger. Your sellers will ask how to become agent-ready, and your buyers will increasingly arrive through agents. The opportunity is leverage: you can make many sellers transactable through one integration rather than each seller doing it alone, which is precisely what the protocols were designed for, one integration rather than a different one per AI platform. The strategic choice is whether to expose your own catalog and checkout to external agents, to build agent-facing capability on behalf of your sellers, or both, and whether to run your own [MCP](/learn/mcp-explained) server so agents can discover and use your platform's tools and data directly. The specific risk is disintermediation of the platform itself: if agents transact with your sellers without routing value through you, your position erodes, so your agent strategy has to protect the role you play, not just enable transactions. The concrete first moves are to decide expose-versus-implement, to give sellers a clear path to agent-readiness, and to evaluate an MCP server as a way to make your platform programmable. If you build one, note that MCP published a stateless `2026-07-28` revision as final on 28 July 2026, removing the initialize handshake and the session header and requiring header-based routing, so build to that rather than to an older session-based design. What to measure: seller adoption of agent channels, agent-driven volume across the platform, and whether value continues to route through you. For the build pattern, see [how to build a remote MCP server](/learn/build-a-remote-mcp-server). ## If you are a services business Services split into two cases, and they use different parts of the stack. If you sell digital services, APIs, compute, or data, the relevant layer is machine-to-machine settlement. [MPP](/learn/mpp-explained) and x402 let an agent pay for a service programmatically, per call or on a recurring basis, without a human creating an account and entering a card. The opportunity is a genuinely new channel: agents as paying customers for things that previously required a human to subscribe. The concrete first moves are to make your service programmatically purchasable, to choose a settlement approach (MPP and x402 are the two machine-native options, and providers such as Stripe support both), and to price for per-call or subscription consumption. What to measure: agent-initiated usage and revenue, and the conversion from programmatic trial to paid. If you sell human services, bookings, appointments, travel, or similar, the logic is closer to retail. An agent can only recommend and transact what it can read, so structured, accurate, machine-readable availability and pricing is the foundation, and an API-driven booking path is what lets the transaction complete. Surfaces that already do travel and local commerce through agents are where to watch first. The specific risk is the same disintermediation and commoditization pressure retailers face, with availability and price reduced to a comparison. The concrete first moves are to expose structured availability and pricing, to make booking API-driven, and to protect the direct relationship with guests or clients. What to measure: agent-initiated bookings and their value, and how accurately agents represent your availability. ## How to use this Pick your type, but read the others, because most real businesses are a blend: a brand that also sells direct is part brand and part retailer, and a marketplace is part platform and part participant. Wherever you sit, the common foundation comes first, clean data and an API-driven path to transact, and the role-specific emphasis tells you where to spend next. For the overall decision of whether and how fast to move, return to [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business); for what to watch out for, see [agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness); and for how the money and trust work underneath all of this, see [how AI agents pay](/learn/how-ai-agents-pay). ## FAQ **How does it differ for a brand versus a retailer?** A retailer competes on catalog breadth and the buying moment, so its priority is an accurate feed on agent surfaces and the per-sale economics. A brand competes on authority over its product information and faces commoditization, so its priority is being the canonical source of its attributes and deciding where it wants to be bought. **What should a marketplace do differently?** Decide whether to expose its own catalog and checkout to agents, build agent-facing capability for sellers, or both, and protect the platform's role against disintermediation. It can integrate once on its sellers' behalf, and may run its own MCP server. **Does it matter for a services business?** Yes. Digital and API services can be sold to agents programmatically through the settlement layer (MPP and x402). Human services follow retail logic: structured availability and pricing plus API-driven booking. **What is common to every type?** Clean structured data that matches your live systems, an API-driven path to transact, and a deliberate choice to keep the customer relationship. The differences are emphasis and which protocols and surfaces matter most. Primary sources: - The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants - New tech and tools for retailers to succeed in an agentic shopping era: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ - OpenAI shifts checkout plans in its agentic commerce strategy: https://www.digitalcommerce360.com/2026/03/06/openai-shifts-checkout-plans-agentic-commerce-strategy/ --- # Agentic Commerce Examples: How AI Agents Shop, Decide, And Pay URL: https://agenticcommerceatlas.com/learn/agentic-commerce-examples Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-examples.md Section: learn Updated: 2026-10-01 Agentic commerce is easiest to understand through examples: an AI agent finds products, compares options, chooses within a user's constraints, creates or updates a cart, and completes checkout or payment with authorization. The important shift is action. A product recommender suggests; an agentic commerce flow can actually buy. ## Short answer A typical agentic commerce example is: "Find me trail running shoes under 150 dollars that fit wide feet, can arrive by Friday, and use my saved payment method if I approve." The agent searches, compares, filters, asks for any missing approval, and completes the purchase through a supported checkout and payment flow. ## Live, announced, and hypothetical Keep three categories separate. | Status | What it means | Example type | |---|---|---| | Live | A real user can complete at least part of the flow today | UCP-powered checkout on Google surfaces for select merchants; Instant Checkout with US Etsy sellers in ChatGPT | | Announced or pilot | A provider has announced partners, pilots, or a rollout path | Google's Universal Cart; network agent-payment programs | | Hypothetical but plausible | The flow is technically consistent but not documented as live | Multi-agent procurement across several suppliers | This distinction matters because agentic commerce is moving faster in press releases than in routine production transactions. It also moves backwards sometimes, which is why the section on announced-but-not-shipped capabilities below is part of the picture rather than a footnote. ## Example 1: Retail product discovery and checkout A shopper asks an assistant for "a dishwasher-safe travel mug under 35 dollars that fits a car cup holder." The agent compares products, filters by price and attributes, checks availability and shipping, then presents a short list. If the shopper approves one, the agent creates a checkout session and completes the order through a supported checkout protocol such as [ACP](/learn/acp-explained) or a platform-specific flow. What has to work: - structured product data with price, availability, shipping, and attributes; - a checkout path the agent can call; - scoped payment authorization; - an order record and return policy. This is the consumer example most people mean when they say "AI shopping agent." ## Example 2: Replenishment with constraints A household agent notices that a buyer is likely to run out of coffee filters. It can reorder the same item, or choose an equivalent if the usual one is out of stock, but only under a pre-set price and from approved merchants. This is where authorization matters: the agent should not have open-ended permission to spend. It needs constraints such as merchant, category, amount, recurrence, and expiry. This is the kind of flow [AP2](/learn/ap2-explained) is designed to make defensible, because a merchant or issuer needs proof of what the user delegated. ## Example 3: Travel planning with partial autonomy A travel agent can compare flights, hotels, and activities against a budget and preference set. It may reserve an itinerary, ask for approval on the final payment, and then complete booking. The commercial value is not just checkout; it is orchestration across multiple suppliers and constraints. This flow is harder than simple retail because inventory changes quickly, policies are complex, and cancellation terms matter. It requires stronger evidence of what the user saw and approved. ## Example 4: B2B procurement A procurement agent receives a request: "Buy 20 replacement laptop chargers compatible with this model, under the approved supplier policy, delivered by next week." The agent searches approved vendors, checks price and stock, validates policy constraints, creates a cart, and routes the purchase for approval. This is not just a consumer shopping problem. In B2B, agentic commerce is often about policy, approval, and auditability. The buyer may care less about a slick chat surface and more about evidence, exportable records, and vendor terms. ## Example 5: Local services and appointments A user asks an agent to book a car service, dental appointment, or home repair window. The agent checks availability, matches constraints, reserves a slot, and may pay a deposit. This is commerce even when the "product" is time. The readiness work is different: inventory is appointment availability, checkout may be a booking API, and cancellation rules become part of the transaction. ## Example 6: Software paying software Not all agentic commerce is retail checkout. An AI agent may need to pay for an API call, a data file, compute, or another software service. Protocols such as [x402](/learn/x402-explained) and [MPP](/learn/mpp-explained) target this machine-to-machine lane, where software requests a resource, receives a payment requirement, pays, and gets access. This lane is now getting network-level attention as well. On 10 June 2026 Mastercard introduced Agent Pay for Machines, a service for high-frequency, low-value payments executed between agents and machines, with credentialing, programmatic spending limits, and settlement across cards, accounts, and stablecoins. It launched with more than 30 named participants and supporters including Adyen, Cloudflare, Coinbase, Global Payments, Stripe, and Tempo. This is closer to internet infrastructure than shopping, but it belongs in the same map because the buyer is still software acting within rules. ## What has been announced but not shipped An examples page is only useful if it separates capability from intent. These are worth knowing precisely because they are commonly cited as though they were live. **In-chat checkout in ChatGPT has narrowed, not widened.** Instant Checkout launched in September 2025 with US Etsy sellers live and "over a million Shopify merchants" described as coming soon. On 24 March 2026 OpenAI said the first version had not offered the flexibility it wanted, so it would let merchants use their own checkout experiences while it focused on product discovery, and expanded the Agentic Commerce Protocol to cover discovery. The pattern shifted toward discovery in the assistant and checkout on the merchant's own site. It narrowed rather than closed: OpenAI's developer documentation still describes Instant Checkout as currently available to approved partners, with no published merchant or region list. What filled the gap the same day was Shopify's Agentic Storefronts, which made millions of Shopify merchants discoverable in ChatGPT by default; the shopper finds the product in ChatGPT and completes the purchase on the merchant's own checkout in an in-app browser, with the merchant as merchant of record. That discovery-in-the-assistant, checkout-at-the-merchant pattern is now the most widely available form of agentic shopping in ChatGPT. **Walmart's October 2025 announcement with OpenAI was an announcement of intent.** It was widely reported as buying inside ChatGPT, and it should be read alongside the March 2026 repositioning rather than as a shipped, broad consumer capability. **Google's Universal Cart is announced, not general.** At Google Marketing Live on 20 May 2026 Google said shoppers would be able to try select cross-retailer checkout features "soon" with brands including Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair, and Shopify merchants, and that UCP-powered checkout would roll out to Canada and Australia in the coming months and later the UK. Google's merchant documentation still describes the UCP checkout feature as available for select merchants through an early-access process. **American Express has published part of its agent stack.** Amex states that the account enablement, intent intelligence, and payment credentials specifications in its Agentic Commerce Experiences developer kit were available as of 14 April 2026, while agent registration and cart context specifications are still under development, and that its Agent Purchase Protection is a future commitment rather than a live benefit. None of this makes the category less real. It does mean a merchant should ask any vendor which specific surface, which merchants, and which country a claimed capability applies to today. ## What the examples have in common Every good agentic commerce example has the same five layers: 1. **Intent.** The user gives a goal and constraints. 2. **Discovery.** The agent finds products, services, or tools. 3. **Decision.** The agent compares options against the constraints. 4. **Authorization.** The user or a prior mandate permits action. 5. **Transaction.** Checkout or payment completes, and an order or access record is created. The protocols divide those jobs. [MCP](/learn/mcp-explained) helps agents discover tools and data. ACP and [UCP](/learn/ucp-explained) help structure commerce and checkout. AP2 helps prove authorization. x402 and MPP support machine-native payments. ## What this means for merchants The best examples are not magic. They depend on boring readiness work: product data, API checkout, payment terms, evidence, and governance. Before chasing a branded AI-shopping launch, use the [agentic commerce readiness checklist](/learn/agentic-commerce-readiness-checklist) and the [RFP questions](/learn/agentic-commerce-rfp-questions) to check whether your business can support the flow end to end. ## FAQ **What is a simple example of agentic commerce?** A shopper asks an AI assistant to find a product under a budget, compare options, choose one that matches constraints, and complete checkout with approval. **Are examples live today?** Some are live, some are pilots, and some are plausible future flows. The clearest live examples are Shopify's Agentic Storefronts, which make millions of merchants discoverable in ChatGPT, Copilot, and Google's AI surfaces with checkout on the merchant's own site; Google's UCP-powered checkout, gated by application; and Instant Checkout in ChatGPT, de-emphasized in March 2026 but still open to approved partners. Network agent-payment programs are earlier-stage; x402 and MPP are live infrastructure for software payments. **How is this different from a chatbot recommending products?** A recommender suggests. An agentic commerce flow can act: create a cart, carry authorization, and trigger checkout or payment. **Which businesses should look first?** Businesses with structured product data, repeatable buying journeys, clear pricing and inventory, and API-accessible checkout are best positioned. Primary sources: - Stripe and OpenAI launch Instant Checkout: https://stripe.com/newsroom/news/stripe-openai-instant-checkout - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - Visa Intelligent Commerce launch: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - About the Universal Commerce Protocol (UCP) and UCP-powered checkout feature on Google: https://support.google.com/merchants/answer/16837055 - How we're helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google: https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - Agentic Commerce Experiences (ACE) developer kit: https://www.americanexpress.com/en-us/company/agentic-commerce/ - Mastercard launches Agent Pay for Machines to unlock super-fast, always-on payments: https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ --- # Agentic Commerce For Retailers: A Practical Readiness Playbook URL: https://agenticcommerceatlas.com/learn/agentic-commerce-for-retailers Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-for-retailers.md Section: learn Updated: 2026-10-01 For retailers, agentic commerce readiness means your products can be found, compared, added to cart, paid for, fulfilled, returned, and measured when the buyer is an AI agent. The foundation is not a chatbot. It is complete product data, current inventory, API-reachable checkout, scoped payment authorization, and clear economics for the agent channel. ## Short answer A retailer should treat agentic commerce as a new buying surface, not a side experiment. Start with catalog quality and live-store parity, then verify which agent surfaces reach your customers, make checkout callable through ACP, UCP, or platform APIs, add authorization and evidence records, and measure margin after fees, returns, and disputes. ## Retailer readiness map | Layer | Retailer question | Practical first move | |---|---|---| | Product data | Can an agent understand every product and variant? | Audit feed completeness and live-store parity | | Discoverability | Which agents and shopping surfaces can see us? | Check platform syndication and agent-visible listings | | Checkout | Can software build and complete a cart? | Map ACP, UCP, platform, and existing checkout paths | | Payment | Can authorization be scoped and defended? | Define token, mandate, receipt, and dispute evidence requirements | | Operations | Can fulfillment, returns, and exceptions survive automation? | Expose policy and order-state data clearly | | Economics | Does the channel make money after fees and returns? | Model margin by agent surface and product category | | Measurement | Can we see agent behavior separately? | Track impressions, carts, orders, exceptions, and disputes | ## Why retailers are exposed first Retailers sit closest to the buying moment. When a shopper delegates a purchase, the agent needs product options, prices, stock, shipping promises, policies, and a way to complete the order. That makes retailers early beneficiaries, but also early test subjects. If the data is strong and checkout is callable, agents can bring new demand. If the data is thin or stale, agents may skip the retailer or create operational failures. The practical risk is not only technical failure. It is commoditization. If an agent reduces a category to "cheapest in-stock option arriving by Friday," the retailer competes on price, fulfillment, and data quality. That is why agentic commerce for retailers is as much a merchandising and margin question as a protocol question. ## Step 1: Make the catalog agent-ready Retailers should begin with product data because every downstream step depends on it. A clean checkout integration cannot save a catalog an agent cannot understand. At minimum: - product IDs, titles, descriptions, prices, currencies, availability, images, brands, categories, and variants are complete; - GTINs, MPNs, SKUs, merchant IDs, and other identifiers are consistently populated where relevant; - price, promotion, tax-relevant information, and availability match the live store; - shipping, delivery windows, return rules, warranty details, and restrictions are machine-readable where possible; - feed drift is monitored and treated as an operational issue. For the detailed catalog checklist, see [product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce). ## Step 2: Decide which surfaces matter Retailers should not start by asking "which protocol will win?" They should ask where customers will delegate buying. For some categories that may be Google Search and Gemini. For others it may be ChatGPT, a platform marketplace, a commerce provider, or a vertical assistant. The surface decides the integration path. [UCP](/learn/ucp-explained) matters for Google-led shopping surfaces. [ACP](/learn/acp-explained) matters for agent surfaces that support the Agentic Commerce Protocol. Platform integrations may abstract both. The retailer's job is to verify what is actually live for its category and geography, then avoid building twice where a platform already syndicates once. Two market facts are worth holding while you make that call, because both cut against planning around a single consumer channel. First, the shape of the ChatGPT channel changed. In March 2026 an OpenAI spokesperson told Digital Commerce 360 that "Instant Checkout is moving to Apps, where purchases can happen more seamlessly," with the company "prioritizing making ChatGPT search and product discovery great, with ACP serving as the infrastructure that connects users to merchants across the full shopping journey." Read ACP as plumbing that can front several surfaces, including retailer apps inside ChatGPT, rather than as one in-chat buy button you integrate with once. Second, a good deal of UCP news is announced rather than shipped. Google's January 2026 launch post said UCP "will soon power" checkout on eligible listings in AI Mode and the Gemini app for eligible U.S. retailers, and its March 2026 update described simplified Merchant Center onboarding as "rolling out over the coming months" with Commerce Inc, Salesforce, and Stripe implementing UCP "in the near future." That is a real direction of travel, but it is not the same as a live channel in your market. Ask your platform what is switched on for you today. ## Step 3: Make checkout callable Agentic commerce checkout needs structured state. An agent has to know whether a cart is valid, what shipping choices exist, what tax and total apply, whether a promotion is eligible, and whether a restriction blocks the order. For ACP, this is an agentic checkout API. For UCP and platform routes, the exact interface differs, but the requirement is the same: software must be able to create or update a cart and receive a reliable, current answer. Avoid relying on page scraping or hidden storefront logic that only a browser can interpret. Useful internal links: - [how to implement ACP](/learn/implement-acp); - [MCP for ecommerce](/learn/mcp-for-ecommerce); - [agentic commerce RFP questions](/learn/agentic-commerce-rfp-questions). ## Step 4: Treat payment authorization as evidence Retailers need a record of what the user authorized and what the agent did. That can involve a Shared Payment Token, an AP2 mandate, a network token, a passkey-backed approval, or a processor-specific artifact. The names differ, but the retailer requirement is consistent: the payment credential must be scoped, and the evidence record must be strong enough for customer support, fraud review, and disputes. Keep the receipts, not just the authorizations. Under AP2 v0.2, the merchant returns a Checkout Receipt once it accepts or rejects a Checkout Mandate, and the payment processor returns a Payment Receipt for the Payment Mandate. The specification's dispute rules require both pairs, with the hashes that bind them independently recomputed, before the contents can be used as evidence. A retailer that logs only what the user authorized has half the file. Also be clear about what that evidence does and does not buy you. AP2 does not allocate liability. Its executive summary describes its objective as providing supporting evidence that helps payment networks establish accountability and liability principles, and the specification puts dispute resolution, retention, and retrieval out of scope. Good evidence improves your position under whatever rules apply; it does not create the rule. Do not treat this as only a payments-team problem. The evidence touches checkout, pricing, fulfillment, legal, and customer service. For the non-technical version, read [AI shopping agent authorization](/learn/ai-shopping-agent-payment-authorization). ## Step 5: Model the channel economics Agentic commerce can bring incremental demand, but retailers should model it like a channel with costs and incentives. The relevant economics include payment fees, platform fees, referral or ad costs, return rates, support costs, and whether agents push the category toward price-only competition. Segment the model by category. High-margin differentiated products can tolerate more channel cost than commodity products. Fast-moving inventory with frequent price changes needs stricter data controls than a stable catalog. Products with high return rates need clearer policy and fit data before agents start recommending them. ## Step 6: Prepare operations and support Retail operations need to know what to do when an agent-created order goes wrong. Common cases include stale inventory, unavailable shipping, the wrong variant, misunderstood user intent, customer regret, and "I did not authorize that" disputes. Prepare: - clear customer-service scripts for agent-assisted orders; - order records that identify agent surface and authorization method; - return, cancellation, and substitution rules an agent can read; - escalation paths when a checkout requires human confirmation; - reporting that separates agent orders from normal web orders. ## Step 7: Measure before scaling At pilot scale, the question is not only "did orders happen?" It is whether the retailer was represented accurately and whether the channel produces profitable demand. Track: - product inclusion in agent answers; - agent-referred sessions and product views; - cart creation and checkout attempts; - completed orders and order value; - failed checkout reasons; - gross margin after channel costs; - returns, refunds, disputes, and support tickets; - how accurately agents describe product attributes and policies. ## What not to do Do not launch agentic checkout before product data is reliable. Do not accept broad vendor claims without live-use-case proof, and treat an announcement as an announcement until someone shows you it working in your market. Do not assume liability terms are settled, and do not read a protocol's support for signed mandates as a liability answer, because none of the protocols allocates liability. Do not measure only traffic and orders while ignoring returns, disputes, and margin. And do not let an agent surface become the only place your product information is represented well. The next step is the [agentic commerce readiness checklist](/learn/agentic-commerce-readiness-checklist). Once that is mostly green, use the [RFP question guide](/learn/agentic-commerce-rfp-questions) before choosing a platform, processor, or agent-commerce vendor. ## FAQ **What should retailers do first for agentic commerce?** Start with product data: complete structured feeds, exact live-store parity, shipping and return information, and drift monitoring. **Should retailers prioritize ACP or UCP?** Follow the customer surface rather than pick a winner. ACP matters for surfaces using the Agentic Commerce Protocol, which OpenAI has said now serves as the infrastructure connecting ChatGPT users to merchants after it de-emphasized in-chat checkout in March 2026, though Instant Checkout remains open to approved partners; UCP matters for Google Search, Gemini, and Google-led shopping surfaces. Many retailers should plan for both, and for most the practical route is a platform or provider integration rather than two custom builds. **What is the biggest risk for retailers?** Being reduced to a price and availability row in an agent comparison. Rich product data, policy clarity, fulfillment reliability, and margin discipline are the defenses. **How should retailers measure it?** Measure agent answer inclusion, agent referrals, carts, checkout attempts, orders, average order value, margin after fees, returns, disputes, and representation accuracy. Primary sources: - New tech and tools for retailers to succeed in an agentic shopping era: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - AI shopping gets simpler with Universal Commerce Protocol updates: https://blog.google/products-and-platforms/products/shopping/ucp-updates/ - How we're helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google: https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - Product data specification: https://support.google.com/merchants/answer/7052112 - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - Agentic Commerce Protocol documentation: https://docs.stripe.com/agentic-commerce/acp - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Agent Payments Protocol specification (v0.2): https://ap2-protocol.org/ap2/specification/ - OpenAI shifts checkout plans in its agentic commerce strategy: https://www.digitalcommerce360.com/2026/03/06/openai-shifts-checkout-plans-agentic-commerce-strategy/ --- # Agentic Commerce Glossary URL: https://agenticcommerceatlas.com/learn/agentic-commerce-glossary Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-glossary.md Section: learn Updated: 2026-10-01 The fast-moving vocabulary of agentic commerce, defined in plain language. Where a term has its own reference page, the entry links to it. Suggest a term or a correction and it will be added. ## A **A2A (Agent-to-Agent).** An open protocol for agents to communicate and delegate tasks to one another. Created at Google, donated to the Linux Foundation in 2025, at v1.0 since March 2026, and a hosted project of the Agentic AI Foundation since 17 August 2026. It is the coordination layer some payment work builds on, for example the x402 extension for A2A. See [A2A explained](/learn/a2a-explained). **ACE (Agentic Commerce Experiences).** American Express's agentic commerce developer kit, published 14 April 2026. It covers agent registration, account enablement, intent intelligence, payment credentials, and cart context. Amex states that account enablement, intent intelligence, and payment credentials are available and that agent registration and cart context are still under development. **ACP (Agentic Commerce Protocol).** Open standard for agent-to-merchant checkout, launched in September 2025; latest stable specification `2026-04-17`, covering cart, feed, orders, authentication, and MCP. Its README describes OpenAI and Stripe as founding maintainers, while `MAINTAINERS.md` lists OpenAI, Stripe, and Meta as lead maintainers. Licensed Apache 2.0. See [ACP explained](/learn/acp-explained). **Agent.** Software that can take actions on a user's behalf, including searching for and purchasing products. In commerce, the "shopper" may now be an agent rather than a person. **Agent Pay.** Mastercard's agentic payments program, announced April 2025. It uses Mastercard Agentic Tokens, built on the same tokenization behind contactless and Mastercard Payment Passkeys, and requires agents to be registered and verified before they can pay. **Agent Pay for Machines (AP4M).** Mastercard's extension of Agent Pay to machine-to-machine payments, introduced 10 June 2026. It targets high-frequency, low-value transactions between agents and services, with agent credentialing, programmatically enforced spending limits, and settlement across cards, accounts, and stablecoins. **Agentic AI Foundation (AAIF).** A directed fund under the Linux Foundation, announced 9 December 2025, created as a neutral home for agent interoperability projects. It holds MCP, Block's goose, OpenAI's AGENTS.md, agentgateway, Agent Router, and, since 17 August 2026, A2A. It is where both MCP and A2A governance now sit. Its own membership stood at 247 organizations as of 12 August 2026, which is a different figure from the 150-plus organizations that back A2A specifically. **Agentic commerce.** Commerce conducted by AI agents acting for a user: discovery, selection, authorization, and payment with limited human input. See [What Is Agentic Commerce?](/learn/what-is-agentic-commerce). **AI-Ready Cards.** Visa's term, under its Intelligent Commerce program, for card credentials tokenized for agent use, so a chosen agent can be authorized to transact within limits the consumer sets. **AP2 (Agent Payments Protocol).** Google-led standard for proving a user authorized a purchase, built around signed mandates (originally Intent, Cart, and Payment; now a Checkout Mandate and a Payment Mandate). Donated to the FIDO Alliance on 28 April 2026. Still at v0.2, with no stable release and reference implementations that mock real payment providers. See [AP2 explained](/learn/ap2-explained). ## C **Cart Mandate.** In AP2's original (v0.1) model, the signed record of the exact cart the agent assembled for the user to approve. **Checkout Mandate.** In AP2's revised (v0.2) model, one of two credential types, covering the authorization of a finalized checkout. It replaces the earlier Intent plus Cart split with open (pre-cart constraints) and closed (authorization) stages. **Commerce / checkout (layer).** The stack layer where an agent browses, builds a cart, and completes a purchase with a merchant. ACP and UCP are the standards here. See [the four layers](/learn/agentic-commerce-protocol-stack#commerce). ## D **Delegated payment.** A pattern where the buyer authorizes a payment that an agent then presents to the merchant on their behalf, without the agent holding the raw payment credentials. ACP specifies a delegated payment flow; AP2 provides the authorization proof behind it. **Delegated authority.** The general principle that an agent acts within authority a user granted, bounded by constraints such as budget, merchant, or time. Mandates and tokens are the mechanisms that make delegated authority verifiable. **Discovery (layer).** The stack layer where an agent finds a merchant's products and the tools it can call. MCP is the standard here. See [the four layers](/learn/agentic-commerce-protocol-stack#discovery). ## F **Facilitator.** In x402, the service that verifies and settles a stablecoin payment on-chain on behalf of the merchant, so the merchant does not have to operate blockchain infrastructure directly. **FIDO Alliance.** The industry body for authentication standards (including passkeys). Google donated AP2 to FIDO on 28 April 2026, where it advances through a Payments working group chaired by Mastercard and Visa and a new Agentic Authentication group. ## H **Human-present / human-not-present.** AP2 terms distinguishing a purchase a user is actively approving in the moment from one an agent completes later within pre-authorized limits. The distinction shapes how authorization is signaled to the merchant and network. ## I **Instant Checkout.** OpenAI's in-chat buying experience in ChatGPT, launched September 2025 on ACP with US Etsy sellers live from day one. On 24 March 2026 OpenAI said the first version had not offered the flexibility it wanted, so it would let merchants use their own checkout experiences while it focused on product discovery, and expanded the Agentic Commerce Protocol to cover discovery; the pattern shifted toward discovery in the assistant and checkout on the merchant's own site. It was not retired: OpenAI's developer documentation describes Instant Checkout as currently available to approved partners. **Intelligent Commerce.** Visa's program, announced April 2025, that opens its network to AI agents through AI-Ready Cards and, from April 2026, an "Intelligent Commerce Connect" on-ramp that works across multiple agent protocols. **Intent Mandate.** In AP2's original (v0.1) model, the signed record of what the user asked for, including constraints like budget. ## K **Know Your Agent (KYA).** The agent-side counterpart to Know Your Customer: identifying an AI agent, linking it to the operator, cardholder, or business accountable for it, checking it against security and behavioral requirements, and monitoring it while it transacts. There is no single standard. Mastercard uses the term for the trust framework behind Agent Pay; EMVCo names Know Your Agent as possible later work under its draft agentic payments framework; and on 9 September 2026 Ant International, Mastercard, and Visa began a collaboration on making their three existing approaches (Visa's Trusted Agent Protocol, Mastercard Verifiable Intent, and Ant International's Agentic Mobile Protocol) interoperable. That collaboration is a statement of intent, with no specification, governance body, or timeline published. See [the Know-Your-Agent interoperability announcement](/news/know-your-agent-interoperability-ant-mastercard-visa). ## M **LCP (Legal Context Protocol).** Open standard launched 24 June 2026, co-stewarded by Integra Ledger and the American Arbitration Association-International Centre for Dispute Resolution, for publishing the legal terms behind an agent transaction at `/.well-known/legal-context.json`, optionally with a hash proving what those terms said and a requirement that the counterparty sign acceptance. It addresses the recourse layer that the payment and checkout protocols leave out of scope. Early: the v1.0 specification is a draft for community review and no protocol steward has adopted it. See [LCP explained](/learn/lcp-explained). **Mandate.** A cryptographically signed, tamper-evident statement of authorization, expressed as a verifiable credential, that an agent can present as proof of consent. Mandates are the core trust primitive in AP2. **MCP (Model Context Protocol).** Created by Anthropic as the standard for how agents discover and call tools and data, and contributed to the Agentic AI Foundation under the Linux Foundation in December 2025. Revisions are date-versioned; `2026-07-28` is the current stable revision and made the protocol stateless. In commerce it acts as the discovery layer. See [MCP explained](/learn/mcp-explained). **MCP extensions.** Optional MCP capabilities that version independently of the specification, formalized in the `2026-07-28` revision with reverse-DNS identifiers and a negotiated capability map. Five are official as of October 2026: **MCP Apps**, which lets a server ship an interactive HTML interface that the host renders in a sandboxed iframe; **Tasks**, which handles long-running work and moved out of the core specification into an extension; **Enterprise Managed Authorization**, which lets an organization centrally control which servers its people can connect to; **Skills over MCP**, which exposes workflow instructions and supporting files through MCP resources; and **OAuth Client Credentials**, for machine-to-machine authentication without an interactive consent step. **Merchant of record.** The entity legally responsible for selling to the customer, handling payment, tax, refunds, and chargebacks. In ACP the merchant stays the merchant of record, so the agent surface does not take over the sale. **MPP (Machine Payments Protocol).** Open standard co-authored by Stripe and Tempo, launched March 2026, for agents to pay services programmatically. A settlement-layer protocol for machine-to-machine microtransactions and recurring payments, settling in stablecoins as well as the cards, wallets, and other methods Shared Payment Tokens carry. Built on HTTP 402, like x402, and specified as an HTTP authentication scheme submitted to the IETF as an individual Internet-Draft. See [MPP explained](/learn/mpp-explained). ## P **Passkey.** A FIDO-based, phishing-resistant credential tied to a user's device, used to authenticate without a password. Mastercard's Payment Passkeys apply the idea to confirm a user behind an agent-initiated payment. **Payment authorization (layer).** The stack layer where the agent proves a real user approved a specific purchase, and where liability is settled. AP2 is the standard here. See [the four layers](/learn/agentic-commerce-protocol-stack#payment-authorization). **Payment Mandate.** In AP2, the signed record of what will actually be charged, shared with the payment network and issuer to signal agent involvement and that the user consented. **Product feed.** The structured file or API through which a merchant publishes its catalog: identifiers, titles, prices, availability, images, and variants. It is what an agent reads instead of a product page. Each standard defines its own schema (ACP publishes a product feed specification; UCP defines a Catalog capability; Google Merchant Center has its own product data specification), but they ask for substantially the same information. See [how to prepare your product catalog](/learn/product-catalog-for-agentic-commerce). **PSP (payment service provider).** A company that processes payments for merchants (for example Stripe). In agentic checkout, the PSP often issues the payment token the agent passes to the merchant. ## S **Settlement (layer).** The stack layer where money actually moves, across card rails and machine-native options like x402 and MPP. See [the four layers](/learn/agentic-commerce-protocol-stack#settlement). **Shared Payment Token.** In ACP, a single-use payment credential issued by the payment service provider and scoped to one specific seller under usage limits carrying a maximum chargeable amount, a currency, and an expiry, which the agent sets to match the cart the buyer approved. The agent passes it to the merchant to charge, and never sees the buyer's raw card details. Also reused by MPP for its fiat settlement path, covering cards, wallets, and the other methods the token carries. **Stablecoin.** A cryptocurrency designed to hold a steady value against a reference such as the US dollar. Stablecoins (for example USDC) are the settlement medium for machine-native payment approaches like x402 and, optionally, MPP. **Streamable HTTP.** MCP's HTTP transport: a server exposes a single endpoint that accepts JSON-RPC over POST. From the `2026-07-28` revision it is stateless, so the `initialize` handshake and the `Mcp-Session-Id` header are gone, every request carries `Mcp-Method` and (for tool, resource, and prompt calls) `Mcp-Name` headers so gateways can route without reading the body, and list results carry a cache lifetime. The older HTTP plus Server-Sent Events transport is deprecated. It underpins remote MCP servers. See [how to build a remote MCP server](/learn/build-a-remote-mcp-server). ## T **Tempo.** The blockchain, incubated by Stripe with Paradigm, that MPP currently settles on, though MPP is designed to work across multiple rails. **Tokenization.** Replacing sensitive payment details with a token, so an agent can transact without handling raw card numbers. The shared foundation under most network agent-payment products. **Trusted Agent Protocol.** A Visa-led open framework, introduced October 2025, to help merchants distinguish legitimate AI agents from malicious bots when an agent arrives at a storefront. ## U **UCP (Universal Commerce Protocol).** Google's standard, co-developed with Shopify, for the broader shopping journey from discovery through checkout to post-purchase. Launched January 2026; current specification revision `v2026-08-25`, which reorganized the specification into Common, Shopping, and Payment groups, moved payment constructs into the cross-vertical common layer, and added EMV 3-D Secure payment authentication and a Location capability. Its capabilities include Checkout, Cart, Catalog, Order, and Identity Linking over REST, MCP, and A2A transports. Governed by a Governance Council over per-domain Tech Councils for Shopping, Food, Lodging, and, from 2 September 2026, Payments. The main rival to ACP at the commerce layer. See [UCP explained](/learn/ucp-explained). **Universal cart.** The idea of a single cart an agent can fill across multiple merchants. Google announced a product of that name at Google I/O in May 2026 and expanded it at Google Marketing Live on 20 May 2026; as of that announcement the cross-retailer checkout features were described as coming soon rather than generally available. ## V **Verifiable credential.** A W3C standard for a tamper-evident, cryptographically signed digital claim. AP2 mandates are expressed as verifiable credentials, which is what lets a merchant or network check consent without trusting the agent. ## W **WebMCP.** A proposed web standard that lets a website register tools in the browser so an AI agent calls a declared action (search the catalog, update the cart, submit checkout) rather than parsing the page and guessing which button to click. It is distinct from [MCP](/learn/mcp-explained) servers, which agents reach over the network rather than through a page. Shopify switched on WebMCP tools on every Liquid storefront on 5 August 2026 and extended them to checkout on 28 September 2026, describing its checkout tools as the UCP checkout capability over WebMCP; Cloudflare opened a developer preview on 6 August 2026. Agent support is currently limited to Chromium-based browsers. ## X **x402.** A settlement protocol, created by Coinbase, reviving the HTTP `402 Payment Required` status for machine-native, often stablecoin, payments. Coinbase's contribution of the protocol completed with the operational launch of the x402 Foundation under the Linux Foundation on 14 July 2026, with 40 member organizations. Sits alongside MPP at the settlement layer. Primary sources: - WebMCP support for checkout: https://shopify.dev/changelog/posts/webmcp-support-for-checkout - WebMCP support for Liquid and Hydrogen storefronts: https://shopify.dev/changelog/webmcp-liquid-hydrogen - Agentic Commerce Protocol specification: https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - AP2 specification: https://ap2-protocol.org/ - Universal Commerce Protocol: https://ucp.dev/ - Model Context Protocol: https://modelcontextprotocol.io/ - x402 protocol: https://github.com/x402-foundation/x402 - Machine Payments Protocol: https://mpp.dev/ - Visa Intelligent Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Mastercard Agent Pay: https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - Mastercard launches Agent Pay for Machines: https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html - Agentic Commerce Experiences (ACE) developer kit: https://www.americanexpress.com/en-us/company/agentic-commerce/ - Linux Foundation announces the formation of the Agentic AI Foundation (AAIF): https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation - A2A joins AAIF's open agentic stack: https://aaif.io/blog/a2a-joins-aaif - Model Context Protocol specification releases: https://github.com/modelcontextprotocol/modelcontextprotocol/releases - The 2026-07-28 MCP Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - UCP specification overview (v2026-08-25): https://ucp.dev/2026-08-25/specification/overview/ - Linux Foundation announces operational launch of x402 Foundation to standardize internet-native payments for AI agents and applications: https://www.prnewswire.com/news-releases/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications-302824778.html - MCP Extensions Overview (official extensions): https://modelcontextprotocol.io/extensions/overview - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ --- # Agentic Commerce Readiness Checklist: What Merchants Need Before AI Agents Can Buy URL: https://agenticcommerceatlas.com/learn/agentic-commerce-readiness-checklist Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-readiness-checklist.md Section: learn Updated: 2026-10-01 Agentic commerce readiness means a merchant can be found, understood, and bought from by AI agents without breaking price accuracy, checkout control, payment authorization, or dispute evidence. The practical readiness bar is not "install an AI tool." It is clean product data, an agent-reachable transaction path, scoped payment authorization, logs, and a named owner. ## Short answer If most of the checklist below is unchecked, start with product data and governance. If product data is clean but checkout and payment are not ready, focus on API checkout, authorization, and evidence. If all sections are mostly checked, you are ready to run a limited pilot and measure agent-driven discovery, checkout attempts, completed orders, exceptions, and disputes. ## Readiness scorecard | Area | Ready looks like | Risk if missing | |---|---|---| | Product data | Complete, structured, current, and matched to the live store | Agents misread, ignore, or misquote products | | Discoverability | Products and tools are visible to the agent surfaces customers use | You are absent from the agent's consideration set | | Checkout | The cart and checkout path can be called through structured APIs | Agent sessions fail or fall back to brittle page scraping | | Payments | Tokens, mandates, or network credentials are scoped and understood | Authorization and fraud questions become hard to defend | | Evidence | Authorization, cart, price, agent, order, and receipt records are logged | Disputes become reconstructions instead of records | | Governance | One owner can decide standards, risk, and vendor choices | Teams make incompatible platform and payment decisions | ## 1. Product data Start here. For agentic commerce, your product data is the storefront an agent reads. It needs to be complete enough to compare, structured enough to parse, accurate enough to transact against, and current enough that price and availability do not drift. - Every product has a stable identifier, title, description, price, currency, availability, image, brand, category, variant data, and relevant product identifiers. - Prices and inventory match the live store exactly, to the cent and the unit. - Price, availability, promotions, and variants update quickly enough that agents do not act on stale terms. - Product pages and feeds agree with one another. - Someone monitors feed-to-store drift and treats mismatches as operational incidents. For the deeper version, use [how to prepare your product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce). ## 2. Discoverability Once the catalog is reliable, ask where agents will find it. This might be through a commerce platform, a shopping feed, an agent marketplace, a protocol integration, or an MCP server exposing merchant tools. The readiness question is not only "are we listed?" but "do we know how agents represent and rank us?" - You know which agent surfaces matter for your customers. - You can verify how your products are described, compared, and filtered. - If a platform syndicates your feed, you have checked that syndication is enabled and current. - You have a way to monitor impressions, recommendations, referrals, or agent calls when those reports become available. - If you expose an MCP server, you know which revision of the specification it implements. MCP published a stateless `2026-07-28` revision as final on 28 July 2026, which removes the initialize handshake and the session header, requires header-based routing, and starts a twelve-month deprecation clock on the legacy HTTP with server-sent events transport. An integration built around MCP sessions needs a migration plan. ## 3. Checkout and transactability An agent-ready merchant needs a transaction path that software can call without guessing at rendered page behavior. For ACP, that means an Agentic Checkout API. For UCP or other surfaces, the exact interface may differ, but the principle is the same: the agent needs structured cart, fulfillment, tax, policy, and order responses. - Checkout can be reached through structured APIs, not only browser clicks. - The checkout path can return current pricing, shipping, tax, availability, restrictions, and policy links. - Your team understands which standard matters for the surfaces you care about: [ACP](/learn/acp-explained), [UCP](/learn/ucp-explained), or both. - You have completed a test agent-initiated order in a sandbox or pilot. ## 4. Payments and authorization Payment readiness is about proving the user authorized the agent's action and limiting the payment artifact's scope. ACP uses the Shared Payment Token model in its reference implementation. AP2 uses signed mandates to prove authorization. Card-network programs use tokenization and registered-agent controls. - You understand which payment artifact will be used: Shared Payment Token, network token, mandate-backed credential, stablecoin rail, or another mechanism. - Tokens or credentials are scoped to the merchant, amount, cart, and permitted action. - You have read the terms for liability, disputes, consumer protection, and fees, and you know that none of the protocols allocates liability. AP2 states that its objective is to provide supporting evidence that helps payment networks establish accountability and liability principles, and puts dispute resolution out of scope. Liability comes from network rules, issuer policy, and your contracts. - Fraud and customer-service teams know what a valid agent transaction looks like. For the mechanics, see [how AI agents pay](/learn/how-ai-agents-pay) and [AI shopping agent authorization](/learn/ai-shopping-agent-payment-authorization). ## 5. Evidence and monitoring Agent transactions need a defensible record. The evidence does not only help with disputes. It also helps support teams explain what happened, helps fraud teams detect abuse, and gives leadership the measurement layer needed to decide whether the channel is working. Keep records of: - the customer authorization or mandate; - the agent or platform that acted; - constraints such as amount, merchant, product, date, and recurrence; - the cart, price, shipping, tax, and policy state shown at checkout, including the merchant-signed cart object if the flow produces one; - the payment artifact presented; - the receipts returned on both sides, meaning the checkout receipt your systems issue and the payment receipt your processor issues; - the final order, refund, cancellation, or exception. The receipts matter more than they look. AP2's verification rules at the time of dispute require the mandate and its matching receipt on both the checkout side and the payment side, with the hashes binding them independently recomputed. A log that holds authorizations but not receipts will not pass that check. ## 6. Governance and risk Readiness is also an ownership problem. Agentic commerce spans ecommerce, product data, payments, legal, privacy, customer service, analytics, and marketing. If nobody owns the whole decision, a merchant can accidentally accept a payment program, expose product data, or sign a platform contract without understanding the tradeoffs. - Assign an executive or operating owner. - Decide which standards and surfaces are in scope for the next 90 days. - Define the risk review for privacy, disputes, fraud, and customer data. - Use an RFP or vendor scorecard before committing to a platform. - Track what is live, what is announced, and what is only a roadmap claim. A shorter, printable merchant readiness checklist is available on the [resources page](/resources), alongside the [vendor evaluation scorecard](/resources/vendor-evaluation-scorecard.md) and [RFP question bank](/resources/rfp-question-bank.md). Use this page for the reasoning and the printable version as the working sheet. ## The bottom line The safest path into agentic commerce is staged. Clean the catalog first, make checkout callable second, understand payment authorization third, then pilot with logs and governance in place. The standards are still moving, but those foundations are low-regret. They improve conventional ecommerce and make the business easier for agents to represent accurately. ## FAQ **What is the minimum readiness bar for agentic commerce?** Complete structured product data, exact live-store parity, an API path to checkout, a payment and authorization model you understand, transaction logs, and a named owner. **Should a merchant start with payments or product data?** Product data. Agents cannot choose or buy what they cannot understand, and stale product data can break checkout even when payment works. **Does readiness mean choosing ACP or UCP now?** Not always. It means knowing which customer surfaces matter and what each requires. Some merchants can wait while they clean data and governance; others need ACP, UCP, or both because their platform already depends on them. **What evidence should a merchant keep?** The authorization, agent identity, constraints, cart, price, payment artifact, order, any exception or refund record, and the receipts returned by the merchant and the payment processor. AP2's dispute procedure needs the mandate and the matching receipt on both sides, so authorizations alone will not verify. Primary sources: - Agentic Commerce Protocol documentation: https://docs.stripe.com/agentic-commerce/acp - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Agent Payments Protocol specification (v0.2): https://ap2-protocol.org/ap2/specification/ - Product data specification: https://support.google.com/merchants/answer/7052112 - Model Context Protocol: https://modelcontextprotocol.io/ - The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ --- # Agentic Commerce RFP Questions: What To Ask Platforms, Processors, And AI Vendors URL: https://agenticcommerceatlas.com/learn/agentic-commerce-rfp-questions Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-rfp-questions.md Section: learn Updated: 2026-10-01 An agentic commerce RFP should turn vendor claims into evidence. Ask what is live, which standards are supported, how product data stays current, how checkout and payment authorization work, who carries liability, what data is shared, and what reporting exports you receive. If a vendor cannot answer those concretely, the capability is not ready for procurement. ## Short answer Use the questions below to separate three things vendors often blend together: product discovery, agent-assisted checkout, and agent-authorized payment. A vendor may support one without supporting the others. Your RFP should force that distinction, then test interoperability, data quality, liability, reporting, and lock-in. ## RFP question map | Area | What the answer should prove | |---|---| | Scope | Which use cases are live, in pilot, or only roadmap | | Standards | Where ACP, AP2, UCP, MCP, A2A, x402, MPP, or proprietary APIs are used, and at which version | | Product data | How catalog freshness, completeness, and live-store parity are maintained | | Checkout | Whether the vendor can create, update, complete, cancel, and report orders | | Payments | How authorization, tokens, mandates, disputes, and liability work | | Privacy | What customer, product, and transaction data is collected or shared | | Reporting | Whether exports separate agent surface, product, order state, and outcome | | Portability | What you can take with you if you leave | ## 1. Scope and live status Start by asking what is actually shipping. Agentic commerce is full of announcements, pilots, and future-roadmap language, so the first RFP job is to classify claims. - Which use cases do you support today: discovery, comparison, cart creation, checkout, payment authorization, post-purchase support, or all of these? - Which capabilities are generally available, in private beta, in pilot, or still roadmap? - Which customers, verticals, or categories are live now? - Which capabilities have you announced publicly that are not yet available to a customer like us, and in which countries? - Can you show an end-to-end demo using our category and a realistic product set? - What fails or falls back to a human when the agent cannot complete the task? That second question is doing more work than it looks. A large share of agentic commerce news is an announcement of intent rather than a shipped capability, including retailer and payment-provider commitments made at launch events, so an RFP that does not force the distinction will buy a roadmap. ## 2. Standards and interoperability Do not accept "standards-based" without details. A useful answer names the standard, the version if relevant, and the boundary where proprietary APIs begin. - Which open standards do you support: [ACP](/learn/acp-explained), [AP2](/learn/ap2-explained), [UCP](/learn/ucp-explained), [MCP](/learn/mcp-explained), A2A, x402, MPP, or others? - Which revision of each? These specifications are date-versioned and moving. Ask for the exact version, then check it against the standard's own release page rather than the vendor's marketing page. - Where do you use open standards, and where do you use proprietary APIs? - Can we export integration mappings, product mappings, order logs, and transaction records? - How do you handle version changes and backward compatibility, and what notice do we get before a breaking change? - Can we support more than one agent surface or protocol without rebuilding? Two version questions are worth asking by name in 2026. **MCP.** The `2026-07-28` revision shipped as final on 28 July 2026 and is a deliberate clean break. The protocol is now stateless: the initialize handshake and the session header are gone, protocol version and capabilities travel on every request, and header-based routing is required on the Streamable HTTP transport. Authorization was hardened, with dynamic client registration deprecated in favor of client ID metadata documents, and the legacy HTTP with server-sent events transport is deprecated on a twelve-month clock. So ask which revision the vendor implements, whether anything in their design still depends on MCP sessions, and what their migration plan and timeline are. Treat a vendor who describes MCP session handling as a current feature as behind the spec. **ACP and UCP.** Both are date-versioned too. Ask which ACP spec release the integration targets, and which UCP revision, and which optional UCP capabilities such as cart, catalog, and identity linking are actually implemented rather than merely available in the specification. ## 3. Product data and catalog quality Agents buy from data. If a vendor cannot explain feed requirements and data freshness, the integration is fragile. - What fields are required, recommended, and optional? - Which identifiers are used for product matching: SKU, GTIN, brand, category, merchant ID, or platform IDs? - How quickly do price, availability, promotion, and variant changes reach agent surfaces? - How are feed errors, mismatches, missing attributes, and stale inventory reported? - Can we see how agents describe and compare our products before launch? For the underlying readiness work, see [product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce). ## 4. Checkout and transaction control The buyer may interact with an agent, but the merchant still needs control over pricing, tax, fulfillment, eligibility, policies, and order state. - Does the agent complete checkout through your platform, our checkout, or a third-party checkout surface? - Which checkout standard or API is used? - What cart, shipping, tax, promotion, inventory, and policy data is exchanged? - Can we enforce restricted products, shipping limits, minimum order values, fraud rules, and promotion exclusions? - How are failed, partial, canceled, refunded, or changed orders handled? ## 5. Payments, authorization, and disputes This is the highest-risk section. Ask for precise flows and contract terms, not conceptual diagrams. - Which payment methods and delegated-payment models are supported? - How is customer authorization captured, scoped, stored, and auditable? - Do you support Shared Payment Tokens, network tokens, AP2 mandates, stablecoins, or other payment artifacts? - If AP2 mandates are used, do you retain the receipts as well as the mandates? AP2's dispute procedure requires the checkout mandate with its receipt and the payment mandate with its receipt, and independently recomputes the hashes that bind them. A vendor that stores authorizations but not receipts cannot produce verifiable evidence. - Who is liable for fraud, agent error, customer dispute, chargeback, unauthorized purchase, or "not as described" claims, and which clause of the contract says so? - What evidence is available to defend a dispute, in what format, how is it exported, and how long is it retained? - Which consumer-protection programs do you rely on, and do any of them shift liability away from us? A cardholder protection pledge, such as the one American Express announced in April 2026 for registered-agent purchases, protects the cardholder and does not by itself change what a merchant absorbs. One framing to hold on to through this section: no agentic commerce protocol allocates liability. AP2 states that its objective is to provide supporting evidence that helps payment networks establish accountability and liability principles, and its specification puts dispute resolution, retention, and retrieval out of scope. If a vendor answers a liability question by naming a protocol, the question is still open. Push until the answer is a contract term, a network rule, or a written indemnity. For a non-technical payment overview, see [how AI agents pay](/learn/how-ai-agents-pay). For the authorization layer, see [AI shopping agent authorization](/learn/ai-shopping-agent-payment-authorization). For the wider risk picture, see [agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness). ## 6. Privacy, security, and data use Agentic commerce creates new data flows among merchants, agents, platforms, processors, networks, and model providers. Your RFP should make those flows explicit. - What customer, product, transaction, and behavioral data do you collect? - Which data is shared with agent platforms, model providers, payment networks, processors, or partners? - Do you use our data to train models, rank competitors, improve unrelated services, or sell insights? - What retention, deletion, access-log, and security controls are available? - Can we restrict sensitive products, geographies, customer groups, or data fields? ## 7. Measurement and reporting If agentic commerce is a channel, it needs channel reporting. - What reporting is available for impressions, recommendations, comparisons, clicks, carts, completed purchases, exceptions, returns, and disputes? - Can reporting separate agent surface, protocol, product category, campaign, and order state? - How do you attribute a purchase when discovery happens in one agent and checkout happens elsewhere? - Can data be exported to our analytics, warehouse, or BI tools? - Do logs distinguish human traffic, agent traffic, and platform-to-platform calls? ## 8. Commercial terms and lock-in Finally, ask what it costs and what you give up. - What fees apply: setup, monthly platform, per-order, payment, referral, ad, data, or support fees? - Are fees different by agent surface, protocol, payment method, geography, or category? - What contract terms limit portability, direct customer relationships, data reuse, or future integrations? - What happens to our data, listings, integration, and transaction history if we leave? ## Red flags - "We support agentic commerce" without naming live use cases. - "Standards-based" without naming where standards end and proprietary APIs begin. - Naming a standard without naming the version, especially for MCP, ACP, and UCP, which are all date-versioned. - "Real-time catalog sync" without a measurable freshness commitment. - "Agents can buy for users" without a clear authorization and dispute record, including receipts. - Answering a liability question with a protocol name instead of a contract clause. - "Full reporting" without exports by agent surface and transaction state. - "Low lift" without naming the work required from ecommerce, product data, legal, payments, analytics, and support. The downloadable [RFP question bank](/resources/rfp-question-bank.md) contains a longer buyer-ready version of these questions. It does not yet carry the version and receipts questions added above, so use this page alongside it. Pair both with the [agent-readiness checklist](/learn/agentic-commerce-readiness-checklist) before opening procurement. ## FAQ **What should an agentic commerce RFP test first?** What is actually live. Ask which use cases are generally available, which are in pilot, which customers are live, and whether the vendor can demo your category end to end. **Which standards should vendors name?** ACP, AP2, UCP, MCP, A2A, x402, MPP, network tokens, and any proprietary APIs they use, with the version for each. Several are date-versioned and moving, so ask for the revision. The point is precision, not claiming support for everything. **What is the most important payments question?** How authorization is captured, scoped, stored, and defended in a dispute, including whether receipts are kept alongside mandates, plus who carries liability and which contract clause says so. No protocol allocates liability, so a protocol name is not an answer. **What is a red-flag answer?** Any broad claim that lacks live use cases, supported standards, data freshness commitments, authorization records, reporting exports, and liability terms. Primary sources: - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - Agentic Commerce Protocol documentation: https://docs.stripe.com/agentic-commerce/acp - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Agent Payments Protocol specification (v0.2): https://ap2-protocol.org/ap2/specification/ - AP2 Executive Summary: https://ap2-protocol.org/overview/ - Model Context Protocol: https://modelcontextprotocol.io/ - The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - Find and Buy with AI: Visa Unveils New Era of Commerce (Visa Intelligent Commerce): https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html --- # Agentic Commerce Risks and Readiness URL: https://agenticcommerceatlas.com/learn/agentic-commerce-risks-and-readiness Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-risks-and-readiness.md Section: learn Updated: 2026-10-01 The real risks of agentic commerce fall into a handful of categories: confirming that an agent is genuinely authorized to act for a customer, fraud and unauthorized purchases, the still-unsettled question of liability when an agent-made purchase goes wrong, privacy and data, and the strategic risk of being disintermediated from your own customer. None of these is a reason to stay out. Each is a reason to enter deliberately, with the right safeguards and a clear view of who carries the risk. This guide maps the risks, shows how the emerging standards address each, and ends with a readiness checklist. It is the companion to [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business), which covers the strategic decision; this page covers what to watch out for. ## The risk landscape in one paragraph When the buyer is software, two things change. The trust that a payment system normally places in a present, authenticating human has to be reconstructed for an agent, and the accountability that normally has a clear owner becomes contested. Most of the technical work in agentic commerce is really about rebuilding that trust, and most of the open questions are really about who is accountable when something fails. Hold those two themes in mind and the specific risks below are easier to reason about. ## Agent authenticity and impersonation The first question a merchant faces is whether the agent at the door is a legitimate agent acting for a real customer, or a bot pretending to be one. This is the agent-authenticity problem, and several efforts target it directly. Visa's [Trusted Agent Protocol](/learn/agentic-commerce-glossary), published in October 2025 and developed with Cloudflare, gives merchants a cryptographic way to recognize a trusted agent with commerce intent and separate it from malicious automation and rogue bots. One caveat matters for planning: Visa states that the initial specifications apply to the Visa network in this phase, with alignment to bodies such as the IETF, the OpenID Foundation, and EMVCo as an intention rather than a finished cross-network standard. The card networks' agent programs, Visa Intelligent Commerce and Mastercard Agent Pay, are built on registering and verifying agents before they transact rather than letting any piece of software present a card, and American Express describes the same pattern in its ACE Developer Kit, where agent registration is listed as a service still in development. The risk to manage is treating an unverified agent as trusted; the mitigation is to rely on these verification layers rather than rolling your own. ## Authorization and unauthorized purchases Even a legitimate agent raises a harder question: did the user approve this specific purchase, or just delegate a general goal? This is what [AP2](/learn/ap2-explained) exists to answer. It uses cryptographically signed mandates, expressed as verifiable digital credentials, that record what the user authorized and can be presented as proof of consent. AP2 v0.2 defines two: a Checkout Mandate covering what is being bought, verified by the merchant, and a Payment Mandate covering how it is paid for, verified by the credential provider, the network, and the merchant's payment processor. Each can be open, where the user approves a set of constraints an agent may act within later, or closed, where the user approves a specific finalized checkout. That is the distinction between a purchase a human is actively approving and one an agent completes later within pre-set limits. On the payment side, the [Shared Payment Token](/learn/acp-explained) design limits the blast radius of any single authorization: a token is scoped to one merchant and one cart total and cannot be reused for a different amount or seller. The risk is an agent spending beyond what the user actually intended; the mitigations are scoped mandates, scoped tokens, and clear spending limits set at the point of delegation. ## Liability, chargebacks, and disputes This is the least settled part of agentic commerce, and the one a leader should watch most closely. There is not yet a finalized, cross-network rulebook for how disputes on agent-initiated transactions are handled, which means the answer to "who pays when it goes wrong" is still being worked out. Trade and legal commentary widely expects much of the risk to land on merchants, on the logic that the card networks, issuers, and AI providers are each positioned to avoid absorbing it. The composition of disputes is also expected to shift, with fewer classic fraud claims and more "I did not authorize that" and "not as described" claims, for example when an agent misreads a user's intent and buys the wrong item. Be clear about one thing that is often stated the wrong way round: none of the agentic commerce protocols allocates liability. AP2 is the closest thing the ecosystem has to a dispute-evidence standard, and it says so itself. Its executive summary states that a primary objective is "to provide supporting evidence that helps payment networks establish accountability and liability principles," and it poses accountability, meaning who is responsible when a transaction is fraudulent or incorrect, as a question current systems cannot answer. The v0.2 specification puts dispute resolution itself out of scope: it describes how the mandates and receipts can be brought together as evidence, then states that the details of how that is used for dispute resolution, retention, and retrieval are outside the specification. Liability is settled by network rules, issuer policy, and your contracts, not by a protocol. American Express has made the most explicit consumer-protection commitment so far, Amex Agent Purchase Protection, announced in April 2026 alongside its Agentic Commerce Experiences (ACE) Developer Kit. It stands out precisely because a settled industry-wide standard does not exist, but read the scope before planning around it. Amex describes it prospectively, saying that in the future, if a Card Member authorizes an agent and that agent sends Amex the customer's authenticated purchase intent, Amex will protect eligible customers from charges related to AI agent error. The announcement carries a forward-looking-statements caveat, the agent registration and cart context services it leans on are marked as in development, and terms and conditions are noted as applying. It protects cardholders, not merchants, and it does not tell a merchant who absorbs a disputed agent-initiated sale. On regulation, the honest position is that no jurisdiction has published rules written specifically for agent-initiated disputes. The existing consumer-payment and chargeback regimes were drafted on the assumption that a human initiated the payment, and how they map onto delegated agent purchases is being argued rather than decided. Track it; do not assume it, and do not accept a vendor's assurance that it is settled. The practical defense, regardless of how the rules settle, is evidence, and it is worth being precise about what evidence means. AP2's dispute procedure needs both halves of each pair: the Checkout Mandate and the Checkout Receipt the merchant returns, and the Payment Mandate and the Payment Receipt the processor returns, with the hashes binding them independently recomputed at the time of dispute. A log of mandates alone will not verify. Capture the user's authorization, the cart the merchant signed, and the receipts, continuously, rather than trying to reconstruct consent after a dispute. ## Privacy and data Agent transactions create new data flows. An agent may share a user's intent, constraints, and context with merchants and networks, and the question of what is shared, with whose consent, and who retains it is unsettled. For a business, this is both a compliance obligation and a strategic asset: the customer data and consent you hold, and handle responsibly, is part of what keeps the relationship yours rather than the agent platform's. Treat agent-channel data with the same care as any other customer data, and be deliberate about what you expose to an agent surface. ## Channel disintermediation The largest strategic risk is not fraud but position. If an agent surface becomes the place customers shop, it can sit between you and the buyer, own the discovery moment, and commoditize your catalog against competitors who are one comparison away. This is not a reason to be absent, being absent only means being represented badly or not at all, but it is a reason to compete on the things an agent cannot strip away: owning your first-party relationships and data, and keeping your product information richer and more accurate than rivals so that when an agent compares options, you are surfaced and described well. ## Operational and accuracy risks A quieter risk is simply being wrong in a way agents cannot tolerate. Agents read machine-readable data and transact against it programmatically. If the price or availability an agent reads does not match your live store, an agent-initiated checkout can fail outright, or complete at terms you did not intend. And if an agent misinterprets a user's request and orders the wrong item, the merchant is often the one left with the return and the dispute. The mitigation is unglamorous and high-value: keep your product data complete, structured, and accurate to the cent against what is live, and make your checkout API-driven so agents see real, current terms. ## A readiness checklist Use this as a starting point, not a finish line. A printable, downloadable version is on the [resources page](/resources). Governance: assign a clear owner for agentic commerce, and brief leadership on the two contested points, the unsettled liability picture and which checkout standard you will support. On the second, note that the standards question is increasingly answered for you by whoever you already buy from: Google has said that partners including Commerce Inc, Salesforce, and Stripe will implement UCP on their platforms, so for many merchants this is a question to put to a provider rather than an independent build decision. Data: audit your product feed for completeness, structure, and exact agreement with your live site, and fix mismatches. Payments and verification: rely on the networks' agent-verification and scoped-token mechanisms rather than building your own trust layer, and read the terms of any program you join, including its consumer-protection and liability provisions, remembering that a consumer-protection pledge is not a merchant liability shift. Evidence and monitoring: log agent authorization and behavior continuously across the transaction, and keep the receipts as well as the mandates, so you can defend a dispute with a complete record rather than a reconstruction. Privacy: handle agent-channel data to the same standard as the rest of your customer data, and decide deliberately what you expose. Strategy: protect your first-party relationships and keep your product information better than competitors', so an agent surface complements your channel rather than replacing it. ## The bottom line Agentic commerce is safe to enter, but not safe to enter carelessly. The authenticity and authorization problems are being solved by the standards, and you can lean on them. The liability picture is genuinely unsettled, and no protocol resolves it, so read the network and vendor terms and keep your evidence, receipts included. And the strategic risk, losing the customer relationship, is the one most within your own control. For the decision of whether and how to act, see [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business); for how the money and trust mechanics work, see [how AI agents pay](/learn/how-ai-agents-pay). ## FAQ **Who is liable when an AI agent makes a purchase that goes wrong?** There is not yet a finalized, cross-network rulebook for agent-initiated disputes, so this is the least settled part of agentic commerce. No protocol allocates it: AP2's executive summary says its objective is to provide supporting evidence that helps payment networks establish accountability and liability principles, and while its specification sets mandatory verification rules for dispute evidence, it leaves dispute resolution itself, and retention and retrieval, out of scope. Trade and legal commentary widely expects much of the risk to fall on merchants. American Express has made the most explicit consumer-protection pledge so far, but it is scoped to agent error, protects cardholders rather than merchants, and is stated prospectively. The practical defense is to capture authorization, the agreed cart, and the receipts at the point of delegation, not after a dispute. **How do I know an agent is genuinely authorized?** AP2 uses signed mandates, expressed as verifiable digital credentials, to prove a specific user approved a specific purchase. Visa's Trusted Agent Protocol, developed with Cloudflare, gives merchants a cryptographic way to tell legitimate agents from bots, though Visa states its initial specifications apply to the Visa network in this phase. The networks' agent programs are built on registering and verifying agents before they transact. **What is the biggest strategic risk?** Channel disintermediation: an agent surface owning the customer and the discovery moment. The defenses are owning your first-party data and relationships and keeping your product information richer and more accurate than competitors'. **What is the single most useful thing to do now?** Build an evidence and audit trail for agent transactions, and keep your product data accurate against your live site. Log the receipts as well as the mandates, because AP2's dispute procedure needs both halves of each pair, and accurate data prevents the mismatches that can break an agent checkout. Primary sources: - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - AP2 Executive Summary: https://ap2-protocol.org/overview/ - Agent Payments Protocol specification (v0.2): https://ap2-protocol.org/ap2/specification/ - American Express Debuts Agentic Commerce Experiences (ACE) Developer Kit and Announces Industry-First Protection for Registered Agent Purchases: https://www.americanexpress.com/en-us/newsroom/articles/innovation/american-express-debuts-agentic-commerce-experiences--ace--devel.html - Find and Buy with AI: Visa Unveils New Era of Commerce (Visa Intelligent Commerce): https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Visa Introduces Trusted Agent Protocol: An Ecosystem-Led Framework for AI Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21716.html - Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI: https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - AI shopping gets simpler with Universal Commerce Protocol updates: https://blog.google/products-and-platforms/products/shopping/ucp-updates/ --- # AI Shopping Agent Authorization: Mandates, Tokens, Passkeys, And Liability URL: https://agenticcommerceatlas.com/learn/ai-shopping-agent-payment-authorization Markdown URL: https://agenticcommerceatlas.com/learn/ai-shopping-agent-payment-authorization.md Section: learn Updated: 2026-10-01 AI shopping agent authorization is the proof that a user allowed software to buy something on their behalf. The safest designs avoid handing an agent a raw card number. They use signed mandates, scoped payment tokens, passkeys, registered agents, and audit logs so the buyer, merchant, issuer, and network can see what was authorized. ## Short answer For an AI agent to pay safely, three things must be true: the user authorized the action, the payment credential is scoped so it cannot be reused broadly, and the merchant can keep evidence of the transaction. The industry is converging on mandates, tokenization, and strong authentication to solve those problems. ## The authorization problem Normal ecommerce assumes a human is present at checkout. Agentic commerce breaks that assumption. A user may ask an agent to act now, or may delegate a future purchase under constraints. That creates a hard question: did the agent have permission to make this exact purchase at this exact price from this merchant? Good authorization answers that question before a dispute. Weak authorization tries to infer it after the fact. ## Four authorization mechanisms | Mechanism | What it proves | Where it appears | |---|---|---| | Mandate | The user delegated or approved a specific action or constraint set | AP2 | | Shared Payment Token | The payment credential is scoped to a merchant and cart total | ACP and Instant Checkout | | Network token | A card-network credential is bound to an agent, device, merchant, or use case | Visa, Mastercard, and related programs | | Passkey or device-bound approval | The human used strong authentication to approve or delegate | Mastercard Agent Pay, AP2-style flows | These are not mutually exclusive. A future transaction may combine an AP2 mandate, a tokenized payment credential, and a checkout protocol such as [ACP](/learn/acp-explained) or [UCP](/learn/ucp-explained). ## Mandates: proof of delegated intent [AP2](/learn/ap2-explained), the Agent Payments Protocol, is the clearest attempt to standardize agent authorization. Its core object is a mandate: a signed, tamper-evident credential that records what the user authorized. A closed mandate authorizes one specific action. An open mandate sets constraints for a later action, such as a spending cap, merchant, recurrence, product type, or time window. The practical value is non-repudiation. If a customer later says "I did not authorize that," the merchant or issuer should not be relying on a log note or a screenshot. It should be able to verify a signed authorization chain. AP2 pairs each mandate with a signed **receipt** from whoever verified it: a Checkout Receipt from the merchant, a Payment Receipt from the payment processor, each carrying a success or error status and a hash of the mandate it answers. That matters for the evidence record below, because AP2's own dispute procedure is not "produce the mandate," it is produce the mandate *and* its receipt on both the checkout and the payment side, then recompute the hashes independently. If you are designing a log, design it to hold both. For implementation detail, see [AP2 mandates in practice](/learn/ap2-mandates-in-practice). ## Tokens: payment without card exposure Tokenization limits what an agent can do with a payment credential. Instead of exposing a card number, a processor or network issues a token that is useful only within the intended scope. In the ACP and Stripe/OpenAI flow, the payment service provider issues a Shared Payment Token. The token is passed to the merchant and is scoped to the merchant and cart total, so it cannot be reused as a general-purpose card credential. Card-network programs use related tokenization patterns, tied to registered agents and customer controls. For the broader payment map, see [how AI agents pay](/learn/how-ai-agents-pay). ## Passkeys and strong customer approval Passkeys and device-bound keys help prove the human approved an action or delegated authority. Mastercard has tied Agent Pay to payment passkeys and tokenization. AP2 uses cryptographic credentials and key binding. The point is the same: authorization should be anchored to something stronger than "the agent said the user wanted it." Strong approval is especially important when a purchase is human-not-present. If the user is not watching the final checkout, the earlier delegation must be narrow enough and verifiable enough to trust. ## Liability is still unsettled The technical patterns are clearer than the liability rules. There is no single cross-network rulebook that settles every fraud, chargeback, "wrong item," or "not as described" dispute for agent-made purchases. American Express has made the most concrete pledge, protecting card members from charges resulting from registered agent error, but that covers one closed-loop network rather than the market. It is worth being precise about what the standards do here, because it is often overstated. AP2 does not assign liability. Its own executive summary lists accountability as an open question, asking whether the user, the agent's developer, the merchant, the network, or the PSP should answer for a bad transaction. What AP2 sets out to do is narrower and more useful: "provide supporting evidence that helps payment networks establish accountability and liability principles." Its specification then puts dispute resolution, retention, and retrieval explicitly out of scope. So a mandate is proof of what was authorized. It is not a promise about who pays. Merchants should not treat this as a reason to ignore agentic commerce. They should treat it as a reason to read terms carefully and keep evidence. ## What merchants should require Before accepting agent-initiated purchases at scale, require: - scoped authorization, not broad permission; - tokenized payment credentials, not exposed card details; - logs that connect the user's authorization to the cart and payment; - clear dispute terms from platforms, processors, and networks; - customer-service workflows for agent errors and exceptions; - reporting that separates agent-driven orders from ordinary web orders. Use the [RFP questions](/learn/agentic-commerce-rfp-questions) to make vendors answer these directly. ## The evidence record A defensible transaction record should include the user's authorization, any signed receipt returned for it, the agent or platform identity, the constraints, the cart and total, the shipping and tax state, policy links, the payment artifact, the order state, and any later refund or dispute event. This is why authorization is not only a payment problem. It is also a logging, customer-service, fraud, and governance problem. ## FAQ **How does an AI shopping agent prove authorization?** With a signed, scoped record of authorization. AP2 calls this a mandate; ACP uses a Shared Payment Token for the payment handoff; network programs use registered agents, tokenized credentials, and customer controls. **Is giving an agent a card number safe?** The safer model is not to give the raw card number to the agent. A scoped token limits reuse and keeps card details out of the agent's hands. **Who is liable if an agent buys the wrong thing?** The rules are not settled across the industry. Merchants should read terms and keep transaction evidence. American Express has pledged to protect card members from charges resulting from registered agent error, but there is not yet one cross-network rulebook, and AP2 deliberately produces evidence rather than allocating liability. **What should merchants log?** Authorization, the signed receipt for it, agent identity, constraints, cart, price, taxes, shipping, policy links, payment artifact, order status, and exceptions. Primary sources: - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - AP2 protocol documentation: https://ap2-protocol.org/ - Stripe and OpenAI launch Instant Checkout: https://stripe.com/newsroom/news/stripe-openai-instant-checkout - Visa Intelligent Commerce launch: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Mastercard unveils Agent Pay: https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - American Express debuts Agentic Commerce Experiences (ACE) Developer Kit: https://www.americanexpress.com/en-us/newsroom/articles/innovation/american-express-debuts-agentic-commerce-experiences--ace--devel.html - AP2 specification v0.2 (dispute evidence, verification rules): https://ap2-protocol.org/ap2/specification/ - AP2 executive summary (accountability as an open question): https://ap2-protocol.org/overview/ --- # AP2 Explained: The Agent Payments Protocol URL: https://agenticcommerceatlas.com/learn/ap2-explained Markdown URL: https://agenticcommerceatlas.com/learn/ap2-explained.md Section: learn Updated: 2026-10-01 The Agent Payments Protocol (AP2) tackles the hardest question in agentic commerce: when a piece of software buys something for you, how does a merchant or bank know you actually authorized that specific purchase, and who is liable if it goes wrong? AP2 is the payment-authorization and trust layer, not a checkout or discovery protocol. ## Who is behind it, and the move to FIDO AP2 was **announced by Google on 16 September 2025**, presented as the work of a diverse group of "more than 60 organizations" and licensed under Apache 2.0. Named partners in the announcement included Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, Salesforce, Intuit, JCB, and UnionPay International, among others. Neither **Visa** nor **Stripe** was named in that launch group. The governance has since shifted. On **28 April 2026, Google donated AP2 to the FIDO Alliance**, releasing **v0.2** on GitHub the same day. The specification now advances through two FIDO working groups: the Payments Technical Working Group, chaired by members from Mastercard and Visa, which is where AP2 itself is being developed into a specification, and a new Agentic Authentication Technical Working Group, chaired at launch by members from CVS Health, Google, and OpenAI and vice-chaired by members from Amazon, Google, and Okta. Alongside AP2, Mastercard contributed **Verifiable Intent**, an AP2-compatible framework it co-developed with Google that creates a tamper-evident record of user-authorized agent actions. Google still maintains the reference implementation and SDK, but the normative standard now sits with a neutral body. So calling AP2 "a Google protocol" today is imprecise: it originated at Google and is now under FIDO stewardship. One nuance is easy to miss and worth stating plainly: **FIDO has not published an agentic payments specification of its own.** Its announcement describes AP2 and Verifiable Intent as initial contributions that "will be reviewed and further developed through the FIDO Alliance's collaborative standards process." So what exists today is still AP2 v0.2 on GitHub, not a FIDO standard, and whatever FIDO eventually publishes may draw on both contributions rather than adopting either as written. If you are choosing what to build against now, build against v0.2 and expect movement. ### Where Visa and Stripe actually sit The "Visa and Stripe are absent" reading was accurate for the September 2025 launch list and is worth handling carefully now, because the two companies are in different positions. **Visa** is no longer outside AP2's governance. It co-chairs the FIDO Payments Technical Working Group that is developing the AP2 contribution, and Visa gave a supporting statement in FIDO's own announcement. Visa also runs its own program, Visa Intelligent Commerce, whose Intelligent Commerce Connect on-ramp is described as network, protocol, and token-vault-agnostic; Visa's announcement names the Trusted Agent Protocol, MPP, ACP, and UCP as supported agent protocols, and does not name AP2. **Stripe** remains outside AP2. It is not in the launch group, not in the FIDO contribution, and it backs different layers: [ACP](/learn/acp-explained) with OpenAI for checkout, and [MPP](/learn/mpp-explained) with Tempo for machine payments. Both companies are, however, **premier members of the x402 Foundation**, which the Linux Foundation launched operationally on 14 July 2026 with 40 members at launch. So are Google, Mastercard, American Express, Adyen, AWS, and Shopify. The practical read is that the major players are not lining up behind one authorization standard and against another; they are joining several bodies at once and hedging across rails. ## The mandate model The core idea is a **mandate**: a cryptographically signed, tamper-evident verifiable credential that captures authorization in a way a merchant or network can verify and later use as dispute evidence. The exact model has evolved, and it is worth knowing both versions because secondary write-ups often quote the old one as if it were current. The **original (v0.1) model** used three mandates. An **Intent Mandate** captured the user's high-level instructions and constraints, such as a category, a price ceiling, and timing, and was used especially for purchases made when the user is not present. A **Cart Mandate** captured the finalized cart, the exact items and amount, signed by the user for purchases made when they are present. A **Payment Mandate** was shared with the network and issuer to signal that an agent was involved and whether a human was present. The **current (v0.2) model** reorganizes this into verifiable digital credentials with two primary types, each having an open and a closed stage. A **Checkout Mandate** covers pre-cart constraints (open) and authorization of a finalized cart (closed). A **Payment Mandate** covers instrument and budget constraints (open) and authorization of a specific amount bound to a finalized checkout (closed). If you describe the older "Intent, Cart, Payment" framing, label it as the launch model. The headline change in v0.2 is **Human Not Present** payments: the open mandates let an agent execute a purchase autonomously, within constraints the user signed earlier, when the user is not in the session. Google's example is buying limited-run tickets the moment they go on sale. Each mandate is now also paired with a signed **receipt**, so the verifier's accept or reject decision is itself part of the record. Across both versions the mechanism is the same: signatures use hardware-backed device keys with in-session authentication, and the chain from intent through cart to payment forms a non-repudiable audit trail used for authorization, authenticity, and resolving disputes. For the credential structure, the SD-JWT signing and verification, and a worked SDK example, see [AP2 mandates in practice](/learn/ap2-mandates-in-practice). ## How it relates to the other standards AP2 is built as an extension of **A2A**, the agent-to-agent protocol, and is positioned to work with **MCP** as well. For the commerce side of a transaction, Google pairs AP2 with its **Universal Commerce Protocol (UCP)**: AP2's own FAQ describes UCP as orchestrating the broader purchase lifecycle while AP2 is the specialized layer that authorizes and signs the payment. For how AP2 compares with the card networks' own agent-payment programs, see [AP2 vs network tokens](/learn/ap2-vs-network-tokens). For crypto and machine-to-machine payments, Google built the **A2A x402 extension** with Coinbase, the Ethereum Foundation, and MetaMask, aligning AP2 with the x402 stablecoin approach. Regarding [ACP](/learn/acp-explained), the OpenAI and Stripe checkout standard, no primary AP2 source mentions it directly; the popular "AP2 versus ACP" framing comes from commentary rather than the standards bodies themselves. ## Status and honest limitations As of mid-2026, AP2 is best understood as **pre-production**. Primary sources describe reference implementations, SDKs, and sample scenarios that mock real payment providers, not documented live, real-money deployments. With the standard now mid-flight into FIDO, the normative spec is early-stage and actively in committee. The primary materials are also candid about open problems. **Trust bootstrapping is still being worked out.** v0.2 defines two models for deciding whose signature a verifier should trust: a *User Credential* model, where an external issuer the verifier already trusts vouches for the surface that captured consent, and a *Trusted Agent Provider* model, where the verifier trusts the agent's provider directly. The specification is explicit that the second model is simpler but "requires Verifiers to establish trust with every Agent Provider," which is the allow-list problem in a new form. **AP2 does not allocate liability, and does not claim to.** Its own materials pose accountability as an unanswered question, asking whether the user, the agent's developer, the merchant, the issuer, the PSP, or the orchestration layer is responsible when something goes wrong. What the protocol offers instead is evidence: the stated objective is "to provide supporting evidence that helps payment networks establish accountability and liability principles." Be precise about the scope boundary, because it is narrower than it is often reported. v0.2 does specify dispute evidence, and its verification rules for a dispute are mandatory: the hash of the `checkout_jwt` must be independently computed, and the Checkout Receipt and Payment Receipt references must match the hashes of the closed Checkout and Payment Mandates. What sits outside the specification is how that evidence is then used for dispute resolution, and the retention and retrieval requirements around it. Actual liability still rests on each network's rules. **Payment-type coverage is partial.** Cards are supported and stablecoins are handled through the x402 extension. v0.2 added constraint types for recurring agent use (`payment.agent_recurrence`, `payment.budget`) and for open-banking payment initiation providers (`payment.allowed_pisps`), but AP2's own documentation still describes e-wallets and push payments such as real-time bank transfers (UPI, PIX) as roadmap rather than shipped. ## What it means for you If you are a merchant or a payments team, AP2 is the leading candidate for the authorization-and-trust layer, and its move to FIDO makes it more likely to become a genuine cross-industry standard rather than one vendor's framework. If you are a builder, treat AP2 as the proof-of-authorization layer that sits underneath a checkout protocol, and watch the FIDO working groups for where the spec actually lands. Either way, do not assume it is in production yet. ## FAQ **Is AP2 still a Google protocol?** It originated at Google in September 2025, but Google donated it to the FIDO Alliance on 28 April 2026, where the spec is now developed. Calling it simply a Google protocol is out of date. **What is a mandate?** A cryptographically signed verifiable credential that records authorization. The model moved from Intent, Cart, and Payment mandates to a Checkout Mandate and a Payment Mandate, each with open and closed stages. **Does AP2 compete with ACP?** They sit at different layers, authorization versus checkout, and the standards bodies do not frame them as rivals. Neither Visa nor Stripe was in AP2's September 2025 launch group, but Visa now co-chairs the FIDO working group developing AP2, and both are premier members of the x402 Foundation. Primary sources: - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - AP2 official documentation and FAQ: https://ap2-protocol.org/ - AP2 specification (current): https://ap2-protocol.org/ap2/specification/ - Donating the Agent Payments Protocol to the FIDO Alliance (AP2 v0.2 release): https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/ - FIDO Alliance to develop standards for trusted AI agent interactions: https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/ - AP2 v0.2.0 release: https://github.com/google-agentic-commerce/AP2/releases - AP2 FAQ (AP2 and UCP, accountability): https://ap2-protocol.org/faq/ - Linux Foundation announces operational launch of the x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - A2A x402 extension: https://github.com/google-agentic-commerce/a2a-x402 - FIDO Alliance to Develop Standards for Trusted AI Agent Interactions: https://www.businesswire.com/news/home/20260427506015/en/FIDO-Alliance-to-Develop-Standards-for-Trusted-AI-Agent-Interactions - Verifiable Intent specification (Draft v0.1): https://github.com/agent-intent/verifiable-intent --- # AP2 Mandates in Practice: Credential Structure, Signing, and Verification URL: https://agenticcommerceatlas.com/learn/ap2-mandates-in-practice Markdown URL: https://agenticcommerceatlas.com/learn/ap2-mandates-in-practice.md Section: learn Updated: 2026-10-01 [AP2](/learn/ap2-explained) answers one question: when a piece of software buys something for you, how does a merchant or bank get cryptographic proof that you authorized this specific purchase? The answer is the **mandate**, a signed, tamper-evident credential. This page is the practical companion to the conceptual overview: what a mandate actually contains, how it is signed and verified, and how the human-present and human-not-present flows differ in the data. It reflects AP2 v0.2, released on 28 April 2026 and still the current version. One caveat before the detail: AP2 is still pre-production. The v0.2 release ships an SDK, JSON schemas, and runnable sample scenarios, but the public materials are reference implementations rather than documented live deployments. Build against the v0.2 schemas, and be aware the repository also contains an older model layer (intent and cart mandates) that should not be used for new work. ## Two mandates, two states AP2 v0.2 has two mandate types, and each exists in two states. The **Checkout Mandate** is about what is being bought: the cart, the merchant, the terms. The **Payment Mandate** is about what will be charged: the amount, the instrument, the payee. Splitting them lets the parties who need each one see only that one. The two states are the important part for agents. A **closed** mandate authorizes one specific action; it is the final, transaction-bound proof. An **open** mandate sets constraints on future actions an agent may take on the user's behalf, for example a spending cap or an allowed list of merchants. Open mandates are what make a human-not-present purchase possible: the user signs the constraints once, and the agent later produces a closed mandate that must fall within them. Each is identified by a `vct` (verifiable credential type) value: `mandate.checkout.1` and `mandate.checkout.open.1` for checkout, `mandate.payment.1` and `mandate.payment.open.1` for payment. The numeric suffix is a schema version number, and the specification requires implementations to match the exact `vct` string including that suffix, so a future incompatible revision would ship as `.2` and simply fail to match rather than being silently misread. ## What a closed mandate contains A closed Checkout Mandate carries the merchant-signed checkout and a hash that uniquely identifies it: ```json { "vct": "mandate.checkout.1", "checkout_jwt": "", "checkout_hash": "", "iat": 1781200000, "exp": 1781203600 } ``` A closed Payment Mandate authorizes the charge and binds itself to that checkout by reusing its hash as the `transaction_id`: ```json { "vct": "mandate.payment.1", "transaction_id": "", "payee": { "id": "M-1", "name": "Cat Store", "website": "https://catstore.example" }, "payment_amount": { "amount": 27999, "currency": "USD" }, "payment_instrument": { "id": "pi_123", "type": "card", "description": "Visa ending 4242" } } ``` Two details matter for implementers. Amounts are integers in minor units, so `27999` means 279.99 dollars. And the link between the two mandates is cryptographic: the Payment Mandate's `transaction_id` is the hash of the merchant-signed `checkout_jwt`, so a payment authorization cannot be detached from the exact checkout it was meant for. ## What an open mandate adds: constraints An open mandate replaces a specific action with a set of constraints plus a key-binding claim (`cnf`) that names the public key allowed to produce the eventual closed mandate. An open Payment Mandate might say "this agent may spend up to 50 dollars at these merchants": ```json { "vct": "mandate.payment.open.1", "constraints": [ { "type": "payment.amount_range", "currency": "USD", "max": 5000 }, { "type": "payment.allowed_payees", "allowed": [ { "id": "M-1", "name": "Cat Store" } ] } ], "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } } } ``` The constraint vocabulary is specific. The Payment Mandate defines eight constraint types: `payment.amount_range`, `payment.budget`, `payment.allowed_payees`, `payment.allowed_payment_instruments`, `payment.allowed_pisps`, `payment.agent_recurrence` (with a `frequency` from `ON_DEMAND` through `ANNUALLY` and an optional `max_occurrences`), `payment.execution_date`, and `payment.reference`, which pins a Payment Mandate to one particular open Checkout Mandate by digest. The Checkout Mandate defines two: `checkout.allowed_merchants` and `checkout.line_items`. A closed mandate that does not satisfy the open mandate's constraints is invalid, and a verifier that meets a constraint type it does not recognize must treat it as failing rather than ignore it. ## Signing: a chain of SD-JWTs Mandates are not plain JWTs. They are **SD-JWT verifiable credentials**, which add two properties AP2 needs: selective disclosure, so a party sees only the fields it should, and key binding, so possession of a private key proves the right to act. Keys are EC P-256 and signatures are ES256. One signing rule is easy to miss and worth getting right. The Payment Mandate binds itself to the checkout by hashing the merchant-signed checkout JWT, and that hash is only unguessable if the signature it covers carries entropy of its own. So the specification requires the **checkout JWT** to be signed with a non-deterministic scheme such as ECDSA rather than a deterministic one such as Ed25519, specifically to prevent rainbow-table attacks on the checkout contents. If you do use a deterministic scheme, the specification requires you to add a salt of sufficient entropy to the checkout instead. Delegation is expressed as a chain of arbitrary depth. The root SD-JWT is signed by a root of trust, in AP2 typically the user's bank or agent provider, and carries a `cnf` claim naming the key allowed to sign the next hop. Each subsequent hop is a key-binding SD-JWT signed by that key. Intermediate hops use header `typ` of `kb+sd-jwt+kb` and carry their own `cnf`; the final closed mandate uses `kb+sd-jwt` and must not carry one, which is what makes it terminal. On the wire the hops are joined by a double tilde (`~~`). The merchant separately signs the checkout payload itself (the `checkout_jwt`). The result is a credential that records not just an authorization but the whole delegation path that produced it.
  1. 1RootRoot of trust

    The bank or provider signs the root credential.

    root SD-JWT
  2. 2OpenOpen mandate

    The user signs constraints and an allowed key.

    open + cnf
  3. 3ClosedClosed mandate

    The agent signs the exact action, key-bound to the open mandate.

    closed (KB)
  4. 4VerifyVerify

    Trust the root key; each hop checks the previous one.

    follow the chain
Each hop is signed by the key the previous hop authorized, so the closed mandate carries its whole delegation path.
## Verification: trust the root, follow the chain Verification is the mirror image, and it is simple to state. The verifier trusts only the root issuer key. It then validates every hop using the public key bound in the previous hop's `cnf`, and checks that the closed mandate's `sd_hash` binds the entire preceding chain. If every link holds and the closed mandate satisfies the open mandates above it, the authorization is valid. The Payment Mandate's binding to the `checkout_jwt` hash is checked at the same time, so a verifier knows the payment and the cart belong together. In practice you do not implement SD-JWT by hand. The AP2 SDK provides a `MandateClient` with `create`, `present`, and `verify`: ```python # uv pip install git+https://github.com/google-agentic-commerce/AP2.git@main from ap2.sdk.mandate import MandateClient client = MandateClient() # The user (or their provider) issues an open mandate constraining the agent. open_token = client.create( payloads=[open_payment_mandate], # the v0.2 model shown above issuer_key=issuer_jwk, # EC P-256 root-of-trust key ) # Later, the agent presents a closed mandate as a new hop in the chain, # bound to this transaction by nonce and audience. chain = client.present(holder_key=agent_jwk, mandate_token=open_token, payloads=[closed_payment_mandate], nonce="tx_abc", aud="merchant") # The merchant or network verifies, trusting only the root issuer key. payloads = client.verify( token=chain, key_or_provider=lambda token: issuer_jwk, expected_aud="merchant", expected_nonce="tx_abc", ) ``` Two things are worth doing rather than skipping. Pass `expected_aud` and `expected_nonce`: without them the final hop's transaction binding is not enforced. And feed the returned payloads to `PaymentMandateChain.parse` or `CheckoutMandateChain.parse` and call `verify(...)`, which is what actually evaluates the constraints; `MandateClient.verify` checks the cryptography, not the business rules. Use the v0.2 models under the SDK's generated package and the canonical JSON schemas, not the older `ap2.models` shapes, which are the superseded intent-and-cart design. ## Receipts: the other half of the record A mandate proves what was authorized. A **receipt** proves what the verifier did about it, and v0.2 makes receipts mandatory rather than optional: on accepting or rejecting a mandate, the verifier must return a signed receipt. The Merchant returns a Checkout Receipt, the Merchant Payment Processor returns a Payment Receipt. A receipt is a verifier-signed JWT carrying a `status` of `Success` or `Error`, the issuer, a timestamp, and a `reference` that is the hash of the closed mandate it is binding to. Payment Receipts add a `payment_id` and, on success, `psp_confirmation_id` and `network_confirmation_id`; Checkout Receipts add an `order_id`. In the SDK this is `ReceiptClient`, and the canonical reference is computed the same way every time, as the SHA-256 of the leaf JWT of the chain: ```python reference = compute_sha256_b64url(client.get_closed_mandate_jwt(chain)) ``` Receipts are not bookkeeping. They are load-bearing in two places. The specification's double-spend rule says a shopping agent must not present a further mandate against the same open mandate until it has received a receipt rejecting the previous one, so receipts are the mechanism that stops one open mandate authorizing two carts. And at dispute time the evidence bundle is mandate *and* receipt on both sides: the checkout mandate with its receipt, the payment mandate with its receipt, each receipt's `reference` independently recomputed and matched. AP2 stops there, though. It states plainly that retention, retrieval, and how any of this is used to resolve a dispute are outside its scope. ## Human-present versus human-not-present, in the data This is where the open and closed states pay off. A verifier always receives a closed Checkout Mandate and a closed Payment Mandate, regardless of how the purchase happened. The difference is who signed the closed mandate. In the **human-present** (direct) flow, the user sees the final checkout and signs the closed mandates themselves. There is no open mandate in the chain; trust comes directly from the user's signature. In the **human-not-present** (autonomous) flow, the user is not there at the moment of purchase. They earlier signed open mandates that set constraints, and the agent now assembles and signs the closed mandates on their behalf, using the key the open mandate authorized through its `cnf`. Trust is transitive: the verifier trusts the agent's closed mandate because it sits in a chain rooted in the user's signed constraints. The data signal for this flow is the presence of an open mandate (a `vct` ending in `.open.1`, carrying a `cnf`) in the chain. The two are convertible: a merchant can turn an autonomous flow into a present one by returning an unresolved-constraint error that forces the user back into the loop. ## How this connects to getting paid A closed Payment Mandate is the proof a credential provider, network, or processor needs to release funds. In practice the credential provider verifies the Payment Mandate before returning a scoped payment credential, and the specification is strict about the ordering: the credential or token must only be released to the merchant once a final Payment Mandate has been received and verified, which is what binds the token to that one transaction. The merchant payment processor then has to satisfy itself that the credential it received is correctly scoped to the checkout before the money moves. One naming trap for anyone reading the spec alongside the rest of this site: **AP2 uses "MPP" to mean Merchant Payment Processor**, one of its five roles. That is not the [Machine Payments Protocol](/learn/mpp-explained), the Stripe and Tempo standard that shares the abbreviation. AP2's other four roles are the Shopping Agent, the Credential Provider, the Merchant, and the Trusted Surface, the last of which must be non-agentic because it is the surface that captures user consent. So AP2 produces the authorization, and the payment rails consume it. For the wider money mechanics, see [how AI agents pay](/learn/how-ai-agents-pay), and for where AP2 sits among the other standards, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **What is an AP2 mandate, concretely?** A signed, tamper-evident credential expressed as an SD-JWT verifiable credential. There are two types, Checkout and Payment, each in two states: an open mandate that constrains future actions and a closed mandate that authorizes one specific action. **How is a mandate signed and verified?** With SD-JWT verifiable credentials using EC P-256 keys and ES256 signatures, chained for delegation and joined on the wire by a double tilde. A verifier trusts only the root issuer key; each hop is validated by the previous hop's `cnf` key, and the closed mandate's hash binds the whole chain. **How do the human-present and human-not-present flows differ?** The verifier always gets closed Checkout and Payment mandates. In the present flow the user signs the closed mandate; in the not-present flow an agent signs it, with trust supplied by open mandates the user signed earlier. **What is an AP2 receipt?** The verifier's signed answer to a mandate, required on accept or reject: a Checkout Receipt from the merchant, a Payment Receipt from the merchant payment processor. Each carries a `Success` or `Error` status and a `reference` that is the hash of the closed mandate. Receipts are what stop one open mandate authorizing two carts, and the dispute bundle is mandate plus receipt on both sides. **Is AP2 production-ready?** It reached v0.2 on 28 April 2026 with an SDK, schemas, and sample scenarios in Python, Go, and Android, but it remains pre-production, with reference implementations rather than documented live real-money deployments. The repo also holds an older model layer that should not be used for new work. Primary sources: - AP2 protocol documentation: https://ap2-protocol.org/ - Agent Payments Protocol (AP2) repository, v0.2: https://github.com/google-agentic-commerce/AP2 - AP2 specification v0.2 (roles, modes, mandate versioning, dispute evidence): https://ap2-protocol.org/ap2/specification/ - AP2 agent authorization framework (SD-JWT, key binding, verification rules): https://ap2-protocol.org/ap2/agent_authorization/ - AP2 Checkout Mandate schema, constraints, and receipt: https://ap2-protocol.org/ap2/checkout_mandate/ - AP2 Payment Mandate schema, constraints, and receipt: https://ap2-protocol.org/ap2/payment_mandate/ - AP2 Python SDK API reference (MandateClient, ReceiptClient, wire format): https://github.com/google-agentic-commerce/AP2/blob/main/code/sdk/python/ap2/sdk/README.md --- # AP2 vs Network Tokens: An Open Standard or the Card Networks' Own Rails? URL: https://agenticcommerceatlas.com/learn/ap2-vs-network-tokens Markdown URL: https://agenticcommerceatlas.com/learn/ap2-vs-network-tokens.md Section: learn Updated: 2026-10-01 AP2 and the card networks' agent-payment programs both answer the same hard question, how a merchant or bank can trust that an agent is genuinely authorized to pay for a specific purchase, but they come at it from different directions. **AP2**, the Agent Payments Protocol, is an open, network-agnostic standard: it proves consent with cryptographically signed mandates, and it does not care which rails the money rides. The **network programs**, Visa Intelligent Commerce, Mastercard Agent Pay, and American Express's agentic offering, are each network's own end-to-end approach, built on their existing tokenization and verification and tied to their own rails. The neat framing of "open standard versus proprietary networks" is real, but the more important story is that the two are converging. ## At a glance | | AP2 | Network programs | |---|---|---| | What it is | Open authorization standard | Each network's own agent-payment rails | | Backers | Google, now the FIDO Alliance | Visa, Mastercard, American Express (separately) | | Scope | Proving the user approved the purchase | Tokenization, verification, and settlement on the network | | Approach | Network-agnostic, open spec | Network-specific, proprietary | | Mechanism | Signed mandates (verifiable credentials) | Agentic and network tokens, passkeys, registered agents | | Status | Pre-production (v0.2, April 2026) | Mostly pilot or closed beta | | Liability | Produces evidence; allocates nothing | Amex has made the most concrete pledge | ## What each one is AP2 is a layer, not a network. It defines how a user's authorization is captured and proven: signed mandates, expressed as verifiable credentials, that a merchant, network, or bank can check to confirm a real person consented to this specific charge. It is deliberately network-agnostic, so the same authorization can in principle work across any rail. For the detail, see [AP2 explained](/learn/ap2-explained) and, for the credential mechanics, [AP2 mandates in practice](/learn/ap2-mandates-in-practice). The network programs are broader and proprietary. **Visa Intelligent Commerce** opens Visa's network to agents through tokenized "AI-Ready Cards" and, since 8 April 2026, an "Intelligent Commerce Connect" on-ramp reached through a single Visa Acceptance Platform integration. **Mastercard Agent Pay** uses Mastercard Agentic Tokens, built on the tokenization behind contactless and Mastercard Payment Passkeys, and requires agents to be registered and verified. **American Express** entered on 14 April 2026 with an Agentic Commerce Experiences (ACE) developer kit and Amex Agent Purchase Protection, which it describes as an industry-first commitment to protect card members from charges resulting from registered agent error. Each bundles agent verification, tokenization, and settlement on its own rails. The directory of who does what is in [the landscape](/landscape/agentic-commerce-landscape), and the mechanics are in [how AI agents pay](/learn/how-ai-agents-pay). ## The key difference: a layer versus a network AP2 occupies one layer, authorization, and stops there. The network programs span authorization-like verification, tokenization, and settlement, all inside one network. So they are not strictly like-for-like: AP2 is a piece that composes with rails, while a network program is the whole pipe for that network. The reason they get compared is that both are trying to own "how an agent proves it is allowed to pay," and a merchant choosing how to support agent payments has to weigh an open standard against the networks' own end-to-end offerings. ## Where they overlap, and why they are converging This is the part that gets missed. AP2 and the networks are moving toward each other, not away, though the convergence is further along in governance than in product. The governance side is unambiguous. Google donated AP2 to the **FIDO Alliance** on 28 April 2026, and the group developing it is FIDO's Payments Technical Working Group, chaired by members from **Mastercard and Visa**. Visa also gave a supporting statement in FIDO's own announcement. So the open standard's stewardship now runs through the networks themselves. Separately, Visa, Mastercard, American Express, Google, Stripe, Adyen, AWS, and Shopify are all premier members of the **x402 Foundation**, which the Linux Foundation launched operationally on 14 July 2026 with 40 members at launch. The same names keep appearing in every body. The product side is more cautious. Visa's Intelligent Commerce Connect is described as network, protocol, and token-vault-agnostic, but the agent protocols Visa's own announcement names are the Trusted Agent Protocol, the Machine Payments Protocol, ACP, and UCP. **AP2 is not among them.** Read the on-ramp as genuinely multi-protocol in design, without assuming AP2 support that Visa has not announced. Expect interoperability over time, not a clean either-or, and not a completed one. ## Status and liability Both are early, but in different ways. AP2 has no stable release: it ships schemas and sample scenarios that mock actual payment service providers, the SDK and MCP server are described by the project as still being worked on, and no PyPI package has been published, so the public materials are reference implementations rather than documented live deployments. It also does not allocate liability at all. AP2's stated objective is to "provide supporting evidence that helps payment networks establish accountability and liability principles," and while v0.2 does specify dispute evidence and mandatory verification rules, it puts the use of that evidence for dispute resolution, and the retention and retrieval requirements, outside its scope. The signed mandates and receipts are evidence for someone else's rulebook rather than a rulebook themselves. The network programs are mostly in pilot or closed beta, but they come with the networks' existing rules and, in American Express's case, the most concrete consumer-protection pledge any player has made so far. For the unsettled liability picture across the board, see [agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness). ## Which matters for you For a builder, AP2 is the open authorization layer you can target without committing to a single network, and it is the safer bet for cross-network portability. For a merchant, the network programs are how agent payments actually reach Visa, Mastercard, and Amex cardholders, and they carry the verification requirements and liability terms you will live with. The practical posture is to treat AP2 as the open standard worth building toward and the network programs as the rails you read the fine print on, while watching the two converge through FIDO and protocol-agnostic on-ramps. ## FAQ **What is the difference between AP2 and network tokens?** AP2 is an open, network-agnostic standard for proving a user authorized an agent's purchase, using signed mandates. The network programs are each network's own end-to-end approach, built on their tokenization and verification and tied to their rails. **Do they compete?** Less than it appears. AP2 went to the FIDO Alliance, where members from Mastercard and Visa chair the payments group developing it, and Visa's on-ramp is protocol-agnostic by design, though the protocols Visa names are the Trusted Agent Protocol, MPP, ACP, and UCP rather than AP2. Converging, but in governance ahead of product. **Which matters for a merchant?** Both. AP2 is the open authorization layer to build toward; the network programs are how agent payments reach cardholders and carry the concrete liability and protection terms. Primary sources: - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - FIDO Alliance to develop standards for trusted AI agent interactions: https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/ - Visa Intelligent Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Mastercard Agent Pay: https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - Visa Opens the Door to AI-Driven Shopping for Businesses Worldwide (Intelligent Commerce Connect): https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22276.html - American Express debuts Agentic Commerce Experiences (ACE) Developer Kit and Agent Purchase Protection: https://www.americanexpress.com/en-us/newsroom/articles/innovation/american-express-debuts-agentic-commerce-experiences--ace--devel.html - Linux Foundation announces operational launch of the x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications --- # How AI Agents Pay URL: https://agenticcommerceatlas.com/learn/how-ai-agents-pay Markdown URL: https://agenticcommerceatlas.com/learn/how-ai-agents-pay.md Section: learn Updated: 2026-10-01 When an AI agent buys something for you, four problems have to be solved at once: the payment credential has to reach the merchant without being exposed, the merchant has to know you actually authorized this purchase, the right party has to be on the hook if something goes wrong, and all of it has to happen without a human clicking "buy." This page explains the mechanisms, then the specific products built on them. ## The four mechanisms **Tokenization** is the foundation. Instead of handing an agent a real card number, the networks and processors issue a token bound to a specific authorized agent and to the limits you set. Stripe's Shared Payment Token is the processor-side version: a single-use credential scoped to one merchant and one cart total. **Mandates, or verifiable credentials,** are the trust layer. This is the core of Google's [AP2](/learn/ap2-explained): cryptographically signed, tamper-evident records of what you authorized, which a merchant or bank can verify and later use as dispute evidence. **Passkeys and delegated authority** are how your approval is captured. Mastercard ties its agent tokens to payment passkeys and on-device biometrics; AP2 uses hardware-backed device keys; the Stripe and OpenAI model asks you to confirm each step explicitly. The common thread is strong, device-bound proof that the human, not just the agent, signed off. **Liability handling** is the least settled of the four, and the products differ most here. ## The network and processor products **Visa Intelligent Commerce** opened Visa's network to AI agents, announced on 30 April 2025. It centers on "AI-Ready Cards," which replace card details with tokenized credentials that confirm a chosen agent is authorized to act for the consumer, with spending limits and conditions the consumer sets. Launch collaborators named by Visa included Anthropic, IBM, Microsoft, Mistral AI, OpenAI, Perplexity, Samsung, and Stripe. By a December 2025 update, Visa described hundreds of agent-initiated transactions and a growing partner roster, but the program was still in **closed beta and pilot**, not general availability. On 8 April 2026 Visa added **Intelligent Commerce Connect**, a network, protocol, and token-vault-agnostic "on ramp" that lets merchants accept agent-initiated payments through a single Visa Acceptance Platform integration, working across major agent protocols including the Trusted Agent Protocol, the Machine Payments Protocol, ACP, and UCP. Note that AP2 is not among the protocols Visa names. Visa launched it in pilot with partners including Aldar, AWS, Diddo, Highnote, Mesh, Payabli, and Sumvin. Visa's own announcement said only that it would reach more partners during the year; trade reporting at the time pointed to general availability around the end of June 2026, but **as of August 2026 Visa has not published a first-party confirmation that Connect has reached general availability**, so treat it as still rolling out. Visa also led a separate effort, the Trusted Agent Protocol, to help merchants tell legitimate agents from bots. **Mastercard Agent Pay** was announced a day earlier, on 29 April 2025. It uses Mastercard Agentic Tokens, built on the same tokenization behind contactless and Mastercard Payment Passkeys, and requires agents to be registered and verified before they can pay, with consumers setting controls over what an agent may buy. Named partners included Microsoft, IBM, Braintree, and Checkout.com. **American Express** entered later, on 14 April 2026, with two things together: an Agentic Commerce Experiences (ACE) developer kit and Amex Agent Purchase Protection, which Amex describes as an industry-first commitment to protect card members from charges resulting from registered AI agent error. That pledge is the most concrete liability stance any network has made, though note its scope: agent error on Amex's own closed-loop network, not a general chargeback framework. The developer kit went to select partners first, so this is early-stage rather than broadly available. **PayPal** plays a dual role: it is an AP2 launch partner, announced on 16 September 2025, and it offers an agent toolkit and remote MCP server so businesses can build agentic experiences on PayPal's APIs. Its AP2 work maps the protocol's mandates, expressed as W3C verifiable credentials, onto PayPal's wallet, checkout, and dispute workflows, though much of it is framed as architecture and intent rather than shipped features. **Stripe** co-developed the [Agentic Commerce Protocol](/learn/acp-explained) with OpenAI and powers Instant Checkout in ChatGPT, which is the single most concretely live consumer-facing agentic payment flow in this list. Its mechanism is the Shared Payment Token described above, launched on 29 September 2025 for US buyers. ## Stablecoins and the machine-to-machine rail For payments between software rather than consumer checkout, the leading approach is **x402**, an open protocol from Coinbase that revives the dormant HTTP "402 Payment Required" status code to let software settle in stablecoins such as USDC directly over the web, with no accounts or card credentials. A buyer requests a resource, the server responds with payment instructions, the buyer returns a signed payment, and a facilitator verifies and settles the transaction on-chain. In September 2025, Coinbase and Cloudflare announced an x402 Foundation to steward it as a neutral standard, and Google aligned it with AP2 through the A2A x402 extension. That foundation is no longer just an announcement. On **14 July 2026 the Linux Foundation launched the x402 Foundation operationally**, with Coinbase's contribution of the protocol complete and 40 member organizations. Its premier members, who hold governing-board seats, include Visa, Mastercard, American Express, Stripe, Google, Adyen, AWS, Shopify, Circle, Cloudflare, Coinbase, Fiserv, and Ripple. That membership list is the clearest signal available that the card networks and processors are hedging across rails rather than backing a single standard. x402 is live infrastructure, but it is aimed at agent-to-agent and micro-transaction use cases, not retail checkout. A second machine-native standard arrived in March 2026: the **[Machine Payments Protocol (MPP)](/learn/mpp-explained)**, an open protocol co-authored by **Stripe and Tempo** for agents to pay services programmatically, for things like microtransactions, recurring payments, and paying per API call. An agent requests a resource from a service, API, or MCP endpoint, the service returns a payment request, the agent authorizes it, and the resource is delivered. Stripe lets businesses accept MPP payments through its existing PaymentIntents API, in stablecoins as well as the cards, wallets, and other methods carried by Shared Payment Tokens, so the funds settle into a normal Stripe balance. Like x402, MPP targets the software-to-software lane rather than consumer retail checkout, and Stripe supports both. ## Announced versus live The honest summary is that there is far more announced than live. The genuinely live consumer flow is Stripe and OpenAI's Instant Checkout, and even that started US-only and limited. Visa's and Mastercard's programs are pilots and closed betas. American Express's developer kit reached select partners in April 2026. Across the industry, there have arguably been about as many announcements as real transactions. x402 and MPP are real and running, but in a different lane. Liability deserves a final word because it is what merchants and consumers will care about most. Only American Express has made a concrete pledge, and it covers charges resulting from registered agent error on its own network. AP2 is often described as assigning accountability, and it does not: its own materials pose accountability as an unanswered question, name its objective as providing "supporting evidence that helps payment networks establish accountability and liability principles," and, while specifying dispute evidence and mandatory verification rules, leave the use of that evidence for dispute resolution, and retention and retrieval, outside the specification. Signed mandates and receipts are evidence for someone else's rulebook. No finalized, cross-network rulebook for disputing an agent-initiated purchase exists yet, and that gap, more than any technical one, is what still has to close. ## FAQ **What is actually live versus announced?** The clearest live consumer flow is Stripe and OpenAI's Instant Checkout. Visa and Mastercard are in pilot or closed beta (Visa's Intelligent Commerce Connect on-ramp is still rolling out, with no first-party general-availability confirmation as of August 2026); American Express shipped a developer kit to select partners in April 2026; x402 and MPP are live but for machine-to-machine payments. **How does an agent pay without exposing my card number?** Tokenization. The real card number is replaced by a token bound to a specific authorized agent and your limits; Stripe's Shared Payment Token is single-use and scoped to one merchant and cart total. **Who is liable if an agent buys the wrong thing?** Rules are not settled. Amex has pledged to protect card members from charges resulting from registered agent error; AP2 allocates no liability and instead produces signed evidence for a network to adjudicate on, leaving dispute resolution itself outside its scope; no cross-network chargeback rulebook exists yet. Primary sources: - Visa Intelligent Commerce launch: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Visa agentic commerce milestone: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21961.html - Mastercard unveils Agent Pay: https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - American Express Agentic Commerce Experiences: https://www.americanexpress.com/en-us/newsroom/articles/innovation/american-express-debuts-agentic-commerce-experiences--ace--devel.html - PayPal and the Agent Payments Protocol: https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/ - Stripe and OpenAI launch Instant Checkout: https://stripe.com/newsroom/news/stripe-openai-instant-checkout - Coinbase x402 documentation: https://docs.cdp.coinbase.com/x402/welcome - Coinbase and Cloudflare to launch the x402 Foundation: https://www.coinbase.com/blog/coinbase-and-cloudflare-will-launch-x402-foundation - Visa Opens the Door to AI-Driven Shopping for Businesses Worldwide (Intelligent Commerce Connect): https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22276.html - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - Linux Foundation announces operational launch of the x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - AP2 executive summary (accountability as an open question): https://ap2-protocol.org/overview/ --- # How to Build a Remote MCP Server: A Worked Example URL: https://agenticcommerceatlas.com/learn/build-a-remote-mcp-server Markdown URL: https://agenticcommerceatlas.com/learn/build-a-remote-mcp-server.md Section: learn Updated: 2026-10-01 A remote [Model Context Protocol](/learn/mcp-explained) (MCP) server is, at its simplest, a single web endpoint that speaks JSON-RPC over HTTP and exposes a few tools an AI agent can call. You do not need a framework, a database, or session handling to ship one. This guide builds the smallest useful version end to end, using the server that powers this site as the worked example. It runs as one Cloudflare Worker, holds no data of its own, and is live at `mcp.agenticcommerceatlas.com`. If you just want to connect to it rather than build your own, see [query the Atlas over MCP](/mcp). ## What you are building The Atlas MCP server exposes four read-only tools: `list_protocols`, `get_protocol`, `search_atlas`, and `get_page`. Each one fetches the site's own machine-readable endpoints and returns the result, so the server is a thin proxy with no separate store. The whole thing is one TypeScript file deployed as a stateless Cloudflare Worker. By the end you will have the same shape: a transport, a JSON-RPC handler, tool definitions, and a deploy step. ## The transport, in one paragraph MCP's HTTP transport is called **Streamable HTTP**. The server exposes a single endpoint that supports both POST and GET. The client sends each JSON-RPC message as a POST to that endpoint; the server may reply with a single JSON response or, optionally, stream multiple messages back using Server-Sent Events. Streaming and sessions are optional, so the simplest design is **stateless**: accept a POST, return one JSON response, keep no session. That is all the Atlas server does, which is why it needs no Durable Objects and costs almost nothing to run. > **Which revision this targets.** The code below is the live Atlas server, written against the `2025-06-18` revision, and the design holds through the `2025-11-25` revision. It has not been rewritten for `2026-07-28`, and neither has the live Atlas server. **`2026-07-28` was published as the stable revision on 28 July 2026**, and it broke exactly this layer: the `initialize` handshake and the `Mcp-Session-Id` header were retired, protocol version and client identity moved into `_meta` on every request, an optional `server/discover` method now returns capabilities up front, and `Mcp-Method` and `Mcp-Name` headers became required on Streamable HTTP requests so gateways can route without reading the body. The legacy HTTP+SSE transport was deprecated at the same time, with a twelve-month offramp. The stateless shape this guide argues for is the direction the protocol took, so the architecture stands, but the wire details changed. **If you are building new, target `2026-07-28`**, read the [changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog), and treat the dispatch below as the shape rather than the current method names. ## The JSON-RPC methods you must handle In the revisions this guide targets, an MCP client opens a connection by calling `initialize`, then asks for tools with `tools/list`, then runs them with `tools/call`. Handle those three, plus the `notifications/initialized` notification and `ping`, and a tools-only server is complete. (Under `2026-07-28` there is no handshake to answer, so the equivalent set is `tools/list`, `tools/call`, and an optional `server/discover`.) Here is the Atlas server's entire dispatch: ```ts async function handleRpc(msg, env) { const { id, method, params } = msg; switch (method) { case 'initialize': return rpcResult(id, { protocolVersion: params?.protocolVersion || '2025-06-18', capabilities: { tools: {} }, serverInfo: { name: 'agentic-commerce-atlas', version: '1.0.0' }, instructions: 'Reference for agentic commerce. Use list_protocols and search_atlas to orient, get_protocol and get_page for detail.', }); case 'notifications/initialized': return null; // a notification: no response case 'ping': return rpcResult(id, {}); case 'tools/list': return rpcResult(id, { tools: TOOLS }); case 'tools/call': { const text = await callTool(params?.name, params?.arguments || {}, env); return rpcResult(id, { content: [{ type: 'text', text }] }); } default: return rpcError(id, -32601, `Method not found: ${method}`); } } ``` Two small helpers keep the responses valid JSON-RPC: ```ts const rpcResult = (id, result) => ({ jsonrpc: '2.0', id, result }); const rpcError = (id, code, message) => ({ jsonrpc: '2.0', id, error: { code, message } }); ``` The important details: `initialize` echoes the client's requested protocol version (falling back to the revision you support) and declares `capabilities: { tools: {} }` so the client knows tools are available. `notifications/initialized` is a notification, not a request, so you return nothing. Anything you do not recognize gets a standard `-32601` "method not found" error. ## Defining your tools A tool is a name, a human-readable description, and a JSON Schema for its arguments. The description matters more than it looks: it is what the model reads to decide when to call the tool, so write it for the agent, not for a docs page. Here are two of the Atlas tools: ```ts const TOOLS = [ { name: 'list_protocols', description: 'List the core agentic commerce protocols (ACP, AP2, UCP, MCP, A2A, x402) with maintainer, layer, license, status, and spec URL.', inputSchema: { type: 'object', properties: {}, additionalProperties: false }, }, { name: 'get_protocol', description: 'Get the structured record for one protocol by id (e.g. "acp", "ap2", "ucp").', inputSchema: { type: 'object', properties: { id: { type: 'string', description: 'Protocol id, lowercase.' } }, required: ['id'], additionalProperties: false, }, }, ]; ``` `tools/list` simply returns this array. A tool that takes no arguments still declares an empty object schema, and `additionalProperties: false` keeps clients from sending fields you do not handle. ## Implementing the calls `tools/call` hands you a tool name and an arguments object; you do the work and return text. Because the Atlas server is a thin proxy, each tool is a small fetch against the site's own endpoints: ```ts async function callTool(name, args, env) { const base = siteUrl(env); // e.g. https://agenticcommerceatlas.com switch (name) { case 'list_protocols': return await fetchText(`${base}/data/protocols.json`); case 'get_protocol': { const id = String(args.id || '').toLowerCase(); const data = JSON.parse(await fetchText(`${base}/data/protocols.json`)); const match = (data.protocols || []).find((p) => p.id === id); if (!match) throw new Error(`Unknown protocol "${id}". Try list_protocols.`); return JSON.stringify(match, null, 2); } case 'get_page': { const path = String(args.path || '').replace(/^\/+/, '').replace(/\.md$/, ''); return await fetchText(`${base}/${path}.md`); } // search_atlas scores pages from /llms-full.txt and returns the top matches default: throw new Error(`Unknown tool: ${name}`); } } ``` This is the design choice that pays off most. The server stores nothing; it reads the same `/data/protocols.json`, `/llms-full.txt`, and per-page `.md` files the site already publishes for AI ingestion. When the content changes, the tools return the new content with no sync step. If your data is dynamic, point the same pattern at your own API instead. When a tool fails, return the error inside the result with an `isError` flag rather than throwing out of the response, so the agent sees what went wrong and can recover: ```ts try { const text = await callTool(params.name, params.arguments, env); return rpcResult(id, { content: [{ type: 'text', text }] }); } catch (e) { return rpcResult(id, { content: [{ type: 'text', text: `Error: ${e.message}` }], isError: true }); } ``` ## The HTTP entry point The Worker's `fetch` handler is the transport. It answers CORS preflight, returns a small description on GET, parses the JSON-RPC body on POST (single message or a batched array), and returns `202` when the request contained only notifications: ```ts export default { async fetch(request, env) { if (request.method === 'OPTIONS') return new Response(null, { headers: cors }); if (request.method === 'GET') return new Response(serverInfoJson, { headers: jsonCors }); if (request.method !== 'POST') return new Response('Method Not Allowed', { status: 405 }); const body = await request.json(); const messages = Array.isArray(body) ? body : [body]; const responses = []; for (const msg of messages) { const res = await handleRpc(msg, env); if (res) responses.push(res); } if (responses.length === 0) return new Response(null, { status: 202, headers: cors }); // notifications only const out = Array.isArray(body) ? responses : responses[0]; return new Response(JSON.stringify(out), { headers: jsonCors }); }, }; ``` CORS matters for browser-based clients, so allow the `Content-Type`, `Mcp-Session-Id`, and `Mcp-Protocol-Version` headers even though a stateless server ignores the session id. ## Configure and deploy The Atlas server is a separate Worker with a tiny `wrangler.jsonc`: ```jsonc { "name": "agentic-commerce-atlas-mcp", "main": "src/index.ts", "compatibility_date": "2026-06-18", "compatibility_flags": ["nodejs_compat"], "vars": { "SITE_URL": "https://agenticcommerceatlas.com" } } ``` Deploy from the project folder: ```bash npm install npx wrangler deploy ``` That publishes to `https://..workers.dev`. To put it on a custom subdomain such as `mcp.agenticcommerceatlas.com`, add the route in the Worker's Domains tab in the Cloudflare dashboard. A configuration variable like `SITE_URL` lets you point the same code at a staging site without changing the source. ## Test it List the tools straight from the terminal: ```bash curl -s https://mcp.agenticcommerceatlas.com \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' ``` Call one: ```bash curl -s https://mcp.agenticcommerceatlas.com \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_protocol","arguments":{"id":"ap2"}}}' ``` For an interactive check, point the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) at the endpoint using the Streamable HTTP transport. To use it for real, add it to any MCP-capable client (Claude, Cursor, and others) as a remote HTTP server, as described on the [connect page](/mcp). ## What this example leaves out, and when to add it The server is deliberately minimal, and the gaps are the interesting part. There is no authentication, which is fine for public, read-only content but wrong the moment a tool touches private or per-user data; that is when you add the spec's OAuth flow. There are no sessions and no SSE streaming, which is fine for fast lookups but limiting for long-running tools that should report progress. And the tools return text rather than structured outputs, which is fine for a reference but worth upgrading when a client needs typed results. The MCP spec supports all of these; the lesson is to add them when a tool's job demands it, not by default. On `2026-07-28` the answer for long-running work is the Tasks extension rather than a session, since the protocol core no longer carries one. That is the whole shape of a remote MCP server: a transport, a handful of JSON-RPC methods, tool definitions written for an agent to read, and a deploy. Start with the read-only, stateless version, get it connected to a client, and grow it from there. For where MCP sits among the other agentic commerce standards, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **What is the minimum a remote MCP server has to implement?** Three JSON-RPC methods cover the core: `initialize`, `tools/list`, and `tools/call`. In practice you also handle the `notifications/initialized` notification (reply with nothing) and `ping` (reply with an empty result). That is enough for a tools-only server most clients can connect to. **Do I need Server-Sent Events or sessions?** No. Streamable HTTP allows SSE and sessions, but both are optional. A stateless server can accept a JSON-RPC POST and return a single JSON response, which is the simplest useful design and is what this server does. **Why build it as a thin proxy over your own content?** It removes a class of maintenance. Each tool fetches the site's existing machine-readable endpoints, so when the site updates, the server's answers update with it, with no separate database to sync. **What did this example deliberately leave out?** Authentication and OAuth, sessions, SSE streaming, and structured tool outputs. Add OAuth when tools act on private data, sessions or streaming when a tool is long-running, and structured outputs when clients need typed results. **Which MCP revision does this guide target?** The `2025-06-18` revision the live Atlas server implements, with the design holding through `2025-11-25`. `2026-07-28` was published as the stable revision on 28 July 2026: it retired the `initialize` handshake and `Mcp-Session-Id`, moved protocol version and client identity into `_meta`, added an optional `server/discover`, and made `Mcp-Method` and `Mcp-Name` headers required. The stateless architecture stands; the wire details changed. If you are building new, target `2026-07-28` and read the changelog first. Primary sources: - Model Context Protocol specification: Transports (2025-06-18): https://modelcontextprotocol.io/specification/2025-06-18/basic/transports - Model Context Protocol specification (2025-06-18): https://modelcontextprotocol.io/specification/2025-06-18 - Cloudflare Workers documentation: https://developers.cloudflare.com/workers/ - MCP Inspector: https://github.com/modelcontextprotocol/inspector - The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - MCP specification releases (2026-07-28 stable): https://github.com/modelcontextprotocol/modelcontextprotocol/releases --- # How to Implement ACP: A Merchant Integration Walkthrough URL: https://agenticcommerceatlas.com/learn/implement-acp Markdown URL: https://agenticcommerceatlas.com/learn/implement-acp.md Section: learn Updated: 2026-10-01 Implementing the [Agentic Commerce Protocol](/learn/acp-explained) (ACP) as a merchant comes down to three responsibilities: publish a product feed so agents can find what you sell, host an Agentic Checkout API so an agent can build and complete a cart with you, and accept a Shared Payment Token so you get paid without your store ever touching a card. This guide walks through each, with the real endpoints and payloads from the spec. If you are already on Stripe, which co-authored ACP, most of this is provided and the lift is small; if you are on another processor, you implement the same open spec directly. Throughout, remember the core principle: you stay the merchant of record. ACP standardizes the checkout handshake; it does not take over your store, your fulfillment, your tax, or your customer relationship. > **Which spec revision this targets.** The payloads below were built from the **`2026-01-30`** revision of ACP. The latest stable revision is **`2026-04-17`**. Checked against the `2026-04-17` OpenAPI files, the endpoint set, the status-code behavior, the Shared Payment Token model and the Delegate Payment API are unchanged. Three things to know before you build. First, `Idempotency-Key` is now a **required** header on every POST, not an optional one. Second, `2026-04-17` adds cart, feed, orders, authentication and MCP surfaces that this guide does not cover. Third, the `2026-04-17` OpenAPI file's own example payloads differ in places from the schema shapes introduced in `2026-01-30`, most visibly on `payment_data` (see step 3). Treat the machine-readable spec in `spec/2026-04-17/`, plus your agent platform's and payment provider's own documentation, as authoritative, and validate before you ship. ## How the pieces fit The agent platform (for example ChatGPT) is the client. You, the merchant, are the server. The agent calls endpoints you host to create a checkout session, update it as the buyer chooses options, and complete it. Payment is tokenized by a payment provider into a Shared Payment Token that is scoped to you and to one exact cart total, and that token is handed to you on the final call. You charge it through your processor and return an order. So an ACP integration is a small REST API you implement plus a payment step, not a connection you make to someone else's system. That is what lets one integration work across every agent surface that speaks ACP. ## Step 1: Publish a product feed Before an agent can buy from you, it has to know what you sell. ACP merchants provide a structured product feed: each item with the fields an agent needs to choose and transact, including title, description, price, availability, images, and identifiers. The single most important property of the feed is that it matches your live store exactly. Agents transact against the data you publish, so a price or stock figure that has drifted from reality is the most common cause of a failed or wrong agent checkout. Keep the feed complete, structured, and current; on Stripe and similar platforms, feed syndication is largely handled for you. For the protocol-agnostic detail on getting this right, see [how to prepare your product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce). ## Step 2: Implement the Agentic Checkout API This is the heart of the integration. You host five endpoints under a `/checkout_sessions` base path. Every request carries a few headers. Under `2026-04-17`, four are required: `Authorization` (a bearer API key the agent platform presents, which you verify), `Content-Type: application/json`, `API-Version` (a date such as `2026-04-17`), and `Idempotency-Key` on every POST (an opaque string of up to 255 characters, UUID v4 recommended, scoped to the authenticated identity plus the endpoint). `Accept-Language`, `User-Agent`, `Request-Id`, `Signature`, and `Timestamp` are optional but worth honoring. ``` POST /checkout_sessions create a session -> 201 CheckoutSession POST /checkout_sessions/{checkout_session_id} update a session -> 200 CheckoutSession GET /checkout_sessions/{checkout_session_id} retrieve a session -> 200 CheckoutSession POST /checkout_sessions/{checkout_session_id}/complete complete -> 200 CheckoutSessionWithOrder POST /checkout_sessions/{checkout_session_id}/cancel cancel -> 200 CheckoutSession ``` Note that update is a `POST` to the session path (there is no `PUT` or `PATCH`), and create returns `201` while the rest return `200`. A cancel on a session that is already completed or canceled returns `405`. ### Create a session The agent sends the line items, the settlement currency, and the capabilities it supports. Your job is to price the cart and return a full session. ```json POST /checkout_sessions { "line_items": [ { "item": { "id": "sku_running_shoe_42" }, "quantity": 1 } ], "currency": "usd", "buyer": { "email": "buyer@example.com" }, "fulfillment_details": { "address": { "name": "Jane Doe", "line_one": "185 Berry Street", "city": "San Francisco", "state": "CA", "country": "US", "postal_code": "94107" } } } ``` You respond with a `CheckoutSession`: an `id`, a `status`, the priced `line_items`, the `totals`, the `fulfillment_options` you can offer, any `messages`, your policy `links`, and your `capabilities`. Every monetary `amount` is an integer in minor units, so 4500 means 45.00 dollars. ```json { "id": "cs_01HV3P3ABC123", "status": "ready_for_payment", "currency": "usd", "line_items": [ { "id": "li_001", "item": { "id": "sku_running_shoe_42" }, "quantity": 1, "totals": [{ "type": "subtotal", "display_text": "Subtotal", "amount": 12000 }] } ], "fulfillment_options": [ { "type": "shipping", "id": "ship_standard", "title": "Standard (3-5 days)", "totals": [{ "type": "fulfillment", "display_text": "Shipping", "amount": 0 }] } ], "totals": [ { "type": "subtotal", "display_text": "Subtotal", "amount": 12000 }, { "type": "tax", "display_text": "Tax", "amount": 1080 }, { "type": "total", "display_text": "Total", "amount": 13080 } ], "messages": [], "links": [{ "type": "return_policy", "url": "https://store.example.com/returns" }], "capabilities": {} } ``` ### The session lifecycle The `status` field drives the whole flow, and it is worth implementing as a state machine. The spec defines these values: `incomplete`, `not_ready_for_payment`, `requires_escalation`, `authentication_required`, `ready_for_payment`, `pending_approval`, `complete_in_progress`, `completed`, `canceled`, `in_progress`, and `expired`. The agent will not attempt payment until you report `ready_for_payment`, so your pricing, fulfillment, and validation logic should resolve the session to that status (or surface a clear message explaining what is missing). ### Update a session As the buyer chooses a shipping option or signs in, the agent posts a partial update. For example, selecting a fulfillment option: ```json POST /checkout_sessions/cs_01HV3P3ABC123 { "selected_fulfillment_options": [ { "type": "shipping", "option_id": "ship_standard", "item_ids": ["li_001"] } ] } ``` You recompute and return the updated session, including refreshed `totals` and a new `status`. ## Step 3: Complete the checkout with a Shared Payment Token This is the step people most often get wrong, so it is worth being precise. When the buyer pays, the payment provider issues a **Shared Payment Token**: a single-use credential scoped to your merchant id and the exact cart total, which the agent then hands to you. The token is delivered inside `payment_data` on the complete call. ACP's `2026-01-30` payment-handlers release introduced a nested shape: ```json POST /checkout_sessions/cs_01HV3P3ABC123/complete { "buyer": { "first_name": "Jane", "last_name": "Doe", "email": "buyer@example.com" }, "payment_data": { "handler_id": "handler_stripe_card", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } } } ``` The `credential.type` of `spt` marks it as a Shared Payment Token, and `handler_id` names one of the payment handlers you advertised in your session `capabilities`. **Confirm the shape rather than assuming it.** The `2026-01-30` changelog is explicit that the payment-handlers framework was a breaking change replacing `{ "token": "spt_123", "provider": "stripe" }` with the nested form above. However, the current stable `2026-04-17` OpenAPI file still shows the flat `{ "token": "spt_123", "provider": "stripe" }` form in its own complete-call examples, and Stripe's ACP seller documentation also still documents the flat form. That is an unresolved inconsistency in ACP's own published materials, not a settled answer, so check the expected shape with your agent platform and your payment provider and validate against the machine-readable schema before you go live. (The superficially similar nested `handler_id` plus `credential.token` structure in UCP is a different protocol's payload; do not treat the two as interchangeable.) Charge the token through your processor, and on success return a `CheckoutSessionWithOrder`, the session plus an `order`: ```json { "id": "cs_01HV3P3ABC123", "status": "completed", "order": { "id": "ord_88212", "checkout_session_id": "cs_01HV3P3ABC123", "permalink_url": "https://store.example.com/orders/88212", "status": "confirmed" } } ``` The `order.status` progresses through `confirmed`, `processing`, `shipped`, and `delivered` as you fulfill. Because the token is scoped to one merchant and one total and is single-use, the agent never holds reusable payment power and your store never sees the raw card. Merchants on Stripe can accept the token with minimal code. Merchants on other processors tokenize and charge through the protocol's separate **Delegate Payment API** (`POST /agentic_commerce/delegate_payment`), which vaults a card under an `allowance` that fixes the `max_amount`, `currency`, `merchant_id`, `checkout_session_id`, and an `expires_at`, the same scoping by another route. It returns `201` with a vault token id (a `vt_` prefixed string). That endpoint, its request shape and its allowance fields are unchanged in `2026-04-17`. For the concepts behind all this, see [how AI agents pay](/learn/how-ai-agents-pay). ## Security essentials Three things keep the integration safe. Verify the bearer token on every request, so only authorized agent platforms can drive a checkout. Honor the optional `Signature` and `Timestamp` headers when present, by validating the detached signature over the request body within a short time window, to prevent tampering and replay. And implement idempotency properly, because under `2026-04-17` it is no longer optional. Store the `Idempotency-Key` against the request body and the endpoint, return the original result on a replay (with an `Idempotent-Replayed: true` response header), and handle the three defined failure cases: `400` with code `idempotency_key_required` when the header is missing, `409` with code `idempotency_in_flight` plus a `Retry-After` header when the original request is still processing, and `422` with code `idempotency_conflict` when the same key arrives with a different body. The Delegate Payment API uses the same idempotency and signing conventions. ## Errors versus messages ACP separates two kinds of problem, and your implementation should too. A protocol-level failure (malformed request, bad auth, rate limit) returns an `Error` object with a `type`, `code`, and `message` and an appropriate 4xx or 5xx status. A business-level condition that is part of a valid checkout (an item went out of stock, a coupon is invalid, a sign-in or 3-D Secure step is required) is not an HTTP error; it is a `message` inside an otherwise valid `200` session, with a `code` such as `out_of_stock` or `requires_3ds` and a matching `status`. Returning the right one is what lets an agent recover gracefully rather than giving up. ## Test, then go live Build against the spec's examples and your processor's sandbox first. Walk the full lifecycle: create a session, update it to select fulfillment, complete it with a test Shared Payment Token, and confirm you return an order. Check the unhappy paths too: an out-of-stock item, an expired session, an idempotent retry. When it behaves, going live is a matter of your processor enabling agentic payments and your feed being present and accurate. Then the same integration works across every ACP agent surface, which is the entire point of adopting a standard rather than building one deal at a time. ## Where to go next The conceptual companion to this page is [ACP explained](/learn/acp-explained), and the authoritative detail lives in the ACP spec on GitHub, linked below. If your next step is exposing your own tools or data to agents rather than selling through them, see [how to build a remote MCP server](/learn/build-a-remote-mcp-server). And for where ACP sits among the other standards, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **What does a merchant actually have to build?** A product feed, an Agentic Checkout API (create, update, get, complete, cancel a session), and payment handling that accepts a Shared Payment Token on completion. On Stripe much of this is provided. **How is the payment passed without my store seeing the card?** On complete, the agent sends `payment_data` whose `instrument.credential.token` is a Shared Payment Token (`credential.type` of `spt`), scoped to your merchant id and the exact total. You charge that token; the raw card never reaches you. **Do I have to be on Stripe?** No. Stripe provides a reference implementation, but ACP is an open standard. Other processors implement the same spec and use the Delegate Payment API or their own equivalent. **Which spec revision does this walkthrough target?** The payloads were built from `2026-01-30`. Latest stable is `2026-04-17`, in which the endpoints, the Shared Payment Token model and the Delegate Payment API are unchanged, `Idempotency-Key` becomes required on every POST, and cart, feed, orders, authentication and MCP surfaces are added beyond what this guide covers. **What is the most common mistake?** Assuming a `payment_data` shape without checking. The `2026-01-30` release replaced the flat `{ token, provider }` form with the nested `handler_id` plus `instrument.credential.token`, but the `2026-04-17` OpenAPI file and Stripe's ACP seller docs still show the flat form, so confirm with your agent platform and payment provider. The other common mistake is letting feed prices or stock drift from your live store, since amounts are integers in minor units and mismatches break checkout. Primary sources: - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - ACP Agentic Checkout API (OpenAPI, 2026-04-17): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml - ACP Delegate Payment API (OpenAPI, 2026-04-17): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml - ACP changelog (2026-01-30 payment handlers): https://www.agenticcommerce.dev/docs/changelog - Stripe Agentic Commerce documentation: https://docs.stripe.com/agentic-commerce - Stripe: Agentic Commerce Protocol: https://docs.stripe.com/agentic-commerce/acp --- # How to Prepare Your Product Catalog for Agentic Commerce URL: https://agenticcommerceatlas.com/learn/product-catalog-for-agentic-commerce Markdown URL: https://agenticcommerceatlas.com/learn/product-catalog-for-agentic-commerce.md Section: learn Updated: 2026-10-01 For an AI agent to find and buy your products, your product data has to be four things: complete, structured, accurate, and machine-readable, and it has to match your live store exactly. Agents do not read your storefront the way a person does. They read structured product data, and they transact against it. If that data is thin, an agent overlooks you; if it disagrees with your live prices or stock, an agent's checkout can fail outright. Getting your catalog right is the foundational, protocol-agnostic step that makes everything else in agentic commerce possible, and it is useful whichever standards and surfaces win. This guide covers what agent-ready product data means, the fields that matter most, where the feed goes, and how to keep it current. ## Why product data is the foundation In conventional e-commerce, a person reads your product page, fills the gaps with judgment, and clicks buy. An agent has neither the page-reading nor the judgment. It works from a feed of structured attributes and makes decisions on them: whether to include you in a comparison, which variant fits the buyer's request, whether you are in stock and in budget. So your product data is not a marketing asset that supports the sale; for an agent it *is* the storefront. Two failures follow from getting it wrong. If the data is incomplete or unstructured, you are invisible to the agent, or represented worse than a competitor who did the work. If the data is inaccurate, you are visible but you break: an agent quotes a price or promises stock you cannot honor. ## What "agent-ready" means Hold onto four properties. **Complete.** Every item carries the fields an agent needs to choose and to transact, not just a name and a photo. **Structured.** The data is machine-readable, expressed in a recognized product schema, rather than prose a human reads off a page. Established vocabularies like schema.org's Product type and the major shopping-feed specifications already define these fields; you do not need to invent a format. **Accurate.** The feed matches your live store to the cent and the unit. This is the property merchants most often neglect and the one agents are least forgiving about. **Current.** Prices, availability, and promotions change, and the feed has to change with them, ideally in near real time. ## The fields that matter most At minimum, agents rely on a core set of attributes. The exact names vary by schema, but the substance is consistent. | Field | Why an agent needs it | |---|---| | Unique ID | To reference the exact item across the session and the order | | Title and description | To match the buyer's request and describe the item | | Price and currency | To check budget and compute the cart total | | Availability and quantity | To know it can actually be bought, and how many | | Images | To present the item to the buyer | | Brand | To match brand-specific requests and rank fairly | | Category and product type | To place the item in the right comparison | | Identifiers (GTIN, MPN) | To disambiguate the exact product | | Variants (size, color, etc.) | To pick the right option for the request | | Shipping and returns | To set expectations and complete fulfillment | Richer, more accurate attributes are what get you surfaced and described well when an agent compares options. Thin data is the most common reason a product is overlooked. Expect the modeling to differ between schemas even where the substance matches. ACP's product feed specification, for example, requires very little (a stable product ID and a set of variants, each with a stable ID and a title) and treats almost everything else, including price and availability, as optional per variant. It carries standardized identifiers as barcode entries, where GTIN is one barcode type, rather than as dedicated GTIN and MPN fields, and it represents shipping and returns as policy links on the seller rather than as delivery attributes. Google Merchant Center, by contrast, has dedicated delivery attributes and added more at the product level in its April 2026 specification update. The lesson is not to code to one schema, but to hold the substance completely enough that any of them can be populated from it. ## Accuracy and live-store parity This deserves its own emphasis because it is where real money is lost. An agent transacts against the data you publish. If your feed says 45.00 and your live store says 49.00, or your feed says in stock and your live store is sold out, an agent-initiated checkout can fail or complete at the wrong terms, and the merchant is often the one left with the return and the chargeback. Treat exact parity between the feed and your live systems as non-negotiable, and prefer near-real-time sync over periodic batch updates for price and stock. This is the same operational risk covered in [agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness), seen from the data side. ## Where the feed goes You probably do not need a brand-new system of record. Most merchants already publish a structured product feed (for example a shopping feed through a commerce platform or a merchant center), and that same well-formed data is most of what agents need. Increasingly, platforms syndicate a merchant's product feed to multiple agent surfaces at once. Be precise about what the protocols actually ask for, though, because "the protocols just read your existing feed" is not quite right. Each defines its own schema for the same substance. The [Agentic Commerce Protocol](/learn/acp-explained) publishes a product feed specification with its own field names and a required header describing the feed, the account, the target merchant, and the target country. Google's [UCP](/learn/ucp-explained) defines a Catalog capability in its `v2026-08-25` specification, served over REST or MCP, alongside Cart, Checkout, Order, and Identity Linking. That release also added a Location capability for finding physical stores, and UCP describes it as bringing "grocery shopping readiness," which trade reporting of the release notes says includes ordering by weight rather than in whole units. Both matter if your catalog covers grocery or a store estate. And a specific surface can add its own requirement on top: Google's documentation states that only product listings using the `native_commerce` product attribute will show the buy button for UCP-powered checkout. So the practical position is that the catalog you already maintain is the right source, but plan for a mapping step per surface rather than assuming a single feed is consumed as-is. ## Curating and managing the catalog over time Agent-ready data is not a one-time project. A few ongoing practices keep it healthy. Maintain a clean taxonomy so products land in the right comparisons. Enrich attributes deliberately, since richer, accurate data is what wins the agent's consideration. Handle variants explicitly rather than collapsing them, so an agent can pick the right size or color. Represent out-of-stock and backorder states honestly so agents do not try to buy what you cannot ship. And keep pricing and promotions in sync, because a discount that is live on your site but stale in your feed is exactly the kind of mismatch that breaks an agent checkout. ## A practical checklist A low-regret program for most merchants: - **Audit** your existing product data for completeness and for exact agreement with your live store, and fix the gaps. - **Structure** the data against a recognized product schema rather than leaving key facts in page prose. - **Enrich** the attributes that help an agent choose: identifiers, variants, categories, clear descriptions. - **Sync** price and availability in near real time, not in slow batches. - **Monitor** for drift between the feed and the live store, and treat mismatches as incidents. ## Where this fits Clean product data is the step before the protocols, not a part of them, which is why it pays off no matter which standards win. Once your catalog is agent-ready, the next move is the checkout integration that consumes it: for merchants adopting ACP, that is [how to implement ACP](/learn/implement-acp). For why this matters differently depending on your business, see [agentic commerce by business type](/learn/agentic-commerce-by-business-type), and for the bigger picture, [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business). ## FAQ **What makes a product catalog agent-ready?** Complete fields, structured machine-readable data, accuracy that matches your live store, and currency as prices and stock change. Agents transact against your data, so gaps hide you and mismatches break the purchase. **Do I need a special feed?** Usually not a new source of truth. A well-formed shopping feed you already publish is most of what agents need. Each protocol does define its own schema (ACP has a product feed specification, UCP a Catalog capability) and a surface may require its own attribute, so expect a mapping step rather than a separate catalog. Prioritize quality and accuracy of the data you already hold. **Why does live-store parity matter so much?** An agent acts programmatically on your published data. A price or stock mismatch can make an agent checkout fail or complete at the wrong terms, often leaving the merchant with the return and dispute. **What is the most important first step?** Audit your product data for completeness and exact agreement with your live store, and fix the gaps. It is low-regret, since clean data also helps conventional search and your own storefront. Primary sources: - Product (schema.org type): https://schema.org/Product - Product data specification: https://support.google.com/merchants/answer/7052112 - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - Product Feed Spec, Agentic Commerce: https://developers.openai.com/commerce/specs/file-upload/products - UCP specification overview (v2026-08-25): https://ucp.dev/2026-08-25/specification/overview/ - About the Universal Commerce Protocol (UCP) and UCP-powered checkout feature on Google: https://support.google.com/merchants/answer/16837055 - Merchant Center product data specification update 2026: https://support.google.com/merchants/answer/16989427 --- # Introducing Agentic Commerce URL: https://agenticcommerceatlas.com/learn/introducing-agentic-commerce Markdown URL: https://agenticcommerceatlas.com/learn/introducing-agentic-commerce.md Section: learn Updated: 2026-10-01 Agentic commerce is a simple idea with big implications: instead of doing your online shopping yourself, you ask an AI assistant to do it for you, and it can search, compare, and actually buy on your behalf. You stay in charge of what you want and what you are willing to spend. The assistant handles the legwork. If you have ever used an AI chat assistant to help research a purchase, you have already seen the first half of this. Agentic commerce is what happens when the assistant can also complete the purchase, not just point you to a website. ## An everyday example Say you want new running shoes, in your size, under a set budget, and well reviewed. Today you would open a few sites, compare them, and check out yourself. In an agentic version, you tell an assistant once what you want, and it finds the options, picks one that fits your rules, and places the order, checking back with you at the moments that matter. The work shifts from you to the assistant, while the decisions that count stay with you. ## Why this is a big deal For shoppers, it removes a lot of busywork. For businesses, it changes who they are selling to: more and more, the "customer" arriving at the store is a piece of software acting for a person. That sounds like a small change, but it reshapes how products get found, compared, and paid for. Analysts expect the shift to be significant. McKinsey estimates agentic shopping could drive up to a trillion dollars of US retail activity by 2030. Whether or not that exact figure holds, the largest technology and payment companies are all building for it now. ## How it differs from normal online shopping Normal online shopping is built around a person clicking "buy." Agentic commerce removes the person from that final click, and that raises a brand-new question: how does a store know the software in front of it is genuinely acting for you, with your permission, for this exact purchase? Answering that safely, proving you authorized it, and moving the money without ever handing your card details to the assistant, is most of what the new technology behind agentic commerce is about. You do not need to understand any of it to use agentic commerce, but it is why the field exists, and why there is so much activity around it. ## Is this real yet? Partly. You can already buy some things through AI assistants today, and more is arriving steadily, though plenty of what gets announced is still early or limited. It does not only move forward, either: OpenAI has stepped back from letting you complete a purchase inside a ChatGPT conversation, and now sends more shoppers to the store's own checkout instead. Google's buy-on-Google checkout is running with a selected group of merchants rather than the whole web. It is genuinely new and moving quickly, which is exactly why a calm, neutral guide is useful: it is easy to mistake an announcement for something you can actually do. ## Where to go next That is the whole idea in a nutshell. When you are ready for a little more depth, including how a purchase actually flows from start to finish and which companies are building what, read [What Is Agentic Commerce?](/learn/what-is-agentic-commerce). From there, this site maps the rest, the standards, the players, the payments, and what it all means, arranged roughly from the basics through to the technical detail. Agentic Commerce Atlas is an independent, vendor-neutral guide. It does not sell any of these products. It just explains them. ## FAQ **Do I need to be technical to understand agentic commerce?** No. At its heart it is just delegating your shopping to an AI assistant that can act for you. There is technical machinery that makes it safe, but you can understand and use agentic commerce without knowing any of it. **Is agentic commerce the same as an AI chatbot recommending products?** Not quite. A recommendation points you to a product to buy yourself. Agentic commerce is when the assistant can also complete the purchase for you, within the limits you set. Primary sources: - The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants - Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ - About the Universal Commerce Protocol (UCP) and UCP-powered checkout feature on Google: https://support.google.com/merchants/answer/16837055 --- # LCP Explained: The Legal Context Protocol URL: https://agenticcommerceatlas.com/learn/lcp-explained Markdown URL: https://agenticcommerceatlas.com/learn/lcp-explained.md Section: learn Updated: 2026-10-01 The Legal Context Protocol (LCP) is an open standard for publishing the legal terms behind an agent transaction in a place an agent can find, in a form it can verify. A business puts one JSON file at a fixed address on its domain, `/.well-known/legal-context.json`, and that file points to the terms governing any deal done there. The point is to answer three questions the rest of the agentic commerce stack leaves open: what was agreed, under whose law, and what happens if it goes wrong. > **Editor's note.** This page describes a protocol that launched in June 2026 and whose specification is published as a draft for community review. It is included because the institutional backing is unusual and the gap it addresses is real, not because it is established. Adoption is unproven. Verify against the primary sources below before making any decision on it. ## The gap it is trying to fill Every protocol the Atlas covers handles a mechanical part of a transaction. [MCP](/learn/mcp-explained) handles discovery. [ACP](/learn/acp-explained) and [UCP](/learn/ucp-explained) handle the shopping journey and checkout. [AP2](/learn/ap2-explained) handles proof that the user authorized the purchase. [x402](/learn/x402-explained) and [MPP](/learn/mpp-explained) move the money. [A2A](/learn/a2a-explained) lets agents coordinate. None of them says what the parties agreed to, which jurisdiction governs it, or how a dispute gets resolved. On the consumer web this rarely bites, because a human clicked through terms on a page and card-network chargeback rules sit underneath. In agent-mediated commerce both of those assumptions weaken: no human read anything, and a growing share of the value moves over rails that have no chargeback mechanism at all. The Atlas has flagged this before, in [risks and readiness](/learn/agentic-commerce-risks-and-readiness): AP2 states plainly that dispute resolution is out of its scope, and its own documentation lists accountability among the open questions. LCP is one attempt at the missing piece. Whether it is the attempt that wins is a separate question. ## How it works The mechanism is deliberately unremarkable, which is the strongest thing about it. A business serves a JSON file over HTTPS at `/.well-known/legal-context.json`. It has one required field: the URL of a standalone, downloadable terms document. The comparison LCP draws for itself is `robots.txt` for crawling rules and `/.well-known/openid-configuration` for identity discovery. Any agent, on any framework, can make one HTTP request and find out where it stands. Two optional fields do the heavier lifting. An **`atrHash`** is a SHA-256 hash of the terms document, so a party can prove exactly what the terms said at the moment of the transaction rather than arguing about it later. An **`acceptanceRequired`** flag, when true, means the counterparty must digitally sign the terms before transacting, producing cryptographic evidence of explicit consent. The specification recommends machine-readable formats for the terms document itself, Markdown, JSON, or plain text, and notes that PDF and Word are poorly suited to automated parsing. That is a small detail with a real consequence for merchants: the terms of service you already publish as a web page may not be usable as-is. ## The four levels of trust LCP frames adoption as four levels, described in the specification as advisory guidance rather than a normative requirement. Each is independently useful, and a business can implement one without the others. | Level | Name | What it adds | |---|---|---| | 1 | Informational | The terms are discoverable at a known URL. Proceeding implies consent. No hash, no signature. | | 2 | Provable | An `atrHash` proves the terms have not changed since the transaction. | | 3 | Signed | A digital signature binds a specific party to a specific document. Proof of explicit intent. | | 4 | Integrated | Hooks into dispute resolution, escrow, compliance, and other recourse infrastructure. | Level 3 is bilateral, and this is the part most relevant to anyone actually running agents. The service publishes terms; the buyer's principal publishes a **policy** stating what it will accept: a minimum trust level, acceptable jurisdictions, acceptable dispute methods, a cap on the commitment size, and a signing threshold above which the agent's signing key is gated behind human review. That is a concrete answer to a question buyers keep asking, which is how you stop an agent from agreeing to something you would never have agreed to. ## Who is behind it LCP launched on **24 June 2026**. It is co-stewarded by two Founding Maintainers: **Integra Ledger**, the protocol's creator and technology steward, and the **American Arbitration Association-International Centre for Dispute Resolution (AAA-ICDR)**, which describes itself as the world's largest private provider of alternative dispute resolution and marks its centennial in 2026. That pairing is the genuinely interesting part. Most new standards in this space are backed by technology companies, and their credibility rests on distribution. LCP's second steward is an adjudication institution, and it is the only entity in agentic commerce standards-setting that actually resolves disputes for a living. Founding contributors named in the launch announcement include **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**. Two of those, Google and Wayfair, are already central to [UCP](/learn/ucp-explained), and Circle is in the x402 ecosystem, so this is not a set of names disconnected from the rest of the map. It is also, notably, heavy on blockchain foundations and light on merchants, payment networks, and the AI platforms that operate the agents. The protocol is **Apache 2.0** licensed with no fees at any level. Governance runs through a contribution-based technical steering committee of up to seven seats, with changes made via public enhancement proposals and a contributor licence agreement required. The launch announcement states that governance is designed to transition to a neutral foundation, which has not yet happened. ## How mature is it, really This is where a neutral reference has to be blunt, because the framing around LCP runs ahead of its state. The specification is versioned **v1.0** but labelled on LCP's own site as a **draft released for community review**. The public repository is small: a handful of commits, no tagged releases, and a star count in the teens as of early August 2026. Those are early-project numbers, not adoption numbers. More importantly, **none of the protocols LCP proposes to attach to has adopted it**. LCP's documentation is unusually honest about this, splitting integrations into two tiers: Tier A mechanisms that work today against stock, unmodified protocols by borrowing an existing extension surface, and Tier B mechanisms that would need a change to the other protocol's specification. Every Tier A route is a workaround. For ACP it means putting a `legalContext` value in checkout-session metadata, because the relevant enum is closed. For Visa's Trusted Agent Protocol it means a custom HTTP header sitting outside the signature chain, which LCP itself labels advisory. The first-class integrations, a `legalContext` field in the MPP payment challenge, a registered x402 extension identifier, a field inside an AP2 signed mandate, are all Tier B, all proposed, and all dependent on stewards LCP describes itself as inviting. So the accurate summary is: a well-designed proposal with a serious institutional sponsor, published openly, addressing a real and undersupplied gap, and not yet adopted by anyone whose adoption would matter. ## What it means for you **If you are a merchant or operator**, the useful action is not to implement LCP. It is to check whether you could. Ask whether your terms of service exist as a standalone, hashable, machine-readable document rather than only as a web page, and whether you know which jurisdiction and dispute process govern a sale an agent completes on your site. Those questions are worth answering regardless of which standard eventually wins, and most organizations cannot currently answer them. **If you are a builder**, the buyer-policy model is worth reading even if you never adopt the protocol. Encoding acceptable jurisdictions, dispute methods, commitment caps, and a human-review threshold as machine-checkable policy is a pattern that will show up in agent governance whatever the wire format ends up being. **If you are watching the landscape**, treat LCP as the leading candidate in an emerging category rather than as part of the stack. The signals to watch are whether any of ACP, UCP, AP2, x402, or MPP accepts one of the Tier B proposals, whether the promised transition to a neutral foundation happens, and whether a merchant or payment network joins the contributor list. Until at least one of those occurs, this is a proposal with a good pedigree. ## FAQ **What is the Legal Context Protocol?** An open standard for publishing the legal terms behind an agent transaction at `/.well-known/legal-context.json`, with optional hash-proof of the terms and optional signed acceptance. It covers what was agreed, under which law, and with what recourse. **Who is behind it?** Integra Ledger and the American Arbitration Association-International Centre for Dispute Resolution, as Founding Maintainers, with founding contributors including Google, IBM, Circle, Wayfair, and Mysten Labs. Launched 24 June 2026 under Apache 2.0. **Does it compete with ACP, UCP, AP2, x402, or MPP?** No. It is designed to attach to them and addresses the recourse layer that all of them leave out of scope. **Is it being used yet?** Not meaningfully. The v1.0 specification is a draft for community review, the repository is early, and none of the protocols it proposes to bind to has adopted it. Primary sources: - Legal Context Protocol specification and governance (GitHub): https://github.com/legal-context-protocol/legal-context-protocol - Legal Context Protocol: https://legalcontextprotocol.org/ - AAA and industry leaders launch legal protocol for agentic commerce: https://www.adr.org/press-releases/aaa-and-industry-leaders-launch-legal-protocol-for-agentic-commerce/ --- # MCP Explained: The Model Context Protocol in Agentic Commerce URL: https://agenticcommerceatlas.com/learn/mcp-explained Markdown URL: https://agenticcommerceatlas.com/learn/mcp-explained.md Section: learn Updated: 2026-10-05 MCP, the **Model Context Protocol**, is Anthropic's open standard for connecting AI applications to external tools and data, often described as a USB-C port for AI. It is not a commerce protocol at all. In agentic commerce its job is narrow and foundational: it is the **discovery layer**, the standard way an agent finds a merchant's tools before any commerce protocol runs. It became foundational enough that Anthropic donated it to a new foundation in December 2025 to keep it neutral. ## Its role in commerce A merchant or payment provider can expose its capabilities as MCP tools, and an agent can then find and call them the same way it discovers any other tool. This is why the commerce protocols treat MCP as plumbing they plug into rather than a competitor: [ACP](/learn/acp-explained) describes itself as MCP-compatible, and [UCP](/learn/ucp-explained) lists MCP as one of its supported transports. Discovery has to happen before checkout, and MCP is the layer that handles it. ## MCP in payments today You can already see MCP used directly in payments. PayPal released what it called the industry's first remote MCP server in April 2025, initially for conversational invoicing, and Stripe ships an MCP server that exposes payment operations as agent tools. Importantly, there is no first-party "MCP commerce extension" from Anthropic. Commerce use of MCP happens through third parties building MCP servers and through other protocols choosing MCP as a transport, not through a dedicated commerce spec. Agentic Commerce Atlas runs its own MCP server, so you can query this reference live from an AI agent. See [the MCP server](/mcp), and if you want to build one, [how to build a remote MCP server](/learn/build-a-remote-mcp-server). ## Which version of the spec is current MCP revisions are date-versioned, in the form `YYYY-MM-DD`. **`2026-07-28`** is the current stable revision. It was published as final on **28 July 2026**, replacing `2025-11-25`. Five days before that release, the **IETF** put a question to the room that MCP builders should know about. On **23 July 2026** it held a working-group-forming BoF in Vienna, **Agent Communication Protocols (`agentproto`)**, on whether agent-to-agent and agent-to-tool communication needs standardizing at the IETF rather than only in vendor-founded foundations. The draft minutes record strong sense-of-the-room support for forming a group (154 to 51) and for the IETF as the right venue (158 to 30), but the proposed scope was rejected (38 for, 124 against), and participants pushed to reframe the work around context propagation across trust boundaries. MCP came up repeatedly, including its move to a stateless core, and a charter pull request was raised from the MCP side. The process has moved twice since. On **24 July 2026** the IETF Secretariat announced a non-working-group mailing list, `agentproto@ietf.org`, for continuing the discussion, "including updates to the proposed charter and aimed toward the formation of a new working group." And that rewrite has now landed: the Datatracker 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 on 2 October 2026 by the responsible Area Director after working through the review feedback with the proponents; by then two IESG members had recorded Yes positions, several more No Objection, and the one Block, over layering and scope, had been changed to No Objection on 17 September. It is still not a chartered working group, and the IESG may yet send it back, but the direction of travel since the BoF is clear. The rewritten charter also tells MCP builders where they would sit in it. The scope is now "a common baseline agentic dialog management protocol" built around dialog identifiers, lifecycle semantics and the propagation of dialog context, explicitly not a replacement for application-layer agent protocols or a new transport; the 2 October revision drops the earlier wording about extension points and instead says the dialog context "is defined so that existing application-layer agent communication protocols (e.g., the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol) can carry it using their own mechanisms," with any related change to those protocols left to their own maintainers and out of scope. In practice MCP would carry agentproto's dialog context in its own messages rather than plug into a new protocol. The milestones run from an informational use-cases draft adopted in December 2026 to the protocol submitted to the IESG in March 2028, so this is a 2028 question on the IETF's own schedule. **MCP's governance has not changed.** It remains at the Agentic AI Foundation, which on 17 August 2026 also became the home of [A2A](/learn/a2a-explained), and the `2026-07-28` revision is unaffected. This is a venue question that may matter in a year, not a reason to change anything you are building now. The maintainers describe it as the largest revision since launch, and it matters to anyone running or calling an MCP server: - **A stateless core.** The `initialize` handshake and the `Mcp-Session-Id` header are retired, so any request can land on any server instance. Protocol version, client identity, and client capabilities now travel in `_meta` on every request, and an optional `server/discover` method returns server capabilities up front. - **Multi Round-Trip Requests.** The server-initiated `elicitation/create`, `sampling/createMessage`, and `roots/list` calls are replaced by one pattern: the server answers with `resultType: "input_required"`, and the client retries the same request carrying `inputResponses`. - **Routing and caching at the transport.** `Mcp-Method` and `Mcp-Name` headers are now required on Streamable HTTP so gateways can route without reading the body, and list results (`tools/list`, `prompts/list`, `resources/list`, `resources/read`) carry `ttlMs` and `cacheScope` so clients can cache them. - **Extensions are formalized.** They are identified by reverse-DNS IDs, negotiated through an `extensions` capability map, and versioned independently of the spec. The official extensions named in the release were **MCP Apps** (server-rendered HTML interfaces in a sandboxed iframe), **Tasks** (`io.modelcontextprotocol/tasks`, long-running work, moved out of the core after its experimental run in `2025-11-25`), and **Enterprise Managed Authorization**, which lets an organization centrally control which servers its people can connect to. The set has since grown: the official extensions index now lists **five**, adding **Skills over MCP** (discovering workflow instructions and reading supporting files through MCP resources) and **OAuth Client Credentials** (machine-to-machine authentication with application-level credentials, no browser redirect and no user consent step, for background services and CI). Official extensions live in `ext-` repositories inside the MCP GitHub organization and use the `io.modelcontextprotocol` vendor prefix, so the index rather than the release post is the thing to check. - **Hardened authorization**, aligned more closely with how OAuth 2.0 and OpenID Connect are deployed in practice, including RFC 9207 issuer validation. Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents. - **A formal deprecation policy**, giving every feature an Active, Deprecated, and Removed lifecycle with at least twelve months between deprecation and removal, or at least ninety days under an expedited-removal exception the policy reserves. Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated under it, but continue to work. Plan on twelve months, but do not treat it as a guarantee. All four Tier 1 SDKs (TypeScript, Python, Go, and C#) spoke `2026-07-28` from the day it shipped; the Rust SDK support is in beta. This release contains **breaking changes**, which the maintainers frame as a one-off clean break that the new lifecycle policy and Extensions framework are meant to avoid repeating. If you run a server built against an earlier revision, read the changelog before upgrading; see [how to build a remote MCP server](/learn/build-a-remote-mcp-server) for what this means in practice. ## What comes after 2026-07-28 On **22 August 2026** the lead maintainers published a new roadmap covering the next specification release and beyond. Nothing in it is shipped, and no date is attached, but it is the clearest available signal of where the discovery layer is heading. Five priority areas, each with named Core Maintainers and a Working Group behind it: - **Agentic messaging primitives.** Server-initiated events, webhooks and channels so clients are not left polling for results, plus a composition review across the Agents, Transports, and Triggers and Events Working Groups, and maturing the **Tasks** extension so it can move into the specification proper. - **HTTP-native transport unification.** Stretching the stateless model to cover other deployment modes, including local servers speaking Streamable HTTP over stdio, so there is one transport rather than two. - **Agent identity and enterprise-ready security.** Today's authorization assumes a person approving access in a browser. The work here targets agents running as cloud workloads with their own identity, acting for an absent user or delegating narrower authority to sub-agents: finalizing **DPoP** (RFC 9449), and an opinionated path through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange, with continued engagement in the IETF OAuth and WIMSE working groups. - **Improved primitives.** One clear contract for what a `tools/call` result returns, and a **progressive discovery** effort so a server with a large catalog can expose a small entry point and reveal more as the conversation narrows. - **SDK developer experience**, including conformance testing. Two of these matter directly for commerce. **Progressive discovery** is the answer to a problem merchants hit first: a catalog server with a hundred tools makes the model pay for the whole surface before the shopper has asked anything. And the **Server Card Working Group** is still on `.well-known` metadata conventions, so a server can be discovered and reasoned over without connecting to it, which is the same discovery problem [ACP](/learn/acp-explained) and [UCP](/learn/ucp-explained) each solve through their own declared profiles and feeds. Do not read that as active progress, though: the group's only work item, SEP-2127 (MCP Server Card), is still marked Draft against a target date of 3 April 2026, its published output is an experimental repository rather than specification text, and both lead terms are listed as having ended on 14 August 2026. If you need server-level discovery today, the commerce protocols' own feeds are the working answer. Proposals inside these five areas get expedited review; proposals outside them are not rejected, but get maintainer attention last. ## How to hold it in your head The simplest way to keep MCP straight from the commerce protocols: **MCP is a discovery protocol, not a commerce one.** It sits underneath everything, the standard way an agent finds the merchant's tools, while [ACP](/learn/acp-explained) and [UCP](/learn/ucp-explained) define how the shopping and checkout actually run. They are complementary, and a single transaction can easily involve both. For where MCP sits among the other standards, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **Is MCP a commerce protocol?** No. MCP is Anthropic's general tool-and-data standard. In commerce it acts as the discovery layer, and the commerce protocols can use it as a transport. **How does it relate to ACP and UCP?** It is plumbing they plug into. ACP is MCP-compatible and UCP supports MCP as a transport. MCP handles discovery; the commerce protocols run the purchase on top. **Is there an official MCP commerce extension?** No. Commerce use happens through third-party MCP servers (PayPal, Stripe) and through other protocols using MCP as a transport, not a dedicated commerce spec. **Which version of the MCP spec is current?** Revisions are date-versioned. `2026-07-28` is the current stable revision, published as final on 28 July 2026 and replacing `2025-11-25`. It brings a stateless core, Multi Round-Trip Requests, required routing headers on Streamable HTTP, a formalized Extensions framework, and hardened authorization, and it contains breaking changes. Primary sources: - Donating the Model Context Protocol: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation - Model Context Protocol: https://modelcontextprotocol.io/ - PayPal begins rollout of MCP servers: https://developer.paypal.com/community/blog/paypal-model-context-protocol/ - The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - MCP specification releases (2026-07-28 stable): https://github.com/modelcontextprotocol/modelcontextprotocol/releases - MCP Extensions Overview (official extensions): https://modelcontextprotocol.io/extensions/overview - Minutes IETF 126: Agent Communication Protocols (agentproto) WG-forming BoF: https://datatracker.ietf.org/doc/minutes-126-agentproto-202607230700/ - Agent Communication Protocols (agentproto) group status: https://datatracker.ietf.org/wg/agentproto/about/ - New Non-WG Mailing List: agentproto, Agent Communication Protocols: https://mailarchive.ietf.org/arch/msg/ietf-announce/iJ6APXZyFA8cK-D0xMOSPE5IL1g/ - The New MCP Roadmap: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ - A2A joins AAIF's open agentic stack: https://aaif.io/blog/a2a-joins-aaif - Agent Communication Protocols (agentproto) proposed charter, External Review: https://datatracker.ietf.org/doc/charter-ietf-agentproto/ - MCP Server Card Working Group: https://modelcontextprotocol.io/community/working-groups/server-card --- # MCP For Ecommerce: How Merchants Expose Catalog, Cart, Checkout, And Order Tools To AI Agents URL: https://agenticcommerceatlas.com/learn/mcp-for-ecommerce Markdown URL: https://agenticcommerceatlas.com/learn/mcp-for-ecommerce.md Section: learn Updated: 2026-10-01 MCP for ecommerce means giving AI agents a standard way to discover and call merchant tools: product search, product detail, availability, cart, checkout, order status, and support actions. MCP does not replace commerce protocols or payment authorization. It is the tool-access layer that lets agents reach the systems where commerce happens. ## Short answer Use MCP to expose merchant capabilities as tools. Start with read-only catalog and policy tools. Add cart, checkout, order, or account tools only when authentication, authorization, validation, rate limits, and audit logs are in place. Pair MCP with [ACP](/learn/acp-explained), [UCP](/learn/ucp-explained), or your own commerce APIs for the transaction itself. ## Where MCP fits The [Model Context Protocol](/learn/mcp-explained) is not an ecommerce standard. It is a general protocol for connecting AI applications to tools and data. In commerce, that makes it the discovery and tool-call layer. An agent can ask: "What tools does this merchant expose?" Then it can call the right one. The checkout rules still live elsewhere. ACP standardizes an agentic checkout session. UCP covers a broader shopping journey. AP2 handles authorization. Payment networks and processors handle credentials and settlement. MCP is how the agent reaches a merchant's capabilities in a predictable way. MCP is no longer an Anthropic project in governance terms either. It was contributed to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025. ## Which revision of MCP this guide assumes MCP revisions are date-versioned. The current stable revision is **`2026-07-28`**, published on 28 July 2026, and it is the largest change to the protocol since launch. Nothing in this guide about *what* a merchant should expose changes because of it, but three things about *how* do, and they are operationally significant for a commerce deployment: - **The protocol is stateless.** The `initialize` and `initialized` handshake and the `Mcp-Session-Id` header are gone. Any request can land on any instance, so a commerce MCP server can sit behind an ordinary load balancer with no sticky routing and no shared session store. - **State moves into explicit handles.** Because the transport no longer carries a session, a server that needs continuity across calls should mint an identifier from a tool (a cart ID, for example) and have the model pass it back as a normal argument. For ecommerce this is the natural pattern anyway: `create_cart` returns a cart ID, and `update_cart` and `quote_checkout` take it as input. - **Traffic is routable and cacheable at the HTTP layer.** Every Streamable HTTP request carries an `Mcp-Method` header, and tool, resource, and prompt calls also carry `Mcp-Name`, so gateways can route, throttle, and rate-limit per tool without reading the body. List and resource-read results now carry a cache lifetime and a cache scope, so a catalog tool list can be cached rather than re-fetched on every conversation. The older HTTP plus Server-Sent Events transport is deprecated, and three core features (roots, sampling, and logging) are deprecated but still working under a formal policy that requires at least twelve months before removal, with a ninety-day minimum reserved for expedited removals. If you are running a server written against an earlier revision, it will keep working while clients negotiate versions, but new work should target `2026-07-28`. ## The tool set an ecommerce agent needs Think in tiers. Public read-only tools are the safest starting point. | Tool | Read or write | Why an agent needs it | |---|---|---| | `search_products` | Read | Find candidate products from a user's intent | | `get_product` | Read | Retrieve attributes, variants, price, availability, and images | | `estimate_shipping` | Read | Check delivery cost and timing before checkout | | `get_policies` | Read | Return returns, warranty, restrictions, and support policies | | `create_cart` | Write | Assemble a cart from selected items | | `update_cart` | Write | Change quantity, variant, address, or fulfillment choice | | `quote_checkout` | Read/write | Price the final cart with tax, shipping, discounts, and constraints | | `complete_checkout` | Write | Complete an order after authorization and payment are valid | | `get_order_status` | Read | Support post-purchase questions | Not every merchant should expose every tool. A public reference site might expose only search and page retrieval, like the [Atlas MCP server](/mcp). A retailer handling customer carts needs a much stricter trust model. ## Start read-only The lowest-risk ecommerce MCP server exposes public data: product search, product details, availability, store policies, and perhaps a shipping estimate that does not require private customer data. That is enough for an agent to compare and recommend products, and it helps you learn how agents call your systems before letting them mutate carts or orders. Read-only tools still need guardrails. Return structured, current data. Rate-limit calls. Avoid exposing internal fields. Make errors clear enough for agents to recover. Log the tool name, inputs, caller, response status, and latency. ## Add cart and checkout carefully Write tools are where MCP becomes operationally sensitive. A cart tool changes state. A checkout tool can commit money. An order tool can reveal customer data. These tools should require authentication, explicit authorization, input validation, idempotency, and audit logging. Since the protocol is stateless, carry cart state in an explicit identifier your tools return and accept, not in transport metadata. That also makes the state visible to the model and to your logs, which is what you want when you later have to reconstruct what happened. Before adding a write tool, answer: - Who is the caller, and how do we know? - What user or merchant account is this tool acting for? - What constraints apply to price, quantity, products, geography, recurrence, and payment? - Can the call be retried safely? - What record proves what happened? For checkout implementation detail, see [how to implement ACP](/learn/implement-acp). For authorization, see [AI shopping agent authorization](/learn/ai-shopping-agent-payment-authorization). ## Tool descriptions matter MCP tools are selected by models. That means names and descriptions are part of the interface. A vague tool such as `commerce_tool` is hard for an agent to use safely. A precise tool such as `estimate_shipping` with a schema for `product_id`, `quantity`, `postal_code`, and `country` is easier to call and easier to validate. Good ecommerce tool schemas: - use stable IDs rather than display names; - distinguish optional and required fields; - use integer money amounts in minor units when returning prices; - return explicit availability and restriction states; - include policy URLs where a human or agent can inspect terms; - reject ambiguous input rather than guessing. ## Privacy and authentication boundary Public catalog data can often be public. Customer data cannot. Cart, checkout, order, account, loyalty, subscription, and support tools should be authenticated and scoped to the user or organization they act for. If a tool can spend money, expose private data, change an order, or trigger fulfillment, it needs stronger controls than a public product lookup. The MCP specification includes patterns for transports and authorization, but the business rule remains yours: expose the minimum capability needed, and make the tool's scope obvious. ## How this composes with ACP and UCP MCP can expose the door. ACP or UCP can define what happens after the agent walks through it. The two are not mutually exclusive: UCP's `v2026-08-25` specification defines its Checkout, Cart, and Catalog capabilities over REST, MCP, and A2A transports, so a merchant implementing UCP may be exposing those capabilities as MCP tools already. ACP's latest stable specification, `2026-04-17`, likewise covers MCP alongside cart, feed, orders, and authentication. A typical composed flow: 1. An agent calls `search_products` through MCP. 2. It calls `get_product` and `estimate_shipping` for the best candidates. 3. It creates a cart through a merchant tool or ACP checkout endpoint. 4. The user approves, or an AP2 mandate proves prior authorization. 5. Payment is completed with a scoped token or other payment artifact. 6. The order record is returned and logged. This layered model avoids asking one protocol to do everything. MCP is discovery and tool access. Commerce protocols define shopping and checkout semantics. Payment protocols prove and settle the money movement. ## A minimal implementation plan 1. Publish complete, accurate product data. 2. Build read-only MCP tools for search, product detail, policy, and shipping estimate. 3. Add logging, rate limits, monitoring, and clear error shapes. 4. Add authenticated cart tools only after validation and idempotency are ready. 5. Connect checkout through ACP, UCP, or your existing API. 6. Add payment authorization and evidence records before accepting real money. For a worked MCP server example, see [how to build a remote MCP server](/learn/build-a-remote-mcp-server). For the catalog foundation, start with [product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce). ## FAQ **What is MCP for ecommerce?** It is the practice of exposing merchant capabilities, such as catalog search, product details, cart creation, checkout status, and order lookup, as MCP tools an AI agent can discover and call. **Is MCP enough to complete a purchase?** Usually no. MCP is the tool and data access layer. Checkout, authorization, and payment still require commerce and payment protocols or merchant APIs. **Which tools should a merchant expose first?** Start with read-only product search, product detail, availability, shipping estimate, policy lookup, and order status. Add cart and checkout later. **Should public tools require authentication?** Public catalog tools may be unauthenticated if they expose only public data. Anything involving customers, carts, orders, private pricing, or checkout should require authentication and authorization. **Which MCP revision should a merchant build against?** The current stable revision is `2026-07-28`, published on 28 July 2026. It made MCP stateless: no initialize handshake, no session header, required `Mcp-Method` and `Mcp-Name` headers on Streamable HTTP, and cacheable list results. Cart and checkout tools that used to lean on session state should mint an explicit handle, such as a cart ID, and have the agent pass it back on later calls. Primary sources: - Model Context Protocol: https://modelcontextprotocol.io/ - Model Context Protocol specification (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28 - Model Context Protocol specification releases: https://github.com/modelcontextprotocol/modelcontextprotocol/releases - The 2026-07-28 MCP Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - UCP specification overview (v2026-08-25): https://ucp.dev/2026-08-25/specification/overview/ --- # MPP Explained: The Machine Payments Protocol URL: https://agenticcommerceatlas.com/learn/mpp-explained Markdown URL: https://agenticcommerceatlas.com/learn/mpp-explained.md Section: learn Updated: 2026-10-01 The Machine Payments Protocol (MPP) is an open standard for letting an AI agent pay for something on its own, without a person entering card details or clicking a checkout button. It is built for the kinds of purchases agents actually make: paying for an API call, renting compute, buying access to a piece of data, or settling a small recurring charge. MPP is a settlement-layer protocol, not a consumer checkout standard. ## Who is behind it MPP was **co-authored by Stripe and Tempo** and launched on **18 March 2026**. It is published as an open standard, with the specification at **mpp.dev**. Tempo is the blockchain Stripe pairs with MPP for stablecoin settlement, and Stripe provides the merchant side: businesses already on Stripe can accept payments over MPP using the same PaymentIntents API they use for human payments. The problem MPP sets out to solve is that today's financial tools were built for people. To buy something, an agent often has to create an account, read a pricing page, choose a plan, enter payment details, and set up billing, steps that usually need a human. MPP replaces that with a programmatic handshake an agent can complete by itself. ## What MPP actually does MPP standardizes the payment conversation between an agent and a service. The flow is deliberately simple: an agent requests a resource from a service, an API, a Model Context Protocol (MCP) endpoint, or any HTTP-addressable endpoint; the service responds with a payment request; the agent authorizes the payment; and the resource is delivered to the agent. For a business accepting MPP through Stripe, these payments appear in the Stripe API and Dashboard like any other transaction. Funds settle into the business's existing balance, in its default currency, on its normal payout schedule, and the usual Stripe machinery applies, including tax calculation, fraud protection, reporting, accounting integrations, and refunds. Payment can be made in **stablecoins** as well as **cards, wallets, and the other methods that Stripe's [Shared Payment Tokens](/learn/acp-explained) carry**. Stripe's machine-payments documentation sets out the two halves plainly: crypto payments settle on-chain through a deposit address on **Tempo or Solana**, available to businesses in more than 30 countries and in all US states except New York; fiat payments run over Stripe's card rails through Shared Payment Tokens and are open to developers with a US legal entity. Individual charges can be as small as 0.01 USDC, and Stripe applies a minimum charge of 0.50 USD or equivalent to card payments made through a Shared Payment Token. Stripe also documents accepting **x402** alongside MPP, on Base. ## How MPP is specified, and where it stands as a standard This is worth being precise about, because MPP is marketed alongside a link labelled "IETF Specs" and it is easy to read that as meaning MPP is already an internet standard. It is not, yet. The core of MPP is not a bespoke API. It is defined as an **HTTP authentication scheme**, an extension of the ordinary HTTP authentication mechanism that uses the "402 Payment Required" status code. A client requests a resource; the server answers `402` with a `WWW-Authenticate: Payment` challenge describing what is owed; the client fulfills the challenge and retries with an `Authorization: Payment` credential; the server verifies it and returns the resource together with a receipt. That core was **submitted to the IETF on 18 March 2026** as `draft-ryan-httpauth-payment`, authored by Brendan Ryan, Jake Moxey, and Tom Meagher of Tempo Labs and Jeff Weinstein and Steve Kaliski of Stripe. The draft header states an intended status of Standards Track. **The status to hold onto is what the IETF Datatracker itself records**: the document is an individual Internet-Draft with no RFC stream, no responsible area director, no working group, and, in the Datatracker's own wording, no formal standing in the IETF standards process. Anyone may submit an Internet-Draft. So the honest characterization is that MPP's authors have started down the IETF path in the normal way, not that MPP is an IETF standard. The same work now also runs under a second, shorter document name, **`draft-httpauth-payment`**, with the author prefix dropped: `-00` was posted on 19 June 2026 and `-01` on **9 September 2026**, by the same five authors and under the same title. It expires **13 March 2027**, which supersedes the 19 September 2026 expiry the original name carried. Do not read the shortened name as adoption. Draft filenames usually lose their author prefix when a working group takes a document over, but that has not happened here: the Datatracker still lists `draft-httpauth-payment` as an *Active Internet-Draft (individual)*, with RFC stream `(None)`, intended RFC status `(None)`, an IESG state of *I-D Exists*, and no responsible area director. It records no formal replaces relationship between the two names either, so on paper the two documents simply coexist. The practical read is that the core specification is being kept alive and current in the IETF's document system while remaining outside the IETF's process. The specification is deliberately **modular**, which matters if you are building against it: a payment-method-agnostic **core** (HTTP 402 semantics, headers, IANA registries), **intents** that describe abstract payment patterns, **methods** that implement those patterns on a concrete network, and **extensions** for optional additions such as discovery and identity. The repository README gives the intents as charge, authorize, and subscription and the methods as Tempo, Stripe, and ACH, but read that as illustration rather than inventory: as of October 2026 the published drafts cover a **charge** intent with eleven methods (card, EVM, Hedera, Lightning, NearIntents, Solana, Stellar, Stripe, Tempo, USDC, XRPL), a **session** intent with six, and a **subscription** intent with Stripe and Tempo, while no ACH draft is published. The core also establishes two IANA registries, for payment methods and payment intents, and three header fields: `Accept-Payment`, `Payment-Authorization`, and `Payment-Receipt`. The design principles state that the protocol is network- and currency-agnostic and intended to cover bank rails and cards as well as stablecoins. The specifications are released into the public domain under **CC0 1.0**, with the surrounding tooling under Apache 2.0 or MIT. The drafts are now collected on a dedicated site, **paymentauth.org**, and the family is growing. A second document, `draft-payment-discovery`, "Service Discovery for HTTP Payment Authentication," by Tempo Labs and Merit Systems, lets a service publish an OpenAPI document at `/openapi.json` annotated with two extensions, `x-service-info` and `x-payment-info`, so an agent can find priced endpoints and their input schemas *before* making a request. It reached revision `-01` on **1 October 2026**, adding output-schema guidance so an agent can evaluate a seller-declared response shape before paying, with careful language that such a schema is "seller-declared discovery metadata" and "MUST NOT be described as a runtime observation." The draft is careful to keep discovery advisory throughout: "The runtime 402 challenge remains authoritative for all payment parameters," and clients "MUST NOT rely on discovery metadata for security decisions." ### MPP over MCP: the settlement layer reaches the discovery layer The most consequential document in the family for agentic commerce arrived on **1 October 2026**: `draft-payment-transport-mcp-00`, "Payment Authentication Scheme: JSON-RPC & MCP Transport," by two Tempo Labs authors. It defines how the Payment scheme operates over **JSON-RPC 2.0**, and therefore over MCP, which uses JSON-RPC as its message format. A server signals that payment is required by returning JSON-RPC error code **`-32042`** carrying one or more challenges, with `httpStatus: 402` included for transports that bridge to HTTP. The client then retries with a credential in `_meta` under the key `org.paymentauth/credential`, and the server returns a receipt in `_meta` under `org.paymentauth/receipt`. The operations named as payable are exactly the ones a merchant server would expose: **`tools/call`, `resources/read`, and `prompts/get`**. Why this matters more than its draft status suggests. Everywhere else on this site, the settlement layer and the discovery layer are described as adjacent: MCP is how an agent finds a merchant's tools, and x402 or MPP is how software pays software. This draft joins them. A merchant's MCP server could put a price on an individual tool call, which is a different commercial shape from either agentic checkout or flat-rate API access. Two things keep it in proportion. It is an individual Internet-Draft of intended status Informational, with no working group, like the rest of the family. And it still cites MCP revision **`2025-11-25`** and advertises capabilities under `experimental`, two revisions behind the current `2026-07-28`, which is a fair measure of how early the work is. See [MCP explained](/learn/mcp-explained) for what changed in between. Two details in that second draft are worth noticing. Its authors are **Brendan Ryan and Jake Moxey of Tempo Labs together with Ryan Sproule and Sam Ragsdale of Merit Systems**, so Stripe is not on it. And it carries an intended status of **Informational**, expiring 8 February 2027. Like the core draft, it is an individual submission with no working group behind it. The pattern to read is a spec family accumulating in the IETF's document system without yet entering the IETF's process. Governance sits with the two co-authors. The specification repository names **Tempo Labs and Stripe** as the maintaining organizations. Unlike [x402](/learn/x402-explained), which now sits under a Linux Foundation body, MPP has no neutral foundation, and the IETF submission is currently the only route toward multi-party stewardship. ## What has changed since launch MPP has iterated steadily rather than sitting still since the March release, and the running list on the MPP blog is the place to check before you build. Subscriptions for recurring access arrived in May 2026, followed by typed payment hooks in the core SDKs for logging, monitoring, and request context. In June, one SDK gained the ability to speak both generic EVM payments and x402 `exact` flows alongside MPP, so a single client can pay whichever protocol an endpoint supports, and the pay-as-you-go sessions experience was reworked. In July, `mppx` added hooks for agent runtimes: it installs a payment-aware global `fetch`, so existing HTTP tools and MCP transports can call paid endpoints without changing their request code, with published integration guides for Cloudflare Agents, the Vercel AI SDK, and the official TypeScript MCP SDK. On **3 August 2026** the **`mppx` SDK** added support for **relays**. Note the layer: this was an SDK and ecosystem capability rather than a change to the specification. A relay is an external service that sits between an application and the settlement layer and handles two operations on the application's behalf: validating that a payment credential is acceptable to the underlying rail, and broadcasting it to finalize payment and return what is needed to build a receipt. The practical effect is that a business can accept several payment methods through one interface and let the relay operator deal with each rail. The design point to note is how loose it is: MPP "does not require relays or require them to conform to a single interface," and relay authors define their own API shape. That keeps the protocol small, and it means relay behavior is not something a merchant can assume from the specification. ## Where it sits in the stack MPP lives at the **settlement** layer, the part of the stack concerned with how value actually moves. Both MPP and **x402** build on the same web mechanism, the long-dormant HTTP "402 Payment Required" status, so an agent can settle a charge inside a single request; the difference is sponsorship and rails, not the underlying method. x402 is the version contributed by Coinbase and now stewarded by the x402 Foundation under the Linux Foundation, which is stablecoin-focused in practice though network and token agnostic by design. The two are best understood as parallel machine-native options rather than a commerce protocol versus a payment one: both target agent-to-agent and micro-transaction use cases, and Stripe explicitly supports both MPP and x402. For a side-by-side, see [x402 vs MPP](/learn/x402-vs-mpp). It is just as important to be clear about what MPP is **not**. It is not a checkout protocol for the consumer shopping journey, that is the job of [ACP](/learn/acp-explained) and [UCP](/learn/ucp-explained). It is not a discovery layer, that is MCP. And it is not a payment-authorization and trust framework like [AP2](/learn/ap2-explained). MPP composes beneath or alongside those layers. For the full picture, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## What is actually live MPP is live infrastructure on Stripe, and the launch came with named businesses already using it rather than just intentions. Browserbase lets agents spin up headless browsers and pay per session. PostalForm helps agents pay to print and send physical mail. Prospect Butcher Co. lets agents order sandwiches for pickup or delivery in New York City. Agents can also contribute programmatically to Stripe Climate. Parallel Web Systems uses machine payments so agents can pay per API call for web access. The honest caveat is the same one that applies across agentic commerce: this is early, and it sits in the machine-to-machine lane, not retail checkout. MPP makes agent-initiated payments for services real and easy to accept on Stripe, but the broad ecosystem of agents and services transacting over it is still forming. ## What it means for you If you sell APIs, compute, data, or other digital services, MPP is the standard that lets agents become paying customers without a human in the loop, and if you are already on Stripe, accepting it is a small lift. If you are a builder, treat MPP as one of two settlement options for machine-native payments, alongside x402, and choose per use case. And if you are mapping the landscape, file MPP under settlement, next to x402, not as another contender at the checkout layer. ## FAQ **Who created MPP?** Stripe and Tempo co-authored it, launched 18 March 2026, with the spec at mpp.dev and acceptance available through Stripe's PaymentIntents API. **How is MPP different from x402?** Both are machine-native settlement standards for software-to-software payments, and both build on the HTTP "402 Payment Required" status. x402 is Coinbase's stablecoin-focused version; MPP is Stripe and Tempo's, settling in stablecoins as well as the cards, wallets, and other methods Shared Payment Tokens carry. Stripe supports both. **Is MPP a checkout protocol like ACP or UCP?** No. It is a settlement-layer protocol for agents paying for APIs, compute, and services. ACP and UCP handle the consumer shopping journey; MPP composes beneath or alongside them. **Is MPP an IETF standard?** Not yet. The core was submitted to the IETF on 18 March 2026 as `draft-ryan-httpauth-payment`, by Tempo Labs and Stripe engineers, with an intended status of Standards Track. The IETF Datatracker records it as an individual Internet-Draft with no RFC stream, no working group, and no formal standing in the standards process. That original document has since expired and is archived; the live one is the shorter name, `draft-httpauth-payment`, whose `-01` revision was posted on 9 September 2026 and expires 13 March 2027. The rename is not an adoption: the Datatracker records an individual submission with no working group and an IESG state of `I-D Exists`, and no formal replaces relationship between the two names. Primary sources: - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - Machine Payments Protocol specification: https://mpp.dev/ - Accept payments over MPP (Stripe docs): https://docs.stripe.com/payments/machine - MPP payments (Stripe docs): https://docs.stripe.com/payments/machine/mpp - x402 protocol (GitHub): https://github.com/x402-foundation/x402 - MPP specifications (GitHub): https://github.com/tempoxyz/mpp-specs - The "Payment" HTTP Authentication Scheme (draft-ryan-httpauth-payment): https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment/ - The "Payment" HTTP Authentication Scheme (draft-httpauth-payment): https://datatracker.ietf.org/doc/draft-httpauth-payment/ - Service Discovery for HTTP Payment Authentication (draft-payment-discovery-01): https://paymentauth.org/draft-payment-discovery-01.html - Payment Authentication Scheme: JSON-RPC & MCP Transport (draft-payment-transport-mcp-00): https://paymentauth.org/draft-payment-transport-mcp-00.html - MPP specification drafts index: https://paymentauth.org/ - Simplify MPP integrations with relays: https://mpp.dev/blog/relays - MPP blog: protocol development updates: https://mpp.dev/blog - MPP registries and header fields (core draft, draft-httpauth-payment-01): https://paymentauth.org/draft-httpauth-payment-01.html --- # The Agentic Commerce Protocol Stack: ACP vs AP2 vs UCP vs MCP vs x402 vs MPP URL: https://agenticcommerceatlas.com/learn/agentic-commerce-protocol-stack Markdown URL: https://agenticcommerceatlas.com/learn/agentic-commerce-protocol-stack.md Section: learn Updated: 2026-10-01 If you have tried to follow agentic commerce, you have hit a wall of acronyms: ACP, AP2, UCP, MCP, A2A, x402, and now MPP. They are not competing versions of the same thing. They solve different parts of one problem: how an AI agent can discover a product, agree on a cart, prove a real person authorized the purchase, and move the money, all without a human clicking a checkout button. This page is a neutral map. It explains what each protocol does, who is behind it, and how they stack together. ## The mental model: four layers, not one standard The cleanest way to make sense of the acronyms is to separate them by the job they do. Each layer is a distinct step in a single agentic purchase, and most protocols sit mainly in one.

Discovery

Discovery is how an agent finds what you sell and learns what it can do. Before anything is bought, the agent has to locate a merchant's products and the tools or endpoints it can call, the machine-readable equivalent of finding the right shop and reading the shelves. This is the job of [MCP](/learn/mcp-explained).

Commerce and checkout

Commerce, or checkout, is how an agent browses, builds a cart, and completes the purchase with a merchant: selecting items, applying the cart, and running the checkout conversation. It is the heart of the transaction, and the layer where the two rival standards, [ACP](/learn/acp-explained) and [UCP](/learn/ucp-explained), compete.

Payment authorization

Payment authorization is how the agent proves a real person approved this specific purchase, and where the question of who is liable is settled. Removing the human from the checkout creates a new trust problem: a merchant or bank needs cryptographic confidence that the buyer actually consented, not just that software decided to spend. [AP2](/learn/ap2-explained) is the standard for this layer.

Settlement

Settlement is how the money actually moves once a purchase is authorized. It spans the familiar card rails and machine-native options for software paying software, including stablecoin settlement. [x402](/learn/x402-explained) and [MPP](/learn/mpp-explained) are the machine-native standards here, alongside the card networks. Most of the protocols below sit mainly in one of these layers. They overlap at the edges, which is the source of most of the confusion.
DiscoveryHow an agent finds a merchant's tools
MCP
Commerce / checkoutBrowsing, cart, and completing the purchase
ACPUCP
Payment authorizationProving the user approved this purchase
AP2
SettlementMoving the money
Card railsx402MPP
A2A coordinates agents across every layer.
## The protocols ### ACP: Agentic Commerce Protocol Launched by **OpenAI and Stripe**, ACP is an open standard (Apache 2.0) for agent-to-merchant checkout. Its README describes OpenAI and Stripe as founding maintainers, while `MAINTAINERS.md` lists OpenAI, Stripe, and Meta as lead maintainers. A merchant implements it once, and any ACP-compatible agent can then browse, build a cart, and complete a purchase. It powered ChatGPT's original in-conversation buying. ACP describes itself as compatible with both REST and MCP. **Layer:** commerce semantics (checkout). **As of August 2026:** still in beta, with `2026-04-17` the latest stable spec revision (it added cart, feed, orders, authentication, and MCP). Etsy was live from launch and Walmart announced support, but the widely cited "million Shopify merchants" never materialized, and trade reporting indicates OpenAI scaled back native in-chat checkout in early 2026. See [ACP explained](/learn/acp-explained). ### AP2: Agent Payments Protocol Announced by **Google** in September 2025 with 60+ launch partners (including Mastercard, PayPal, American Express, Coinbase, and Salesforce), AP2 is a vendor-neutral standard for payment authorization. The point is trust: proving to a merchant or network that a real user consented to a specific amount. Note that the mandate vocabulary changed at v0.2. The launch (v0.1) model used three mandates, an **Intent Mandate** (what the user wanted), a **Cart Mandate** (what the agent assembled), and a **Payment Mandate** (what gets charged). **v0.2 defines two**: a **Checkout Mandate** covering what is being bought and a **Payment Mandate** covering how it is paid for, each existing in an open stage (the user approves constraints an agent may act within later) and a closed stage (the user approves a specific finalized checkout), with a matching receipt for each. Any three-mandate description you encounter is pre-v0.2 vocabulary. See [AP2 explained](/learn/ap2-explained) and [AP2 mandates in practice](/learn/ap2-mandates-in-practice). Google donated AP2 to the **FIDO Alliance** on 28 April 2026, alongside a v0.2 release, and FIDO now develops it through a Payments Technical Working Group that Visa co-chairs. AP2 remains at **v0.2** with no stable release: its public materials are schemas and sample scenarios that mock real payment service providers, and the project says an SDK and MCP server are still in progress. Note also that the handover is of future standardization rather than of the artifacts, since the repository, documentation, and copyright are still Google's. Stripe is not named among AP2's backers and supports ACP and MPP instead, though no first-party membership roster confirms it is outside FIDO's agentic work, so treat that as unconfirmed rather than settled. **Layer:** payment authorization and trust. **Backed by:** Google and the FIDO Alliance, plus major networks and PSPs. ### UCP: Universal Commerce Protocol Launched by **Google** in January 2026 with backers including Shopify, Etsy, Target, Wayfair, and Walmart, UCP standardizes the broader shopping journey, from discovery through checkout to post-purchase, rather than checkout alone. It is the main rival to ACP at the commerce-semantics layer, and Google pairs it with AP2 as the payments half of its stack. UCP is governed by a **Governance Council** that oversees overall adoption and health (Google, Shopify, and Stripe, which joined in April 2026, with two seats open for election) sitting over **per-domain Tech Councils** that lead technical direction. The **Shopping Tech Council** expanded to 16 seats on 24 April 2026 and all of them are filled, across ten companies: Google, Shopify, Etsy, Target, and Wayfair, joined by Amazon, Meta, Microsoft, Salesforce, and Stripe. A second body, the **Food Tech Council**, was seated on 16 July 2026 with Block (Square), DoorDash, Google, Toast, and Uber Eats, and a third, the **Lodging Tech Council**, on 11 August 2026 with Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com. A fourth, the **Payments Tech Council**, was seated on 2 September 2026 with Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe; it governs a capability rather than a retail vertical, which mirrors the way the specification now treats payment. The current spec revision is **`v2026-08-25`**, released 25 August 2026, which reorganized the specification into Common, Shopping, and Payment groups so the payment layer is shared across verticals rather than living under shopping, added EMV 3-D Secure payment authentication, and carries breaking changes. **Layer:** commerce semantics. **Backed by:** Google and Shopify, with a Tech Council spanning major retailers, platforms, and Stripe. ### MCP: Model Context Protocol Created by **Anthropic** and now held by the **Agentic AI Foundation, a directed fund under the Linux Foundation**, MCP is not a commerce protocol at all. It is the broader standard for how agents discover and call tools and data sources. In commerce, it acts as the discovery layer: an ACP-aware merchant can advertise its checkout as an MCP tool, so agents find it the same way they find any other capability. MCP uses date-versioned revisions, and the current specification is **`2026-07-28`**, published on 28 July 2026. It is the largest change since the protocol launched: the `initialize`/`initialized` handshake and the `Mcp-Session-Id` header have been retired, so the protocol core is now **stateless** and each request carries its own protocol version, client identity, and capabilities. If you read a description of MCP as a stateful, session-based protocol, it predates this revision. **Layer:** discovery and capability. See [MCP explained](/learn/mcp-explained). ### A2A: Agent-to-Agent A2A standardizes how independent agents talk to each other and delegate tasks. In a commerce flow, it matters when a buyer's agent negotiates or coordinates with a merchant's agent rather than calling a fixed endpoint. It originated at Google, was donated to the **Linux Foundation** in 2025, and reached **v1.0**, its first stable specification, in March 2026. On 17 August 2026 it became a hosted project of the **Agentic AI Foundation**, the Linux Foundation body that also holds MCP, so coordination and discovery now share one governance home. **Layer:** agent coordination. See [A2A explained](/learn/a2a-explained). ### x402: machine-native payments x402 revives the long-dormant HTTP `402 Payment Required` status to let software pay for resources programmatically, typically with stablecoins, in amounts and at frequencies that card rails handle poorly. It is the settlement option for machine-to-machine and micro-transaction use cases rather than consumer retail checkout. The protocol itself is network, token, and currency agnostic by design, so "stablecoins" describes current practice rather than a limit in the spec. x402 was contributed by **Coinbase** and is now stewarded by the **x402 Foundation**, which launched operationally under the Linux Foundation on 14 July 2026 with 40 members at launch. Its seventeen premier members span the 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). Block joined on 24 September 2026, contributing Bitcoin Lightning payments. **Layer:** settlement. See [x402 explained](/learn/x402-explained). ### MPP: Machine Payments Protocol Launched in March 2026 and **co-authored by Stripe and Tempo**, MPP is a second machine-native standard in the same lane as x402. An agent requests a resource from a service, API, or MCP endpoint, the service returns a payment request, the agent authorizes it, and the resource is delivered. It is built for microtransactions, recurring payments, and paying per API call, and it can settle in stablecoins as well as the cards, wallets, and other methods carried by Shared Payment Tokens. Stripe supports both MPP and x402. **Layer:** settlement. See [MPP explained](/learn/mpp-explained). ## Side-by-side | Protocol | Primary layer | Backed by | Best thought of as | | --- | --- | --- | --- | | [ACP](/learn/acp-explained) | Commerce semantics (checkout) | OpenAI and Stripe (Meta also a lead maintainer) | The agent-to-merchant checkout standard | | [AP2](/learn/ap2-explained) | Payment authorization | Google, now the FIDO Alliance, plus networks and PSPs | The proof that a user authorized the purchase | | [UCP](/learn/ucp-explained) | Commerce semantics | Google and Shopify, plus a Tech Council of retailers, platforms, and Stripe | The broader discover-to-post-purchase layer | | [MCP](/learn/mcp-explained) | Discovery / capability | Anthropic, now the Agentic AI Foundation (Linux Foundation) | How agents find the checkout in the first place | | [A2A](/learn/a2a-explained) | Agent coordination | Google, now the Agentic AI Foundation | How buyer and merchant agents talk | | [x402](/learn/x402-explained) | Settlement | Coinbase, now the x402 Foundation (Linux Foundation) | Machine-native, stablecoin micropayments | | [MPP](/learn/mpp-explained) | Settlement | Stripe and Tempo | Machine-native agent payments for APIs and services | ## How they fit together In practice these are complementary, not rivals. A realistic flow: an agent **discovers** a merchant's checkout via MCP, runs the **checkout** via ACP or UCP, attaches an AP2 **mandate** to prove the user authorized it, and **settles** over card rails or, for machine-to-machine cases, x402. The reason there is no single winner is that no one standard spans discovery, semantics, authorization, and settlement at once. ## What it means for you **Merchants:** you do not have to bet on one acronym. The pattern emerging is checkout (ACP/UCP) plus authorization (AP2). Implementing ACP gets you into ChatGPT's buying surface today; supporting AP2 mandates prepares you for the liability and trust questions that follow. **Builders:** treat the stack as layered. Use MCP for discovery, a commerce protocol for the cart, AP2 for signed authorization, and pick a settlement rail per use case. **Decision-makers:** the strategic question is not "which protocol wins" but "which layer is your moat." Networks are fighting over authorization; model providers are fighting over the checkout surface; the merchant's job is to be present and verifiable across both. ## FAQ **Is ACP or AP2 going to win?** They address different layers, so the likely outcome is coexistence: ACP/UCP for checkout, AP2 for authorization. Watch for convergence at the edges rather than a single victor. **Do I need all of these protocols?** No. Most real deployments touch two or three: a discovery layer, a checkout layer, and an authorization layer. Settlement depends on your use case. **Where does MCP fit if it is not a commerce protocol?** It is the discovery plumbing. Agents use MCP to find capabilities, including a merchant's checkout, before any commerce protocol runs. Primary sources: - Agentic Commerce Protocol specification: https://github.com/agentic-commerce-protocol/agentic-commerce-protocol - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Universal Commerce Protocol launch: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Model Context Protocol: https://modelcontextprotocol.io/ - The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - x402 protocol (GitHub): https://github.com/x402-foundation/x402 - Linux Foundation announces operational launch of x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - We're donating Agent Payments Protocol to the FIDO Alliance: https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/ - Announcing new Tech Council members (UCP): https://github.com/Universal-Commerce-Protocol/ucp/discussions/379 - UCP announcements (v2026-08-25 release, Lodging and Payments Tech Councils): https://ucp.dev/documentation/announcements/ - A2A joins AAIF's open agentic stack: https://aaif.io/blog/a2a-joins-aaif - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol --- # UCP Explained: The Universal Commerce Protocol URL: https://agenticcommerceatlas.com/learn/ucp-explained Markdown URL: https://agenticcommerceatlas.com/learn/ucp-explained.md Section: learn Updated: 2026-10-01 The Universal Commerce Protocol (UCP) is Google's open standard for agentic commerce. Where [ACP](/learn/acp-explained) began as a checkout handshake, UCP is broader: it aims to standardize the entire shopping journey, from discovery and buying through to post-purchase support. It is the one genuine rival to ACP at the commerce layer, and it is live today inside Google's own surfaces. ## Who is behind it UCP was announced on **11 January 2026** at the NRF retail show. It was co-developed with **Shopify, Etsy, Wayfair, Target, and Walmart**, and endorsed at launch by more than twenty other companies including Adyen, American Express, Best Buy, Flipkart, Macy's, Mastercard, Stripe, The Home Depot, Visa, and Zalando. That circle has since widened: ucp.dev now lists Amazon, Microsoft, Meta, Salesforce, and Stripe alongside the original shopping co-developers, and the endorsement list has grown to include payment and platform names such as Affirm, Block, Checkout.com, Fiserv, Klarna, PayPal, SAP, Splitit, VTEX, and Worldpay. It is licensed under Apache 2.0, with the specification at ucp.dev and code under a dedicated GitHub organization. ### How UCP is governed Governance runs on two levels. A **Governing Council** is responsible for the overall adoption and health of the protocol. (UCP's own announcements use "Governing Council"; "Governance Council" appears in a good deal of secondary coverage.) Beneath it sit **per-domain Tech Councils**, each responsible for the technical direction of one vertical. The public roster is the `MAINTAINERS.md` file in UCP's GitHub organization, and it names individuals rather than companies, which is the detail most summaries miss. The **Shopping Tech Council** reviews contribution proposals and stewards the shopping specification. Its founding members were Google, Shopify, Etsy, Target, and Wayfair. On **24 April 2026** it expanded to sixteen seats when **Amazon, Meta, Microsoft, Salesforce, and Stripe** joined, a notable convergence that brought several companies with previously rival positions under one open-standard governance body. All sixteen seats are currently filled, spread across ten companies. Four days later, on **28 April 2026**, Stripe also joined the **Governing Council** alongside Google and Shopify, and that council added two more seats to be filled by election. Both remained unfilled as of October 2026. On **16 July 2026** a second domain body was seated. The **Food Tech Council**, which covers local food ordering and delivery, welcomed **Block (Square), DoorDash, Google, Toast, and Uber Eats** as inaugural members, filling ten of its sixteen seats with six left open for election. A third followed on **11 August 2026**: the **Lodging Tech Council**, with inaugural members **Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com**. Read the roster as a map of the lodging supply chain: global distribution and online travel agencies, hotel groups, and Google as the consumer surface convening the effort. Three domain councils in five weeks is the clearest signal yet that UCP intends to be a multi-vertical protocol rather than a retail one. A fourth followed on **2 September 2026**, and it is a different kind of council. The **Payments Tech Council** was seated with **Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe**. Shopping, Food, and Lodging are retail verticals; payments is a capability that runs underneath all of them, so this is the governance counterpart to the structural change in `v2026-08-25`, which lifted payment out from under shopping into a cross-vertical Common layer. The roster is the other thing to read: acquirers and processors (Adyen, Global Payments, Stripe), wallets (Ant International, PayPal), a stablecoin rail (Coinbase), and the two permanent Governing Council members. It is the first time UCP governance has drawn in the payments industry as payments rather than as endorsers. Two things are worth reading plainly off that roster. First, Google's weight: it holds four of the sixteen Shopping seats and six of the ten filled Food seats, and one of the three filled Governing Council seats. UCP is open-governed on paper, and Google is still its largest single voice. Second, the overlap: Stripe and Meta sit formally inside UCP governance while remaining tied to the rival ACP, where Stripe is a founding maintainer and Meta is a lead maintainer. The big platforms are hedging across both commerce standards. One distinction to keep straight: the companies listed on ucp.dev as shopping **co-developers** are a wider group than the Tech Council. Walmart, for instance, is named as a co-developer and as a launch retailer for Universal Cart, but does not hold a Tech Council seat. ## Which version of the spec is current UCP uses date-based releases. The published versions are **`v2026-01-11`** (the launch release), **`v2026-01-23`**, **`v2026-04-08`**, and **`v2026-08-25`**, which is the current one. Releases and governance notices are posted on ucp.dev's announcements page and tagged in the GitHub repository. The `2026-04-08` release was a substantial expansion of scope: the Cart capability for basket building, Catalog search and lookup for product discovery, an updated Order capability, identity linking on an OAuth 2.0 foundation with capability-driven scopes, request and response signing, a first-class error model, and an embedded checkout protocol. The `2026-08-25` release, published on **25 August 2026**, is a change of shape rather than a change of scope. UCP's announcement describes it as "major protocol enhancements, key structural refactorings to support multi-vertical expansion, payments security improvements (3DS2), structured request constraints, independent capability versioning, grocery shopping readiness and many more." What that means in the published specification: - **The tree is no longer shopping-first.** The top level is now **Common**, **Shopping**, and **Payment**. Payment constructs moved out of shopping and into the cross-vertical common group, so payment extensions are now namespaced under `dev.ucp.common.payment.*` rather than living under shopping. (The release notes give the namespace rather than individual action identifiers, so treat any specific action name you see quoted as needing a check against the specification itself.) This is the refactor that makes food and lodging possible without forking the payment layer. - **A Payment Authentication extension**, with vendor-neutral EMV 3-D Secure challenge and device data collection actions, alongside new Payment Terms and Split Payments extensions and the existing AP2 Mandates extension. - **A Location capability under Common**, for agents to find physical stores, which is the groundwork for grocery and for anything else with a store estate. It carries **breaking changes**. If you have a UCP integration running, read the release notes against the capabilities you actually use before moving versions; UCP's versioning policy lets you keep serving an earlier snapshot in the meantime. ## What UCP actually does What distinguishes UCP is scope. Its capability set covers catalog search and lookup, cart building, checkout, identity linking via OAuth 2.0, an order lifecycle (shipped, delivered, returned, refunded), and a payment-handler model. Businesses choose which capabilities to support. There are also two ways to do checkout: a **native** mode, where the platform negotiates directly with the seller's checkout API and renders its own interface, and an **embedded** mode, where the seller's own checkout interface is rendered inside the platform's surface for more complex flows. In other words, UCP tries to standardize the whole sequence, with payment as one composable piece rather than something baked in. That payment piece is where AP2 comes in. Google designed the two to fit together. UCP's own documentation states that "UCP is fully compatible with Agent Payments Protocol (AP2)" and that AP2 "serves as the trust layer for agent-led transactions completed on behalf of a user." Mechanically, [AP2](/learn/ap2-explained) is an opt-in UCP extension: the business declares support in its discovery document, signs the checkout state, and at completion the platform submits a CheckoutMandate and a PaymentMandate that the business and the payment processor verify separately. UCP is also designed to be compatible with the agent-to-agent protocol [A2A](/learn/a2a-explained) and with [MCP](/learn/mcp-explained), and businesses can expose UCP capabilities over REST or JSON-RPC transports. ## What is actually live As of mid-2026, the specification, documentation, code samples, SDKs, reference implementations, and an interactive playground are published, and Google built the first production implementation to power checkout inside AI Mode in Search and the Gemini app for eligible US retailers, paying through Google Pay, with PayPal flagged at launch as a payment option to follow. In **March 2026** Google announced new optional UCP capabilities: a **Cart** option that lets agents add multiple items at once from a single store, a **Catalog** capability for retrieving real-time product details like variants, inventory, and pricing, and **Identity Linking** so shoppers keep loyalty and member benefits on UCP-integrated surfaces, plus a simplified onboarding path in Merchant Center. The same announcement named Commerce Inc, Salesforce, and Stripe as platforms that would implement UCP on their own products. At **Google Marketing Live on 20 May 2026**, Google set out how far it intends to take this. Its **Universal Cart**, introduced the previous day at Google I/O, works across retailers and across Google surfaces, and UCP handles the checkout: shoppers either pay with Google Pay in a few taps or transfer the items to the merchant's site to finish there, with the retailer remaining merchant of record either way. Google said shoppers would be able to try these checkout features "soon" with retailers including Nike, Sephora, Target, Ulta Beauty, Walmart, and Wayfair, and Shopify merchants such as Fenty and Steve Madden. Google also said UCP-powered buying would reach ad formats (Direct Offers and Shopping ads on YouTube), that Affirm and Klarna buy-now-pay-later options would be embedded in Google Pay, and that UCP-powered checkout would roll out across **Canada and Australia** in the coming months and later the **UK**. That geography has since slipped rather than landed. Google's own post of **16 September 2026** says the new integration-hub capabilities are "gradually rolling out in the U.S., with Australia and Canada to follow early next year," and there is no first-party evidence of a UK launch. The help-center eligibility note now names the United States, Canada, and Australia while its sibling terms-of-service article is still titled "US only," so even Google's own documentation is not internally settled. Do not plan on UCP checkout being live in Canada, Australia, or the UK. UCP is also reaching browser agents, not only server-to-server integrations. 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, sharing the same checkout object, statuses, and messages. A browser agent on a Shopify store can read, update, and submit the checkout through four tools, with the buyer confirming the order before the agent completes it. WebMCP is itself still a proposed web standard, and agent support is currently limited to Chromium-based browsers, so treat this as the first large-scale use of UCP semantics in the browser rather than a settled pattern. Shopify has also removed the catalog and cart tools from its older Storefront MCP endpoint and points developers to UCP instead. Beyond retail, ucp.dev now lists two further verticals with their own co-developer groups: **lodging** (Amadeus, Booking.com, Expedia Group, Google, Hilton, Marriott, and Trip.com) and **food** (DoorDash, Google, Square, Toast, and Uber Eats). Detailed specifications for both are still described on the roadmap as being developed rather than published, though the lodging entry now reads "beyond Booking," which concedes the Booking capability has landed. And it has: on **25 September 2026** the initial draft of the Lodging Booking capability, `dev.ucp.lodging.booking`, was merged into the UCP repository, which UCP calls the formal expansion of the protocol into the Lodging domain. It was developed by the Lodging Tech Council with open-source contributors and covers real-time pricing and availability checks, guest registration, complex payment schedules, and cross-vertical primitive interoperability. Two caveats matter. It is a **draft** merged outside the release cadence, so it is not part of a published revision, `v2026-08-25` remains the current one. And it is the first time one of the three vertical councils seated between July and September has produced specification text, which is the most direct evidence so far that the multi-vertical restructuring is doing work rather than just reorganizing the tree. Lodging is the furthest along on Google's own side. Google runs a dedicated developer site, **UCP for Lodging**, pitching hotel operators on turning AI interactions into room bookings on Google surfaces such as AI Mode in Search, with the merchant of record staying with the hotel. What it does not yet offer is a specification: the page opens an interest waitlist and states that detailed onboarding and specs are coming soon, and the product image carries the label "Conceptual mock only." That is a useful calibration for the whole vertical expansion. A developer surface and a waitlist are real steps, and they are still several steps short of something a hotel can integrate against. Hold one more figure alongside the gating language, or the picture tips too far the other way: Google's 16 September 2026 post states that "UCP already enables direct checkout for hundreds of thousands of brands and retailers across Google." Gated by application is not the same as small. So UCP is real and shipping in Google's own surfaces, is scoped to expand geographically and into new industries, and has a large endorsement list that now includes several payment providers and platforms. Broad third-party adoption outside Google's surfaces is still early, and a good deal of what was announced in May is framed as coming rather than live. ## A common point of confusion "UCP" the acronym is overloaded in the wider tech world, and the generic phrase "unified commerce platform" is a different, older retail concept. In agentic commerce, UCP means this Google-led protocol. The live confusion to avoid is UCP versus ACP: two parallel standards launched by rivals, not two names for the same thing. For a side-by-side, see [ACP vs UCP](/learn/acp-vs-ucp), and for where UCP sits among the other standards, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **What is UCP?** Google's open standard for agentic commerce, launched January 2026, covering the full shopping journey from discovery to post-purchase, with payment as a composable piece. **Is UCP the same as ACP?** No. They are rival commerce-layer standards: UCP is Google's whole-journey protocol; ACP is OpenAI and Stripe's checkout protocol. Both are Apache 2.0, and several companies back both. **How do UCP and AP2 fit together?** Google pairs them. UCP's documentation says UCP is fully compatible with AP2 and that AP2 is the trust layer for agent-led transactions. AP2 is an opt-in extension within UCP: the business signs the checkout state, and at completion the platform submits a CheckoutMandate and a PaymentMandate for verification. **Who governs UCP?** A Governing Council responsible for the protocol's overall adoption and health (Google and Shopify as permanent members, joined by Stripe on 28 April 2026, with two seats still open for election) sits over per-domain Tech Councils that lead technical direction. There are four: Shopping, expanded to sixteen seats across ten companies on 24 April 2026; Food, seated 16 July 2026; Lodging, seated 11 August 2026; and Payments, seated 2 September 2026 with Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe. **Which version of the UCP spec is current?** UCP uses date-based releases. The published versions are `v2026-01-11`, `v2026-01-23`, `v2026-04-08`, and `v2026-08-25`, which is the current one. UCP describes the 25 August 2026 release as introducing major protocol enhancements, structural refactorings to support multi-vertical expansion, payments security improvements (3DS2), structured request constraints, independent capability versioning, and grocery shopping readiness. It carries breaking changes, so existing implementers should read the release notes before moving versions. Primary sources: - WebMCP support for checkout: https://shopify.dev/changelog/posts/webmcp-support-for-checkout - Checkout WebMCP (Shopify developer documentation): https://shopify.dev/docs/agents/carts-and-checkout/checkout-webmcp - Migrate from Storefront MCP: https://shopify.dev/docs/apps/build/storefront-mcp - New agentic commerce tools and a protocol for retailers and platforms: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Universal Commerce Protocol official site: https://ucp.dev/ - Amazon, Meta, Microsoft, Salesforce, and Stripe join the UCP Tech Council: https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council - AI shopping gets simpler with Universal Commerce Protocol updates: https://blog.google/products-and-platforms/products/shopping/ucp-updates/ - New Universal Commerce Protocol features and AI tools (Google Marketing Live 2026): https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - AP2 FAQ (UCP and AP2 relationship): https://ap2-protocol.org/faq/ - UCP and AP2: https://ucp.dev/documentation/ucp-and-ap2/ - UCP announcements (releases, Tech Council, Governing Council): https://ucp.dev/documentation/announcements/ - UCP protocol releases: https://github.com/Universal-Commerce-Protocol/ucp/releases - UCP protocol release v2026-08-25: https://github.com/Universal-Commerce-Protocol/ucp/releases/tag/v2026-08-25 - UCP v2026-08-25 specification overview: https://ucp.dev/2026-08-25/specification/overview/ - Announcing the new Payments Tech Council members: https://github.com/Universal-Commerce-Protocol/ucp/discussions/798 - Announcing the new Lodging Tech Council members: https://github.com/Universal-Commerce-Protocol/ucp/discussions/714 - UCP Maintainers (Shopping Tech Council, Food Tech Council, Governing Council rosters): https://github.com/Universal-Commerce-Protocol/.github/blob/main/MAINTAINERS.md - Announcing the new Food Tech Council members: https://github.com/Universal-Commerce-Protocol/ucp/discussions/593 - Google Universal Commerce Protocol (UCP) for Lodging: https://developers.google.com/hotels/ucp - UCP Lodging: Booking Capability draft spec release: https://ucp.dev/documentation/announcements/ - Boost your holiday sales with these agentic commerce updates: https://blog.google/products/ads-commerce/agentic-commerce-holiday-updates/ --- # What Is Agentic Commerce? URL: https://agenticcommerceatlas.com/learn/what-is-agentic-commerce Markdown URL: https://agenticcommerceatlas.com/learn/what-is-agentic-commerce.md Section: learn Updated: 2026-10-01 **Agentic commerce** is commerce carried out by AI agents acting on a person's behalf: software that can search for products, compare options, build a cart, and complete a purchase with limited or no human clicking. Instead of a person navigating to a store and checking out, they delegate the task to an agent, and the agent transacts for them. This page is the starting point for the whole reference. It defines the term, walks through how an agentic transaction actually flows, explains why it is happening now, sets out what is genuinely live today, and points to the deeper pages. ## The shift in one sentence For three decades, e-commerce optimized the human checkout. Every "buy now" button, saved card, and one-click flow was built to get a person through payment faster. Agentic commerce removes the human from the checkout and asks a harder question: how does a merchant trust, and get paid by, a piece of software that is shopping for someone else? Answering that question, safely and at scale, is what the new standards and network products are all about. ## How an agentic purchase works A typical agentic transaction has four moving parts. It helps to follow a concrete example: "find me running shoes in my size under 120 dollars and buy the best-reviewed pair." First, **intent**. The user tells an agent what they want, with constraints such as budget, size, timing, and preferences. The agent now has a goal it is authorized to pursue, within limits the user set. Second, **discovery and selection**. The agent finds candidate products, often across multiple merchants, and chooses. To be considered, a merchant's products have to be legible to an agent: structured, accurate, machine-readable data rather than information buried in a web page a human reads. Third, **authorization**. Before money moves, the purchase is checked against what the user actually approved, so the merchant and the payment network have cryptographic confidence that a real person consented to this specific charge, not just that an agent decided to spend. This is the genuinely new trust problem, and it is the one most of the payment work is solving. Fourth, **checkout and settlement**. The agent completes the purchase through a checkout the merchant exposes, a payment token is passed so the agent never touches raw card details, and the money settles. The merchant typically remains the merchant of record and keeps the customer relationship, fulfillment, returns, and support. Each of those four parts is being standardized by a different protocol, which is why the field can look like alphabet soup at first. The map is laid out in [the protocol stack](/learn/agentic-commerce-protocol-stack).
  1. 1MCPDiscover

    The agent finds the products.

  2. 2ACPCheck out

    The agent builds and completes the cart.

  3. 3AP2Authorize

    A signed mandate proves the user consented.

  4. 4RAILSSettle

    A scoped token is charged and funds move.

MCP handles discovery, ACP the checkout, AP2 the authorization, and the payment rails the settlement.
## The standards, in brief You do not need the detail to understand the shape. Discovery is handled by [MCP](/learn/mcp-explained), the layer agents use to find and call tools and data. Checkout is handled by [ACP](/learn/acp-explained), the OpenAI and Stripe standard for agent-to-merchant purchases, and by [UCP](/learn/ucp-explained), Google's broader standard for the whole shopping journey. Authorization and trust are handled by [AP2](/learn/ap2-explained), which proves the user approved a specific purchase. Machine-to-machine settlement, agents paying for APIs, compute, and services, is handled by x402 and [MPP](/learn/mpp-explained). For how the money and trust actually move, see [how AI agents pay](/learn/how-ai-agents-pay). These standards mostly compose rather than compete. The main genuine rivalry is at the checkout layer, where ACP and UCP overlap, and even there several large companies back both. ## Why now Three things arrived at once. Capable conversational agents that people already use to research purchases. Checkout standards (ACP, UCP) that let those agents transact with merchants rather than just recommend. And payment-authorization standards (AP2) plus network products from Visa, Mastercard, and American Express that tackle the trust and liability problem. Together they turn "an AI that recommends" into "an AI that can buy." The expected prize is large enough to explain the rush. McKinsey estimates that by 2030 the US business-to-consumer retail market alone could see up to one trillion dollars in orchestrated agentic revenue, with global projections as high as three to five trillion. Those are forecasts, not facts, but the direction is backed by the largest platforms and payment networks all building at once. ## What is actually live today This is where the gap between announcement and reality matters most, and a neutral reference should be plain about it. Google's Universal Commerce Protocol powers a checkout button on eligible product listings in AI Mode in Search and in Gemini, paying through Google Pay, with the retailer remaining the merchant of record. Google's own merchant documentation is careful about the scope: the feature "is available for select merchants at this time," participation runs through an early-access interest form, and only listings carrying a specific product attribute show the buy button. At Google Marketing Live on 20 May 2026 Google announced a Universal Cart that works across retailers, checkout with named brands including Nike, Sephora, Target, Walmart and Wayfair, and a rollout to Canada and Australia and later the UK, but described those as coming rather than shipped. On the ChatGPT side, OpenAI and Stripe launched in-chat Instant Checkout in September 2025 with US Etsy sellers live from day one and over a million Shopify merchants promised as "coming soon." Only a small number of merchants integrated, and on 24 March 2026 OpenAI said the first version of Instant Checkout had not offered the flexibility it wanted, so it would let merchants use their own checkout experiences while it focused on product discovery, and it expanded the Agentic Commerce Protocol to cover discovery. In practice that means more discovery in the assistant and more checkout on the merchant's own site. It is a change of emphasis rather than a withdrawal: OpenAI's developer documentation still describes Instant Checkout as currently available to approved partners. The same day, Shopify's Agentic Storefronts made millions of Shopify merchants discoverable in ChatGPT by default, with the purchase completed on the merchant's own checkout, which is now the most widely available form of this pattern. The card networks' agent-payment programs are further along on specification than on general availability. American Express published its Agentic Commerce Experiences developer kit on 14 April 2026, and states on its own site that the account enablement, intent intelligence, and payment credentials specifications are available while agent registration and cart context are still under development, and that its agent purchase protection is a future commitment. Visa announced a collaboration with OpenAI on 10 June 2026 to carry Visa credentials into agent-initiated payments. Mastercard extended Agent Pay with Agent Pay for Machines on 10 June 2026 for machine-to-machine payments. The honest summary is that the rails are being laid quickly, real transactions happen today, but the "buy anything directly inside the chat" future is further along on some surfaces than others, and at least one large surface has moved backwards. The lesson for anyone planning is that adoption depends as much on the host surface promoting it as on the standard itself. ## Who the players are Three groups are building agentic commerce, and many companies sit in more than one. **Model and agent providers** such as OpenAI, Google, and Anthropic build the surfaces where buying happens. **Payment networks and providers** such as Visa, Mastercard, American Express, PayPal, and Stripe build the authorization and settlement rails. And **platforms and merchants** such as Shopify, Walmart, and Etsy decide how to be present and verifiable when the shopper is an agent. A maintained view of who is doing what lives in [the landscape](/landscape/agentic-commerce-landscape), and the order of events is in [the timeline](/landscape/agentic-commerce-timeline). ## What it means for you If you run a business, the practical question is whether your products can be found, understood, and bought by an agent, and on whose terms. The short answer for most companies in 2026 is to get discoverable and transactable now, in a low-cost way, while watching the parts that are still settling. That decision is worked through, by business type, in [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business). ## What to read next For the standards compared side by side, read [the protocol stack](/learn/agentic-commerce-protocol-stack). For the two pivotal protocols in depth, read [ACP explained](/learn/acp-explained) and [AP2 explained](/learn/ap2-explained). For the money mechanics, read [how AI agents pay](/learn/how-ai-agents-pay). And keep [the glossary](/learn/agentic-commerce-glossary) handy for the acronyms. ## FAQ **What is agentic commerce?** Commerce carried out by AI agents acting on a person's behalf: software that can search for products, compare options, build a cart, and complete a purchase with limited or no human clicking. The person delegates the task, and the agent transacts for them. **How is it different from regular e-commerce?** Traditional e-commerce optimizes a human checkout, a person clicking Buy. Agentic commerce removes the human from the checkout, which raises a new problem the standards exist to solve: how a merchant trusts, and gets paid by, software shopping on someone else's behalf. **Is agentic commerce actually being used yet?** In a narrow way, yes. Google's UCP powers a checkout button in AI Mode and Gemini, though Google describes it as available to select participating US merchants, and a small set of merchants transact through ChatGPT. Much is still pilot or "coming soon," and in March 2026 OpenAI de-emphasized in-chat Instant Checkout in favor of product discovery, with ACP expanded to serve as the infrastructure; Instant Checkout remains open to approved partners. **What are the main protocols?** ACP and UCP for checkout, AP2 for payment authorization, MCP for discovery, and x402 and MPP for machine-to-machine settlement. Each handles a different part of an agentic transaction, and they mostly compose together. Primary sources: - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ - New agentic commerce tools and a protocol for retailers and platforms: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants - About the Universal Commerce Protocol (UCP) and UCP-powered checkout feature on Google: https://support.google.com/merchants/answer/16837055 - How we're helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google: https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - Agentic Commerce Experiences (ACE) developer kit: https://www.americanexpress.com/en-us/company/agentic-commerce/ - Visa Partners with OpenAI to Power the Next Generation of AI Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseid.22496.html - Mastercard launches Agent Pay for Machines to unlock super-fast, always-on payments: https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ --- # x402 Explained: HTTP 402 for Machine-Native Payments URL: https://agenticcommerceatlas.com/learn/x402-explained Markdown URL: https://agenticcommerceatlas.com/learn/x402-explained.md Section: learn Updated: 2026-10-01 x402 is Coinbase's open protocol that revives the long-dormant HTTP **402 "Payment Required"** status so that software can pay for resources programmatically, typically with stablecoins, in amounts and at frequencies that card rails handle poorly. It is not a consumer-checkout protocol. It sits at the **settlement** layer and exists for software paying software: an agent paying for an API call, compute, data, or content. ## How payment flows The mechanism is the elegant part. A client requests a resource from a service; the service responds with a **402** and a payment requirement; the client pays; and a **facilitator** verifies and settles the payment **on-chain** on the merchant's behalf before the resource is delivered. The facilitator model is what makes x402 practical: the merchant does not have to run blockchain infrastructure itself, it relies on the facilitator to verify and settle. Settlement is in stablecoins such as USDC, which suits micro-transactions and per-call billing where traditional rails are too slow or too expensive. ## Who is behind it x402 comes from **Coinbase**, and is crypto-native by design. Coinbase and **Cloudflare** announced their intent to form an **x402 Foundation** in September 2025 to steward the protocol, and it moved under the **Linux Foundation** in 2026, giving it neutral, multi-party governance. That early move to a foundation is a familiar pattern: the crypto-native standard leans on neutral stewardship sooner, while provider-backed standards often start under their sponsors. In mid-2026 the protocol gained meaningful infrastructure backing. **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 attached to a CloudFront distribution (AWS does not itself use the words "generally available"), and **Cloudflare** opened a waitlist for a **Monetization Gateway** that lets sites charge for pages, APIs, datasets, or MCP tools via x402, both settling in stablecoins (primarily USDC) through Coinbase's facilitator. Then, on **July 14, 2026**, the **Linux Foundation** announced the **operational launch** of the x402 Foundation under formal, open governance, with Coinbase's contribution of the protocol complete and **40 members** on board at launch. The premier tier is striking for a crypto-native rail: its seventeen 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). Membership has grown past that launch figure: the foundation's 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, the first major non-stablecoin rail in x402. Two hyperscalers enforcing the same payment protocol at the edge, and every major card network signing on to help govern it, is a signal that agent-to-service micropayments are moving from concept to infrastructure, though open questions remain around tax, invoicing, and how sellers distinguish paying agents from ordinary traffic. The handover is now visible in the code as well as the governance. The canonical repository is **`github.com/x402-foundation/x402`**; Coinbase's original `coinbase/x402` repository was moved under the Foundation, with issues and pull requests transferred, and now serves as a development fork. The published documentation moved with it, to **docs.x402.org**. Worth noting alongside the stablecoin framing: the project's own principles describe x402 as **network, token, and currency agnostic**, and the Linux Foundation describes it as supporting "payment types ranging from traditional cards to stablecoins." Stablecoins are current practice, not a limit written into the specification. ## Where it sits in the stack x402 is one of two machine-native settlement standards, alongside [MPP](/learn/mpp-explained). Both build on HTTP 402 and target the same agent-to-agent and micro-transaction use cases; the difference is sponsorship and rails, and Stripe supports both. For a side-by-side, see [x402 vs MPP](/learn/x402-vs-mpp). It also connects to the authorization layer. An **A2A x402 extension**, built by Google with Coinbase, the Ethereum Foundation, and MetaMask, brings x402-style stablecoin payments to the [A2A](/learn/a2a-explained) agent-to-agent protocol, which is how [AP2](/learn/ap2-explained) composes with crypto settlement. So x402 handles the money movement, while AP2 and A2A handle authorization and coordination around it. For the full map, see [the protocol stack](/learn/agentic-commerce-protocol-stack). ## FAQ **What is x402?** Coinbase's open protocol reviving HTTP 402 so software can pay for resources programmatically, typically in stablecoins. It is a settlement-layer standard for machine-to-machine and micro-transaction use cases. **How does payment work?** A 402 response carries a payment requirement, the client pays, and a facilitator verifies and settles on-chain before the resource is delivered, so the merchant needs no blockchain infrastructure of its own. **How is it different from MPP?** Both are HTTP 402-based settlement standards. x402 is Coinbase's stablecoin-focused, on-chain protocol; MPP is Stripe and Tempo's, settling in stablecoins as well as cards and BNPL through Stripe. Stripe supports both. Primary sources: - x402 protocol (GitHub): https://github.com/x402-foundation/x402 - x402 documentation: https://docs.x402.org/introduction - A2A x402 extension (GitHub): https://github.com/google-agentic-commerce/a2a-x402 - Coinbase and AWS let publishers accept agents as customers via x402: https://www.coinbase.com/blog/coinbase-and-aws-let-publishers-accept-agents-as-customers-via-x402 - Cloudflare Monetization Gateway: https://blog.cloudflare.com/monetization-gateway/ - Linux Foundation announces operational launch of x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - Block joins the x402 Foundation to advance open agentic commerce: https://block.xyz/inside/block-joins-the-x402-foundation-to-advance-open-agentic-commerce - x402 Foundation members: https://x402.org/members/ --- # x402 vs MPP: Comparing the Machine-Native Payment Protocols URL: https://agenticcommerceatlas.com/learn/x402-vs-mpp Markdown URL: https://agenticcommerceatlas.com/learn/x402-vs-mpp.md Section: learn Updated: 2026-10-01 x402 and MPP are the two machine-native settlement standards: both are built on the HTTP 402 "Payment Required" status, and both exist for software paying software, an agent paying for an API call, compute, data, or a digital service, rather than a person checking out. **x402** is Coinbase's stablecoin-focused protocol. **MPP**, the Machine Payments Protocol, is Stripe and Tempo's, and settles in stablecoins as well as the cards, wallets, and other methods Shared Payment Tokens carry. They sit at the same layer of [the stack](/learn/agentic-commerce-protocol-stack), and Stripe supports both, so they are best understood as parallel options rather than a winner-take-all rivalry. ## At a glance | | x402 | MPP | |---|---|---| | Full name | x402 | Machine Payments Protocol | | Led by | Contributed by Coinbase, now the x402 Foundation | Stripe and Tempo | | Launched | 2025 | March 2026 | | Built on | HTTP 402 "Payment Required" | HTTP 402 "Payment Required" | | Settles in | Stablecoins in practice (for example USDC); the spec is network, token, and currency agnostic | Stablecoins, plus the cards, wallets, and other methods carried by Shared Payment Tokens | | Rails | On-chain, via a facilitator | Tempo and Solana for crypto, Stripe's card rails via Shared Payment Tokens | | Governance | x402 Foundation, operational under the Linux Foundation since 14 July 2026, 40 members at launch and more since | Tempo Labs and Stripe; core submitted to the IETF as an individual Internet-Draft, no working group yet | | Best for | Crypto-native, on-chain settlement | Mixed settlement through one provider | ## What each one is x402 revives the long-dormant HTTP 402 status so a service can demand payment inline: a client requests a resource, the server responds with a payment requirement, the client pays, and a facilitator verifies and settles the payment on-chain before the resource is delivered. It is stablecoin-native and aimed at a decentralized agent ecosystem. For the basics, see [the glossary entry](/learn/agentic-commerce-glossary). MPP standardizes the same kind of inline machine payment, but routes it through Stripe. A business already on Stripe can accept payments over MPP using the same PaymentIntents API it uses for human payments, and the funds settle into its normal Stripe balance, with the usual tax, fraud, reporting, and refund machinery. It pairs with Tempo, the blockchain Stripe uses for stablecoin settlement, and Stripe's machine-payments documentation now lists Solana alongside Tempo for MPP crypto settlement, plus Stripe's card networks for fiat. For the detail, see [MPP explained](/learn/mpp-explained). ## What they share The important thing to hold onto is how much they have in common. Both build on the same web mechanism, HTTP 402, so an agent can settle a charge inside a single request. Both target the machine-to-machine lane: agent-to-agent payments, microtransactions, and per-call billing for APIs, compute, and content. And both are real today, sitting beneath the consumer-checkout protocols rather than competing with them. The difference is not the idea; it is who sponsors it and how the money actually moves. ## How they differ Three differences matter. **Sponsorship:** x402 comes from Coinbase and is crypto-native; MPP comes from Stripe and Tempo and is anchored in Stripe's existing payments stack. **Settlement breadth:** x402 settles in stablecoins; MPP settles in stablecoins as well as the cards, wallets, and other methods carried by Stripe's Shared Payment Tokens, which makes it easier to fold machine payments into a business that already takes card payments. **Rails:** x402 settles on-chain through a facilitator the merchant does not have to operate; MPP settles through Tempo and Stripe, so the integration looks like the rest of Stripe. For how both relate to the wider money flow, see [how AI agents pay](/learn/how-ai-agents-pay). ## Governance x402 is organized through the x402 Foundation, which launched operationally under the Linux Foundation on 14 July 2026 with 40 members at launch and a seventeen-strong premier tier spanning Visa, Mastercard, American Express, Stripe, Adyen, Fiserv, Google, Shopify, AWS, Cloudflare, Coinbase, Circle, Ripple, MoonPay, and the Monad, Solana and Stellar foundations. Block joined on 24 September 2026, contributing Bitcoin Lightning payments. That gives it genuinely neutral, multi-party stewardship, and the protocol repository now lives at `github.com/x402-foundation/x402` rather than under Coinbase. MPP is steered by its co-authors, Tempo Labs and Stripe, who are named as the maintaining organizations on the specification repository. There is no foundation. What MPP has instead is a **standards-body route**: its core, defined as an HTTP authentication scheme, was submitted to the IETF on 18 March 2026 as `draft-ryan-httpauth-payment` with an intended status of Standards Track. Read that carefully, because MPP's own site links to it as "IETF Specs." The IETF Datatracker records the document as an individual Internet-Draft with no RFC stream, no working group, and no formal standing in the IETF standards process, expiring 19 September 2026. Anyone may submit an Internet-Draft; adoption by a working group is the step that has not happened. The drafts are now collected at paymentauth.org, and a second one, `draft-payment-discovery-00`, was submitted on 7 August 2026 by Tempo Labs and Merit Systems, covering OpenAPI-based service discovery with an intended status of Informational. It is an individual submission too. The picture is a spec family accumulating in the IETF's document system rather than moving through the IETF's process. The MPP specifications themselves are released under CC0 1.0, effectively the public domain, which is a more permissive posture than either protocol's tooling license. So the two have taken different routes to the same destination. The crypto-native standard leaned on a foundation early and now has multi-party governance in place. The provider-backed standard has stayed with its sponsors and pointed at the IETF, which, if a working group takes the draft up, would eventually deliver a more durable form of neutrality than a foundation, and which, if it does not, delivers none. As of August 2026 that question is open. ## Which should you use? Follow the settlement you need. If you want pure on-chain stablecoin settlement and a facilitator model, x402 fits, and its foundation governance may appeal if neutrality matters to you. If you want to accept machine payments alongside your existing card and wallet flows, through a single provider with familiar tooling, MPP through Stripe is the smaller lift. And because Stripe supports both, the choice is frequently not exclusive: you can pick based on whether you want stablecoin-only or mixed settlement, and revisit as the two standards mature. ## FAQ **What is the difference between x402 and MPP?** Both are HTTP 402-based machine settlement standards. x402 is Coinbase's stablecoin-focused protocol, settling on-chain through a facilitator; MPP is Stripe and Tempo's, settling in stablecoins as well as the cards, wallets, and other methods Shared Payment Tokens carry. **Do they compete?** They are parallel options at the same settlement layer, targeting the same machine-to-machine use cases. But Stripe supports both, so they are not mutually exclusive. **Which should I use?** x402 for pure on-chain stablecoin settlement and a crypto-native facilitator model; MPP for accepting machine payments alongside existing card flows through Stripe. Stripe supporting both means the decision often comes down to stablecoin-only versus mixed settlement. Primary sources: - x402 protocol (GitHub): https://github.com/x402-foundation/x402 - Linux Foundation announces operational launch of x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - Machine payments (Stripe docs): https://docs.stripe.com/payments/machine - MPP documentation: https://mpp.dev/ - MPP specifications (GitHub): https://github.com/tempoxyz/mpp-specs - The "Payment" HTTP Authentication Scheme (draft-ryan-httpauth-payment): https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment/ --- # Agentic Commerce Timeline URL: https://agenticcommerceatlas.com/landscape/agentic-commerce-timeline Markdown URL: https://agenticcommerceatlas.com/landscape/agentic-commerce-timeline.md Section: landscape Updated: 2026-10-05 The key milestones in agentic commerce, in order, each tied to a primary source. This page is maintained as new developments land. For a forward-looking counterpart, when this is likely to become unavoidable, see [when agentic commerce becomes table stakes](/analysis/when-agentic-commerce-becomes-table-stakes). Apr 2025Visa, MastercardSep 2025AP2 (Google)Sep 2025ACP launchOct 2025Walmart, PayPalJan 2026UCP (Google)Mar 2026MPP launchApr 2026AP2 to FIDO ## 2025 **29 April**: **Mastercard** unveils **Agent Pay**, its agentic payments program built on agentic tokens, with launch partners including Microsoft and IBM. **30 April**: **Visa** announces **Intelligent Commerce**, opening its network to AI agents through tokenized "AI-Ready Cards," with collaborators including Anthropic, OpenAI, and Stripe. **6 May**: **Coinbase** launches **x402**, an open protocol that revives the HTTP "402 Payment Required" status for stablecoin payments between software. **14 May**: **Perplexity** selects **PayPal** to power agentic checkout in Perplexity Pro, one of the earliest named agent-checkout partnerships. **16 September**: **Google** announces the **Agent Payments Protocol (AP2)**, a payment-authorization standard backed by more than 60 organizations. **PayPal** announces AP2 support the same day. **23 September**: **Coinbase and Cloudflare** announce their intent to form the **x402 Foundation** to steward the stablecoin protocol as a neutral standard. **29 September**: **OpenAI and Stripe** launch **Instant Checkout** in ChatGPT and release the **Agentic Commerce Protocol (ACP)**, with Etsy live first. **14 October**: **Walmart** partners with **OpenAI** to let ChatGPT users buy its catalog. **28 October**: **PayPal** adopts **ACP**, bringing its merchant network and wallet into ChatGPT's Instant Checkout. **9 December**: **Anthropic** donates the **Model Context Protocol (MCP)** to a new foundation under the Linux Foundation, cementing MCP as the neutral discovery layer beneath the stack. ## 2026 **11 January**: **Google** launches the **Universal Commerce Protocol (UCP)** at the NRF retail show, co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, covering the full shopping journey. **March**: **A2A** reaches **v1.0**, its first stable specification, adding multi-protocol bindings and version negotiation, enterprise multi-tenancy, and signed agent cards for cryptographic identity verification. It is the coordination layer UCP's A2A checkout binding and the A2A x402 extension build on. **18 March**: **Stripe and Tempo** launch the **Machine Payments Protocol (MPP)**, an open standard for agents to pay services programmatically, for microtransactions and recurring payments, with payment supported in stablecoins as well as cards. It joins x402 in the machine-to-machine settlement lane. The core is specified as an HTTP authentication scheme and was submitted to the IETF the same day as `draft-ryan-httpauth-payment`, an individual Internet-Draft with an intended status of Standards Track that has not been taken up by a working group. **24 March**: The ChatGPT channel changes shape, in two first-party announcements on the same day. **OpenAI** says the first version of Instant Checkout "did not offer the level of flexibility that we aspire to provide," so it is "allowing merchants to use their own checkout experiences" while it focuses on product discovery, and it expands ACP to cover discovery. Instant Checkout is narrowed rather than retired; OpenAI's developer documentation still describes it as available to approved partners. And **Shopify** switches on **Agentic Storefronts**: "Starting this week, millions of merchants can sell to ChatGPT users," with products "discoverable in ChatGPT by default," no separate integration or apps, and no transaction fees beyond standard processing. Shoppers find products through Shopify Catalog and complete the purchase on the merchant's own checkout, in an in-app browser on mobile or a separate tab on desktop, and merchants remain the merchant of record. The same Agentic Storefronts panel reaches Microsoft Copilot, where Shopify says thousands of merchants are already selling, and AI Mode in Search and the Gemini app, where select brands sell through UCP. Read together, these are one event seen from two sides: OpenAI stepped back from owning the checkout, and the largest commerce platform stepped in to supply discovery at scale while leaving checkout with the merchant. That, rather than in-chat buying, is the shape agentic shopping in ChatGPT actually took. Shopify also opened its **Agentic plan** globally, so brands not on Shopify can list in Shopify Catalog and reach the same AI channels. **2 April**: The **x402 Foundation** formally launches under the **Linux Foundation**, with Coinbase contributing the protocol. **8 April**: **Visa** unveils **Intelligent Commerce Connect**, a network, protocol, and token-vault-agnostic "on ramp" that lets merchants accept agent-initiated payments across protocols including the Trusted Agent Protocol, MPP, ACP, and UCP, launching in pilot with general availability targeted for the end of June 2026. **14 April**: **American Express** debuts its **Agentic Commerce Experiences** developer kit and an industry-first **Agent Purchase Protection** pledge for purchases made by registered agents. **24 April**: **Amazon, Meta, Microsoft, Salesforce, and Stripe** join what is now the **UCP Shopping Tech Council**, alongside founders Google, Shopify, Etsy, Target, and Wayfair, taking it to sixteen seats across ten companies, a sign the industry is converging on UCP as a shared open standard. **April**: **Google** donates **AP2 to the FIDO Alliance** and releases AP2 v0.2, adding support for autonomous "human not present" payments. Mastercard's compatible Verifiable Intent standard is contributed to FIDO alongside it. **20 May**: At **Google Marketing Live**, Google expands **UCP**, extending **Universal Cart** to named brands (Nike, Sephora, Target, Walmart, Wayfair, and Shopify merchants) and pushing UCP into new verticals beyond retail, hotel booking and food delivery, rolling out in the US first. **24 June**: The **American Arbitration Association-International Centre for Dispute Resolution** and **Integra Ledger** launch the **Legal Context Protocol (LCP)**, an Apache 2.0 standard that publishes a business's legal terms, and the route to recourse, at `/.well-known/legal-context.json`. Founding contributors include Google, IBM, Circle, Wayfair, Stellar Development Foundation, Ava Labs, UiPath, Cardano, Hedera, and Mysten Labs. It is the first serious attempt at the layer every payment and checkout protocol leaves out of scope, and it is early: the v1.0 specification is a draft for community review and no protocol steward has adopted it. **Late June to early July**: **AWS** and **Cloudflare** embed **x402** at the edge. AWS makes x402 settlement generally available in CloudFront and AWS WAF; Cloudflare opens a waitlist for a Monetization Gateway that charges for pages, APIs, datasets, and MCP tools via x402. Both settle in stablecoins through Coinbase's facilitator, a sign the machine-payments rail is moving from concept to infrastructure. **14 July**: The **Linux Foundation** announces the **operational launch** of the **x402 Foundation** under formal, open governance, with Coinbase's contribution of the protocol complete and 40 members on board. The premier tier now spans every major card network (Visa, Mastercard, American Express), payment providers (Stripe, Adyen, Fiserv), platforms (Google, Shopify, AWS, Cloudflare), and crypto infrastructure (Coinbase, Circle, Ripple), a notable mainstreaming of the stablecoin rail. **16 July**: **UCP** seats a second domain body, the **Food Tech Council**, with **Block (Square), DoorDash, Google, Toast, and Uber Eats** as inaugural members, filling ten of sixteen seats. It is the first evidence that UCP's per-vertical governance model is more than a diagram, and it follows the May commitment to extend the protocol into food delivery. **23 July**: The **IETF** holds a working-group-forming **BoF in Vienna, Agent Communication Protocols (`agentproto`)**, asking whether agent-to-agent and agent-to-tool communication needs standards at the IETF rather than only at vendor consortia and the Linux Foundation. It is the first time the venue question has been put formally. The draft minutes record strong sense-of-the-room support for forming a group (154 to 51) and for the IETF as the right place (158 to 30), but the proposed scope was rejected (38 for, 124 against), and the responsible Area Director confirmed a new mailing list. The results are explicitly non-binding, and the datatracker still lists the group as state `BOF` with no charter. MCP and A2A ran through the discussion, and a charter pull request was raised from the MCP side. Worth watching rather than acting on: if `agentproto` charters, the agent layer gains a third governance venue alongside FIDO and the Linux Foundation. **28 July**: The **`2026-07-28` revision of MCP** is published as the stable specification, replacing `2025-11-25` and becoming the largest revision of the discovery layer since launch. The protocol core goes stateless (the `initialize` handshake and `Mcp-Session-Id` are retired, with protocol version, client identity, and capabilities carried in `_meta` on every request); Multi Round-Trip Requests replace server-initiated elicitation, sampling, and roots calls; `Mcp-Method` and `Mcp-Name` headers become required on Streamable HTTP; the Extensions framework is formalized with MCP Apps, Tasks, and Enterprise Managed Authorization as the official extensions named in the release, a set that has since grown to five with Skills over MCP and OAuth Client Credentials; and OAuth and OpenID Connect authorization is hardened. It contains breaking changes for existing MCP servers, and deprecates Roots, Sampling, Logging, and the legacy HTTP+SSE transport under a new twelve-month policy. All four Tier 1 SDKs shipped support the same day. **4 August**: The **US Court of Appeals for the Ninth Circuit** vacates the preliminary injunction Amazon had won against **Perplexity's** Comet assistant, the first US federal appellate decision on agentic AI and the Computer Fraud and Abuse Act. The panel held that it was the user, not Perplexity, who accessed Amazon's computers for CFAA purposes, and that "however advanced the Assistant currently is, it is a tool, not a person for statutory purposes." Read the limits as carefully as the holding: the court said expressly that it does not establish a new legal regime governing agentic AI, that it does not reach other theories such as tort claims, and that the outcome "does not impair Amazon's ability to regulate access to Amazon.com via private terms of service for its users." It belongs in this timeline because the underlying dispute was about an agent declining to identify itself as an agent, which is exactly the problem Visa's Trusted Agent Protocol, Mastercard's Verifiable Intent, and the Know-Your-Agent work exist to solve. The courtroom and the identity layer are the same story. On **10 September** the court denied Amazon's petition for rehearing en banc; the full court was advised and no judge requested a vote, so the panel's opinion stands and the case returns to the district court. See [the ruling](/news/ninth-circuit-amazon-perplexity-cfaa-ruling). **3 and 7 August**: **MPP** widens on two fronts. On 3 August it adds **relays**, an optional external service that takes over payment validation and settlement so an application can accept several rails through one interface; MPP deliberately does not standardize the relay interface. On 7 August the family is widened with a second document, **`draft-payment-discovery`**, by Tempo Labs and Merit Systems, defining OpenAPI-based discovery so agents can find priced endpoints before requesting them. Like the core draft it is an individual submission with no working group behind it, and its intended status is Informational; it reached revision `-01` on 1 October 2026. (This draft is published on MPP's own `paymentauth.org` rather than appearing on the IETF Datatracker, so it is an Internet-Draft in format rather than a submitted one.) **11 August**: **UCP** seats a third domain body, the **Lodging Tech Council**, with **Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com** as inaugural members. The roster covers the lodging supply chain end to end: global distribution and online travel agencies, hotel groups, and Google as the convening consumer surface. Three domain councils in five weeks, and the second vertical to be governed rather than only announced. **17 August**: **A2A** becomes a hosted project of the **Agentic AI Foundation**, moving out of the Linux Foundation's broader portfolio into the body that already holds MCP, Block's goose, AGENTS.md, agentgateway, and Agent Router. Each project keeps its own maintainers, specification process, and release schedule. A2A's own announcement, on 27 August, describes the governance tier as a Growth Stage project. It is the sharpest illustration yet of the year's consolidation pattern: the two protocols agentic commerce leans on most, MCP for tool access and A2A for agent coordination, are now governed in one neutral place. The specification itself is unchanged. **18 August**: **Rain** launches the **Agentic Payments Alliance**, a coalition of 26 founding members including **Visa, Mastercard, Fiserv, Circle, Solana, Uniswap Labs, Chainalysis, Fireblocks, Shift4, Lithic, and Remitly**. Its stated early work is shared research and frameworks, testing emerging standards for agent identity and authorization, and advocacy on the regulatory questions. Note what it is and is not: a working coalition run collectively by its members, with no specification of its own, arriving into a field that already has FIDO, the Linux Foundation, and a possible IETF venue. Worth tracking for whether it produces a standard or a position. **22 August**: The **MCP** lead maintainers publish a **new roadmap** for the releases after `2026-07-28`, with five priority areas: agentic messaging primitives, HTTP-native transport unification, agent identity and enterprise-ready security, improved primitives, and SDK developer experience. Two bear on commerce: **progressive discovery**, so a server with a large catalog can expose a small entry point rather than making the model pay for every tool up front, and continuing Server Card work on `.well-known` metadata so a server can be discovered without connecting to it. Direction rather than specification, with no dates attached. **25 August**: **UCP** publishes **`v2026-08-25`**, its fourth release and the first since April. UCP describes it as major protocol enhancements, 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 the one to note: the specification is now organized as **Common, Shopping, and Payment** rather than shopping-first, with payment constructs lifted into the cross-vertical common layer, a Location capability for finding physical stores added under Common, and new Payment Terms and Schedules, Split Payments, and Loyalty extensions. It carries breaking changes. Read alongside the Food and Lodging councils, it is UCP rebuilding itself so verticals can be added without forking the payment layer. **1 September**: **EMVCo** publishes a draft, **EMV Agentic Payments: Framework for Specifications v1.0**, for public comment, and confirms an **Agentic Payments Task Force** to develop its approach. The comment period closed on 30 September 2026 with no disposition of comments published. The draft proposes **Intent Services**, a shared interoperable layer for registering, referencing, retrieving, and managing consumer-authorized intent before, during, and after a transaction, aimed at the cases where intent has to persist: recurring purchases, cumulative budgets, post-transaction activity. EMVCo frames it as complementing cryptographic approaches such as Mastercard's Verifiable Intent rather than replacing them, and flags **Know Your Agent** and **Agentic Transaction Indicators** as possible later work. It is a draft framework, not a specification, but EMVCo is owned by the six card networks, so this is the card industry's own answer to the agent-identity and persistent-intent problem, arriving alongside FIDO's. **2 September**: **Anthropic** publishes an open **commerce agent blueprint**, reference shopping and merchant agents on Claude under Apache 2.0, with Accenture, Mastercard, and Visa named as ecosystem partners and a Shopify implementation built over **UCP** and Sign in with Shop. The boundary is the interesting part: Anthropic supplies the agent patterns and hands payment to the merchant, contributing no rail of its own. It is the third model provider to take a position at the commerce layer, and it took it by adopting someone else's protocol. **2 September**: **UCP** seats a fourth domain body, and the first that is not a retail vertical. The **Payments Tech Council** welcomes **Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe** as inaugural members: acquirers and processors, wallets, a stablecoin rail, and the two permanent Governing Council members. It is the governance counterpart to the structural change in `v2026-08-25`, which moved payment out from under shopping into a cross-vertical Common layer. Read together, the specification and the governance now treat payment as something that runs beneath every vertical rather than as part of retail checkout. **8 September**: **Meta** launches **Muse**, a consumer agent that acts rather than answers, rolling out in the US on iOS, Android, and muse.ai with a free tier and paid plans. It runs on a dedicated cloud virtual machine with its own browser, can "open a browser, fill out forms, and negotiate" on the user's behalf, and checks with the user "before sensitive actions like sending an email or making a purchase." Payment is the detail to note: Muse checks out with **Link by Stripe**, whose wallet for agents issues a one-time-use card so real card details stay hidden, and Meta says Muse is the first AI agent covered by Link's purchase protections; Shop Pay is "coming soon." Two things follow for this map. Meta joins OpenAI, Google, and Perplexity as an operator of a mass-market buying agent, not only as a backer of ACP and UCP. And Muse buys through a browser and a wallet rather than through a commerce protocol: Meta names no ACP or UCP integration, though Shopify said in March that UCP would "soon" power checkout in some Meta experiences. It is the clearest example yet of agentic shopping that works without the merchant opting in. **9 September**: **Ant International, Mastercard, and Visa** begin a collaboration on **Know-Your-Agent interoperability**, so that networks, wallets, agent platforms, and marketplaces can recognize a trusted agent without each running its own identity check. Three areas are named: cross-network operator traceability linking an agent to a validated operator, cardholder, or business; shared certification against common security and behavioral requirements; and continuous monitoring using identity and transaction signals. Each network keeps its own verification and decisioning, and the three approaches it aims to bridge stay in place: Visa's Trusted Agent Protocol, Mastercard's Verifiable Intent, and Ant International's Agentic Mobile Protocol. The work runs through **BuildFin.ai**, an industry platform convened by the Monetary Authority of Singapore, which puts a financial regulator's platform under an agent-identity effort for the first time. No specification, governance body, or timeline was published, so this is intent rather than standard. See [the announcement](/news/know-your-agent-interoperability-ant-mastercard-visa). **9 September**: The **MPP** core specification is refreshed in the IETF's document system under a shorter name, **`draft-httpauth-payment-01`**, by the same Tempo Labs and Stripe authors, extending its life to 13 March 2027. Losing the author prefix from a draft name usually signals working-group adoption; here it does not. The Datatracker still records an individual Internet-Draft with no RFC stream, no intended RFC status, and no working group, and it records no formal replaces relationship with `draft-ryan-httpauth-payment`. The specification is being kept current inside the IETF's document system while staying outside the IETF's process. **24 September**: **Block** joins the **x402 Foundation** and contributes **Bitcoin Lightning** payments to the protocol, announced on Block's own newsroom with a quote from x402's creator as a Technical Steering Committee member. It is the first major non-stablecoin rail inside x402, which until now settled overwhelmingly in USDC, and it widens the settlement layer rather than the commerce layer. The foundation itself had not announced it as of 1 October, so this is sourced from the contributing company. **25 September**: **UCP** merges the first draft of the **Lodging Booking capability** (`dev.ucp.lodging.booking`) into its repository, which UCP calls the formal expansion of the protocol into the Lodging domain. Developed by the Lodging Tech Council with open-source contributors, it covers real-time pricing and availability checks, guest registration, complex payment schedules, and cross-vertical primitive interoperability. This is the entry that answers the question the July-to-September run of vertical councils raised: the councils are producing specification text, not only rosters. Two qualifications hold it in proportion. It is a **draft merged outside the release cadence**, so `v2026-08-25` is still the current revision and there is nothing versioned to build against. And the roadmap still lists food and lodging as being developed, now worded as going "beyond Booking." **28 September**: **Shopify** extends **WebMCP** into checkout. WebMCP is a proposed web standard, which Shopify says it is helping shape alongside Google and Microsoft, that lets a site register tools a browser agent calls directly instead of reading page code or simulating clicks. On 5 August Shopify had switched on WebMCP tools for catalog search, carts, and orders on every Liquid storefront, with "nothing to install or configure"; the 28 September changelog adds checkout, so browser agents can read and update a Shopify checkout and submit it through four tools (`navigate_to_storefront`, `get_checkout`, `update_checkout`, `complete_checkout`) on eligible checkouts. The buyer stays in the loop: Shopify's documentation says the buyer confirms the order before the agent calls `complete_checkout`, and control returns to the buyer for steps such as 3D Secure or Shop Pay login. The protocol detail is the one that matters for this map: Shopify describes Checkout WebMCP as implementing **the UCP checkout capability over browser-registered WebMCP tools** instead of server-side JSON-RPC. So the merchant-opt-in protocol and the browser agent are no longer separate routes into a Shopify store; the same checkout object now serves both. Agent support is currently limited to Chromium-based browsers. **30 September**: **Mastercard** expands **Agent Pay** with trust and intelligence services, which it describes as the intelligence layer of an **Agent Pay Trust Framework** spanning identity, intent, controls, execution, and intelligence. The first service is a probability score indicating how likely it is that a transaction was initiated by an AI agent, so issuers can approve legitimate agent-led purchases rather than decline them as anomalies; it is "rolling out for testing in the U.S.," not generally available. Mastercard also names Cloudflare (combining web and payment-network signals in privacy-preserving environments) and Skyfire, a Know Your Agent provider. This is the network-side answer to a problem the timeline keeps returning to: a card network that cannot tell an agent from a fraudster will decline the agent. **30 September**: The **EMVCo** comment period on its draft agentic payments framework **closes**, with no disposition of comments or specification published. The fourth-quarter question the September entry posed now has a clock on it rather than an open door. **1 October**: **MPP** reaches into the discovery layer. Two drafts are published at `paymentauth.org` on the same day: `draft-payment-discovery-01`, which adds output-schema guidance to the OpenAPI discovery mechanism, and a new document, **`draft-payment-transport-mcp-00`**, which defines how the Payment HTTP authentication scheme operates over **JSON-RPC 2.0 and therefore over MCP**. It maps a payment challenge to JSON-RPC error code `-32042`, carries credentials and receipts in `_meta` under `org.paymentauth` keys, and names `tools/call`, `resources/read`, and `prompts/get` as the MCP operations that can be put behind a payment. That is the settlement layer wiring itself directly into the discovery layer, and it is the most commerce-relevant thing the MPP family has produced: a merchant's MCP server could charge per tool call. Two caveats. It is an individual Internet-Draft of intended status Informational with no working group, like the rest of the family. And it still cites MCP revision `2025-11-25`, two revisions behind current, which is a fair measure of how early this is. ## What to watch The trajectory is clear: a land-grab phase of competing vendor announcements in 2025, followed in 2026 by consolidation into neutral standards bodies (the FIDO Alliance and the Linux Foundation) and a settling-out between the two commerce-layer camps, ACP and UCP. August tightened that consolidation a notch, with A2A joining MCP inside the Agentic AI Foundation. Three open questions sit at the end of this window. First, whether consolidation continues into the formal standards world. The July `agentproto` BoF was the first test, and the IETF has now partly answered: the Datatracker records `agentproto` as a **Proposed** working group, with its charter in External Review and on the agenda of the **8 October 2026 IESG telechat**; a revised text, `charter-ietf-agentproto-00-04`, was posted on 2 October with two Yes positions already recorded and no Block outstanding. That is a decision due days from this update rather than an open question, and the rewritten charter has narrowed the work to a baseline agentic dialog management protocol in which MCP and A2A carry the dialog context using their own mechanisms rather than being redesigned, on milestones running to March 2028. Second, whether the counter-movement matters: the Agentic Payments Alliance formed in August as a vendor coalition, not a standards body, which is the shape the industry was supposedly growing out of. Third, and newest, what the incumbent payments industry does now that it has arrived, on two fronts at once: EMVCo's draft framework closed for comment on 30 September, and whether Intent Services becomes a specification is the question to carry into the fourth quarter; and the Ant International, Mastercard, and Visa Know-Your-Agent collaboration announced on 9 September has to turn shared principles into something implementable. Agent identity is now being worked on in at least five places (FIDO, the MCP roadmap, Rain's coalition, EMVCo, and this collaboration), which says more about how unsettled it is than about how close it is to settling, and the Ninth Circuit's August ruling is a reminder that the courts will reach the question whether or not the standards bodies get there first. For how the pieces relate, see [the landscape](/landscape/agentic-commerce-landscape) and [the protocol stack](/learn/agentic-commerce-protocol-stack). Primary sources: - WebMCP support for checkout: https://shopify.dev/changelog/posts/webmcp-support-for-checkout - WebMCP support for Liquid and Hydrogen storefronts: https://shopify.dev/changelog/webmcp-liquid-hydrogen - Checkout WebMCP (Shopify developer documentation): https://shopify.dev/docs/agents/carts-and-checkout/checkout-webmcp - Mastercard unveils Agent Pay: https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - Visa Intelligent Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - x402 protocol: https://github.com/x402-foundation/x402 - Perplexity selects PayPal to power agentic commerce: https://newsroom.paypal-corp.com/2025-05-14-Perplexity-Selects-PayPal-to-Power-Agentic-Commerce - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Coinbase and Cloudflare on the x402 Foundation: https://blog.cloudflare.com/x402/ - Stripe and OpenAI launch Instant Checkout: https://stripe.com/newsroom/news/stripe-openai-instant-checkout - Walmart partners with OpenAI: https://corporate.walmart.com/news/2025/10/14/walmart-partners-with-openai-to-create-ai-first-shopping-experiences - OpenAI and PayPal team up for Instant Checkout: https://newsroom.paypal-corp.com/2025-10-28-OpenAI-and-PayPal-Team-Up-to-Power-Instant-Checkout-and-Agentic-Commerce-in-ChatGPT - Donating the Model Context Protocol: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation - NRF 2026 remarks introducing UCP: https://blog.google/company-news/inside-google/message-ceo/nrf-2026-remarks/ - Donating the Agent Payments Protocol to the FIDO Alliance: https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/ - AAA and industry leaders launch legal protocol for agentic commerce: https://www.adr.org/press-releases/aaa-and-industry-leaders-launch-legal-protocol-for-agentic-commerce/ - The "Payment" HTTP Authentication Scheme (draft-ryan-httpauth-payment): https://datatracker.ietf.org/doc/draft-ryan-httpauth-payment/ - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - Visa Opens the Door to AI-Driven Shopping for Businesses Worldwide (Intelligent Commerce Connect): https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22276.html - Amazon, Meta, Microsoft, Salesforce, and Stripe join the UCP Tech Council: https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council - New Universal Commerce Protocol features and AI tools (Google Marketing Live 2026): https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - Coinbase and AWS let publishers accept agents as customers via x402: https://www.coinbase.com/blog/coinbase-and-aws-let-publishers-accept-agents-as-customers-via-x402 - Cloudflare Monetization Gateway: https://blog.cloudflare.com/monetization-gateway/ - Linux Foundation announces operational launch of x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - The 2026-07-28 Specification: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - Announcing the new Food Tech Council members (UCP): https://github.com/Universal-Commerce-Protocol/ucp/discussions/593 - Simplify MPP integrations with relays: https://mpp.dev/blog/relays - Service Discovery for HTTP Payment Authentication (draft-payment-discovery-00): https://paymentauth.org/draft-payment-discovery-00.html - Minutes IETF 126: Agent Communication Protocols (agentproto) WG-forming BoF: https://datatracker.ietf.org/doc/minutes-126-agentproto-202607230700/ - Agent Communication Protocols (agentproto) group status: https://datatracker.ietf.org/wg/agentproto/about/ - New Non-WG Mailing List: agentproto, Agent Communication Protocols: https://mailarchive.ietf.org/arch/msg/ietf-announce/iJ6APXZyFA8cK-D0xMOSPE5IL1g/ - A2A joins AAIF's open agentic stack: https://aaif.io/blog/a2a-joins-aaif - Rain launches the Agentic Payments Alliance to guide the future of agent-driven commerce: https://www.rain.xyz/resources/rain-launches-the-agentic-payments-alliance - The New MCP Roadmap: https://blog.modelcontextprotocol.io/posts/mcp-roadmap/ - Announcing the new Payments Tech Council members (UCP): https://github.com/Universal-Commerce-Protocol/ucp/discussions/798 - Ant International, Mastercard and Visa Initiate Collaboration on Know-Your-Agent Interoperability to Scale Agentic Commerce: https://www.ant-intl.com/en/news/detail/?id=ant-international-mastercard-and-visa-initiate-collaboration-on-know-your-agent-interoperability-to-scale-agentic-commerce - The "Payment" HTTP Authentication Scheme (draft-httpauth-payment): https://datatracker.ietf.org/doc/draft-httpauth-payment/ - UCP announcements (v2026-08-25 release, Lodging and Payments Tech Councils): https://ucp.dev/documentation/announcements/ - UCP protocol release v2026-08-25: https://github.com/Universal-Commerce-Protocol/ucp/releases/tag/v2026-08-25 - How EMVCo is Working to Enable Secure, Interoperable and Scalable Card-Based Agentic Payments: https://www.emvco.com/knowledge-hub/how-emvco-is-working-to-enable-secure-interoperable-and-scalable-card-based-agentic-payments/ - Claude for commerce agents: https://claude.com/blog/claude-for-commerce-agents - Payment Authentication Scheme: JSON-RPC & MCP Transport (draft-payment-transport-mcp-00): https://paymentauth.org/draft-payment-transport-mcp-00.html - Block joins the x402 Foundation to advance open agentic commerce: https://block.xyz/inside/block-joins-the-x402-foundation-to-advance-open-agentic-commerce - Agent Communication Protocols (agentproto) proposed charter, External Review: https://datatracker.ietf.org/doc/charter-ietf-agentproto/ - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ - Millions of merchants can sell in AI chats (Agentic Storefronts): https://www.shopify.com/news/agentic-commerce-momentum - Introducing Muse: The World's First Personal AI Agent Built for Everyone: https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/ - Mastercard advances agentic commerce with new trust and intelligence services: https://www.mastercard.com/us/en/news-and-trends/press/2026/september/new-trust-and-intelligence-services.html - Order denying rehearing en banc, Amazon.com Services v. Perplexity AI, No. 26-1444: https://www.courthousenews.com/wp-content/uploads/2026/09/amazon-perplexity-no-rehearing.pdf --- # The Agentic Commerce Landscape URL: https://agenticcommerceatlas.com/landscape/agentic-commerce-landscape Markdown URL: https://agenticcommerceatlas.com/landscape/agentic-commerce-landscape.md Section: landscape Updated: 2026-10-01 A map of who is building what in agentic commerce, organized by the layer they operate in. The field is moving quickly, so treat this as a snapshot rather than a fixed picture. ## The stack, in one view Agentic commerce divides into layers, and most organizations occupy one or two of them: the **agent surfaces** where shopping happens, the **commerce protocols** that run the shopping journey, the **payment-authorization** layer that proves you approved a purchase, the **networks and processors** that move the money, the **platforms and merchants** that sell, and the **standards bodies** that steward the open specifications. The map below follows that order.
Agent & model providers
OpenAIGoogleAnthropicMicrosoftAmazonPerplexityMeta
Commerce protocols
ACPUCPMCPA2A
Payment authorization
AP2Verifiable Intent
Networks & processors
VisaMastercardAmexStripePayPal
Legal context & recourse
LCPAAA-ICDRIntegra Ledger
Platforms & merchants
ShopifyEtsyWalmartTargetWayfair
Settlement & standards
x402MPPCoinbaseTempoFIDO AllianceLinux FoundationEMVCo
## Who backs each standard
  • ACP · CheckoutAgentic Commerce Protocol

    OpenAI and Stripe in founding governance; OpenAI, Stripe, and Meta listed as lead maintainers.

    Apache 2.0
  • UCP · CheckoutUniversal Commerce Protocol

    Google, Shopify and Stripe on the Governing Council, over per-domain Tech Councils: Shopping (16 seats across Google, Shopify, Etsy, Target, Wayfair, Amazon, Meta, Microsoft, Salesforce, Stripe), Food (seated July 2026), Lodging (seated August 2026) and Payments (seated September 2026: Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, Stripe). Current spec revision v2026-08-25; a first draft Lodging Booking capability was merged 25 September 2026.

    Google-led
  • AP2 · AuthorizationAgent Payments Protocol

    Created by Google with more than 60 launch organizations, and donated to the FIDO Alliance on 28 April 2026. Still v0.2, with no stable release and reference implementations that mock real payment providers.

    FIDO Alliance
  • MCP · DiscoveryModel Context Protocol

    Created by Anthropic, now held by the Agentic AI Foundation, a directed fund under the Linux Foundation. Current spec revision 2026-07-28.

    Agentic AI Foundation
  • A2A · CoordinationAgent-to-Agent

    Created by Google, donated to the Linux Foundation in 2025, and a hosted project of the Agentic AI Foundation since 17 August 2026. At v1.0 since March 2026 and v1.0.1 since May 2026, with more than 150 supporting organizations reported at its one-year mark in April 2026.

    Agentic AI Foundation
  • x402 · Settlementx402

    Contributed by Coinbase, now stewarded by the x402 Foundation, operational under the Linux Foundation since July 2026, with 40 members at launch and more since. Block joined in September 2026, contributing Bitcoin Lightning.

    Linux Foundation
  • MPP · SettlementMachine Payments Protocol

    Stripe and Tempo.

    Stripe + Tempo
Notice the overlaps: Stripe backs ACP, UCP, and MPP; Meta backs ACP and UCP; Google backs AP2 and UCP (plus A2A). The standards are still settling, which is why several big names hedge across more than one.
## Agent and model providers These are the surfaces where agentic shopping happens. **OpenAI** built the first major in-chat buying experience, Instant Checkout, and co-created the ACP standard; since March 2026 it has concentrated on product discovery and let merchants keep their own checkout. **Google** is pushing agentic shopping through AI Mode in Search and the Gemini app, and authored both the UCP commerce protocol and the AP2 payments protocol. **Anthropic** created MCP, the discovery layer the rest of the stack plugs into. **Microsoft** sells through Copilot, where Shopify says thousands of its merchants are already live, and **Amazon** joined the UCP Tech Council in April 2026, bringing the largest US retailer-platform into the open-standard camp. **Perplexity** partnered early with PayPal for in-chat checkout, and has since become the field's most consequential litigant rather than merely an early integrator: on 4 August 2026 the Ninth Circuit vacated the preliminary injunction Amazon had won against its Comet agent, holding that for CFAA purposes it was the user, not Perplexity, who accessed Amazon's computers, and that the agent "is a tool, not a person for statutory purposes." The full Ninth Circuit declined to rehear the case on 10 September 2026, with no judge requesting a vote. See [the timeline](/landscape/agentic-commerce-timeline) for the ruling and its limits. **Meta** became an agent operator rather than only a standards backer on 8 September 2026, when it launched **Muse**, a US consumer agent that runs its own browser in a cloud virtual machine, asks before it buys, and pays through Link by Stripe's one-time-use cards. Note what it does not use: Meta names no commerce protocol for Muse, so it shops the way a person does, through the merchant's ordinary website, whether or not the merchant has integrated anything. ## Commerce protocols The standards that define how an agent runs a purchase with a merchant. **ACP (Agentic Commerce Protocol)**, governed by OpenAI and Stripe as founding maintainers and listing OpenAI, Stripe, and Meta as lead maintainers in `MAINTAINERS.md`, is the checkout layer. **UCP (Universal Commerce Protocol)**, Google's standard, covers the broader shopping journey and is ACP's main rival; it is governed by a Governing Council that oversees overall adoption and health (Google, Shopify, and Stripe, which joined in April 2026, with two seats open for election) sitting over per-domain Tech Councils. The Shopping Tech Council expanded to 16 seats on 24 April 2026 when Amazon, Meta, Microsoft, Salesforce, and Stripe joined Google, Shopify, Etsy, Target, and Wayfair; all sixteen seats are filled across those ten companies. A Food Tech Council was seated on 16 July 2026 with Block (Square), DoorDash, Google, Toast, and Uber Eats, and a Lodging Tech Council on 11 August 2026 with Amadeus, Booking.com, Expedia, Google, Hilton, Marriott, and Trip.com, bringing global distribution, online travel agencies, and hotel groups inside UCP governance. A fourth, the Payments Tech Council, was seated on 2 September 2026 with Adyen, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe, the first UCP council organized around a capability rather than a retail vertical. Google holds four of the sixteen Shopping seats and six of the ten filled Food seats, which is worth holding alongside the open-governance framing. Its current spec revision is `v2026-08-25`, released 25 August 2026, which reorganized the specification into Common, Shopping, and Payment groups so payment sits above any one vertical, added EMV 3-D Secure payment authentication, and carries breaking changes. Three vertical councils in five weeks, a payment layer lifted out of shopping, and then a Payments council seated to govern it are the same move made repeatedly: UCP is being rebuilt as multi-vertical infrastructure with retail as its first vertical. At Google Marketing Live in May 2026 Google extended UCP with named-brand Universal Cart (Nike, Sephora, Target, Walmart, Wayfair, and Shopify merchants) and into new verticals, hotel booking and food delivery. **MCP (Model Context Protocol)**, created by Anthropic and now held by the Agentic AI Foundation, is the discovery layer; its `2026-07-28` revision made the protocol core stateless. **A2A (Agent-to-Agent)** standardizes coordination between agents; it reached v1.0 in March 2026 and, on 17 August 2026, moved from the Linux Foundation's broader portfolio into the Agentic AI Foundation, so it now sits under the same governance as MCP. See [the protocol stack](/learn/agentic-commerce-protocol-stack) for how they compare. ## Payment authorization and trust The layer that proves a real user authorized a specific purchase. **AP2 (Agent Payments Protocol)**, created by Google and donated to the FIDO Alliance on 28 April 2026 alongside a v0.2 release, is the leading standard here, using signed mandates as verifiable credentials. It remains at v0.2 with no stable release, and Visa co-chairs the FIDO Payments Technical Working Group developing it. FIDO has published no specification from the contribution, and the repository, documentation, and copyright are still Google's, so what moved to FIDO is future standardization rather than the artifacts. Stripe is not named among AP2's backers and supports ACP and MPP instead, though no first-party roster confirms it is outside FIDO's agentic work. **Mastercard's Verifiable Intent**, co-developed with Google and also contributed to FIDO, is a compatible effort. The **FIDO Alliance** now stewards both. See [AP2 explained](/learn/ap2-explained). ## Payment networks **Visa** launched Intelligent Commerce in April 2025, with tokenized "AI-Ready Cards," and led the Trusted Agent Protocol to help merchants tell legitimate agents from bots; on 8 April 2026 it added Intelligent Commerce Connect, a network-, protocol- and token-vault-agnostic acceptance "on ramp" that lets merchants accept payments initiated over the Trusted Agent Protocol, MPP, ACP, and UCP (AP2 is not among the named protocols). Visa's own announcement describes it as in pilot with select partners, including Aldar, AWS, Diddo, Highnote, Mesh, Payabli, and Sumvin, and rolling out to more through the year. Trade reporting pointed to general availability by the end of June 2026, but that date has passed and Visa has published no first-party confirmation of general availability. **Mastercard** launched Agent Pay, built on agentic tokens and payment passkeys, also in April 2025, and on 30 September 2026 added trust and intelligence services that it calls the intelligence layer of its Agent Pay Trust Framework, starting with a score for how likely a transaction is to have been initiated by an agent. That score is rolling out for testing in the US, not generally available. **American Express** entered in April 2026 with a developer kit and an industry-first purchase-protection pledge for registered agents. See [how AI agents pay](/learn/how-ai-agents-pay). ## Processors and providers **Stripe** co-created ACP and powered ChatGPT's Instant Checkout through its Shared Payment Token, which was the most concretely live consumer flow until OpenAI shifted its emphasis to product discovery in March 2026. Instant Checkout was narrowed rather than retired, and OpenAI's developer documentation still describes it as available to approved partners. The Shared Payment Token remains the mechanism ACP integrations use. The flow that replaced it as the most concretely live is not a payment provider's at all: see Shopify, below. Stripe also co-authored the Machine Payments Protocol (MPP) with Tempo for machine-to-machine payments, joined the UCP Tech Council in April 2026, and supports both MPP and x402. **PayPal** is both an AP2 partner and an early MCP-server provider, and has adopted ACP. **Adyen, Worldpay, Checkout.com, and Braintree** appear across the protocol partner lists. ## Platforms and merchants **Shopify** co-developed UCP, and on 24 March 2026, the same day OpenAI stepped back from in-chat checkout, it made itself the largest single route into AI shopping. **Agentic Storefronts** made "millions of merchants" sellable to ChatGPT users, discoverable "by default" with no separate integration and no transaction fees beyond standard processing, with the same panel reaching Microsoft Copilot, AI Mode in Search, and the Gemini app. The purchase completes on the merchant's own checkout, in an in-app browser on mobile, and the merchant stays merchant of record. That is now the most concretely live consumer flow in agentic commerce, and its shape matters: the agent does discovery, the platform supplies the catalog, and checkout never leaves the merchant. Shopify's Agentic plan, opened globally the same day, extends Shopify Catalog to brands that do not use Shopify for ecommerce. Shopify is also making its stores callable by browser agents, not only by protocol integrations: WebMCP tools for catalog, cart, and orders went live on every Liquid storefront on 5 August 2026, and on 28 September 2026 Shopify extended them to checkout, with the buyer confirming the order before the agent submits it. Shopify describes Checkout WebMCP as the UCP checkout capability delivered through browser-registered tools, so one checkout object now serves both the protocol route and the browser-agent route. **Etsy** was the first merchant genuinely live on ACP. **Walmart** announced ChatGPT buying and is a UCP co-developer. **Target, Wayfair, Best Buy, and Macy's** are aligned with UCP. Merchants generally remain the merchant of record across these standards. ## Standards bodies and foundations **The FIDO Alliance** stewards AP2 and Verifiable Intent, both contributed on 28 April 2026. Neither is yet a FIDO specification: FIDO describes them as contributions that will be reviewed and developed through its own process, in a 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. **The Linux Foundation** hosts the **Agentic AI Foundation**, a directed fund co-founded by Anthropic, Block, and OpenAI in December 2025, and the **x402 Foundation**, which became operational on 14 July 2026 with 40 members at launch and has grown since. The Agentic AI Foundation grew on **17 August 2026**, when **A2A** joined it as a hosted project, moving out of the Linux Foundation's broader portfolio into the body that already held MCP, goose, AGENTS.md, agentgateway, and Agent Router. Each project keeps its own maintainers and release schedule, so nothing changed in either specification, but the agent layer's two load-bearing protocols, tool access and agent coordination, are now governed in one neutral place. A third venue is being tested. 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 formal Internet standards rather than only consortium governance. The draft minutes record strong support for forming a group and for the IETF as the venue, but the proposed scope was rejected, and the datatracker still lists `agentproto` as a BoF with no charter. On **24 July 2026** the IETF Secretariat opened a non-working-group mailing list, `agentproto@ietf.org`, explicitly for updating the proposed charter and working toward forming a group. That is the rewrite happening in public, not a decision. MCP, A2A, and the MPP drafts all sit in its shadow. Read it as the question being asked, not answered. **EMVCo**, the body jointly owned by American Express, Discover, JCB, Mastercard, UnionPay, and Visa that maintains the EMV chip, tokenization, 3-D Secure, and Secure Remote Commerce specifications, entered the field formally on **1 September 2026**. It published a draft, *EMV Agentic Payments: Framework for Specifications v1.0*, for public comment, and stood up an Agentic Payments Task Force to develop its approach. **That comment period closed on 30 September 2026**, and EMVCo has not yet published a disposition of comments or any specification arising from it. The draft's central proposal is **Intent Services**: a shared, interoperable layer that lets payment participants register, reference, retrieve, and manage consumer-authorized intent before, during, and after a transaction. EMVCo's stated focus is the scenarios where intent has to persist rather than be proved once, such as recurring purchases, cumulative budgets, and post-transaction activity, and it positions Intent Services as complementing cryptographic approaches like Mastercard's Verifiable Intent rather than replacing them. It says the work may later extend to **Know Your Agent** and **Agentic Transaction Indicators**, and could inform changes to EMV 3DS, payment tokenization, SRC, and the Digital Payment Credential. It is collaborating with the FIDO Alliance, the OpenID Foundation, the OpenWallet Foundation, and W3C. Two things make this worth its own paragraph. It is a **draft framework, not a specification**: nothing is published to build against, and the comment period closed on 30 September 2026 without a published outcome. And EMVCo is owned by the six card networks, so unlike a vendor coalition its output tends to become the thing acquirers and issuers implement. If agent identity and persistent consumer intent are the unsettled layer, this is the card industry's own answer to it, arriving alongside FIDO's. A further kind of body appeared in August, and it is worth naming for what it is not. On **18 August 2026** the stablecoin infrastructure company **Rain** launched the **Agentic Payments Alliance**, a coalition of 26 founding members including Visa, Mastercard, Fiserv, Circle, Solana, Uniswap Labs, Chainalysis, Fireblocks, Shift4, Lithic, and Remitly. Rain describes it as a working coalition run collectively by its founding members rather than owned by any one company, with early work expected to cover shared research and frameworks, testing emerging standards for agent identity and authorization, and advocacy on regulatory questions. It publishes no specification and stewards no protocol, so it does not belong in the same category as FIDO or the Linux Foundation. What makes it worth tracking is the subject: how an agent proves who it is acting for and how much it may spend is the one layer where no standard has settled, and the same networks that co-chair FIDO's Payments working group have now also joined a vendor coalition looking at it. That layer gained a fifth effort in September. On **9 September 2026** **Ant International, Mastercard, and Visa** announced a collaboration on **Know-Your-Agent interoperability**, so that card networks, wallet ecosystems, agent platforms, and marketplaces can recognize a trusted agent without each running a separate identity check. The named work is cross-network operator traceability linking an agent to a validated operator, cardholder, or business; shared certification against common security and behavioral requirements; and continuous monitoring using identity and transaction signals. Each network keeps its own verification and decisioning, and the three existing approaches it is meant to bridge stay in place: Visa's Trusted Agent Protocol, Mastercard's Verifiable Intent, and Ant International's Agentic Mobile Protocol. The work runs through **BuildFin.ai**, an industry platform convened by the Monetary Authority of Singapore, which makes this the first agent-identity effort with a financial regulator's platform underneath it. Read it for what it is: a statement of intent with no specification, governance body, or timeline published. Counting FIDO's Agentic Authentication working group, MCP's roadmap agent-identity priority, Rain's coalition, EMVCo's draft framework, and now this, five separate efforts are circling agent identity. That is the shape of an unsolved problem. See [the announcement](/news/know-your-agent-interoperability-ant-mastercard-visa). ## Crypto and stablecoin rails **Coinbase** created x402, the HTTP-native stablecoin protocol for machine-to-machine payments, with **Circle** (USDC), the **Ethereum Foundation**, and **MetaMask** in the ecosystem. Google aligned it with AP2 through an x402 extension. By mid-2026 x402 was moving from concept to infrastructure: **AWS** made it generally available at the edge in CloudFront and AWS WAF, and **Cloudflare** opened a waitlist for an x402-based Monetization Gateway. In **July 2026** the **Linux Foundation** announced the operational launch of the **x402 Foundation** under formal open governance with 40 members; its premier tier now spans 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), a notable mainstreaming of a crypto-native rail. **Stripe and Tempo** added the [Machine Payments Protocol (MPP)](/learn/mpp-explained) in March 2026, a second machine-native standard in the same lane that settles in stablecoins as well as cards. The two have taken different governance routes: x402 to a Linux Foundation body, MPP to the IETF, where its core was submitted on 18 March 2026 as an individual Internet-Draft that has not yet been taken up by a working group. That core draft was refreshed on 9 September 2026 under a shorter name without the author prefix, `draft-httpauth-payment-01`, extending its life to 13 March 2027; the Datatracker still records it as an individual submission with no working group and no RFC stream. ## Legal context and recourse (emerging) A newer and much less settled category, covering what the parties agreed to and what happens when a transaction goes wrong. Every layer above answers a mechanical question, who found what, who authorized it, how the money moved, and every one of them leaves terms, jurisdiction, and dispute resolution out of scope. AP2 says so explicitly. **The Legal Context Protocol (LCP)**, launched on 24 June 2026, is the most credible entrant so far. It is co-stewarded by **Integra Ledger** and the **American Arbitration Association-International Centre for Dispute Resolution (AAA-ICDR)** as Founding Maintainers, with founding contributors including **Google, IBM, Circle, Wayfair, Stellar Development Foundation, Ava Labs, UiPath, Cardano, Hedera, and Mysten Labs**. A business publishes one Apache 2.0-specified JSON file at `/.well-known/legal-context.json` pointing to its terms, optionally with a hash proving what those terms said and a flag requiring signed acceptance. Treat it as early: the v1.0 specification is a draft released for community review, and none of the protocols it proposes to attach to has adopted it. See [LCP explained](/learn/lcp-explained). Also in this category, and further back: the **A-Comm Evidence Protocol (AEP)**, a single-vendor draft evidence and audit standard from A-Comm Technologies that was open for public comment through 14 August 2026 with no named adopters or governing body. The Atlas is watching it rather than mapping it. ## How to read the map Three patterns are worth noticing. First, the big platform companies are hedging: Stripe and Meta are associated with both ACP and UCP, and Google spans protocols, payments, and a surface. Second, the open standards are consolidating into neutral bodies, FIDO and the Linux Foundation, and the established payments standards bodies have now arrived too, with EMVCo opening a draft framework for card-based agentic payments in September 2026. That is usually a sign a field is maturing past the land-grab phase. Third, and most useful if you are deciding where the gaps are, the mature layers are the mechanical ones. Discovery, checkout, authorization, and settlement all have working standards with real backers. Recourse does not, and the entrants trying to fill it are at draft stage. For the dated sequence of how this came together, see [the timeline](/landscape/agentic-commerce-timeline). Primary sources: - WebMCP support for checkout: https://shopify.dev/changelog/posts/webmcp-support-for-checkout - WebMCP support for Liquid and Hydrogen storefronts: https://shopify.dev/changelog/webmcp-liquid-hydrogen - OpenAI: Buy it in ChatGPT (ACP): https://openai.com/index/buy-it-in-chatgpt/ - Universal Commerce Protocol launch: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Donating the Model Context Protocol: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation - Visa Intelligent Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html - Mastercard unveils Agent Pay: https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html - Amazon, Meta, Microsoft, Salesforce, and Stripe join the UCP Tech Council: https://www.newsfilecorp.com/release/294133/Amazon-Meta-Microsoft-Salesforce-and-Stripe-Join-the-Universal-Commerce-Protocol-Tech-Council - Coinbase and AWS let publishers accept agents as customers via x402: https://www.coinbase.com/blog/coinbase-and-aws-let-publishers-accept-agents-as-customers-via-x402 - Linux Foundation announces operational launch of x402 Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications - AAA and industry leaders launch legal protocol for agentic commerce: https://www.adr.org/press-releases/aaa-and-industry-leaders-launch-legal-protocol-for-agentic-commerce/ - Legal Context Protocol specification (GitHub): https://github.com/legal-context-protocol/legal-context-protocol - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - Visa Opens the Door to AI-Driven Shopping for Businesses Worldwide (Intelligent Commerce Connect): https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.22276.html - New Universal Commerce Protocol features and AI tools (Google Marketing Live 2026): https://blog.google/products-and-platforms/products/shopping/shopping-updates-google-marketing-live/ - Linux Foundation announces the formation of the Agentic AI Foundation: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation - The 2026-07-28 Specification (MCP): https://blog.modelcontextprotocol.io/posts/2026-07-28/ - We're donating Agent Payments Protocol to the FIDO Alliance: https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/ - Announcing new Tech Council members (UCP): https://github.com/Universal-Commerce-Protocol/ucp/discussions/379 - How EMVCo is Working to Enable Secure, Interoperable and Scalable Card-Based Agentic Payments: https://www.emvco.com/knowledge-hub/how-emvco-is-working-to-enable-secure-interoperable-and-scalable-card-based-agentic-payments/ - UCP announcements (v2026-08-25 release, Lodging and Payments Tech Councils): https://ucp.dev/documentation/announcements/ - Ant International, Mastercard and Visa Initiate Collaboration on Know-Your-Agent Interoperability to Scale Agentic Commerce: https://www.ant-intl.com/en/news/detail/?id=ant-international-mastercard-and-visa-initiate-collaboration-on-know-your-agent-interoperability-to-scale-agentic-commerce - The "Payment" HTTP Authentication Scheme (draft-httpauth-payment): https://datatracker.ietf.org/doc/draft-httpauth-payment/ - FIDO Alliance to Develop Standards for Trusted AI Agent Interactions: https://www.businesswire.com/news/home/20260427506015/en/FIDO-Alliance-to-Develop-Standards-for-Trusted-AI-Agent-Interactions - A2A joins AAIF's open agentic stack: https://aaif.io/blog/a2a-joins-aaif - Rain launches the Agentic Payments Alliance to guide the future of agent-driven commerce: https://www.rain.xyz/resources/rain-launches-the-agentic-payments-alliance - New Non-WG Mailing List: agentproto, Agent Communication Protocols: https://mailarchive.ietf.org/arch/msg/ietf-announce/iJ6APXZyFA8cK-D0xMOSPE5IL1g/ - Minutes IETF 126: Agent Communication Protocols (agentproto) WG-forming BoF: https://datatracker.ietf.org/doc/minutes-126-agentproto-202607230700/ - Agent Communication Protocols (agentproto) group status: https://datatracker.ietf.org/wg/agentproto/about/ - Boost your holiday sales with these agentic commerce updates: https://blog.google/products/ads-commerce/agentic-commerce-holiday-updates/ - Agentic Commerce key concepts (Instant Checkout availability): https://developers.openai.com/commerce/guides/key-concepts - Millions of merchants can sell in AI chats (Agentic Storefronts): https://www.shopify.com/news/agentic-commerce-momentum - Introducing Muse: The World's First Personal AI Agent Built for Everyone: https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/ - Mastercard advances agentic commerce with new trust and intelligence services: https://www.mastercard.com/us/en/news-and-trends/press/2026/september/new-trust-and-intelligence-services.html - Order denying rehearing en banc, Amazon.com Services v. Perplexity AI, No. 26-1444: https://www.courthousenews.com/wp-content/uploads/2026/09/amazon-perplexity-no-rehearing.pdf - Powering Product Discovery in ChatGPT: https://openai.com/index/powering-product-discovery-in-chatgpt/ --- # Agentic Commerce Turns to the Merchant's Own Side URL: https://agenticcommerceatlas.com/news/agentic-commerce-merchant-side-2026 Markdown URL: https://agenticcommerceatlas.com/news/agentic-commerce-merchant-side-2026.md Section: news During the week of 6 to 10 July 2026, agentic commerce news was quieter than the previous week, when Europe's payment rails went live at the [Visa Payments Forum in Paris](/news/european-agentic-commerce-goes-live-2026). The most interesting news was on either side of the payment rather than on the payment itself, and primarily on the merchant's side: the agents a business deploys on its own channels, and the product data it makes readable by agents. Where the earlier headlines this year came from the large platforms and the card networks, this week they came from a CRM company, a product-data company and one national market. Taken together, they point to agentic commerce becoming something a business stands up and owns, rather than only a capability that lives on someone else's assistant. ## Salesforce makes its Agentforce Commerce agents generally available In a press release dated 6 July, Salesforce said three commerce agents are now generally available. The Shopper Agent carries a customer conversation from discovery through checkout and into service on the brand's own storefront. The Buyer Agent handles B2B ordering inside WhatsApp and SMS. The Merchant Agent runs back-office catalog and merchandising work in natural language, organizing catalogs and sorting products from plain-language instructions. Salesforce said the agents integrate natively with ChatGPT, with Google Search, including its AI Mode, and the Gemini app described as arriving in the coming months, and positioned the release as one platform spanning B2C, B2B, point of sale and order management, grounded in the customer's own data. Most agentic commerce coverage this year has been about being discovered and paid on someone else's platform. This release is the opposite: a business running its own agents on its own channels, wired into its own catalog, inventory and orders. The most novel of the three is arguably the B2B Buyer Agent, because it puts agent-mediated reordering inside WhatsApp and SMS with no portal login, which is close to how a lot of business reordering already happens. For Salesforce customers, this creates a choice that is now available: deploy your own commerce agent on your storefront and messaging channels, or wait to be found inside a third-party assistant. That choice, and the trade-off underneath it, is the subject of [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business) and, for retailers specifically, [agentic commerce for retailers](/learn/agentic-commerce-for-retailers). One detail worth flagging for builders: Salesforce framed the split as owned channels for the transaction and external assistants for discovery, and pointed to syndicated commerce through UCP as the longer-term route for pushing commerce directly into external channels. UCP is covered in the [UCP explainer](/learn/ucp-explained). ## Akeneo puts agents into the product-data work On 8 July, Akeneo announced its Summer Release, introducing Agentic Ziggy, an agentic layer inside its Product Cloud. Akeneo said it lets product-data teams deploy and oversee a fleet of specialist AI agents across the product-data lifecycle, covering data modeling, schema mapping, enrichment and quality checks, with a natural-language workspace, syndication error troubleshooting that translates retailer errors into plain guidance, and prompt-based image editing. Governance is described as a propose-and-approve model, with role-based permissions and visibility into what each agent did. Akeneo framed the work as getting product data ready for agentic commerce, including preparing a catalog for AI-powered shopping. The current advice to merchants is to make their catalogs machine-readable so agents can find and transact their products, which is the substance of [building a product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce). That work is often time-consuming and mostly unglamorous, and it sits inside product information management. What Akeneo described is applying agents to that preparation itself, so the tooling that cleans and structures product data is now partly agent-run. For a business with a large catalog across many channels, the readiness step and the execution step start to use the same kind of tooling. The open question is how well a propose-and-approve model holds up in practice, or whether teams gradually let more of the product-data work run without review, which is the kind of governance question the [risks and readiness](/learn/agentic-commerce-risks-and-readiness) guide raises. ## Mastercard switches on one more market On 8 July, Mastercard said it had completed a pilot delivering the first agentic transactions in Moldova, with the banks maib and Moldindconbank, through Mastercard Agent Pay. Per the release, the transactions run on the Know Your Agent trust framework, where an AI agent can transact after it is identified, registered, shows verified intent and is authenticated, with agentic tokens keeping each transaction, including recurring payments, inside the permissions and limits the consumer set, and biometric confirmation through Payment Passkeys. The design keeps the bank in the authorization seat and the agent identified before it acts, which is the same pattern described in [how AI agents pay](/learn/how-ai-agents-pay) and [agent payment authorization](/learn/ai-shopping-agent-payment-authorization). On its own, a first transaction in one market is a small item. Read alongside the rest of the year, it is part of a steady, market-by-market switch-on: Mastercard has announced Agent Pay firsts across several markets earlier in 2026, including New Zealand, Australia, India, South Korea, Latin America, the Netherlands and Ukraine, with Moldova the latest. The addition signals coverage building out quietly rather than a new capability. For a business selling across several markets, the ability to accept an agent-initiated payment is arriving country by country through local banks and networks, rather than all at once, so the map of where this works is worth tracking as it fills in. ## The pattern The week's activity sat on the merchant's own side of agentic commerce and on the edges of the payment map, not on the payment itself. Salesforce made a business's own selling and buying agents generally available. Akeneo put agents into the product-data work that makes a catalog readable to other agents. Mastercard added one more market to a rollout that already spans several continents. None of it was a platform launch or a new protocol. Taken together, these are signals that the near-term work of agentic commerce is becoming ordinary business work: standing up your own agents, cleaning your own product data, and waiting for your own market's rails to be switched on. That is a less dramatic phase than the one before it, and it may be the phase where most businesses actually start. For a sense of when this crosses from optional to expected, see [when agentic commerce becomes table stakes](/analysis/when-agentic-commerce-becomes-table-stakes). ## What it points to For a business that sells products, this week points at two pieces of internal work rather than a platform to react to. The first is product data. If a catalog needs to be legible to shopping agents, that work is unglamorous and has to be done, though the tooling for it is starting to run partly on agents; it is worth asking whether a given product-data platform is moving that way, and how much human approval it keeps. The [readiness checklist](/learn/agentic-commerce-readiness-checklist) is a practical starting point. The second is a choice about channels. Deploying a business's own commerce agent on its storefront and messaging channels is now an available option, not a research topic. For B2B sellers in particular, an agent that takes a reorder over WhatsApp or SMS, with no portal login, is a specific thing to evaluate this year; the trade-offs by business type are set out in [agentic commerce by business type](/learn/agentic-commerce-by-business-type). The businesses that treat agentic commerce as their own capability to build, rather than only a platform to be found on, are the ones positioning to keep the customer relationship. For the underlying concepts, see [what agentic commerce is](/learn/what-is-agentic-commerce). ## FAQ **What were the main developments in the week of 6 to 10 July 2026?** Three, all on the merchant's side rather than the payment: Salesforce made its Agentforce Commerce agents (Shopper, Buyer, Merchant) generally available, Akeneo introduced Agentic Ziggy to make catalogs agent-ready, and Mastercard completed a first agent-initiated payment in Moldova. **What is the near-term work for a merchant?** Making product data legible to shopping agents, and deciding whether to deploy your own commerce agents on your own storefront and messaging channels rather than waiting to be found on a third-party platform. For B2B, agent-mediated reordering over messaging is now a shipped product to evaluate. Primary sources: - As AI Agents Transform Commerce, Salesforce Unleashes Its Biggest Agentforce Commerce Release Yet: https://www.salesforce.com/ap/news/press-releases/2026/07/06/as-ai-agents-transform-commerce-salesforce-unleashes-its-biggest-agentforce-commerce-release-yet/ - Akeneo Summer 2026 Release: introducing Agentic Ziggy: https://www.akeneo.com/seasonal-release/summer-26/ - Mastercard completes Moldova's first payments executed by an AI agent with maib and Moldindconbank: https://www.mastercard.com/news/eemea/en/newsroom/press-releases/en/2026/mastercard-completes-moldova-s-first-payments-executed-by-an-ai-agent-with-maib-and-moldindconbank/ --- # Ant International, Mastercard and Visa Begin Work on Know-Your-Agent Interoperability URL: https://agenticcommerceatlas.com/news/know-your-agent-interoperability-ant-mastercard-visa Markdown URL: https://agenticcommerceatlas.com/news/know-your-agent-interoperability-ant-mastercard-visa.md Section: news Updated: 2026-09-13 Ant International, Mastercard and Visa have begun a collaboration on a **Know-Your-Agent (KYA) interoperability framework**, announced on 9 September 2026 US time and reported on 10 September. The goal is that an AI agent verified on one payment network can be recognised across others, so that card networks, digital wallet ecosystems, agent platforms and marketplaces do not each have to run a separate onboarding and identity check for the same agent. Each network keeps its own verification and decisioning. At this stage the announcement is a statement of intent: no technical specification, governance body or rollout timeline has been published. *Editor's note: this page is built from the Business Wire announcement as quoted and linked by PYMNTS, The Next Web and Forkast, plus CNBC's reporting of an interview with Ant International. The release was not retrieved directly during drafting, so quoted wording is reported as those outlets render it. Scope, participants and timing should be re-checked against the companies' own materials.* ## What was announced The three companies said they are initiating work toward common approaches for AI agent verification, accountability and risk management across payment ecosystems. Three areas of work are named: | Work area | What it means | |---|---| | Cross-network operator traceability | Linking each AI agent back to a validated operator, cardholder or business, so an agent's actions can be attributed to an accountable party. | | Shared certification | Assessing agents against common security and behavioural requirements, rather than each network running its own bar. | | Continuous monitoring | Ongoing assessment of an agent using identity and transaction signals, not a one-off check at onboarding. | Ant International's chief innovation officer Jiang-Ming Yang gave CNBC the plainest version of the objective: if an agent registers with Ant, it should not need to register again with Visa or Mastercard. Mastercard's chief digital officer Pablo Fourez is quoted in the announcement saying that interoperability across Know-Your-Agent frameworks is essential to making agentic commerce work at scale. Visa's Rubail Birwadker, global head of growth products and strategic partnerships, is quoted saying that as AI agents become a bigger part of how people discover and buy, trust must scale with them. ## Three protocols, one problem Each of the three companies already runs its own agent-trust protocol: - **Visa Trusted Agent Protocol (TAP)**, published on GitHub, covering how agents are authenticated and authorised at the transaction level. - **Mastercard Verifiable Intent**, an open standard for verifying that an agent's action reflects the user's intent. - **Ant International Agentic Mobile Protocol (AMP)**, connected to the Alipay+ wallet ecosystem. That is the problem the collaboration is aimed at. An agent operator facing three separate registration and certification regimes, and a merchant facing three separate trust signals, is the friction that keeps agent-initiated transactions in pilot territory. The announcement says the companies will now "explore ways to work toward common principles", which is a lower bar than converging the protocols. ## Where the work sits The collaboration runs through **BuildFin.ai**, an industry platform convened by the **Monetary Authority of Singapore** that brings together financial institutions, technology providers and researchers to develop AI solutions for financial services. The announcement says the work builds on MAS's **Safeguards for Agentic Finance at Runtime (SAFR)** framework and covers payment ecosystems in Singapore. That scoping matters for anyone reading this as a global standards move. The participants are global, but the announced venue and initial scope are Singaporean, and the regulator's framework is the reference point. Whether the output travels to US and European ecosystems is not addressed in the announcement. ## Why it matters Agent identity is the layer beneath everything else in agentic commerce. Protocols such as [ACP](/learn/acp-explained/), [UCP](/learn/ucp-explained/) and [AP2](/learn/ap2-explained/) define how an agent discovers a product, builds a cart and carries a mandate to pay. None of that resolves the merchant's first question, which is who this agent is, who operates it, what it was permitted to do, and who carries the loss when it goes wrong. Until that question has a portable answer, agent traffic is hard to distinguish from unattributed automation, and merchants default to blocking or to manual review. This is also the second network-level move in a week. On 9 September Mastercard announced [Agent Connect](/news/mastercard-agent-connect/), positioning itself at the merchant-to-agent integration point. The KYA collaboration addresses the layer below that: whether the agent arriving at that integration point can be trusted at all. The announcement cites a McKinsey projection that AI agents could orchestrate US$3 trillion to US$5 trillion of global consumer commerce by 2030. That figure is a projection made by a consultancy and quoted in a press release, not a measured market, and should be read accordingly. ## What to watch - **Whether a specification appears.** Common principles without published requirements does not change anything a merchant or agent operator can build against. - **Governance.** Three commercial competitors aligning on identity raises the question of who decides what counts as a certified agent, and whether the framework stays open or becomes a gate that favours incumbents. - **Geographic scope.** The named venue is Singapore. Movement into US and European ecosystems, or alignment with the EMVCo agentic payments work and the UK's Know Your Agent proposals, would be the signal that this is more than a regional pilot. - **Who else joins.** American Express, the account-to-account rails and the agent platforms themselves are absent from this announcement. ## Related reading - [How AI agents pay](/learn/how-ai-agents-pay/) - [The agentic commerce protocol stack](/learn/agentic-commerce-protocol-stack/) - [Agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness/) - [AI shopping agent payment authorization](/learn/ai-shopping-agent-payment-authorization/) Primary sources: - Ant International, Mastercard and Visa Initiate Collaboration on Know-Your-Agent Interoperability to Scale Agentic Commerce: https://www.businesswire.com/news/home/20260909003891/en/Ant-International-Mastercard-and-Visa-Initiate-Collaboration-on-Know-Your-Agent-Interoperability-to-Scale-Agentic-Commerce - Ant International partners with Visa, Mastercard on developing AI payments: https://www.cnbc.com/2026/09/10/ant-international-visa-mastercard-ai-agent-payment-standard.html - Visa, Mastercard and Ant International team up on ID checks for AI agents: https://thenextweb.com/news/visa-mastercard-ant-international-know-your-agent-ai-agents - Visa and Mastercard Team With Ant on Know Your Agent Framework: https://www.pymnts.com/cybersecurity/2026/visa-mastercard-team-with-ant-know-your-agent-framework/ - Ant International, Visa, and Mastercard Agree on Agent Identity Standard. Now Comes the Hard Part.: https://forkast.news/ant-international-visa-and-mastercard-agree-on-agent-identity-standard-now-comes-the-hard-part/ - Visa Trusted Agent Protocol: https://github.com/visa/trusted-agent-protocol --- # Anthropic Publishes an Open Commerce Agent Blueprint, and Leaves Payment to the Merchant URL: https://agenticcommerceatlas.com/news/anthropic-commerce-agent-blueprint Markdown URL: https://agenticcommerceatlas.com/news/anthropic-commerce-agent-blueprint.md Section: news Updated: 2026-09-13 On 2 September 2026 Anthropic published an open commerce agent blueprint: reference implementations of a shopping agent and a merchant agent built on Claude, released on GitHub with a Claude Code plugin and live demos for retail, travel, telecom and ticketing. Accenture, Mastercard and Visa are named as ecosystem partners, and Shopify has published its own implementation over UCP and Sign in with Shop. The shopping agent searches the catalogue, assembles a cart and hands it to checkout. Anthropic's announcement says payment is left to the merchant. *Editor's note: this page is built from Anthropic's announcement, the linked repositories and Shopify's public implementation, verified 4 September 2026. The performance figures quoted below are Anthropic's own and carry no published methodology; they are attributed rather than stated as fact.* ## What was released Anthropic describes the blueprint as containing "the harnesses, patterns, and guardrails an engineering team needs to get a commerce agent running in days". It is available at [github.com/anthropics/commerce-agents](https://github.com/anthropics/commerce-agents), and the code deploys on the Claude API, Amazon Bedrock, Microsoft Foundry or Google Cloud Vertex AI. The agents can be built using the Messages API, the Agent SDK, or Claude Managed Agents (beta). Two reference implementations ship in the repository. **The shopping agent** runs inside the merchant's own app or website. Anthropic lists integration points for catalog, cart, checkout, customer preferences and order history. The agent searches the catalogue and assembles multi-item orders, remembers customer preferences, renders products, comparisons and the cart in the conversation rather than as plain text, builds the cart and hands it to checkout, and answers customer service questions in the same conversation, including order status, returns, exchanges and refund policy. Anthropic states the agent "features guardrails designed to constrain prices and products to actual catalog data, and avoids manipulative upsell patterns". **The merchant agent** serves store operators. It answers sales performance questions, tracks inventory and flags problems such as an item about to sell out before a promotion starts, recommends pricing and promotions from the store's own sales history, and drafts marketing campaigns. Anthropic notes that when the agent proactively suggests a change, a person approves it before anything goes live. ## The boundary is where it stops The commercially significant sentence in Anthropic's announcement is about the shopping agent's integration points: the blueprint "leaves payment to you, whether that is your existing checkout or an agentic payments provider". Anthropic is not shipping a payment rail, a wallet, an agent credential scheme or a protocol of its own here. The agent builds the cart and hands it over. That is a deliberate boundary, and it sits Anthropic in a different position from the checkout-owning approach taken by OpenAI and Stripe with the Agentic Commerce Protocol, or by the card networks with their own agent payment products. Two shapes of agentic commerce are visibly forming. In the first, a buyer converses with a third-party assistant and the purchase completes on that assistant's surface. In the second, the merchant runs the agent on its own site, and keeps the customer relationship, the behavioural data and the payment relationship. This release is infrastructure for the second, and it does not foreclose the first: a merchant can adopt the blueprint and still route payment through an agentic payments provider. The Visa quote in the announcement makes that positioning explicit. Jack Forestell, Visa's Chief Product and Strategy Officer, describes the collaboration as "empowering merchants to deliver better customer experiences while maintaining the relationships that drive their businesses forward". Mastercard's Sherri Haymond frames it as "helping merchants build their own agents with Claude to drive their growth". ## Shopify's implementation is the practical on-ramp Shopify has published [its own implementations](https://github.com/Shopify/claude-for-commerce-examples) on top of the blueprint: a storefront shopping agent over Shopify's UCP endpoints and Sign in with Shop, and a merchant agent over the Admin API. Shopify's VP Product Vanessa Lee describes it in Anthropic's announcement as "a reference storefront implementation that connects them to a merchant's store through Catalog, UCP and Shop Sign-in". For a Shopify merchant, this shortens the distance between the announcement and a working agent considerably. It also puts UCP, the protocol Google announced at NRF 2026 and Shopify has since implemented, on the merchant-agent path as well as the third-party-assistant path. Both repositories are open reference code rather than supported products. Teams fork them and own what they build. ## The performance claims, and how to read them Anthropic's announcement headline states that "retailers running shopping agents on Claude have seen carts up to 35% larger and shoppers 60% more likely to complete a purchase". No methodology, sample, time period or baseline is published alongside those figures, and no third party has verified them. They should be read as a vendor claim rather than as measured industry data. The named-customer quotes are more checkable in kind, and mostly concern implementation speed rather than commercial outcome. Fetch's Ashley Nader reports both agents "running locally in well under an hour". Zomato's Akhil Bansal reports the setup "worked exactly as documented". Wix's Dror Zalika reports "a working commerce agent taking prompts within fifteen minutes". These are participant reports in a vendor announcement, useful as a signal of how packaged the release is and not as independent benchmarks. ## Why it matters for merchants Anthropic explicitly frames the timing: available "just in time for holiday season planning". That is the practical read. A merchant considering an agent on its own storefront for the 2026 peak season now has a starting point that is days rather than months of scaffolding, from a frontier lab, with the two largest card networks and a global systems integrator publicly attached to it. The gating factor is unlikely to be the agent. It is whether the catalogue, policy and order data behind it can answer an agent's questions. A shopping agent that assembles a multi-item order needs accurate structured attributes; one that answers returns questions in-conversation needs the returns policy in a form it can query rather than a PDF. That readiness work is the same work that makes a business legible to third-party assistants, which is a reason to do it once and use it on both paths. ## What to watch - Whether Anthropic stays out of payment, or whether a later release adds an agent payment capability of its own. The current boundary is a positioning choice, and positioning choices change. - Which other commerce platforms follow Shopify in publishing a first-party implementation over the blueprint. That is the signal of whether this becomes a de facto merchant-side pattern. - Whether Visa and Mastercard's involvement produces anything specific beyond enablement, in particular whether either wires its own agent authentication or tokenisation into a reference path. - Adoption evidence over the holiday period that is independent of Anthropic's own reporting. Primary sources: - Building commerce agents with Claude: https://claude.com/blog/claude-for-commerce-agents - anthropics/commerce-agents: Reference blueprint for building shopping and merchant agents with Claude: https://github.com/anthropics/commerce-agents - A guide to the anatomy of effective commerce agents: https://claude.com/blog/the-anatomy-of-effective-commerce-agents - Shopify/claude-for-commerce-examples: Shopify implementations of Anthropic's commerce-agents blueprint: https://github.com/Shopify/claude-for-commerce-examples - Build commerce agents with Claude: https://claude.com/solutions/commerce --- # AWS Makes Bedrock AgentCore Payments Generally Available, with x402 and MPP Support URL: https://agenticcommerceatlas.com/news/aws-agentcore-payments-generally-available Markdown URL: https://agenticcommerceatlas.com/news/aws-agentcore-payments-generally-available.md Section: news Updated: 2026-09-13 On 18 August 2026 AWS announced that Amazon Bedrock AgentCore payments is generally available, moving a managed agent-payment service from preview into production. Agents built on AWS can autonomously pay for paid APIs, MCP servers and web content, spending from a Coinbase or Stripe Privy wallet the end user funds and delegates authority over, inside a payment session whose spend cap and expiry are enforced deterministically at the infrastructure layer. At general availability AWS added Machine Payment Protocol support alongside x402, positioning the service as protocol-agnostic. *Editor's note: this page is built from the AWS announcement and documentation linked in the sources. AWS's own GA post describes the preview as launching "in May" 2026, while the AWS What's New entry for the preview sits at a 2026/04 URL. The preview date is reported here as AWS describes it. Regional availability changes over time and should be checked against the AWS documentation.* ## What was announced AgentCore payments entered preview in collaboration with Coinbase and Stripe, letting agent developers equip agents to pay for paid APIs, MCP servers and content in a few lines of code. General availability adds production-oriented capability rather than a new premise. Four changes are worth recording: - **Protocol support widened.** Preview supported x402. GA adds the Machine Payment Protocol, which AWS describes as "another standard for machine payments co-authored by Stripe and Tempo", so a developer can pay any MPP-compatible service without an additional line of code. AWS frames the service as protocol-agnostic, "abstracting away the complexity so developers can integrate once and work with merchants regardless of which protocol they use". - **A spending ceiling instead of a fixed price.** AWS added support for the "upto" scheme within x402, which lets an agent set a ceiling rather than commit to a fixed price. AWS describes this as unlocking pay-per-inference and dynamic pricing: a merchant serving LLM tokens, compute, or a usage-metered API can charge for what was consumed at the end of a call rather than requiring a fixed price per request. The existing "exact" scheme remains. - **Credential provisioning moved in-product.** A "Quick Create" option for Coinbase in the AgentCore console and CLI provisions credentials without leaving AgentCore. Stripe Privy credentials are still obtained from the Privy dashboard. - **Endpoint discovery curated.** AgentCore exposes Coinbase's pay-per-use x402 endpoints as an MCP server through AgentCore Gateway. At GA that MCP server was updated to a curated list, selected by AWS on social proof, metadata richness, description quality and availability. ## The controls are the substance of the release The design problem AWS names is worth quoting directly, because it is the one every buyer-side agent deployment runs into: "Agents are inherently non-deterministic, so they can misinterpret a response as authorization to spend or repeat a payment because of an unexpected retry." The answer is a payment session, which AWS describes as a scoped payment context for a single agent interaction, carrying a maximum spend amount in a specified currency and an expiry time. Before signing a payment, AgentCore checks the request against the session budget and rejects anything that would push the session past its cap. AWS states plainly that "the check is deterministic and runs at the infrastructure layer". A spend limit that lives outside the model is a materially different control from one expressed as an instruction to the model, and it is the part a finance or risk function will ask about first. Credential handling follows the same pattern. Developer credentials sit in AgentCore Identity Secrets Manager, and AWS states that the agent does not see the raw credentials: AgentCore derives short-lived tokens from them to instruct the wallet provider to perform wallet operations such as transaction signing. The third piece is the audit trail. AgentCore payments emits vended logs to Amazon CloudWatch and spans to AgentCore Observability, with prebuilt dashboards covering transaction success rate and average transaction value across agents, payment sessions and time periods. Delegation, a hard spend cap, an expiry, no raw credential exposure, and a transaction log. That is recognisably the same control set a business already applies to a corporate card, expressed for an agent. ## The named deployments AWS names customers across three use cases, each with an attributed quotation in the announcement: - **Paying for paywalled web content.** Anchor Browser, a cloud browser automation platform for AI agents, integrated AgentCore payments so its customers can reach paid web content inside agentic workflows. Its CEO and co-founder Idan Raman is quoted on the integration and its built-in payment limits. - **Pay per inference.** SpreadX used AgentCore payments in its Incarna product to pay for inference through BlockRun, described as a routing and payment layer where agents pay per call over x402. BlockRun founder and CEO Vicky Fu is quoted. - **Consumer booking and research.** Travala integrated AgentCore payments into its travel MCP servers so end customers on agentic platforms such as Claude can book hotels conversationally in a single chat. Travala CEO Juan Otero puts the catalogue at 2.2 million properties, which is Travala's own figure. Elsa AI and Heurist AI use the service to reach pay-per-use APIs over x402 for financial research and advisory. Framework coverage is broad enough to matter for adoption: plugins and middleware for Strands Agents, LangGraph and OpenClaw, an AWS Agent Toolkit plugin, an AgentCore CLI, and a coding-assistant skill AWS points at Claude Code, Kiro and Codex. ## The selling side is in the same announcement The part of this release with the widest commercial reach is not the buyer-side SDK. It is that AWS published it alongside two quotations about charging agents. Nishit Sawhney, General Manager of AWS Edge Services, describes Amazon CloudFront and AWS WAF as giving content owners "a single control plane for AI traffic, which agents can access what content, at what price, and for what use, with payment verified at the edge over the open x402 protocol", and characterises the effect as changing the conversation "from defense to commerce". Stephanie Cohen, Chief Strategy Officer at Cloudflare, describes Cloudflare's Monetization Gateway letting owners of content, APIs and MCP servers charge agents directly, per request, at a price they set over x402. Read the two halves together and the shape is a two-sided market being assembled from both ends at once: a managed way for agents to pay, and CDN-level infrastructure for merchants and publishers to charge. Both sides settle over the same protocol. For any business whose product is an API, a dataset or professional content, the practical question moves from whether to block agent traffic to what to charge it, and that is a pricing decision rather than a security one. ## What it does not cover This is machine-to-machine commerce, and it should not be read as retail agentic checkout. The transactions in scope are an agent paying for an API call, an inference, a piece of content or another agent's service, typically at cent-level amounts, funded through stablecoin wallets. It is a different layer from a shopper's agent completing a card purchase at a merchant, which is where the [Agentic Commerce Protocol](/learn/acp-explained/), the [Universal Commerce Protocol](/learn/ucp-explained/) and [AP2](/learn/ap2-explained/) sit. Two further limits are worth stating. Wallet choice is currently Coinbase or Stripe Privy, so funding runs through stablecoin rails even where the end user tops up by card. And the protocol-agnostic claim covers x402 and MPP; it is not a claim about the retail checkout protocols. ## Why it matters A hyperscaler taking an agent-payment service to general availability is a production-readiness signal rather than a pilot, and it lands the argument about protocol choice in a specific place. If the cloud platform abstracts x402 and MPP behind one integration, the question of which machine-payment protocol to back becomes less of a commitment for the developer and more of a question for the merchant on the other side. That is worth watching as more protocols reach the same abstraction. For a business evaluating agent deployments, the useful test from this release is the one the controls imply: whether a hard spend cap, a session expiry, a delegation record and a transaction log would satisfy your own finance and risk people before an agent is given a budget. See [How AI Agents Pay](/learn/how-ai-agents-pay/) for the payment layer in full, [x402 vs MPP](/learn/x402-vs-mpp/) for the two protocols AgentCore now spans, and [The Agentic Commerce Protocol Stack](/learn/agentic-commerce-protocol-stack/) for where machine-to-machine payment sits relative to retail checkout. Primary sources: - Amazon Bedrock AgentCore payments is now generally available: Enabling agents to transact safely and autonomously at scale: https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-payments-is-now-generally-available-enabling-agents-to-transact-safely-and-autonomously-at-scale/ - Agents that transact: Introducing Amazon Bedrock AgentCore payments, built with Coinbase and Stripe: https://aws.amazon.com/blogs/machine-learning/agents-that-transact-introducing-amazon-bedrock-agentcore-payments-built-with-coinbase-and-stripe/ - Amazon Bedrock AgentCore payments: Enable secure microtransaction payments for AI agents: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments.html --- # Cannes Lions 2026: Agentic Commerce Shows Up as a Discovery and Advertising Story URL: https://agenticcommerceatlas.com/news/cannes-lions-2026-agentic-commerce Markdown URL: https://agenticcommerceatlas.com/news/cannes-lions-2026-agentic-commerce.md Section: news At the Cannes Lions advertising festival, which ran from 22 to 26 June 2026, agentic commerce surfaced as a discovery and advertising story rather than a payments one. Three developments stood out, and the common thread is the agent influencing what a customer notices and chooses, ahead of the checkout: Amazon's Alexa+ Agentic Ads, which complete a purchase inside the conversation; a Glance and Samsung experience that puts agent-led shopping on millions of US smart TVs; and reporting that Amazon has begun buying ads inside ChatGPT. Earlier in June, the news was about the payment side, where agents pay and merchants integrate. At an event about advertising, agentic commerce showed up at the other end of the journey, the [discovery layer](/learn/mcp-explained), where an agent shapes the decision before any checkout runs. For the wider context, see [what agentic commerce is](/learn/what-is-agentic-commerce). ## Amazon introduces Alexa+ Agentic Ads On 23 June 2026, Amazon introduced **Alexa+ Agentic Ads**, which it describes as the first ad format that takes a customer from seeing an ad to completing a purchase entirely within the conversation, without leaving the ad. It launched on Echo Show devices with a small set of named partners, including Papa Johns for food ordering and the artists Beck, Jill Scott, and Omar Courtz for concert ticket purchases through Ticketmaster. Amazon said it would expand the format to more brands and services over time. This is the advertising counterpart to agentic checkout: the ad and the store become the same interaction, anchored to a logged-in customer relationship in which the assistant already knows the customer's history and preferences. Amazon framed it through its Alexa for Shopping base, and tied it to the same week's launch of Prime Day. Alongside it, Amazon Ads also pointed to an Amazon Ads MCP server that connects external AI agents to its advertising API, a reminder that [MCP](/learn/mcp-explained) is the discovery and tool-calling layer underneath much of this. The commercial framing is worth noting. Amazon and WPP used the festival to describe a "Share of Answer" measure, meaning whether the AI names a brand when a customer asks. That reframes structured product information and brand trust as a commercial asset, not only a creative one, and it is the same legibility point that makes [an accurate, machine-readable product catalog](/learn/product-catalog-for-agentic-commerce) a near-term priority. The scale signal is modest so far: this is an early production format running with chosen partners, not a self-serve product, so the direction matters more than the reach. ## Glance and Samsung put agent shopping on smart TVs Also on 23 June, **Glance**, InMobi's consumer technology company, announced with **Samsung** an agentic commerce experience running across millions of Samsung smart televisions in the United States. It runs natively on Samsung's Tizen operating system and turns the TV into a two-way, AI-powered shopping experience: viewers build personalized shopping feeds and virtual wardrobes and browse fashion, accessories, and lifestyle products using voice and the remote, without a phone or a second device. Per the announcement, it is live on all 2020-and-later Samsung models in the US, on the "For You" and "Apps" tabs. This widens the surfaces where an agent can shape a purchase beyond search and chat to the living-room screen, and it reaches customers without an app install or a separate device. It is distinct from the chat assistant and the payment network. As with any large agent channel, the customer relationship sits with the platform, here Glance and Samsung, rather than with the brand's own site, which is the channel-disintermediation trade covered in [risks and readiness](/learn/agentic-commerce-risks-and-readiness). ## Amazon is reported to be buying ads inside ChatGPT According to reporting by **Business Insider**, citing the e-commerce analyst Juozas Kaziukenas of Marketplace Pulse, Amazon has begun buying ads on ChatGPT, becoming one of the more prominent retailers in OpenAI's emerging advertising business. The ads are reported to send users back to Amazon's own storefront, where Amazon keeps the experience and the transaction. The same reporting notes that Amazon has largely declined to let third-party agents aggregate its products and pricing, and earlier in the year won a court order temporarily blocking Perplexity's Comet agent. As a single secondary-sourced report, this is best read as a reported development rather than a confirmed program. If accurate, it is the counterweight to the first two items. Amazon is willing to pay to reach ChatGPT's customers, but on its own terms, advertising into the assistant and pulling the customer back rather than letting an agent transact on its catalog. It also fits the surface's recent trajectory: OpenAI scaled back its in-chat Instant Checkout in early 2026 and shifted toward discovery and merchant apps, as covered on the [ACP page](/learn/acp-explained). The reporting frames it as a sign that advertising, not agent-led checkout, may be the nearer-term way to make money from shopping intent on the assistant, though that is a claim about timing rather than a verdict on agentic checkout. ## The pattern Across the three, the through-line is influence over the decision through discovery and recommendation, ahead of the checkout. Amazon collapsing the ad and the purchase into one Alexa conversation, Glance and Samsung putting agent shopping on the TV, and Amazon advertising into ChatGPT are all about shaping what a customer notices and chooses. Underneath them is one commercial question that is still open: whether the value sits in the agent completing the checkout or in advertising inside the assistant. Amazon's two moves this week sit on both sides of it, which suggests the larger players have not yet settled the answer. That timing question is the subject of [when agentic commerce becomes table stakes](/analysis/when-agentic-commerce-becomes-table-stakes). ## What it points to For now, the place agents are influencing purchases is discovery and recommendation, not autonomous checkout. The practical near-term implication for a business is to be legible and recommendable to the assistant: accurate, structured product information, and enough brand trust that the AI names it when a customer asks, the "Share of Answer" idea Amazon and WPP put a label on this week. Full agent-led checkout remains early and is mostly running with small, chosen launch-partner sets. The discovery side is live now, on phones, TVs, and inside chat. For how to weigh all of this for a specific business, see [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business). ## FAQ **What happened with agentic commerce at Cannes Lions 2026?** During the festival week the news shifted from payments to discovery and advertising: Amazon's Alexa+ Agentic Ads (purchase completed in the conversation), a Glance and Samsung agent-shopping experience on US smart TVs, and reporting that Amazon is buying ads inside ChatGPT. **Is this agent-led checkout?** Mostly no. These sit at the discovery and recommendation stage. Amazon's Alexa+ Agentic Ads complete a purchase in the conversation, but as an early, partner-gated format. The open question is whether value sits in agent-led checkout or in advertising inside the assistant. Primary sources: - Amazon introduces Alexa+ Agentic Ads: https://advertising.amazon.com/library/news/alexa-agentic-ads - Cannes Lions 2026: agentic and AI advertising news: https://advertising.amazon.com/library/news/cannes-lions-2026-news-advertising - Glance and Samsung Unveil Agentic Commerce Experience on Millions of U.S. Smart TVs: https://www.businesswire.com/news/home/20260623768093/en/Glance-and-Samsung-Unveil-Agentic-Commerce-Experience-on-Millions-of-U.S.-Smart-TVs - Amazon is buying its first ads inside ChatGPT: https://www.businessinsider.com/amazon-first-chatgpt-ads-ai-strategy-openai-data-2026-6 --- # Cloudflare Sets Out a Four-Part Agentic Internet: Readable, Discoverable, Callable, Payable URL: https://agenticcommerceatlas.com/news/cloudflare-agentic-internet-wallets-webmcp Markdown URL: https://agenticcommerceatlas.com/news/cloudflare-agentic-internet-wallets-webmcp.md Section: news Updated: 2026-09-13 Cloudflare published a post on 6 August 2026 setting out four things it says the web must become for AI agents: readable, discoverable, callable, and payable. Two days earlier it announced Cloudflare Wallets and cloudflare.pay, which give an agent a stable identity and a stablecoin balance its owner controls through a spending cap, an approved merchant list, and a maximum transaction size. On the same day as the four-part post it opened a developer preview of WebMCP, which Cloudflare says lets a site expose its actions to browser agents with one switch, no new APIs, and no changes at the origin. Most of the payment side is a handle reservation rather than a live product, and Cloudflare says full wallet access follows in the coming months. ## What was announced **Cloudflare Wallets and cloudflare.pay (4 August 2026).** Cloudflare's press release says each Cloudflare account will get a unique web address that works as a stable ID, and that users will be able to extend that identity to specific agents "so any business receiving a request can see exactly who authorized it." An Account Wallet will "receive, hold, and manage stablecoins," and from it users will be able to assign Virtual Wallets to individual agents. Cloudflare states the guardrails are built in from the start: "Users will be free to define a spending cap, an approved merchant list, and even a maximum transaction size the agent cannot exceed on its own." Handle reservation opened on 4 August. Full wallet access, including onramping and offramping funds and issuing Virtual Wallets, is described as "available in the coming months." Cloudflare CEO Matthew Prince is quoted in the release: "When an agent shows up at your door, you need to know who sent it." He goes on to describe giving agents "a face", meaning a link to the human or organisation that owns them, "so that trust, accountability, and real commerce can follow." **The four primitives (6 August 2026).** The post frames the four as a description of what the agentic internet needs, mapped to specific Cloudflare products: | Primitive | What it addresses | Named tooling | | --- | --- | --- | | Readable | Agents burning bandwidth and tokens parsing pages built for humans | Markdown for Agents (server side), Kitesurf, an agent-first browser running on Workers | | Discoverable | Agents finding a resource, and site owners knowing how visible they are to agents | AI Search, which Cloudflare says "is available today"; Agent Engine Optimization | | Callable | Agents taking actions without parsing HTML and guessing at buttons | [WebMCP](https://blog.cloudflare.com/webmcp/), Code Mode | | Payable | Charging for agent access when ads and seats do not apply | Wallets, Monetization Gateway | Identity sits underneath all four. Cloudflare points to Web Bot Auth, which "lets a bot cryptographically identify itself to any site it visits," and to Private Access Control Tokens (PACT), "announced with Mozilla, Google, Microsoft, and Shopify," which let a site that already knows the human behind a request vouch for them anonymously so the agent can present the token elsewhere. **WebMCP developer preview (6 August 2026).** Cloudflare's description is that "with one switch, any site becomes usable by browser AI agents", with "no new APIs, no origin changes", "while the human stays in control and creators keep their traffic." The mechanism is a site registering named tools that agents call directly, so, in Cloudflare's words, "the tool 'contract' becomes explicit. No HTML parsing, no guessing at form fields." Because the tools run inside the page, they reuse the user's existing session and state. ## Why it matters Most of the agentic commerce build-out through 2026 has come from one of two directions. Platforms have built checkouts inside assistants, which is the shape of the [Agentic Commerce Protocol](/learn/acp-explained) and Google's [Universal Commerce Protocol](/learn/ucp-explained) work. Merchants and their payment providers have built agent-readable storefronts and payment authorisation, covered in [AI shopping agent payment authorization](/learn/ai-shopping-agent-payment-authorization) and [product catalogues for agentic commerce](/learn/product-catalog-for-agentic-commerce). Cloudflare is neither. It does not run a commerce platform or a checkout, and it sits in front of a large share of the web as a network layer. Its position is stated directly in the post: the specifications are "open standards that anyone can implement", named as x402, MCP, Web Bot Auth and PACT; domain owners "choose their own identity providers, their own payment processors, their own agent partners"; and "Cloudflare is one option, not the whole stack." Two things follow for merchants and operators. The first is a lower bar for becoming callable. Making a site usable by agents has generally meant building something new: an [MCP server](/learn/build-a-remote-mcp-server), a checkout API, a structured feed. If a one-switch WebMCP interface works as described, an existing site can be made callable without that work. It is a developer preview, so the claim is worth testing rather than assuming. The second is that the agent-facing question widens. Integrating with a single platform's checkout answers whether that platform's agent can buy from you. An identity layer, an open payment standard, and a callable interface together raise a broader one: whether any agent, arriving with its own funded wallet, can read your site, call it, and pay you. Where the payment itself would run is compared in [x402 vs MPP](/learn/x402-vs-mpp) and [How AI agents pay](/learn/how-ai-agents-pay). The commercial framing Cloudflare puts on this is that ad-based and seat-based models do not survive a visitor that renders no ads and is not a person, and that per-request payment is the replacement. Its illustration is a recipe site charging "a fraction of a cent per fetch," which is an example rather than a price. ## What to watch - Whether the WebMCP developer preview moves to general availability, and whether merchants outside the developer audience turn it on. - Whether full Cloudflare Wallet access, including Virtual Wallet issuance, arrives on the "coming months" timeline, and which stablecoins and onramps it supports. - Whether Agent Engine Optimization ships as a measurable product, given site owners currently have limited ways to check their visibility to agents. The [agentic commerce readiness checklist](/learn/agentic-commerce-readiness-checklist) covers the manual version of the same question. - Whether other neutral infrastructure providers, rather than commerce platforms, take comparable positions on agent identity and payment. *Editor's note: verified against Cloudflare's own press release and blog posts on 7 August 2026 (NZ). Availability wording is Cloudflare's: Wallets is at handle reservation with full access "in the coming months", WebMCP is a developer preview, AI Search is described as "available today", and Agent Engine Optimization is a sign-up. Cloudflare's own 6 August post calls that product "Agent Engine Optimization" in the body and "Answer Engine Optimization" in its closing line; this page uses the former. The claim that more than half of requests now come from machines rather than people is Cloudflare's, from its 6 August Agent Engine Optimization post, and has not been independently verified. Cloudflare's separate "Building the agentic cloud: everything we launched during Agents Week 2026" post is dated 20 April 2026 and covers the first Agents Week; nothing from it is used here.* Primary sources: - Building an open Agentic Internet: readable, discoverable, callable, and payable: https://blog.cloudflare.com/the-agentic-internet/ - Give any website a WebMCP interface: https://blog.cloudflare.com/webmcp/ - From ranking to recommended: get your site ready to thrive in the age of AI agents: https://blog.cloudflare.com/aeo/ - Cloudflare gives AI agents an identity and a wallet: https://www.cloudflare.com/press/press-releases/2026/cloudflare-gives-ai-agents-an-identity-and-a-wallet/ - Announcing Cloudflare Wallets: the programmable wallet for the agentic Internet: https://blog.cloudflare.com/wallets/ --- # Coinbase Turns On Agent Payment Acceptance for Its Business Customers URL: https://agenticcommerceatlas.com/news/coinbase-business-agent-payments-x402 Markdown URL: https://agenticcommerceatlas.com/news/coinbase-business-agent-payments-x402.md Section: news Updated: 2026-09-13 Coinbase announced on 23 July 2026 that Coinbase Business customers can accept USDC payments from AI agents through the [x402 standard](/learn/x402-explained), with settlement handled by Coinbase Payments and no extra setup required, according to the company's press release as reported by CoinDesk and The Block. The same release added real-time market views and plain-language conditional trading to Coinbase for Agents, and introduced a Coinbase Developer Platform x402 SDK that the company says adds x402 payment acceptance to any API, MCP server, or web service in three lines of code. Taken together, it is the first time a major platform has offered merchant-side acceptance of agent payments as a default product feature for its existing customer base rather than as a pilot. ## What was announced The announcement covers three parts. For businesses, Coinbase Business accounts can now accept USDC payments made by AI agents over x402, the HTTP-native payment standard Coinbase incubated and [contributed to the Linux Foundation's x402 Foundation](/learn/x402-explained) earlier in July. CoinDesk reports the capability is rolling out this week with no extra setup for the merchant side. For individual users, Coinbase for Agents, the company's tooling for connecting AI agents to Coinbase accounts, gains a live order list that streams an agent's open and active orders, plus conditional instructions given in plain English, executed within limits the user sets. For developers, the new CDP x402 SDK packages payment acceptance for any API, MCP server, or web service, with managed wallets and spend controls included. Coinbase Business launched in June 2025. The Block, which interviewed Coinbase Business head Sid Coelho-Prabhu, reports the unit has about 5,000 customers and roughly $1 billion in combined payments and trading volume in its first year. Coelho-Prabhu called agentic payments one of Coinbase's "most high-conviction bets" and described the end-to-end path now in place: an agent reads Coinbase's developer documentation, creates a wallet for itself, gets funded, pays a merchant that accepts through Coinbase Business, and settles in USDC on Base or other chains. ## Why it matters Most agent payment news in 2026 has come from the card networks: [Visa Intelligent Commerce and Mastercard Agent Pay](/learn/how-ai-agents-pay) pilots, controlled European transactions with issuing banks, and tokenized-credential programs. Those efforts extend existing card infrastructure to agents, and they move at the pace of issuer and merchant enablement. This release comes from the other architecture. Stablecoin payments over x402 need no issuer, no card credential, and no checkout page, which is why Coinbase can switch on acceptance for its whole business customer base at once. The comparison between the two approaches is covered in more depth in [x402 vs MPP](/learn/x402-vs-mpp). Two data points in the trade coverage indicate where agent buying actually is today. Coelho-Prabhu told The Block that the earliest adopters are businesses in the digital infrastructure space, whose agents buy OpenRouter credits, domain names, and cloud storage. And a Coinbase spokesperson told The Block that since June, around 53% of traffic to the Base blockchain's documentation has come from agentic visitors. Agent commerce is real but narrow: machine-readable digital services first, ordinary goods later. For business leaders, the practical read is that accepting agent payments is becoming the cheapest part of agentic commerce to test. If a business sells anything an agent can consume, an API, credits, digital services, acceptance is starting to arrive as a platform default rather than a build decision. *Editor's note: the customer count (about 5,000), volume figure (about $1 billion), and agent traffic share (around 53%) are company-provided figures reported by The Block on 23 July 2026 and have not been independently verified. Coinbase's own press release page was not located at the time of writing; the claims above trace to CoinDesk and The Block, both of which interviewed Coinbase directly.* Primary sources: - Coinbase's corporate customers can now accept payments from AI agents: https://www.coindesk.com/business/2026/07/23/coinbase-closes-the-gaps-in-ai-agent-economy-for-businesses-users-and-developers - Coinbase calls AI payments its 'most high-conviction bet' as businesses begin accepting agent payments: https://www.theblock.co/post/409539/coinbase-ai-payments-most-high-conviction-bet-businesses-accepting-agent-payments --- # EMVCo Proposes an Intent Layer for Card-Based Agentic Payments URL: https://agenticcommerceatlas.com/news/emvco-agentic-payments-intent-services Markdown URL: https://agenticcommerceatlas.com/news/emvco-agentic-payments-intent-services.md Section: news Updated: 2026-09-13 On 1 September 2026 EMVCo released a draft framework for card-based agentic payments and opened it for public comment until 30 September. The draft proposes a shared layer called Intent Services, which would let authorised payment participants register, reference, retrieve and manage consumer-authorised intent before, during and after a transaction. It is the card system's own answer to a question the existing rails were not built to settle: not whether an AI agent *can* pay, but whether this particular purchase is one the customer actually allowed. *Editor's note: the account of the framework here was verified on 7 September 2026 against EMVCo's own EMV Insights post of 1 September, written by the chair of its Agentic Payments Task Force, which is linked in the sources. The draft document itself sits behind EMVCo's resources page and has not been read in full, so treat the summary of its contents as EMVCo's own description rather than a reading of the specification. The comment period closes 30 September 2026. Nothing here is legal advice.* ## Who EMVCo is, and why a draft from it matters EMVCo is the technical body that creates and manages the EMV Specifications behind card-based payments worldwide. It is collectively owned by six payment networks: American Express, Discover, JCB, Mastercard, UnionPay and Visa. Its specifications cover EMV contact and contactless chip, EMV 3-D Secure, EMV Payment Tokenisation, EMV Secure Remote Commerce and EMV QR Codes. This is not a vendor protocol competing for adoption in the way ACP, UCP, AP2 and x402 are. EMVCo does not launch products or sign partners. It writes the specifications that issuers, acquirers, networks and terminal vendors build against. A framework document from EMVCo is an early signal about where the card system as a whole expects agentic payment controls to sit. EMVCo first said publicly that it was working on this in November 2025, when it announced it was examining how EMV 3-D Secure, EMV Payment Tokenisation and EMV Secure Remote Commerce could be developed to support card-based agentic payments. The September 2026 draft is the first concrete output of that work. ## The problem the framework addresses Existing card infrastructure has well-developed tools for three things: authenticating the consumer, protecting the credential, and authorising an individual transaction. Agentic commerce introduces a fourth question that none of them answers. A payment credential presented by an AI agent can be entirely valid while the purchase it is being used for sits outside what the consumer permitted. The example used in trade coverage of the draft is a consumer who authorises an agent to spend up to a set amount per month on groceries. Each individual purchase may carry a valid credential and involve a merchant that has done nothing wrong, and yet a later purchase in the sequence can breach the cumulative limit. Nothing in the authorisation message tells the issuer that. The gap is specifically about permission that persists over time. A single transaction can be authorised in the moment. A standing mandate has a status and a lifecycle: it can be created, drawn down, amended, exhausted or revoked, and the parties to a transaction currently have no shared way to see where it stands. ## What Intent Services would do The draft proposes Intent Services as a shared, interoperable layer that authorised payment participants could use to register, reference, retrieve and manage consumer-authorised intent across the life of a mandate, not just at the moment of authorisation. The framework concentrates on the persistent cases: recurring purchases, cumulative spending limits and post-transaction activity. Read alongside the controls that already exist, the emerging shape is a stack of four distinct checks rather than one: | Layer | Question it answers | Status today | | --- | --- | --- | | Credential authentication | Is this a valid payment credential? | Established (tokenisation, 3-D Secure) | | Agent identity | Which AI system initiated this payment? | Emerging (Know Your Agent work across the industry) | | Persistent intent | What did the consumer permit, and is that permission still live? | Proposed here as Intent Services | | Transaction authorisation | Should this specific transaction be approved? | Established | EMVCo has said later work may include Know Your Agent capabilities and Agentic Transaction Indicators, which would identify the agent involved, carry relevant information about it, and flag to payment participants that an AI system acted on the consumer's behalf. The framework could in turn inform future revisions to EMV 3-D Secure, EMV Payment Tokenisation, EMV Secure Remote Commerce and digital payment credentials. ## The dispute and chargeback implication The most immediately commercial consequence is in disputes. A card dispute today largely resolves around whether the cardholder authorised the transaction. Where an agent initiated the purchase, that framing is incomplete. Resolving the dispute may require a record of what the consumer instructed the agent to do, how long that authority ran, and whether the purchase remained inside its limits. If intent becomes part of the transaction record, disputes over agent-initiated purchases become answerable from data rather than from reconstruction after the event. That is a meaningful change for issuers and merchants, and it points at a practical readiness question: most organisations accepting cards today hold no such record, and would have no way to answer an intent question if one arrived attached to a chargeback. ## What this is not This is a consultation on a draft framework. It is not a rule, not a regulation and not a finished specification. No participant is required to adopt Intent Services, and the framework may change materially in response to feedback. EMVCo has invited all interested stakeholders to comment by 30 September 2026. It is also worth being precise about scope. The framework addresses card-based agentic payments. It does not speak to stablecoin or account-to-account rails, where agent payment activity is developing under different protocols and different governance. ## What to do about it For merchants, issuers and acquirers, three steps follow from the draft while the comment period is open. Read the draft and consider responding, particularly if agent-initiated orders are already reaching your checkout. The comment period closes on 30 September 2026 and the framework is at the stage where industry input still shapes it. Work out who in your organisation would answer an intent question during a chargeback. If the answer is nobody, that is the gap the framework is describing. Watch the Know Your Agent and Agentic Transaction Indicator workstreams. Those are the pieces that would tell a merchant that an agent, rather than a person, was on the other side of a transaction, and they are the ones most likely to arrive as concrete specification changes. Primary sources: - EMVCo Requests Feedback on Framework for Secure, Interoperable and Scalable Card-Based Agentic Payments: https://www.emvco.com/news/emvco-requests-feedback-on-framework-for-secure-interoperable-and-scalable-card-based-agentic-payments/ - EMV Agentic Payments - Framework for Specifications v1.0 (draft, comment period ends 30 September 2026): https://www.emvco.com/resources/emv-agentic-payments-framework-for-specifications-v1-0-draft-comment-period-ends-30-sept-2026/ - How EMVCo is Working to Enable Secure, Interoperable and Scalable Card-Based Agentic Payments: https://www.emvco.com/knowledge-hub/how-emvco-is-working-to-enable-secure-interoperable-and-scalable-card-based-agentic-payments/ - EMVCo Working on How Global Specifications Can Support Agentic Payments: https://www.emvco.com/news/emvco-working-on-how-global-specifications-can-support-agentic-payments/ - EMVCo Proposes Intent Layer for Agentic Card Payments: https://www.pymnts.com/news/artificial-intelligence/2026/emvco-proposes-intent-layer-for-agentic-card-payments/ - EMVCo reqests feedback on framework for card-based agentic payments: https://www.finextra.com/pressarticle/110760/emvco-reqests-feedback-on-framework-for-card-based-agentic-payments --- # European Agentic Commerce Moves From Pilots to Live Transactions URL: https://agenticcommerceatlas.com/news/european-agentic-commerce-goes-live-2026 Markdown URL: https://agenticcommerceatlas.com/news/european-agentic-commerce-goes-live-2026.md Section: news In the week of 29 June to 3 July 2026, European agentic commerce crossed from single, first-of-a-kind demonstrations to controlled live transactions, and almost all of it landed at one event: the Visa Payments Forum in Paris on 1 and 2 July. Visa and more than 30 European issuing banks said AI agents are now making real purchases at independent merchants, and a set of acquirers, processors and merchant enablers published their own proof points the same day. The through-line is that the visible work was done by the payments ecosystem, not the AI labs, and that the organizing constraint has moved from whether an agent can pay to how you identify the agent and prove which one acted. The shift is easier to see against the prior milestones. Earlier in 2026, the European headlines were individual production payments, such as the first agentic payment completed at Money20/20 in June. This week the framing changed from a first transaction to a rollout across an issuer base. The transactions all ran on payment rails that already exist: [tokenization, passkeys and issuer authorization](/learn/how-ai-agents-pay). Every announcement assumed an agent can pay and focused instead on the [authorization and trust layer](/learn/agentic-commerce-protocol-stack): consent, authentication, and agent verification. ## Visa: live transactions across more than 30 issuers At the forum on 2 July, Visa announced the execution of live agentic commerce transactions across Europe, with AI agents browsing products, selecting items and initiating purchases at participating merchant websites within parameters set in advance by the cardholder. Visa said the transactions run through Visa Intelligent Commerce, using existing tokenization, identity verification and real-time fraud monitoring, with explicit cardholder consent and issuer oversight, in line with European regulatory requirements. Visa named more than 30 participating issuers, among them Abanca, Alpha Bank, Bankinter, Barclays, BBVA, CaixaBank, Commerzbank, HSBC UK, ING, Klarna, Lloyds Banking Group, NatWest, Nordea and Revolut, with merchants including lastminute.com, Frasers, Cleverbridge and BrickDepot across travel, retail and e-commerce. Visa described it as the next phase of its Agentic Ready program in Europe. The significance sits on the issuer side. A single production transaction shows a path is possible; more than 30 issuers and a set of named merchants is closer to the start of a market. The issuing bank is the party that authorizes the payment and carries the fraud liability, so when that many issuers agree to recognize and authorize agent-initiated transactions on existing rails, the binding constraint stops being the technology and becomes the commercial and governance agreement across the ecosystem. For a merchant selling online in Europe, the practical read is that accepting an agent-initiated payment is starting to look like a capability an acquirer or bank enables, rather than something the merchant builds. What it means for a given business is the subject of [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business). ## Three proof points, three layers of the same stack Alongside the Visa announcement, three partners published transactions the same day, each demonstrating a different layer. **Worldline, ING and Visa: bank authorization.** Worldline and ING said they completed a live, end-to-end agent-driven payment in Europe with Visa. In the scenario, completed in Germany, a consumer set the conditions for a purchase and instructed a merchant AI agent to act within them; the agent identified the product, the consumer authenticated the intent using Visa Payment Passkeys with biometric confirmation, and ING authorized the transaction under existing Strong Customer Authentication rules. This is the same shape as the June Mastercard transaction, now completed on Visa rails, which suggests the two networks are converging on one design for Europe rather than competing on different ones. The design keeps the issuing bank in the authorization seat and keeps a verifiable record of what was authorized, by whom, and under what conditions, which for a regulated market matters more than the novelty of the agent. The mechanics of that record are covered in [agent payment authorization](/learn/ai-shopping-agent-payment-authorization), and the standing conditions a cardholder sets in advance are the "mandate" idea explained in [AP2 mandates in practice](/learn/ap2-mandates-in-practice). **Nuvei: a merchant-led execution layer.** Nuvei said it completed a live proof of concept with Visa, merchant technology provider Arvato Systems and fashion brand Kings and Priests, in which a merchant's AI agent initiated a purchase and paid inside the agent, with no hand-off to a separate checkout, settling on Visa rails across several European issuers with a tokenized credential and shopper-set spend caps and approved categories. What stood out is where the payment completed: inside the agent rather than on a merchant checkout page, which is the harder version of the problem. Nuvei used the transaction to introduce Nuvei Agentic, described as a protocol-agnostic execution layer any AI agent can call to pay, with a Protocol Compatibility Layer covering the [ACP](/learn/acp-explained), [AP2](/learn/ap2-explained) and [MCP](/learn/mcp-explained) standards, a Know Your Agent registry and agent risk scoring, targeting initial availability in the second half of 2026. Nuvei also stated its order of priority plainly: first-party agents, meaning a merchant's own agent, now, and third-party agents when the market demands them. For a merchant, an execution layer that accepts multiple agent protocols through one integration lowers the cost of not knowing which standard wins. **Cleverbridge: merchant-side agent recognition, in B2B.** Cleverbridge, a commerce partner and digital reseller for software and SaaS companies, said it is among the first merchants to enable Visa's Trusted Agent Protocol and Agent Directory, which let it distinguish verified AI agents from unknown traffic and define how approved agents can access its platform and product information within its existing risk and control frameworks. Most agentic commerce examples so far are consumer retail; this one is a software and SaaS reseller, closer to a B2B setting. The specific work Cleverbridge described was making its catalog and checkout legible and executable by verified agents, and deciding which agents it will recognize. That decision, which agents a business trusts to transact on its platform, is becoming something merchants have to work out now rather than later. Across the three, one detail is worth drawing out: Visa said merchant participation was enabled through its Trusted Agent Protocol and Agent Directory, with implementation support from infrastructure providers including Cloudflare and Akamai. The agent-identity signal is being pushed down into the systems that already sit in front of merchant websites, rather than bolted on as a separate product. ## A regulator moving on agent identity The private-sector work this week was about proving agents can pay. A parallel signal came from the public side. At a press conference on 26 June, China's State Administration for Market Regulation discussed making an AI agent identity code a mandatory requirement and accelerating standards for agent auditing and transactions, and in early July the country's cybersecurity technical committee, TC260, published a non-binding practice guide on deploying AI agents securely. Nothing here is enacted, and it is best read as signaled intent rather than a rule. China is not alone in asking the question. The Bank of England's 25 June consultation on next-generation retail payments raised the same issues of accountability and agent authentication, and other jurisdictions have begun to sketch national agent-identity frameworks. The payment networks are building trust into the transaction; regulators are starting to ask who the agent is and who is accountable when it acts. Those are the same problem approached from two directions, and both point at agent identity. ## The pattern Agentic commerce in Europe crossed from demonstration to controlled live transactions this week, and the visible work was done by the acquirers, processors and merchant enablers. Worldline, Nuvei and Cleverbridge each showed a different layer of the same stack: bank authorization, a merchant-led execution layer, and merchant-side agent recognition. All of it ran on payment infrastructure that already exists. Underneath the transactions, the organizing constraint was trust. Every announcement led with consent, authentication, issuer authorization or agent verification before it described the purchase, which is the same constraint the regulators are now naming from the other side. With the payment itself largely demonstrated, the private proof points and the government standards both now point at the same frontier: agent identity and accountability. The governance and identity questions that raises for a business are the substance of [risks and readiness](/learn/agentic-commerce-risks-and-readiness). ## What it points to For a business that sells online in Europe, accepting agent-initiated payments is starting to look like enabling an existing capability through an acquirer, PSP or commerce platform, rather than building something new. The near-term work is commercial rather than technical: which verified agents a business is willing to recognize, and how it will prove which agent acted on a given transaction. Businesses that sell through a reseller or platform may find that readiness arrives through the partner, which makes it worth asking now whether the partner enables verified-agent recognition, on what terms, and how a dispute involving an agent-initiated purchase would be handled. The Cleverbridge example suggests B2B sellers are close behind consumer retail, not years behind it. For how to judge the timing, see [when agentic commerce becomes table stakes](/analysis/when-agentic-commerce-becomes-table-stakes); for the underlying mechanics, see [how AI agents pay](/learn/how-ai-agents-pay) and [what agentic commerce is](/learn/what-is-agentic-commerce). ## FAQ **What happened with agentic commerce in Europe in early July 2026?** At the Visa Payments Forum in Paris on 2 July, Visa announced live agent-initiated purchases at independent merchants across more than 30 European issuers, and Worldline and ING, Nuvei, and Cleverbridge published proof points the same day covering bank authorization, an in-agent execution layer, and merchant-side agent recognition. China's market regulator separately signaled it may make an AI agent identity code mandatory. **Does a merchant have to build new infrastructure?** Largely no. The transactions ran on existing rails (tokenization, passkeys, issuer authorization, Strong Customer Authentication). The near-term merchant work is deciding which verified agents to recognize and how to prove which agent acted. Primary sources: - Visa and Banks Across Europe Reach the Next Phase of Agentic Commerce: https://www.visa.co.uk/about-visa/newsroom/press-releases.3457328.html - Nuvei Completes First-Party In-Agent Payment with Visa; Unveils Merchant-Led Agentic Payments Strategy: https://www.nuvei.com/posts/nuvei-completes-first-party-in-agent-payment-with-visa-unveils-merchant-led-agentic-payments-strategy - Worldline, ING and Visa complete a live agentic payment in Europe: https://finance.yahoo.com/technology/ai/articles/worldline-worldline-ing-visa-complete-114500034.html - Cleverbridge among first to enable Visa's Trusted Agent Protocol: https://finance.yahoo.com/technology/ai/articles/cleverbridge-among-first-enable-visa-113000995.html - China's policy framework for AI agents: https://english.www.gov.cn/policies/policywatch/202607/03/content_WS6a4727f8c6d00ca5f9a0c014.html - Bank of England consultation on next-generation UK payments infrastructure: https://www.bankofengland.co.uk/news/2026/june/rpib-launches-consultation-on-next-generation-uk-payments-infrastructure --- # Mastercard Debuts Agent Connect and Expands Agent Suite for Merchants URL: https://agenticcommerceatlas.com/news/mastercard-agent-connect Markdown URL: https://agenticcommerceatlas.com/news/mastercard-agent-connect.md Section: news Updated: 2026-09-13 On 9 September 2026 Mastercard introduced **Mastercard Agent Connect**, described as a single integration through which merchants, AI agents, digital platforms and payment providers can connect and transact, and published an update to **Agent Suite for Merchants** aimed at making merchant-defined product data readable and actionable by AI agents. Mastercard also said it will make Anthropic's commerce agent blueprint available to merchants so they can build shopping agents on Claude models with Mastercard's capabilities integrated. The move places a card network at the merchant integration point that open protocols such as ACP and UCP are also competing for. *Editor's note: this page is built from Mastercard's announcement as quoted and linked by PYMNTS, plus independent coverage by Finextra and other trade press. Mastercard's own press release was not retrieved directly during drafting, so quoted wording is reported as PYMNTS renders it. Product availability, participating agents and regional rollout are not detailed in the announcement and should be checked with Mastercard.* ## What was announced Two things, presented together. **Agent Connect** is the new component. Mastercard positions it as one integration that connects a merchant to participating third-party AI agents, digital platforms and payment providers, spanning a three-stage journey: product discovery, cart recommendation and building, and consumer-authorized transaction. The stated benefit is that a merchant no longer builds and maintains a separate connection per agent platform. Merchants supply current pricing, product details and availability from their existing catalogs, and retain control over branding, pricing and the customer relationship. **Agent Suite for Merchants** is the existing wrapper, now updated. Mastercard's framing of the problem is a catalog-legibility problem. In the company's words, quoted by PYMNTS: > "To participate, merchants need product information that AI agents can find, understand and act on. Agent Suite for Merchants lets businesses make merchant-defined information, including product details, pricing, availability and fulfillment options, accessible across models, platforms and agent experiences while maintaining control over how that information is used, represented and acted upon." The updated suite supports product search, comparison, recommendation and checkout inside merchant-controlled digital channels, and extends agents into post-purchase work: order tracking, refunds and returns. Mastercard notes that merchants can pair it with **Mastercard Agent Pay** for the payment leg, where a consumer-authorized agent transacts against a tokenized permission. Mastercard first launched Agent Suite in January 2026, initially framed around readiness services including AI consulting. The September update moves it from preparation toward execution. ## The Anthropic blueprint distribution Mastercard said it will make Anthropic's commerce agent blueprint available to merchants, so a business can build a shopping agent with Claude models that already integrates Mastercard's capabilities. Anthropic published the [commerce agent blueprint](/news/anthropic-commerce-agent-blueprint) in early September 2026 as an open reference implementation for merchant-side shopping agents. Pairing it with a payment network changes its distribution rather than its content: a merchant that already has an acquiring relationship gets a supported path from blueprint to live agent, rather than assembling the payment layer independently. This is the first announced network-level distribution of the blueprint. ## Why it matters The contested layer in agentic commerce right now is not the payment step. It is the connection between a merchant's catalog and the agent surfaces where buying decisions are increasingly made. Three approaches are visible: | Approach | Backed by | Shape | | --- | --- | --- | | [ACP](/learn/acp-explained) | OpenAI, Stripe | Open protocol; merchant implements a specification | | [UCP](/learn/ucp-explained) | Google (Mastercard among participants) | Open protocol; merchant implements a specification | | Agent Connect | Mastercard | Network-operated hub; merchant integrates with the network | The distinction is meaningful. An open protocol makes the merchant responsible for its own integration and leaves the merchant free of any intermediary. A network hub trades some of that independence for a single relationship and a party that maintains the connections. Neither is settled, and Mastercard's participation in UCP shows the company is not treating these as mutually exclusive. For a merchant, the practical implication is unchanged by which one wins: agent-readable product data is a prerequisite for all three. See [Product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce) for what that involves. ## What is not yet clear - **Which agents participate.** Agent Connect's value rests entirely on the breadth of agent surfaces it reaches. The announcement does not name participating third-party agents. - **Whether it is a specification or a service.** Mastercard has not published Agent Connect as an open specification, which distinguishes it from ACP and UCP and leaves the interoperability question open. - **Commercial terms.** Pricing, eligibility and regional availability are not detailed. - **Demand.** PYMNTS Intelligence research cited in the same coverage found 46% of merchants name pricing and final price as the function they are least willing to delegate to an agent. Investment intent thins as capability approaches the transaction: 31% plan to invest within a year in automated product search and comparison, against 26% for agent-completed checkout, with nearly half placing multi-merchant bundling, autonomous checkout and dispute management in the "later or never" category. ## Related reading - [The agentic commerce protocol stack](/learn/agentic-commerce-protocol-stack) - [ACP vs UCP](/learn/acp-vs-ucp) - [Anthropic's commerce agent blueprint](/news/anthropic-commerce-agent-blueprint) - [Agentic commerce for retailers](/learn/agentic-commerce-for-retailers) - [Product catalog for agentic commerce](/learn/product-catalog-for-agentic-commerce) Primary sources: - Mastercard gives merchants a simpler way to build, connect and sell in the agentic era: https://www.mastercard.com/us/en/news-and-trends/press/2026/september/mastercard-gives-merchants-a-simpler-way-to-build--connect-and-s.html - Mastercard Expands Agentic Suite to Help Merchants Scale AI Shopping: https://www.pymnts.com/news/artificial-intelligence/2026/mastercard-expands-agentic-suite-to-help-merchants-scale-ai-shopping/ - Mastercard moves to help merchants prepare for AI-powered shopping: https://www.finextra.com/newsarticle/48374/mastercard-moves-to-help-merchants-prepare-for-ai-powered-shopping - Mastercard launches Agent Suite to ready enterprises for a new era: https://www.mastercard.com/us/en/news-and-trends/press/2026/january/mastercard-launches-agent-suite-to-ready-enterprises-for-a-new-e.html - Global Digital Shopping Index: Agentic Commerce Deep Dive: https://www.pymnts.com/study/global-digital-shopping-index-agentic-commerce-deep-dive/ --- # MoonPay Launches PayBox, a Payment Vault That Runs Inside Claude and ChatGPT URL: https://agenticcommerceatlas.com/news/moonpay-paybox-agent-payment-vault Markdown URL: https://agenticcommerceatlas.com/news/moonpay-paybox-agent-payment-vault.md Section: news Updated: 2026-09-13 MoonPay announced on 29 July 2026 that it has launched PayBox, a payment vault a user installs as a custom connector inside Claude or ChatGPT so the assistant can prepare and execute payments without leaving the conversation. According to MoonPay's release, the user describes what they want in natural language, the assistant prepares the transaction, and the user approves it with a passkey before any funds move. An optional autonomous mode lets the assistant act within limits the user sets. PayBox pays online services over the [x402 standard](/learn/x402-explained) and, MoonPay says, makes card payments through Visa's agentic commerce protocol. It is one of the first general-purpose consumer payment credentials available inside both major AI assistants, and it places payment authority with the customer rather than with an AI platform's checkout or a merchant's storefront. ## What was announced MoonPay describes PayBox as "the first payment vault built for AI." The company says it is live at paybox.sh as of the announcement. Setup, per MoonPay, is: install PayBox inside Claude or ChatGPT, create an account, register a passkey, then create or import a wallet and optionally add payment cards. Funding comes from an existing wallet or from a card after MoonPay's one-time identity verification. Every credential then operates under one of two user-selected permission models: - **Always Ask**, where every transaction requires a passkey approval. - **Autonomous**, where the AI can act within limits the user chooses. MoonPay says changing those permissions always requires a new passkey approval from a person, every authorization is scoped to a single action and cannot be reused, and access can be revoked instantly at any time. On the payment side, PayBox holds both card credentials and wallet keys. Cards are stored so that, according to MoonPay, the assistant can pay with them without ever seeing card details, and card transactions run through Visa's agentic commerce protocol so the raw number is not seen or stored. For online services, PayBox pays over x402, the HTTP-native agent payment standard Coinbase incubated and which now sits under the Linux Foundation. MoonPay says the first x402 integrations are live for restaurant reservations, travel bookings, and shopping. PayBox launches with support for Solana and EVM-compatible chains including Ethereum, Hyperliquid, Tempo, Base, Robinhood Chain, Arbitrum, and Polygon. On key security, MoonPay says wallet keys are protected by threshold cryptography (MPC) and secure enclaves (TEEs), so no single party, including MoonPay and the assistant itself, can access a complete private key or sign a transaction alone. The company attributes the underlying key management to Sodot, which MoonPay says it acquired earlier in 2026. MoonPay says support for additional AI platforms is coming, along with deeper decentralized finance capability such as routing swaps and managing liquidity under the same approval rules. ## Why it matters The agentic commerce build-out through 2026 has concentrated payment authority in two places. One is the AI platform: a checkout inside the assistant, with the platform brokering the transaction, as in the OpenAI and Stripe [Agentic Commerce Protocol](/learn/acp-explained) and Google's [Universal Commerce Protocol](/learn/ucp-explained) work with merchants and payment providers. The other is the merchant: an agent-readable storefront, a checkout API, and a payment credential the merchant accepts, which is the model covered in [AI shopping agent payment authorization](/learn/ai-shopping-agent-payment-authorization). PayBox is a third position. The payment credential belongs to the customer, sits in a vault they control, and moves with them between assistants. Reach comes from x402 acceptance on the service side rather than from a bilateral integration with any one platform or merchant. For merchants and operators, the practical consequence is a question that sits alongside "which agentic checkout should we support?": can an agent that arrives already holding a funded payment method complete a purchase with us? Supporting one platform's checkout answers a narrower version of that question than accepting an open payment standard does. The trade-offs between the card-network route and the HTTP-native route are compared in [x402 vs MPP](/learn/x402-vs-mpp) and [How AI agents pay](/learn/how-ai-agents-pay). Two caveats belong with this. First, MoonPay's core business is crypto, and a large share of the examples in its own release are onramping, swapping, bridging, and yield rather than buying goods, so the shopping use case is real but early. Second, the named commerce integrations at launch are small services, not major retailers. The pattern worth watching is whether a mainstream wallet or card issuer releases an equivalent customer-side agent payment credential. *Editor's note: the product claims above are MoonPay's own, taken from its 29 July 2026 release and corroborated by a Digital Transactions news brief the same day. The reference to "Visa's agentic commerce protocol" is MoonPay's wording; the release does not name the specific Visa program, so this page attributes rather than asserts it. Company-provided scale figures in the release (Sodot securing more than $50 billion in assets and over 10 million wallets, and MoonPay serving more than 1,700 enterprise clients) have not been independently verified and are omitted from the body above.* Primary sources: - MoonPay Launches PayBox, a Payment Vault for Claude and ChatGPT That Turns Prompts Into Payments: https://www.moonpay.com/newsroom/moonpay-paybox - MoonPay's Open Web Agentic Commerce Tool and other Digital Transactions News briefs from 7/29/26: https://www.digitaltransactions.net/moonpays-open-web-agentic-commerce-tool-and-other-digital-transactions-news-briefs-from-7-29-26/ --- # Natural Raises $30M to Build Payments Infrastructure Designed for AI Agents URL: https://agenticcommerceatlas.com/news/natural-30m-agent-payments-infrastructure Markdown URL: https://agenticcommerceatlas.com/news/natural-30m-agent-payments-infrastructure.md Section: news Updated: 2026-09-13 Natural, a US payments startup founded in 2025, announced a $30 million Series A on 20 July 2026, led by Kirsten Green at Forerunner. TechCrunch, which reported the round, puts the company's total funding at $40 million. Natural is building payment infrastructure designed for AI agents from the ground up: an orchestration layer that lets agents hold funds, make payments, collect money, and transact with people and with other agents. The company has been operating in a beta trial and names Stripe as its main competitor. The round is a small one by 2026 fintech standards. The reason it is worth noting is the thesis being funded. Most agent payments activity so far has come from the incumbents extending what already exists: [tokenized credentials, passkeys, and issuer authorization](/learn/how-ai-agents-pay) carried over to agent-initiated transactions through programs like Visa Intelligent Commerce and Mastercard Agent Pay, and through Stripe's agent tooling. Natural is a venture bet on the opposite architecture: that infrastructure built around a person authorizing each transaction fits poorly with autonomous software, and that agent transactions need a system designed for them from the start. ## What Natural is building According to TechCrunch and the company's news release, Natural positions itself as an orchestration layer for agent money movement. By integrating its infrastructure, a company can allow its agents to make autonomous payments, collect funds, and transact with both people and other agents. Founder and CEO Kahlil Lalji told TechCrunch the company also intends to redesign parts of the machinery around the payment itself, including how disputed transactions are handled when an agent, rather than a person, made the purchase. Lalji previously co-founded Ivella, a YC-backed banking product sold to Earnin in 2023, and founded Natural with Eric Wang and Walt Leung. TechCrunch reports the team includes senior staff who previously worked at Stripe, Ramp, and Square. Natural plans to support stablecoins alongside traditional bank payments, which distinguishes it from stablecoin-first competitors in the same space such as DCVC-backed Skyfire Systems. The commercial logic behind the bet is scale. Lalji's argument, quoted by TechCrunch, is that if transactions happen at machine speed rather than at the pace people approve them, the number of payments in the world could be orders of magnitude larger than today. That is a projection, not a result, and it should be read as the founding thesis rather than evidence. ## Where this sits in the landscape The agent payments field now has three visible architectural approaches. The card networks and processors are extending existing rails to agents, keeping the issuing bank in the authorization seat, which is the approach behind the [live European agent transactions](/news/european-agentic-commerce-goes-live-2026) earlier this month. The open protocol efforts, [AP2](/learn/ap2-explained), [ACP](/learn/acp-explained), and [x402](/learn/x402-explained), are standardizing how agents express payment intent across whichever rails carry the money. Natural represents a third approach: proprietary infrastructure purpose-built for agent transactions, sold as a platform. For most businesses, nothing changes this week. Natural is in beta, has not named production customers, and is competing with the most entrenched infrastructure providers in commerce. The development worth tracking is whether venture-funded, agent-native platforms of this kind win real merchant and platform adoption, or whether the incumbents' approach of extending existing rails absorbs the category. Who Natural's first production customers are, and what they use it for, will be the early evidence either way. The questions a business should be asking about agent transactions in the meantime are covered in [risks and readiness](/learn/agentic-commerce-risks-and-readiness). *Editor's note: funding figures and product details are as reported by TechCrunch and the company's news release of 20 July 2026 and have not been independently verified beyond those sources. Natural's product is in beta; capabilities described are the company's own characterization.* Primary sources: - Natural raises $30M to reinvent payments for AI agents: https://techcrunch.com/2026/07/20/natural-raises-30m-to-reinvent-payments-for-ai-agents-and-take-on-stripe/ - Natural Raises $30M Series A to Build Payments Infrastructure for AI Agents: https://www.prnewswire.com/news-releases/natural-raises-30m-series-a-to-build-payments-infrastructure-for-ai-agents-302829855.html --- # Ninth Circuit: The User, Not the AI Company, Accesses a Site Under the CFAA URL: https://agenticcommerceatlas.com/news/ninth-circuit-amazon-perplexity-cfaa-ruling Markdown URL: https://agenticcommerceatlas.com/news/ninth-circuit-amazon-perplexity-cfaa-ruling.md Section: news Updated: 2026-10-01 On 4 August 2026 the US Court of Appeals for the Ninth Circuit vacated the preliminary injunction against Perplexity's Comet browser assistant, holding that when a customer directs an AI assistant to act on a website, it is the customer, not the AI company, who "accesses" that website under the Computer Fraud and Abuse Act. It is the first US federal appellate decision addressing agentic AI and the CFAA, and it went against the platform. *Editor's note: this page was verified against the full text of the opinion, which is linked in the sources, and against independent reporting. The case is at the preliminary injunction stage and has been remanded to the district court, so the position may change. Nothing here is legal advice.* *Update, 1 October 2026: Amazon petitioned for rehearing en banc. On 10 September 2026 the Ninth Circuit denied the petition. Judges M. Smith and Tung voted to deny, Judge Hinderaker recommended denial, and the full court was advised and "no judge requested a vote on whether to rehear the matter." The court also granted a motion for leave to file an amicus brief. The panel opinion described below therefore stands, and the case returns to the district court on remand.* ## What the court decided Amazon sued Perplexity in November 2025, alleging violations of the CFAA and its California analogue, the California Comprehensive Computer Data Access and Fraud Act (CDAFA). In March 2026 Senior US District Judge Maxine Chesney of the Northern District of California granted Amazon a preliminary injunction, finding Amazon likely to succeed on both claims. Perplexity appealed, and a motions panel of the Ninth Circuit issued a stay pending appeal, so the injunction did not restrict Comet while the appeal was heard. The case was argued and submitted in Seattle on 11 June 2026. The Ninth Circuit panel found the district court had abused its discretion in its "access" analysis. Writing for the panel, Circuit Judge Milan D. Smith Jr. held: > It is the user who "accesses" Amazon's computers, with the help of the Assistant to carry out specific acts on Amazon.com. Two steps got the court to that conclusion. First, it asked whether Perplexity itself communicates directly with Amazon's servers, and found it does not. Only the browser retrieves the page; the Assistant then analyses what is displayed and sends information and user instructions to Perplexity's servers, which reply with directions to act on the page. In the court's words, "Perplexity itself does not directly communicate with Amazon's servers." Second, it asked whether Perplexity uses the Assistant as a tool to access Amazon's computers, and answered no. Receiving screenshots of the user's browser and sending instructions back does not amount to gaining entry to Amazon's servers. As the opinion puts it, "However advanced the Assistant currently is, it is a tool, not a person for statutory purposes." The court reinforced the holding with the rule of lenity, noting that the CFAA applies in criminal as well as civil contexts, so ambiguity cuts against liability. It also observed that Amazon's reading could expose users themselves to criminal liability. The CDAFA claim failed on the same reasoning: "access" under the CDAFA may be broader, but the inquiry still focuses on the person accessing or causing the access. The access analysis is not the only ground. The panel separately held that the district court erred on the remaining injunction factors, describing Amazon's evidence of irreparable harm as weak and finding that an injunction would impair consumer choice and limit the development of a nascent technology. The conclusion is conjunctive: the injunction fell because Amazon is unlikely to succeed on the merits **and** the equitable factors do not otherwise strongly favour an injunction. The panel vacated the injunction and remanded. Circuit Judge Eric C. Tung and US District Judge John Charles Hinderaker (District of Arizona, sitting by designation) completed the panel. ## The dispute was about an agent that would not identify itself The opinion records that at the core of the dispute was Perplexity's decision not to use a user-agent string, a mechanism that would have communicated that the user had activated an AI agent. That string would have let Amazon detect and block the Assistant. This is worth separating from the legal holding. Amazon's underlying complaint was not that agents exist. It was that this agent arrived indistinguishable from a human shopper, which left Amazon with no way to apply a different rule to it. Agent identity, which the protocol and infrastructure layer has been building towards through mechanisms such as Web Bot Auth and signed agent credentials, is the same problem approached from the other side. ## What the court did not decide The opinion is deliberately narrow, and reading it as a general licence for agentic AI would be a mistake. The panel wrote that it does not establish a new legal regime governing agentic AI, and limited its holding to "access" as contemplated by the CFAA, as applied to the Assistant's interactions with Amazon.com on the record before it. Three limits are worth recording separately: - **Other causes of action remain open.** The court wrote that it does not address whether Perplexity can avoid liability in other contexts, "including tort claims". Wilson Sonsini's analysis names trespass to chattels, tortious interference and the anti-circumvention provisions of the Digital Millennium Copyright Act as the obvious untested routes. Those specific causes of action are the firm's reading rather than the court's words. - **Terms of service are explicitly preserved.** A footnote states that the outcome "does not impair Amazon's ability to regulate access to Amazon.com via private terms of service for its users", and that Amazon is simply unlikely to succeed in regulating access by invoking the CFAA and the CDAFA. The court did more than leave contract open; it pointed at it. - **The outcome depended on product architecture, and on geography.** Because the reasoning followed where the chain of communication runs, an agent built differently could reach a different result. An agent whose vendor servers call a merchant's endpoints directly does not have the fact pattern that saved Perplexity here. The decision also binds only federal courts in the Ninth Circuit, which covers California and eight other western states. Amazon has said it disagrees with the ruling and is evaluating next steps. The case returns to the district court. ## Why it matters for agentic commerce Until 4 August 2026 the strongest legal instrument a large marketplace had against an unwanted third-party shopping agent was an anti-hacking statute, and the March injunction suggested it worked. That instrument is now weaker, at least against a client-side agent acting on a user's instruction inside the Ninth Circuit. For a merchant or marketplace, the practical consequence is that exclusion has to rest on something else: - **Terms of service and contract.** Expressly preserved by the court, and untested against agents at appellate level. - **Technical access controls.** Bot detection, rate limits, Web Bot Auth and similar agent-identity mechanisms. These operate regardless of the legal question, and the user-agent string point in this case shows how central detection is to the whole argument. - **Permissioned access.** Admitting agents deliberately, on terms the operator sets, through a declared interface such as an agent-callable API, a Model Context Protocol server, or a supported commerce protocol. The third option is the one this ruling makes more attractive. If keeping agents out through litigation is harder than it looked in March, deciding which agents to recognise, and on what terms, becomes a live commercial question rather than a deferrable one. That is the same question the protocol and agent-identity layer has been approaching from the other direction: see [The Agentic Commerce Protocol Stack](/learn/agentic-commerce-protocol-stack/) for how the access, authorisation and payment layers fit together, [AI Shopping Agent Authorization](/learn/ai-shopping-agent-payment-authorization/) for the merchant-side view of recognising an agent, and [Agentic Commerce Risks and Readiness](/learn/agentic-commerce-risks-and-readiness/) for where third-party agent access sits in the wider risk picture. Primary sources: - Amazon.com Services, LLC v. Perplexity AI, No. 26-1444 (9th Cir. Aug. 4, 2026): https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf - Ninth Circuit lifts block on AI-powered shopping assistant: https://www.courthousenews.com/ninth-circuit-lifts-block-on-ai-powered-shopping-assistant/ - Ninth Circuit Addresses CFAA and Agentic AI Tools in Groundbreaking Decision: https://www.wsgr.com/en/insights/ninth-circuit-addresses-cfaa-and-agentic-ai-tools-in-groundbreaking-decision.html - Order denying rehearing en banc, Amazon.com Services v. Perplexity AI, No. 26-1444: https://www.courthousenews.com/wp-content/uploads/2026/09/amazon-perplexity-no-rehearing.pdf --- # What Agentic Commerce Means for Your Business URL: https://agenticcommerceatlas.com/analysis/what-agentic-commerce-means-for-your-business Markdown URL: https://agenticcommerceatlas.com/analysis/what-agentic-commerce-means-for-your-business.md Section: analysis Agentic commerce means AI agents will increasingly discover products, compare options, and complete purchases on your customers' behalf. For your business, the practical question is no longer whether to have a view on it. It is whether your products can be found, understood, and bought by an agent, and on whose terms. For most companies in mid-2026 the honest answer is to start now, cheaply, on the work that makes you discoverable and transactable, while treating deeper integration as a fast-follow as the standards settle. This guide is for decision-makers. It assumes no implementation detail. If you want the underlying concepts first, start with [what agentic commerce is](/learn/what-is-agentic-commerce) and [the landscape of who is building what](/landscape/agentic-commerce-landscape). ## The short version Three things are true at once, and holding all three is the key to a sensible decision. First, the opportunity is large and credible. McKinsey estimates that by 2030 the US business-to-consumer retail market alone could see up to one trillion dollars in orchestrated agentic revenue, with global projections as high as three to five trillion. Even if those figures prove optimistic, the direction is clear and backed by the largest platforms. Second, what is genuinely live today is narrower than the headlines suggest. A small number of merchants transact inside AI assistants now. Much of what gets announced is a pilot, a "coming soon," or a partnership rather than a working checkout. Third, most of the preparation is low-regret. The work that makes you legible to an agent, clean and structured product data and an API-driven checkout, also improves conventional search, your own storefront, and your operations. You can do it before the winners are clear and lose little if the timeline slips. So the decision is rarely "bet the company" or "ignore it." It is "get discoverable and transactable now, watch the contested parts, and be ready to integrate deeply when it pays." ## Why this matters now Two large coalitions are building the rails, and they are not waiting for consensus. OpenAI and Stripe launched the [Agentic Commerce Protocol](/learn/acp-explained) in September 2025 to let agents check out with merchants, and it powered the original "buy it in ChatGPT" experience. Google launched its [Universal Commerce Protocol](/learn/ucp-explained) in January 2026, aimed at the whole shopping journey, with backers including Shopify, Etsy, Target, Wayfair, and Walmart. The card networks are wiring agents into payments in parallel: Visa, Mastercard, and American Express each have agent-payment programs, mostly in pilot. For how the money and trust actually flow, see [how AI agents pay](/learn/how-ai-agents-pay). Here is the part that matters for planning. The flagship "buy directly inside the chat" moment has been less smooth than its launch implied. OpenAI scaled back native Instant Checkout in early 2026, repositioning the in-chat experience toward apps and product discovery that send shoppers to the merchant's own checkout. Google's protocol, by contrast, is live in AI Mode in Search and the Gemini app for eligible US retailers, paying through Google Pay. The lesson is that adoption depends as much on the host surface promoting it as on the standard itself, which is exactly why a leader should prepare broadly rather than bet on one surface. ## Act now, or wait? Split the question in two, because the answer differs by part. Act now on discovery and presence. Whether or not anyone buys from an agent in your category this quarter, agents are already a discovery channel. They read product feeds and answer "what should I buy" questions today. If your data is thin, stale, or absent, you are invisible or, worse, misrepresented. This is cheap to fix and compounds. Wait, but watch closely, on deep checkout integration. Which checkout standard prevails, ACP or UCP or both, is unsettled, and committing heavily to one integration before that clears risks rework. The pragmatic move is to make your checkout API-driven and standards-friendly so that adopting a protocol later is a small step, not a rebuild. A useful mental model is three postures. Watch means you keep informed and keep your data clean. Pilot means you put a real catalog onto at least one live agent surface and measure what happens. Commit means you treat agent channels as first-class, with owned integration, analytics, and merchandising. Most businesses should be at "watch plus a real pilot" right now, and very few need to be at "commit" yet. For how this is likely to unfold, and the signals that tell you the window has turned, see [when agentic commerce becomes table stakes](/analysis/when-agentic-commerce-becomes-table-stakes). ## Are you ready? A quick readiness check You are in good shape if you can answer yes to most of these. Is your product data complete and structured, with every item carrying title, description, price, availability, images, category, brand, and clear shipping and returns information? Does the data an agent would read match your live site exactly, so that a price or stock mismatch cannot break an agent-initiated checkout? Is your checkout available through an API that returns structured data, rather than only as elements rendered on a web page that an agent cannot see? Can your systems respond quickly and reliably to automated, programmatic requests? And do you have a view on payments, fraud, and who bears liability when a purchase is made by software rather than a person? If most answers are no, that is your roadmap. None of it is exotic, and all of it helps your existing channels too. ## First steps by business type The right first move depends on where you sit in the chain. This section is the summary; for a fuller playbook per type, including the specific risks, metrics, and protocols that matter most, see [agentic commerce by business type](/learn/agentic-commerce-by-business-type). If you are a retailer, your edge is breadth of catalog and the buying moment. Get your full catalog into a clean, structured feed, then put it onto at least one live agent surface to learn how agents represent and rank your products. If you are on a platform such as Shopify that syndicates to agent surfaces, turn that on and verify what actually appears. Watch your margins: some agent surfaces charge a fee per completed sale, so model the economics before you scale, not after. If you are a brand or manufacturer, your edge is authority over your own product information, and your risk is commoditization. When an agent compares options, the brand with the richest, most accurate, most structured data tends to be surfaced and described well. Invest in being the canonical source for your products' attributes, and decide deliberately where you want to be bought, on your own direct channel, through retail partners, or both, because agents will expose those choices to shoppers side by side. If you are a marketplace or platform, you are both a participant and a piece of infrastructure. Your sellers will ask how to be agent-ready, and your buyers will increasingly arrive through agents. Decide whether you expose your catalog and checkout to external agents, implement an agent-facing capability for your sellers, or both. The protocols were designed so that you build one integration rather than a different one per AI platform, which is the whole point of adopting a standard rather than a bespoke deal. If you are a services business, the consumer-checkout protocols are only half your story. Much agent activity is software paying software: an agent paying for an API call, compute, data, or a digital service. If you sell any of those, the [settlement layer](/learn/how-ai-agents-pay) matters as much as retail checkout, and making your service programmatically purchasable can open a machine-to-machine channel that did not exist before. If you sell human services such as bookings or appointments, the same discovery logic applies: structured, accurate, machine-readable information about availability and price is what lets an agent recommend and transact. ## Risks to keep in view Acting early does not mean acting naively. Four risks deserve a place on the agenda. Impersonation and fraud: when a buyer is software, you need confidence that an agent is genuinely authorized to act for a real customer, which is the problem the [payment-authorization layer](/learn/ap2-explained) and the networks' agent-verification schemes are trying to solve. Liability and disputes: there is not yet a settled, cross-network rulebook for who eats the cost when an agent-made purchase goes wrong, so read the terms of any program you join. Channel disintermediation: an agent surface that owns the discovery moment can push you toward competing on price alone, which is why owning your first-party relationships matters. And privacy and data: agent transactions create new data flows and new questions about consent and customer ownership. These deserve a fuller treatment, set out in [agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness). ## What to do in the next 90 days A reasonable, low-regret program for most businesses: audit your product data for completeness, structure, and accuracy against your live site, and fix the gaps. Confirm your checkout is reachable through an API that returns structured data. Run one real pilot by putting a genuine catalog onto a live agent surface and measuring discovery, conversion, and economics. Assign an owner so this is somebody's job, not a committee's hobby. And brief your leadership on the contested points, mainly the checkout-standard question and the liability picture, so you can move quickly when they resolve. For the technical detail behind any of this, point your team to [the protocol stack](/learn/agentic-commerce-protocol-stack), and keep [the glossary](/learn/agentic-commerce-glossary) handy for the acronyms. The strategic posture is simple to state and harder to do: be findable, be buyable, stay neutral on the parts that are still moving, and keep the customer relationship yours. ## FAQ **Should my business act on agentic commerce now or wait?** For most businesses, act now in a low-cost way and treat deep integration as a fast-follow. The work that makes you discoverable and transactable to agents, mainly clean, structured, accurate product data and an API-driven checkout, is the same work that helps conventional search and your own site, so it pays off even if agentic volume stays small. The parts that are still settling, such as which checkout standard wins and how payment disputes are handled, are worth watching rather than betting heavily on yet. **What is actually live today versus just announced?** Live: Google's Universal Commerce Protocol powers checkout inside AI Mode in Search and the Gemini app for eligible US retailers, paying through Google Pay, and a small set of merchants transact through ChatGPT. Repositioned: OpenAI scaled back native in-chat Instant Checkout in early 2026 toward apps and discovery that send shoppers to the merchant's own checkout. Still in pilot: the card networks' agent-payment programs from Visa, Mastercard, and American Express. Treat adoption claims skeptically and check whether a partner is genuinely live or merely announced. **Will agents disintermediate my brand and customer relationship?** That is the central strategic risk. If an agent surface becomes the place customers shop, it can sit between you and the buyer, own the discovery moment, and commoditize your catalog against competitors. The defenses are owning your first-party data and direct relationships, keeping your product information richer and more accurate than rivals, and being present on agent surfaces on terms you choose rather than being absent and surfaced badly. **What is the single most important first step?** Make your product data agent-ready: complete, structured, and identical to what is live on your site. Agents read machine-readable feeds and APIs, and if your price or availability does not match your live store, an agent-initiated checkout can simply fail. Clean product data is the foundation everything else builds on, and it is useful regardless of which protocol or surface wins. Primary sources: - The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants - Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ - New agentic commerce tools and a protocol for retailers and platforms: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Visa Intelligent Commerce: https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html --- # When Does Agentic Commerce Become Table Stakes? URL: https://agenticcommerceatlas.com/analysis/when-agentic-commerce-becomes-table-stakes Markdown URL: https://agenticcommerceatlas.com/analysis/when-agentic-commerce-becomes-table-stakes.md Section: analysis When does agentic commerce stop being optional? The honest answer is that it is staged, not a single date, and the stages are best read as a sequence tied to observable signals rather than a calendar. Being discoverable by agents is effectively table stakes already. Being transactable on the major agent surfaces becomes table stakes in the near term, surface by surface. And deep, optimized integration is a competitive advantage today that will become an expectation later, and unevenly. This page is the forward-looking companion to [the historical timeline](/landscape/agentic-commerce-timeline): the timeline records what has happened, while this is a reasoned view of what to expect and, more usefully, what to watch. A note on confidence. No one can put a reliable date on this, and anyone who offers one precise year is guessing. What follows is an expectation, with the reasoning shown, so you can adjust it as the facts change. ## What "table stakes" actually means "Table stakes" is the point where not doing something costs you, as opposed to doing it early winning you an edge. The two are different decisions. Early-mover advantage is optional and speculative; table stakes is mandatory and defensive. The whole question of timing is really about when each capability crosses from the first category to the second for your business. That crossing does not happen everywhere at once, which is why a staged, signals-based view is more useful than a headline prediction. ## Stage one: discoverable by agents (already table stakes) Agents are a discovery and recommendation channel right now. People already ask assistants what to buy, and those assistants read structured product data to answer. If your catalog is thin, stale, or absent, you are invisible to that channel or, worse, represented badly next to a competitor who is not. This is why discovery readiness, complete and accurate machine-readable product data, is best treated as table stakes today rather than a future project. It also happens to be low-regret: the same data quality helps conventional search and your own storefront, so you are not betting on agentic commerce to justify it. ## Stage two: transactable on the major surfaces (becoming table stakes) The next stage is being able to complete a purchase where the customer is, inside an agent surface. This is arriving now, but unevenly by surface. Google's commerce protocol already powers checkout inside AI Mode in Search and the Gemini app for eligible US retailers. On the ChatGPT side, native in-chat checkout launched and was then scaled back toward apps and discovery that hand off to the merchant's own checkout. The card networks' agent-payment programs are mostly still in pilot. So "transactable" is real on some surfaces and partial on others, and it becomes table stakes for you at the moment your customers start buying through a surface in meaningful numbers, not when the surface first announces support. The single biggest variable here is not the standard but the host surface's commitment to promoting it. A protocol only matters where a popular surface puts it in front of shoppers, which is the clearest lesson of the past year. That is why timing this stage by watching surfaces and your own traffic beats timing it by reading roadmaps. ## Stage three: deep, optimized integration (advantage now, table stakes later) The final stage is treating agent channels as first-class: optimized merchandising, analytics, and owned integration rather than a basic feed and a checkout. Today this is a differentiator that a few leaders are pursuing. It will become an expectation later, as agent-driven volume grows and competitors raise the bar, but it will be the last stage to become mandatory and the most uneven across the market. The forecasts behind the urgency are large, McKinsey estimates that by 2030 the US business-to-consumer retail market alone could see up to one trillion dollars in orchestrated agentic revenue, but a forecast of the prize is not a schedule for when you specifically must act. ## Why it will be uneven, and how to read the unevenness Three forces spread the timing out. Surface: a standard becomes table stakes only where a popular assistant promotes buying, and the leading surfaces are moving at different speeds. Vertical: some categories suit agent buying far sooner than others, with simple, well-specified, repeat-purchase goods ahead of complex, considered, or experiential ones. Geography: the US is ahead of most markets, so the same capability will become table stakes there before it does elsewhere. The practical consequence is that you should expect "table stakes" to arrive at a different time for a US electronics retailer than for a European services business, and you should calibrate to your own surface, vertical, and market rather than to a global headline. ## The signals worth watching Because dates are unreliable, watch signals instead. Four are worth tracking, and the window has moved from early-mover to expected when two or three turn at once in your category. First, presence in agent answers: are agents recommending products like yours, and is yours among them? Second, competitor moves: are peers in your category going live on agent surfaces? Third, your own analytics: is agent-referred traffic appearing and growing? Fourth, platform and payment milestones: are the surfaces and networks your customers use reaching general availability in your market? These tell you about your situation specifically, which a market-wide forecast cannot. ## How to time your investment The uncertainty argues for a low-regret sequence rather than a big bet on a predicted date. Get discoverable now, because that work pays off across every channel regardless of how agentic commerce unfolds. Run a real pilot to make yourself transactable on at least one live surface, so you are learning from actual behavior rather than speculation. And watch the signals before committing to deep, surface-specific integration, so you invest heavily only when the evidence says the window has turned for you. This is the same posture set out in [what agentic commerce means for your business](/analysis/what-agentic-commerce-means-for-your-business), viewed through the lens of timing; the risks that come with moving are covered in [agentic commerce risks and readiness](/learn/agentic-commerce-risks-and-readiness). The summary is short. Discovery is table stakes now. Transactability is becoming table stakes, surface by surface. Deep integration is an edge today and an expectation later. The right move is not to predict the dates but to be ready for the first, to pilot the second, and to watch the signals that will tell you when the third has arrived for you. ## FAQ **When does agentic commerce become table stakes?** It is staged. Being discoverable is table stakes already; being transactable on the major surfaces is becoming table stakes, surface by surface; deep integration is an advantage now and an expectation later. Read it as a sequence tied to signals, not a date. **How will I know it has become table stakes for my business?** Watch signals: your category appearing in agent answers, competitors going live, agent-referred traffic in your analytics, and platform or payment milestones reaching general availability in your market. When several turn at once, the window has moved. **Why will adoption be uneven?** It depends on the host surface, the vertical, and the geography. A standard matters only where a popular surface promotes it, some categories suit agent buying sooner than others, and the US is ahead of most markets. **What should I do given the uncertainty?** Take the low-regret path: be discoverable now, pilot transactability on a live surface, and watch the signals before committing to deep integration. Primary sources: - The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants: https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants - New agentic commerce tools and a protocol for retailers and platforms: https://blog.google/products/ads-commerce/agentic-commerce-ai-tools-protocol-retailers-platforms/ - Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol: https://openai.com/index/buy-it-in-chatgpt/ --- # Downloadable resources These reusable Markdown resources are included for AI assistants, researchers, and builders. # Merchant Agent-Readiness Checklist URL: https://agenticcommerceatlas.com/resources/agent-readiness-checklist.md Format: text/markdown License: CC BY 4.0 with attribution to Agentic Commerce Atlas Agentic Commerce Atlas - agenticcommerceatlas.com - CC BY 4.0 A practical checklist to assess whether your business is ready for AI agents to find and buy your products. Work top to bottom; the early items are foundational. ## 1. Product data - [ ] Every product has complete attributes (title, description, price, currency, availability, images, brand, category, identifiers, variants) - [ ] Your product feed is structured and machine-readable (a recognized schema), not just web-page prose - [ ] Feed prices and stock match your live store exactly, to the cent and the unit - [ ] Price and availability sync in near real time, not in slow batches - [ ] You monitor for drift between the feed and the live store ## 2. Discoverability - [ ] Your products are present on at least one live agent surface your customers use - [ ] You have verified how agents represent and rank your products - [ ] If you sell through a platform, syndication to agent surfaces is enabled and checked ## 3. Transactability - [ ] Your checkout is reachable via an API that returns structured data, not only rendered web-page elements - [ ] You support, or have a clear path to support, a checkout standard (ACP and/or UCP) for the surfaces you care about - [ ] You have completed an agent-initiated order end to end in a test ## 4. Payments and verification - [ ] You rely on the networks' agent-verification and scoped-token mechanisms rather than building your own trust layer - [ ] You understand the Shared Payment Token or delegated-payment flow for your processor - [ ] You have read the terms of any agent-payment program you have joined ## 5. Evidence and monitoring - [ ] You log agent authorization and behavior continuously across the transaction - [ ] You can defend a dispute with a recorded audit trail rather than a reconstruction ## 6. Governance and risk - [ ] Agentic commerce has a named owner in your organization - [ ] Leadership is briefed on the two contested points: the checkout-standard question and the liability picture - [ ] You handle agent-channel data to the same standard as the rest of your customer data - [ ] You have a deliberate plan to protect your first-party customer relationship How to read it: mostly unchecked means start with section 1 (product data); mostly checked means you are ready to run a real pilot and measure. --- Learn more at agenticcommerceatlas.com. Free to reuse under CC BY 4.0 with attribution. --- # Agentic Commerce Vendor and Platform Evaluation Scorecard URL: https://agenticcommerceatlas.com/resources/vendor-evaluation-scorecard.md Format: text/markdown License: CC BY 4.0 with attribution to Agentic Commerce Atlas Agentic Commerce Atlas - agenticcommerceatlas.com - CC BY 4.0 Questions to ask a platform, processor, or vendor before committing to an agentic commerce integration. Score each from 1 (poor) to 5 (strong), or mark N/A, and add notes. A low score on trust and liability or on lock-in deserves extra weight. ## Standards and surfaces - Which checkout standards do you support (ACP, UCP, both)? [ 1 - 5 ] - Which agent surfaces does this reach (ChatGPT, Google AI Mode and Gemini, others)? [ 1 - 5 ] - Do you support the discovery (MCP) and authorization (AP2) layers, or only checkout? [ 1 - 5 ] ## Data and feed - How is our product feed ingested, and how is live-store parity maintained? [ 1 - 5 ] - How quickly do price and stock changes propagate to agent surfaces? [ 1 - 5 ] ## Payments and economics - What payment methods and tokens are supported (Shared Payment Token, network tokens, stablecoins)? [ 1 - 5 ] - What are the fees, including any per-sale fee on agent-initiated orders? [ 1 - 5 ] ## Trust, fraud, and liability - How do you verify that an agent is legitimately authorized to act for a customer? [ 1 - 5 ] - Who bears liability for an agent-initiated chargeback, and what are the dispute terms? [ 1 - 5 ] - What consumer-protection commitments apply? [ 1 - 5 ] ## Independence and lock-in - Is this built on open standards, or proprietary to one network or platform? [ 1 - 5 ] - How portable is our integration if we switch providers? [ 1 - 5 ] ## Support and roadmap - What is your support model and response commitment? [ 1 - 5 ] - What is on your agentic commerce roadmap for the next 6 to 12 months? [ 1 - 5 ] Total: ____ / 70. Add notes against each row, and weight trust, liability, and lock-in heavily. --- Learn more at agenticcommerceatlas.com. Free to reuse under CC BY 4.0 with attribution. --- # Agentic Commerce RFP Question Bank URL: https://agenticcommerceatlas.com/resources/rfp-question-bank.md Format: text/markdown License: CC BY 4.0 with attribution to Agentic Commerce Atlas Agentic Commerce Atlas - agenticcommerceatlas.com - CC BY 4.0 A buyer-ready question bank for RFPs, procurement reviews, and vendor demos involving agentic commerce platforms. Use these questions to turn broad claims about "AI commerce" into specific evidence. ## 1. Scope and supported use cases - Which agentic commerce use cases do you support today: product discovery, comparison, cart creation, checkout, payment authorization, post-purchase support, or all of these? - Which parts are generally available, in private beta, or still roadmap? - Which customer segments or verticals are live on the capability now? - Can you show a real end-to-end demo using our category, not only a generic sample catalog? ## 2. Standards and interoperability - Which open standards do you support: ACP, AP2, UCP, MCP, A2A, x402, MPP, or others? - Where do you use open standards, and where do you use proprietary APIs? - Can we export our integration, data mappings, and transaction records if we move providers? - How do you handle standards changes, versioning, and backward compatibility? ## 3. Product data and catalog quality - What product data fields are required, recommended, and optional? - Which identifiers do you use for matching: GTIN, SKU, brand, category, variant, merchant ID, or platform-specific IDs? - How quickly do price, availability, promotion, and variant changes reach agent surfaces? - How do you detect and report catalog errors, mismatches, or missing attributes? - Can we see how agents currently describe and compare our products? ## 4. Agent discovery and ranking - Which agent surfaces, marketplaces, assistants, or shopping interfaces can discover our products through your integration? - What factors influence whether our products are shown, ranked, or excluded? - Can we receive reporting on impressions, recommendations, comparisons, clicks, carts, and completed purchases by agent surface? - How do sponsored placements, retail media, or paid listings interact with organic agent recommendations? ## 5. Checkout and transaction control - Does the agent complete checkout through your platform, our checkout, or a third-party checkout surface? - Which checkout standard or API is used? - What customer, cart, shipping, tax, promotion, and inventory data is exchanged at checkout? - Can we enforce business rules such as restricted products, shipping limits, minimum order values, fraud controls, and promotion exclusions? - How are failed, partial, canceled, refunded, or changed orders handled? ## 6. Payments, authorization, and disputes - Which payment methods and delegated-payment models are supported? - How is customer authorization captured, scoped, stored, and auditable? - Do you support Shared Payment Tokens, network tokens, stablecoins, or other payment artifacts? - Who is liable for fraud, agent error, customer dispute, chargeback, or unauthorized purchase claims? - What evidence is available to defend a dispute? ## 7. Privacy, security, and data use - What customer, product, transaction, and behavioral data do you collect? - Which data is shared with agent platforms or model providers? - Do you use our data to train models, rank competitors, or improve unrelated services? - What security certifications, data retention terms, deletion controls, and access logs are available? - Can we restrict sensitive products, customer groups, or geographies? ## 8. Measurement and reporting - What dashboards and exports are available for agent-driven discovery, conversion, order value, returns, and disputes? - Can reporting separate agent surface, protocol, product category, campaign, and transaction status? - How do you attribute a purchase when an agent researches on one surface and checkout happens elsewhere? - Can data be exported to our analytics, warehouse, or BI tools? ## 9. Operations and support - What implementation work is required from our ecommerce, payments, product data, legal, and customer-service teams? - What is the typical pilot timeline and launch checklist? - What support, incident response, uptime commitment, and escalation path do you provide? - How are breaking changes, partner outages, policy changes, and standards updates communicated? ## 10. Commercial terms and lock-in - What fees apply: setup, monthly platform, per-order, payment, referral, ad, data, or support fees? - Are fees different by agent surface, protocol, payment method, geography, or category? - What contract terms limit portability, direct customer relationships, data reuse, or future integrations? - What happens to our data, listings, and transaction history if we leave? ## Red-flag answers - "We support agentic commerce" without naming which use cases are live. - "Standards-based" without saying where standards end and proprietary APIs begin. - "Real-time catalog sync" without a measurable freshness commitment. - "Agents can buy for users" without a clear authorization and dispute record. - "Full reporting" without exports by agent surface and transaction state. --- Learn more at agenticcommerceatlas.com. Free to reuse under CC BY 4.0 with attribution. --- # Site pages These pages complement the reference above and can be read directly: - About: https://agenticcommerceatlas.com/about - Editorial standards and how we verify: https://agenticcommerceatlas.com/editorial-standards - Contribute corrections and updates: https://agenticcommerceatlas.com/contribute - Protocol directory: https://agenticcommerceatlas.com/protocols - Downloadable resources: https://agenticcommerceatlas.com/resources - Machine-readable site index: https://agenticcommerceatlas.com/data/site-index.json - MCP server (query the Atlas live): https://agenticcommerceatlas.com/mcp - Machine-readable protocol data: https://agenticcommerceatlas.com/data/protocols.json - Machine-readable resource data: https://agenticcommerceatlas.com/data/resources.json