# 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 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 is now stewarded under the Linux Foundation. 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. ## 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 built as an **extension of A2A**, so the signed-mandate machinery rides 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 and now under the Linux Foundation. It is a coordination layer, not a commerce protocol. **What does it have to do with agentic commerce?** It is the substrate payment extensions build on: AP2 is an A2A 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 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 --- # 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-06-29 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. **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** and governed through a public proposal process, with a stated intention to move toward broader, more neutral stewardship over time. ## 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 that is scoped to one specific merchant and one specific cart 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. 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 on 14 October 2025 to let ChatGPT users buy most of its catalog. **PayPal** announced on 28 October 2025 that it would adopt ACP to bring its merchant network into ChatGPT. The widely repeated claim that "over a million Shopify merchants" went live is not accurate. That figure was an announced ambition described as "coming soon," and only a small number of Shopify merchants actually integrated. According to trade reporting, in early 2026 OpenAI scaled back native Instant Checkout, repositioning the in-chat "buy now" experience toward ChatGPT Apps and product discovery that sends shoppers to a merchant's own checkout. The protocol itself continues as the connective infrastructure, but the flagship "buy directly inside the chat" moment was pulled back. 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**, and the latest stable version as of mid-2026 is dated **2026-04-17**, following a steady cadence of releases that added fulfillment, capability negotiation, discounts, payment handlers, cart, feed, orders, authentication, and MCP support. ## 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. Notably, Stripe and Meta are associated with both efforts, a sign the standards are still settling. 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. That was an announced ambition, not a live fact. Only a handful of Shopify merchants integrated, and OpenAI scaled back native Instant Checkout in early 2026. Etsy was genuinely live from launch. **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 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-06-29 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 Tech Council | | Launched | September 2025 | January 2026 | | Scope | The agent-to-merchant checkout | The whole shopping journey | | Primary surface | ChatGPT | Google Search (AI Mode), Gemini | | Payment | Shared Payment Token | Pairs with AP2, via Google Pay | | License | Apache 2.0 | Apache 2.0 | | What is live | Etsy from launch; native in-chat checkout scaled back in early 2026 | Checkout in AI Mode and Gemini for eligible US retailers | ## 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 steered by a Tech Council. That council doubled to ten members in April 2026 when Amazon, Meta, Microsoft, Salesforce, and Stripe joined the founding group of Google, Shopify, Etsy, Target, and Wayfair. The detail worth noting is the overlap: **Stripe and Meta back both standards**, a clear signal that the field is still settling and that big players are hedging. 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 OpenAI scaled back native in-chat Instant Checkout in early 2026, repositioning toward apps and discovery that hand shoppers to the merchant's own checkout. 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. Both 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 pairs with [AP2](/learn/ap2-explained) for payment authorization (the signed mandate that proves the user approved the purchase) and, in Google's reference implementation, settles through Google Pay. 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. The presence of Stripe and Meta on both sides reinforces 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 --- # 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 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, supporting both [ACP](/learn/acp-explained) and Google's [UCP](/learn/ucp-explained) widens the set of surfaces you can be bought from. The specific risk is margin and commoditization. Some agent surfaces charge a fee on each completed sale, so 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). ## 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. 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 agentic commerce tools and a protocol for retailers and platforms: 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 --- # 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 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 | Instant Checkout in a supported agent surface | | Announced or pilot | A provider has announced partners, pilots, or a rollout path | Network-token and 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. ## 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 is closer to internet infrastructure than shopping, but it belongs in the same map because the buyer is still software acting within rules. ## 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. Instant Checkout is the clearest consumer checkout example; 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 --- # 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 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, 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 and the Stripe/OpenAI checkout model. 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. ## 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. 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. Do not assume liability terms are settled. 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. ACP matters for surfaces using the Agentic Commerce Protocol; UCP matters for Google Search, Gemini, and Google-led shopping surfaces. Many retailers should plan for both through platform or provider integrations. **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 agentic commerce tools and a protocol for retailers and platforms: 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/ - 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/ - Product data specification: https://support.google.com/merchants/answer/7052112 - Agentic Commerce Protocol specification (GitHub): 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 --- # 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-06-29 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. It is the coordination layer some payment work builds on, for example the x402 extension for A2A. **ACP (Agentic Commerce Protocol).** Open standard for agent-to-merchant checkout, launched in September 2025. 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. **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 in April 2026. 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 in 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 Etsy live from day one. OpenAI scaled back native Instant Checkout in early 2026 toward apps and discovery that send shoppers to the merchant's own checkout. **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. ## M **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).** Anthropic's standard for how agents discover and call tools and data, donated to a foundation under the Linux Foundation in December 2025. In commerce it acts as the discovery layer. See [MCP explained](/learn/mcp-explained). **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 cards. Built on HTTP 402, like x402. 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. **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 merchant and one specific cart total. The agent passes it to the merchant to charge, and never sees the buyer's raw card details. Also reused by MPP for card and buy-now-pay-later settlement. **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 and can optionally stream responses with Server-Sent Events. 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 for the broader shopping journey, from discovery through checkout to post-purchase. Launched January 2026; 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. ## 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. ## X **x402.** Coinbase's settlement protocol reviving the HTTP `402 Payment Required` status for machine-native, often stablecoin, payments. Contributed to the Linux Foundation's x402 Foundation in 2026. Sits alongside MPP at the settlement layer. Primary sources: - 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/coinbase/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 --- # 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 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, and order 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. ## 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. - 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; - the payment artifact presented; - the final order, refund, cancellation, or exception. ## 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. The downloadable version of this 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). ## 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, and any exception or refund record. 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 - Product data specification: https://support.google.com/merchants/answer/7052112 - Model Context Protocol: https://modelcontextprotocol.io/ --- # 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 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 | | 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? - 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? ## 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? - 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? - Can we support more than one agent surface or protocol without rebuilding? ## 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? - Who is liable for fraud, agent error, customer dispute, chargeback, unauthorized purchase, or "not as described" claims? - What evidence is available to defend a dispute, and how long is it retained? 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). ## 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. - "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. - "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. Pair it 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. 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, plus who carries liability. **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 - Announcing the Agent Payments Protocol (AP2): https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - Model Context Protocol: https://modelcontextprotocol.io/ - Visa Intelligent Commerce launch: 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 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) is an open framework introduced to help merchants distinguish legitimate AI agents from malicious bots. The card networks' programs, Visa Intelligent Commerce and Mastercard Agent Pay, require agents to be registered and verified before they can transact, rather than letting any piece of software present a card. 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 credentials, that record what the user authorized and can be presented as proof of consent, with a 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. Two things are concrete. American Express has made the most explicit consumer-protection commitment so far, an Agent Purchase Protection pledge tied to purchases made by registered agents, which stands out precisely because a settled industry-wide standard does not exist. And regulators have begun to take an interest in how existing dispute and chargeback regimes apply to agent-initiated purchases, though the detailed rules are still forming and should be tracked rather than assumed. The practical defense, regardless of how the rules settle, is evidence: capture the user's authorization and a clear audit trail at the moment of delegation, continuously, rather than trying to reconstruct consent after a dispute. AP2's design explicitly aims at a non-repudiable audit trail for this reason. ## 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. 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. Evidence and monitoring: log agent authorization and behavior continuously across the transaction so you can defend a dispute with a record, not 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, so read the terms and keep your evidence. 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. Much of the risk is widely expected to fall on merchants, since the networks, issuers, and AI providers are not volunteering to absorb it. American Express has made the most concrete consumer-protection pledge so far. The practical defense is to capture authorization and an audit trail 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 credentials, to prove a specific user approved a specific purchase. Visa's Trusted Agent Protocol helps merchants tell legitimate agents from bots, and the networks' programs require agents to be registered and verified before they can 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. Continuous logging is your strongest position in a dispute, 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 - 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 - 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 --- # 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 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. 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 a concrete consumer-protection pledge for purchases made by registered agents, but that does not settle the whole market. 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, 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 made an explicit protection pledge, but there is not yet one cross-network rulebook. **What should merchants log?** Authorization, 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 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-06-22 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. Two notable absences: **Visa and Stripe**, both of which have pursued their own approaches. The governance has since shifted. In **April 2026, Google donated AP2 to the FIDO Alliance**, where the specification now advances through industry working groups, including a Payments group chaired by Mastercard and Visa and a new Agentic Authentication group. Google still maintains the reference implementation and SDKs, but the normative standard is moving into a neutral body. So calling AP2 "a Google protocol" today is imprecise: it originated at Google and is now under FIDO stewardship. ## 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. 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 unsolved: in the short term, knowing which agents and credential providers to trust relies on manually curated allow-lists rather than a scalable real-time framework. The liability guidance Google published is explicitly a helpful guide, not a binding contract, so actual liability still depends on each network's rules. And payment-type coverage is partial: cards are supported, stablecoins are handled through the x402 extension, but real-time bank transfers and recurring payments are on the 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 in 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. The standards bodies do not frame them as rivals, though Visa and Stripe are absent from AP2's partners. 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: 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/ - A2A x402 extension: https://github.com/google-agentic-commerce/a2a-x402 --- # 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 [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 in April 2026. 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. ## 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. Payment constraints include `payment.amount_range`, `payment.budget`, `payment.allowed_payees`, `payment.allowed_payment_instruments`, `payment.allowed_pisps`, and `payment.agent_recurrence` (with a `frequency` such as `MONTHLY` and a `max_occurrences`). Checkout constraints include `checkout.allowed_merchants` and a required `checkout.line_items`. A closed mandate that does not satisfy the open mandate's constraints is invalid. ## 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. The specification is explicit that a non-deterministic signature scheme (ECDSA) must be used rather than a deterministic one, to avoid certain hash attacks. Delegation is expressed as a chain. The root SD-JWT is signed by a root of trust, typically the user's bank or agent provider. Each subsequent hop is a key-binding SD-JWT signed by the private key whose public half was named in the previous hop's `cnf` claim. 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 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. chain = client.present(holder_key=agent_jwk, mandate_token=open_token, payloads=[closed_payment_mandate]) # The merchant or network verifies, trusting only the root issuer key. result = client.verify(chain, key_or_provider=issuer_jwk) ``` 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. ## 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 can present the Payment Mandate to the payment network and receive a scoped purchase credential, a token, in return; a settlement layer such as MPP then verifies the Payment Mandate and its binding to the checkout hash before the money moves. 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. **Is AP2 production-ready?** It reached v0.2 in April 2026 with an SDK, schemas, and sample scenarios, 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 (modes and mandates): https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md - AP2 agent authorization (SD-JWT and key binding): https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/agent_authorization.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 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) | Mostly pilot or closed beta | | Liability | A framework, not a binding contract | 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 April 2026, an "Intelligent Commerce Connect" on-ramp. **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 with a developer kit and an explicit Agent Purchase Protection pledge. 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. Google donated AP2 to the **FIDO Alliance**, where the payments working group is chaired by members from **Mastercard and Visa**, so the open standard's stewardship now includes the networks themselves. And Visa's Intelligent Commerce Connect is explicitly protocol-agnostic, designed to work across AP2, ACP, and other agent protocols. In other words, the networks are helping steward the open standard while also running their own programs. Expect interoperability, not a clean either-or. ## Status and liability Both are early, but in different ways. AP2 is pre-production: it ships an SDK, schemas, and sample scenarios, but the public materials are reference implementations rather than documented live deployments, and its liability guidance is a framework rather than a binding contract. 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 Mastercard and Visa chair the payments group, and Visa's on-ramp is protocol-agnostic. The open standard and the network rails are converging. **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 --- # 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-06-22 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. Visa launched it in pilot with partners including AWS and Highnote, with broader rollout continuing through 2026; Visa's own announcement said only that it would reach more partners during the year, while trade reporting put general availability around the end of June 2026. 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 developer kit and Amex Agent Purchase Protection, an explicit commitment to back card-member purchases made by registered agents. That consumer-protection pledge is the most concrete liability stance any network has made. 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. This 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 cards and buy-now-pay-later via 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 consumer-protection pledge. AP2's design places accountability on humans, merchants, and issuers rather than the agent. But 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 rolling out through 2026, with trade reporting pointing to general availability around the end of June 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 protection for purchases by registered agents; AP2 puts accountability on humans, merchants, and issuers; 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 --- # 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 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. ## The JSON-RPC methods you must handle 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. 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 2025-06-18 MCP revision supports all of these; the lesson is to add them when a tool's job demands it, not by default. 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. 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 --- # 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 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. ## 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: `Authorization` (a bearer API key the agent platform presents, which you verify), `Content-Type: application/json`, and `API-Version` (a date such as `2026-01-30`) are required; `Idempotency-Key`, `Signature`, `Timestamp`, and `Request-Id` 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`. ### 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, and the schema-correct shape is nested: ```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`. Do not send a flat `{ "token": "spt_123", "provider": "stripe" }`; that form appears in some older examples but is not valid against the current schema, which rejects unknown fields. 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. 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 treat the `Idempotency-Key` seriously: store it and return the original result on a retry, so a network retry never creates a duplicate order or charge. 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. **What is the most common mistake?** Sending a flat `{ token, provider }` payment shape (not schema-valid; use the nested `instrument.credential.token`), and 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-01-30): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-01-30/openapi/openapi.agentic_checkout.yaml - ACP Delegate Payment API (OpenAPI, 2026-01-30): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-01-30/openapi/openapi.delegate_payment.yaml - Stripe Agentic Commerce documentation: https://docs.stripe.com/agentic-commerce --- # 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 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. ## 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. 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, and the agentic commerce protocols consume product feeds rather than inventing a wholly new format: the [Agentic Commerce Protocol](/learn/acp-explained) includes a product feed, and Google's [UCP](/learn/ucp-explained) defines a catalog capability. So the priority is the quality and accuracy of the feed you already have, and making sure it reaches the surfaces your customers use, not building a separate catalog from scratch. ## 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 well-formed shopping feed you already publish is most of what agents need; the protocols consume product feeds rather than invent a new format. Prioritize quality and accuracy over a separate system. **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 --- # Introducing Agentic Commerce URL: https://agenticcommerceatlas.com/learn/introducing-agentic-commerce Markdown URL: https://agenticcommerceatlas.com/learn/introducing-agentic-commerce.md Section: learn 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 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/ --- # 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-06-23 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). ## 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. 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/ --- # 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 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. ## 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. 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. For example: 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. Primary sources: - Model Context Protocol: https://modelcontextprotocol.io/ - 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 - Agentic Commerce Protocol specification (GitHub): https://github.com/agentic-commerce-protocol/agentic-commerce-protocol --- # 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-06-22 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 and buy-now-pay-later** methods, via Stripe's [Shared Payment Tokens](/learn/acp-explained). ## 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 Coinbase's stablecoin-focused version. 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 cards and buy-now-pay-later. 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. 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 - x402 protocol: https://github.com/coinbase/x402 --- # 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-06-29 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 mid-2026:** in beta. 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. It represents each purchase as three cryptographically signed mandates: an **Intent Mandate** (what the user wanted), a **Cart Mandate** (what the agent assembled), and a **Payment Mandate** (what gets charged). The point is trust: proving to a merchant or network that a real user consented to a specific amount. **Layer:** payment authorization and trust. **Backed by:** Google 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. **Layer:** commerce semantics. **Backed by:** Google and major retailers. ### MCP: Model Context Protocol From **Anthropic**, 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. **Layer:** discovery and capability. ### 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. **Layer:** agent coordination. ### 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. **Layer:** settlement. ### 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 cards and buy-now-pay-later via 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, Stripe | The agent-to-merchant checkout standard | | [AP2](/learn/ap2-explained) | Payment authorization | Google + networks/PSPs | The proof that a user authorized the purchase | | [UCP](/learn/ucp-explained) | Commerce semantics | Google + retailers | The broader discover-to-post-purchase layer | | [MCP](/learn/mcp-explained) | Discovery / capability | Anthropic | How agents find the checkout in the first place | | [A2A](/learn/a2a-explained) | Agent coordination | Multi-party | How buyer and merchant agents talk | | [x402](/learn/x402-explained) | Settlement | Coinbase ecosystem | Machine-native, stablecoin micropayments | | [MPP](/learn/mpp-explained) | Settlement | Stripe, 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/ - x402 protocol: https://github.com/coinbase/x402 - 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-06-29 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 during Sundar Pichai's keynote. 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, Macy's, Mastercard, Stripe, The Home Depot, Visa, and Zalando. It is licensed under Apache 2.0, with the specification at ucp.dev and code under a dedicated GitHub organization. The standard is steered by a **UCP Tech Council**, which reviews contribution proposals and stewards the open-source protocol. Its founding members are Google, Shopify, Etsy, Target, and Wayfair. On **24 April 2026** the council doubled in size when **Amazon, Meta, Microsoft, Salesforce, and Stripe** joined it, a notable convergence that brought several companies with previously rival positions under one open-standard governance body. Stripe and Meta now sit formally on the UCP council while also being tied to the rival ACP, a sign the big platforms are hedging across both commerce standards. ## What UCP actually does What distinguishes UCP is scope. Its initial capabilities include catalog search, cart building, checkout, identity linking via OAuth 2.0, an order lifecycle (shipped, delivered, returned), and a payment-token exchange. 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: as AP2's own documentation puts it, UCP orchestrates the broader purchase lifecycle while [AP2](/learn/ap2-explained) is the specialized layer that authorizes and signs the transaction. 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 plain REST, MCP, or A2A. ## What is actually live As of mid-2026, the specification, SDKs, samples, and a conformance suite are published, and Google built the first reference implementation to power checkout inside AI Mode in Search and the Gemini app for eligible US retailers, paying through Google Pay. In March 2026 Google added new optional UCP capabilities: a **Cart** option that lets agents add multiple items at once, 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. At **Google Marketing Live on 20 May 2026**, Google extended **Universal Cart**, which lets shoppers save products across retailers and check out via Google Pay or a retailer's own flow, to named brands including Nike, Sephora, Target, Walmart, Wayfair, and Shopify merchants, and pushed UCP into new verticals beyond retail: **hotel booking** (with Booking.com, Expedia, Hilton, Marriott, IHG, and Accor) and **food delivery** (with DoorDash, Square, Toast, and Uber Eats), rolling out in the US first. So UCP is real and shipping in Google's own surfaces and expanding past retail, though broad third-party adoption is still early. ## 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 orchestrates the purchase lifecycle and AP2 authorizes the payment, with AP2 integrated as an extension within UCP. Primary sources: - 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/ --- # 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-06-22 **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 is live, powering checkout inside AI Mode in Search and the Gemini app for eligible US retailers, paying through Google Pay. On the ChatGPT side, OpenAI and Stripe launched in-chat Instant Checkout in September 2025 with Etsy live from day one, but only a small number of merchants integrated, and OpenAI scaled back native in-chat checkout in early 2026, repositioning toward apps and product discovery that send shoppers to the merchant's own checkout. The card networks' agent-payment programs from Visa, Mastercard, and American Express are mostly in pilot or closed beta. 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. 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 checkout in AI Mode and Gemini for eligible US retailers, and a small set of merchants transact through ChatGPT, but much is still pilot or "coming soon," and OpenAI scaled back native in-chat Instant Checkout in early 2026. **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 --- # 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 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 an **x402 Foundation** in September 2025 to steward the protocol, and it is now organized under the **Linux Foundation**, 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. ## 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/coinbase/x402 - x402 documentation: https://x402.gitbook.io/x402 - A2A x402 extension (GitHub): https://github.com/google-agentic-commerce/a2a-x402 --- # 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 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 cards and buy-now-pay-later. 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 | Coinbase, with Cloudflare | Stripe and Tempo | | Launched | 2025 | March 2026 | | Built on | HTTP 402 "Payment Required" | HTTP 402 "Payment Required" | | Settles in | Stablecoins (for example USDC) | Stablecoins, plus cards and buy-now-pay-later | | Rails | On-chain, via a facilitator | Tempo blockchain and Stripe (PaymentIntents API) | | Governance | x402 Foundation, under the Linux Foundation | Stripe and Tempo | | 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, while also supporting cards and buy-now-pay-later. 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 cards and buy-now-pay-later, via 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, now under the Linux Foundation, giving it neutral, multi-party stewardship. MPP is currently steered by its co-authors, Stripe and Tempo. That is a familiar pattern in agentic commerce: the crypto-native standard leans on a foundation early, while the provider-backed standard starts under its sponsors with the question of broader governance still 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 buy-now-pay-later 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 cards and buy-now-pay-later through Stripe. **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/coinbase/x402 - Introducing the Machine Payments Protocol: https://stripe.com/blog/machine-payments-protocol - MPP documentation: https://mpp.dev/ --- # 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-06-29 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. **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. **March (reported)**: **OpenAI** scales back native Instant Checkout, shifting toward ChatGPT Apps and product discovery. This was surfaced through trade reporting and an OpenAI spokesperson statement rather than a single official release. **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 the **UCP Tech Council**, doubling it to ten members alongside founders Google, Shopify, Etsy, Target, and Wayfair, 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. ## 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. For how the pieces relate, see [the landscape](/landscape/agentic-commerce-landscape) and [the protocol stack](/learn/agentic-commerce-protocol-stack). Primary sources: - 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/coinbase/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/ - 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/ --- # 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-06-29 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
OpenAIGoogleAnthropicMicrosoftAmazonPerplexity
Commerce protocols
ACPUCPMCPA2A
Payment authorization
AP2Verifiable Intent
Networks & processors
VisaMastercardAmexStripePayPal
Platforms & merchants
ShopifyEtsyWalmartTargetWayfair
Settlement & standards
x402MPPCoinbaseTempoFIDO AllianceLinux Foundation
## Who backs each standard
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. **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** is building agentic commerce into Copilot, 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. ## 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 steered by a UCP Tech Council that doubled to ten members in April 2026 when Amazon, Meta, Microsoft, Salesforce, and Stripe joined founders Google, Shopify, Etsy, Target, and Wayfair. 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)**, from Anthropic, is the discovery layer. **A2A (Agent-to-Agent)** standardizes coordination between agents. 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 in April 2026, is the leading standard here, using signed mandates as verifiable credentials. **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; in April 2026 it added Intelligent Commerce Connect, a protocol-agnostic acceptance "on ramp" that works across the Trusted Agent Protocol, MPP, ACP, and UCP, with general availability targeted for the end of June 2026. **Mastercard** launched Agent Pay, built on agentic tokens and payment passkeys, also in April 2025. **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 powers Instant Checkout through its Shared Payment Token, the most concretely live consumer flow; it 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 is central to merchant reach. **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. **The Linux Foundation** hosts the Agentic AI Foundation, which now holds MCP after Anthropic's December 2025 donation, and the x402 Foundation for the stablecoin rail. ## 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. **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. ## How to read the map Two 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, which is usually a sign a field is maturing past the land-grab phase. For the dated sequence of how this came together, see [the timeline](/landscape/agentic-commerce-timeline). Primary sources: - 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 - 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/ --- # 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/ --- # 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 --- # 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 --- # 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