Agentic commerce protocols: ACP, AP2 and UCP, and what your catalogue needs

TL;DR

• The three open agentic commerce protocols that matter in October 2026 are ACP (OpenAI and Stripe), UCP (Google and retail partners) and AP2 (created by Google, now with the FIDO Alliance). They cover different layers of the same purchase.
• ACP and UCP standardise the product catalogue and the checkout between agent and merchant. AP2 standardises the signed proof that a user authorised a specific purchase and payment. Visa and Mastercard run their own programmes for verifying agents and payment credentials.
• All three accept a GTIN in the product data but none requires one, and none mentions GS1 Digital Link. Checkout runs on the merchant's own item IDs, which is exactly where product identity can slip.

Agentic commerce protocols are the open specifications that let an AI agent find a product, put it in a basket and pay for it on someone's behalf without scraping a website. As of October 2026, three of them carry most of the industry's weight: the Agentic Commerce Protocol (ACP), the Universal Commerce Protocol (UCP) and the Agent Payments Protocol (AP2). They work as layers: ACP and UCP describe how an agent talks to a merchant about products, carts and orders, and AP2 describes how everyone can prove afterwards what the user actually authorised.

For a brand or importer the practical question is narrower. Whichever protocol an agent uses, it asks your catalogue the same things: what is this item, how much is it, can I buy it, and which ID do I pass to checkout. This guide covers who owns each protocol, what it standardises, what a merchant must provide and where product identity fits, as of October 2026.

Which agentic commerce protocols exist, and when did they launch?

What is the Agentic Commerce Protocol (ACP)?

ACP is an open specification for commerce between buyers, their AI agents and businesses. OpenAI and Stripe released it on 29 September 2025, together with Instant Checkout in ChatGPT, under the Apache 2.0 licence. The official repository describes it as in beta and maintained by OpenAI and Stripe as founding maintainers; since April 2026 its maintainers file also lists Meta as a lead maintainer. The latest stable version is 2026-04-17.

ACP standardises four things:

• Checkout. The merchant exposes a checkout-session API: the agent creates a session from items, updates it with address and delivery choice, and completes or cancels it. The specification is explicit that the merchant remains the system of record for orders, payments, taxes and compliance, and that payment runs through the merchant's own payment service provider.
• Delegated payment. A payment provider issues a one-time token whose use is limited by an "allowance": a maximum amount, a currency, a specific checkout session, a specific merchant and an expiry time. Stripe's Shared Payment Token was the first compatible implementation. A separate delegated-authentication API covers 3-D Secure 2 checks.
• Product feed. Version 2026-04-17 added a Feed API. It is a push model: the merchant sends its catalogue to a feed hosted by the agent platform, either as a full file or as partial updates.
• Cart and orders, plus a binding for the Model Context Protocol (MCP).

What happened to Instant Checkout?

On 24 March 2026, OpenAI announced that the initial version of Instant Checkout had not offered the flexibility it wanted, and that merchants could use their own checkout while OpenAI concentrated on product discovery. In the same announcement it said it was extending ACP to carry product and promotion feeds into ChatGPT. So the protocol continues, the checkout specification still exists, and in ChatGPT today the feed matters more than the checkout. Onboarding product feeds into ChatGPT is limited to approved partners, who apply through OpenAI.

What product data does an ACP feed need?

In the open ACP Feed API, a product needs a stable id and at least one variant, and each variant needs a stable id and a title. Everything else is optional in the schema: price and list price in minor currency units, availability status, media, categories, variant options such as colour and size, seller, unit price, and a list of barcodes, where each entry has a type such as GTIN, UPC or EAN and a value.

OpenAI's own feed specification for ChatGPT is stricter. It requires an item ID, title, description, product URL, brand, seller name, main image URL, availability and price. The gtin field is optional, must be 8, 12, 13 or 14 digits with a valid check digit, and should be omitted if the product has none. The mpn field must be sent with the brand, and the specification tells merchants not to invent a part number to stand in for a missing GTIN.

The ACP feed proposal also settles an important point: feed data is informational, and the checkout response is authoritative for price, stock, tax and delivery. If the variant ID in the feed is not the ID the merchant's checkout accepts, the merchant must provide a mapping.

What is the Universal Commerce Protocol (UCP)?

UCP is an open standard covering the whole purchase journey: discovery, cart, checkout, account linking and orders. Google launched it on 11 January 2026, developed in collaboration with Shopify, Etsy, Wayfair, Target and Walmart and published at ucp.dev under the Apache 2.0 licence. Governance has grown since: in April 2026 Stripe joined Google and Shopify as permanent members of the Governing Council, and technical committees for payments, lodging and food were formed over the summer. The current release is v2026-08-25.

A business that supports UCP publishes a profile at /.well-known/ucp listing the capabilities it offers, so an agent can discover them without a custom integration. The capabilities include:

• Catalogue search and lookup, added in v2026-04-08.
• Cart and checkout, with taxes and pricing calculated by the business.
• Identity linking through OAuth 2.0, so an agent can act within a customer's account without holding their password.
• Orders, with status, shipment and return updates by webhook.
• Payment handlers, which separate the payment instrument from the provider that processes it, and which use AP2 for payment mandates.

UCP can be offered over REST, MCP or Agent2Agent (A2A). Google's first implementation powers buying from eligible merchants in AI Mode in Search and the Gemini app. It runs from a Google Merchant Center account and existing shopping feeds, access is through a waitlist, and the merchant remains merchant of record.

What product data does UCP need?

A UCP variant must have an id, a title, a description and a price. The variant id is the one used as the item ID at checkout. Optional fields include the merchant's sku, a canonical URL, availability, media, unit price and barcodes, whose well-known types are UPC, EAN, ISBN, GTIN and JAN.

The lookup rules are revealing. A UCP catalogue must support lookup by product ID and variant ID. It may support secondary identifiers such as SKU. A GTIN lookup is not something an agent can count on.

For Google's own implementation, the feed rules of Merchant Center still apply. Google recommends a GTIN for all products that have one assigned by the manufacturer, and warns that leaving out an assigned GTIN can lead to the product being disapproved.

What is the Agent Payments Protocol (AP2)?

AP2 solves a different problem. When an agent pays, the merchant, the card issuer and the payment network were not watching the user click "buy". AP2 gives them signed evidence of what the user authorised, so they can accept the transaction and settle disputes. Google announced it on 16 September 2025. On 28 April 2026 Google released version 0.2 and announced it was donating AP2 to the FIDO Alliance, where standardisation continues in FIDO's working groups. The AP2 specification site and repository are published under the Apache 2.0 licence.

The two versions describe the same idea differently:

• Version 0.1 (September 2025) used three mandates: an Intent Mandate capturing what the user asked for, a Cart Mandate recording the exact items and price the user approved, and a Payment Mandate.
• Version 0.2 (April 2026) uses a Checkout Mandate, which secures what is being bought, and a linked Payment Mandate, which secures the payment. Each exists in an open form, holding the user's constraints before a basket is final, and a closed form, tied to one finalised checkout. Mandates are signed credentials with selective disclosure, so each party sees only what it needs.

AP2 defines five roles (shopping agent, credential provider, merchant, merchant payment processor and a trusted surface where the user consents) and two modes. In "human present" purchases the user approves the final basket. In "human not present" purchases, the main addition in v0.2, the user signs constraints in advance and the agent completes a purchase that meets them.

AP2 deliberately leaves the catalogue and checkout APIs out of scope. It is designed to work with UCP: when used with UCP, the merchant-signed checkout inside a Checkout Mandate must be the UCP checkout object. Its item type carries only an id (described as often the SKU), a title, a price and an optional image URL.

Where do Visa and Mastercard fit?

Both card networks have programmes that sit next to these protocols rather than replacing them. They deal with agent identity and payment credentials, not with product data.

• Visa Trusted Agent Protocol (14 October 2025, developed with Cloudflare) lets an approved agent sign its requests to a merchant so the merchant can tell a legitimate shopping agent from a malicious bot. It can carry agent intent, consumer recognition and optional payment information, and is published on the Visa Developer Center and GitHub.
• Mastercard Agent Pay (29 April 2025) introduced Agentic Tokens and requires agents to be registered and verified before they transact. Verifiable Intent, introduced by Mastercard and Google on 5 March 2026, is an open specification for a tamper-resistant record of what a user authorised, aligned with AP2 and UCP. Google's April 2026 announcement says Verifiable Intent is also being donated to the FIDO Alliance.

A merchant usually meets these through its payment provider, and they do not change what your catalogue has to contain.

How do ACP, UCP and AP2 compare?

Where does product identity fit, and where are the protocols silent?

Read side by side, all three specifications identify a product at checkout with an ID the merchant chose. ACP uses the feed's variant ID, UCP uses its variant ID, and AP2's mandates list acceptable item IDs from the merchant. That is reasonable for completing an order with one shop. It is the weak point Paula Rivero described at the W3C/GS1 workshop in Zurich: an agent can run checkout flawlessly and still buy the wrong product, because a merchant's internal ID says nothing about which physical product it is outside that shop.

The GTIN is the field that crosses that boundary. ACP and UCP both have a place for it, and OpenAI's feed specification validates its check digit. None of the three protocols makes it mandatory, none says how an agent should compare the same GTIN across merchants, and none mentions GS1 Digital Link, the Digital Product Passport or any other way of resolving a product to information from the brand itself.

Our reading of how they fit together, which is not stated in any of the specifications:

• The GTIN in the feed is the bridge between merchants. If two shops sell the same shampoo with the same GTIN, an agent can recognise them as the same product and compare offers rather than guess from titles. If the GTIN is missing, the agent falls back to matching names.
• An open AP2 mandate is only as precise as its item IDs. A user who authorises "reorder this exact product" is, in v0.2, authorising a list of merchant item IDs. A GTIN behind those IDs is what makes the instruction mean the same thing at a second shop.
• GS1 Digital Link is where the brand's version of the truth lives. A GS1 Digital Link URI is built from the same GTIN, so an agent that already has the GTIN can construct it and resolve it to information the brand controls: specifications, instructions, safety information and, in the EU, passport data. None of the protocols requires an agent to do this. Nothing in them prevents it either.

Where a QR code does not help: it plays no part in checkout, payment or mandates, and a protocol-compliant feed does not need one. Its value here is the identifier behind it.

What should brands and importers do now?

The protocols will keep changing; the catalogue work does not depend on which one wins.

1. Make sure every product that has a GTIN carries it in your own systems, in your Google Merchant Center feed and in any ACP feed, and that the check digit is valid. Do not invent identifiers for products that have none.
2. Keep one stable ID per variant, and check that the ID in your feed is the one your checkout accepts. Both ACP and UCP depend on it.
3. Map GTIN to variant ID explicitly. One GTIN should point to one sellable variant in your catalogue, including pack size and formulation.
4. Send the fields agents use to choose: title, description, brand, price, availability, images and a canonical product URL. In ACP and UCP these are what an agent sees before checkout.
5. Keep price and stock fresh. Both specifications treat the feed as informational and the checkout as authoritative, so a stale feed sends agents into failed checkouts.
6. Ask your payment provider which agentic flows it supports: Stripe's Shared Payment Token for ACP, UCP payment handlers, AP2 mandates, Visa's and Mastercard's agent programmes. You rarely implement these yourself.
7. Give the GTIN a resolvable home. A GS1 Digital Link resolver under your own domain lets any agent, on any protocol, check the product against your own data. It is also the route the EU's Digital Product Passport will rely on.

Digital Link is a GS1 solution partner, and our platform gives each product a GS1 Digital Link built on its GTIN, with brand-controlled pages and structured data behind it that people and machines can read. For agentic commerce, that is the identity layer the protocols leave open: one identifier per product that resolves to your data, whichever agent or protocol is asking. If you want to check how ready your catalogue is for agent-led buying, get in touch and our team will review your product data with you.

Frequently asked questions

What is the difference between ACP and AP2?

ACP is a commerce protocol: it standardises the product feed, checkout session and a delegated payment token between an AI agent and a merchant. AP2 is a payments-trust protocol: it standardises signed mandates that prove what a user authorised, and it leaves the catalogue and checkout to other protocols. The AP2 specification names UCP as the commerce protocol it is designed to work with.

Is ACP the same as Instant Checkout in ChatGPT?

No. Instant Checkout was OpenAI's product built on ACP. In March 2026 OpenAI moved away from standalone Instant Checkout so merchants could use their own checkout, and extended ACP to carry product and promotion feeds for discovery in ChatGPT. The ACP specification itself remains open and in beta.

Do agentic commerce protocols require a GTIN?

No. ACP and UCP both offer an optional barcode field that accepts a GTIN, and OpenAI's ChatGPT feed specification lists gtin as optional. Google Merchant Center recommends a GTIN for every product that has one and can disapprove products where an assigned GTIN is missing.

Do any of these protocols use GS1 Digital Link?

Not as of October 2026. None of the ACP, UCP or AP2 specifications mentions GS1 Digital Link. Because a GS1 Digital Link URI is built from the GTIN, any agent that receives a GTIN through these protocols can resolve it, but that is our reading of how they combine, not a protocol requirement.

Who owns AP2 now?

Google created AP2 and announced its donation to the FIDO Alliance on 28 April 2026, together with the release of version 0.2. The specification and SDK remain public on GitHub, and further standardisation takes place in FIDO's working groups.

Can EU merchants use these protocols?

The specifications are open and can be implemented anywhere. The first consumer products built on them launched in the United States, and the platforms decide country by country where merchants can take part, so check each platform's current eligibility before planning on it.