ACP vs UCP in 2026: one checkout core, two adapters, and why UCP ships first

Summary. Two agentic checkout protocols now matter, and they are not in the same shape. OpenAI and Stripe published the Agentic Commerce Protocol (ACP) on 29 September 2025 alongside Instant Checkout in ChatGPT. Google published the Universal Commerce Protocol (UCP) on 11 January 2026 with Shopify, Etsy, Wayfair, Target and Walmart, and the specification has already moved twice, from version 2026-01-11 to 2026-01-23 to 2026-04-08. Then the picture inverted. On 27 February 2026 OpenAI and Amazon announced a partnership including a $50 billion Amazon investment in OpenAI. On 4 March 2026 OpenAI quietly removed Instant Checkout from ChatGPT for Shopify merchants and other retailers, a move Forrester analysts Emily Pfeiffer and Sucharita Kodali covered on 7 March 2026. Roughly 30 Shopify merchants were ever live on it. Meanwhile Google spent 20 May 2026 expanding UCP into ads, YouTube, hotels and food delivery. So the honest engineering answer to "should we ship both?" is: build one checkout core and two thin adapters, then ship the UCP adapter first and keep the ACP adapter behind an interface. The protocols overlap enough that a second backend is waste. They diverge exactly where it costs you: discovery and payment.

Where the two protocols actually stand in July 2026

Most comparisons of these two protocols were written before March 2026 and treat them as symmetric rivals. They are not symmetric any more, and any roadmap built on the old framing will misallocate a quarter of engineering time.

The dates matter, so here they are in order, each traceable to a primary source.

On 29 September 2025 OpenAI announced Instant Checkout in ChatGPT, built with Stripe, opening with US Etsy sellers and promising over a million Shopify merchants. OpenAI open-sourced the underlying protocol as ACP the same day, and said merchants pay "a small fee on completed purchases" while remaining the merchant of record.

On 11 January 2026 Google published UCP, co-developed with Shopify, Etsy, Wayfair, Target and Walmart and endorsed by more than 20 partners including Adyen, American Express, Best Buy, Flipkart, Macy's, Mastercard, Stripe, The Home Depot, Visa and Zalando. Note that Stripe endorsed UCP while co-maintaining ACP. That is a signal about where the payments industry expects volume.

On 27 February 2026 OpenAI and Amazon announced a strategic partnership including a $50 billion Amazon investment in OpenAI. On 4 March 2026 OpenAI removed Instant Checkout. On 11 March 2026 Amazon announced feed support so merchants could send products into its Shop Direct experience. Forrester's Emily Pfeiffer laid out that sequence on 17 March 2026.

The adoption numbers explain the retreat better than the narrative does. Per The Information's reporting, only about a dozen Shopify merchants were live on Instant Checkout; Shopify told Forrester a month earlier the figure was closer to 30 and climbing. Against Shopify's millions of merchants, that is noise. On the demand side, Forrester's December 2025 Consumer Pulse Survey found 23% of Gen X US online adults had used ChatGPT in the past month to search for products, rising to 32% for Millennials and 35% for Gen Z, and single digits for older generations. Searching is not buying. In Forrester's ConsumerVoices survey from March 2026, online adults in the US, UK and Canada who regularly use answer engines ranked completing a purchase inside the answer engine as their least-adopted use case.

Forrester principal analyst Emily Pfeiffer put the engineering problem plainly: "The checkout moment is proving to be the most squirrely to replicate in this channel, as this announcement confirms."

Google's position went the other way. At Google Marketing Live on 20 May 2026, Google announced the Universal Cart working across retailers and across Search and Gemini, checkout with Google Pay at Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair and Shopify merchants including Fenty and Steve Madden, Affirm and Klarna instalment options inside Google Pay, UCP-powered checkout rolling out across Canada and Australia with the UK later, and UCP extending into hotel booking and food delivery in Google Maps.

The strategic read is uncomfortable but useful. In Forrester's February 2026 Consumer Pulse Survey, 71% of US online adults said they used Google to search for products in the past month against 54% for Amazon including Rufus. Google has the traffic and now a shipping checkout. That is the surface to build for.

What ACP actually specifies

Strip the announcements away and ACP is a small, readable REST surface. The Stripe specification defines an agentic checkout session with five operations:

            POST /checkouts                  # create a session
GET  /checkouts/:id              # retrieve
PUT  /checkouts/:id              # update items, address, fulfillment option
POST /checkouts/:id/complete     # process payment, create order
POST /checkouts/:id/cancel       # release inventory
          

The create request is thin: an items array of {id, quantity}, an optional buyer hash of first_name, last_name, email, phone_number, and an optional fulfillment_address. The response carries the seller's view of the world: id, status, currency, line_items, fulfillment_options, totals, messages and links.

The status enum is not_ready_for_payment, ready_for_payment, completed, canceled, in_progress. Money is integer minor units throughout, so 2000 is $20.00. Totals are a typed array rather than a flat object, with type drawn from items_base_amount, items_discount, subtotal, discount, fulfillment, tax, fee, total. That design detail matters when you map it, because a totals array with display text is a presentation contract, not just arithmetic.

Payment is where ACP is narrow. PaymentProvider has a provider field whose only documented value is stripe, and supported_payment_methods whose only documented value is card. Completion posts a payment_data hash of token, provider and optional billing_address, where the token is a Stripe Shared Payment Token such as spt_123. OpenAI's own documentation notes that merchants on other processors can still participate through the Shared Payment Token API or the Delegated Payments spec, but the shape of the protocol is built around one provider and one method.

Error handling is well specified. ErrorMessage codes include missing, invalid, out_of_stock, payment_declined, requires_sign_in and requires_3ds, and messages carry an RFC 9535 JSONPath param pointing at the offending component. Order events are order_created and order_updated, with order status drawn from created, manual_review, confirmed, canceled, shipped, fulfilled. Refunds are typed store_credit or original_payment. ACP versions by date in YYYY-MM-DD form.

There is no discovery manifest in the published checkout specification. The agent is told where your endpoints are out of band, through the merchant application process. That is a smaller protocol, and for a single-agent world it is a perfectly reasonable one.

What UCP actually specifies

UCP is a bigger idea and a bigger surface. It is not only a checkout API; it is a negotiation framework with checkout as one capability.

A UCP business publishes a profile at /.well-known/ucp. The 2026-04-08 specification requires that profile to be served over HTTPS, to avoid 3xx redirects, and to carry a Cache-Control header that is public with max-age of at least 60 seconds. The profile advertises ucp.version, ucp.services, ucp.capabilities, ucp.payment_handlers and a signing_keys array of JWKs used to verify signatures on webhooks and other authenticated messages.

Capabilities are namespaced by reverse domain, in the form {reverse-domain}.{service}.{capability}. The standard set includes dev.ucp.shopping.checkout, dev.ucp.shopping.cart, dev.ucp.shopping.order and dev.ucp.common.identity_linking, with extensions such as dev.ucp.shopping.fulfillment and dev.ucp.shopping.discount declaring an extends pointer at their parent capability.

Two governance rules in that spec have real implementation consequences. First, the dev.ucp.* namespace is reserved for the UCP governing body, and vendors must use their own reverse domain for custom capabilities. Second, spec URL origin must match the namespace authority: a dev.ucp.* capability must cite a https://ucp.dev/... spec URL, and platforms must validate that binding and should reject capabilities where it does not hold. If you invent dev.ucp.shopping.loyalty and point it at your own docs, conforming agents are entitled to drop it.

Version negotiation is explicit. Both sides declare capability versions as arrays; the intersection is computed per capability; the highest mutual version wins; a capability with no mutual version is excluded. Businesses supporting older protocol versions should publish version-specific profiles and advertise them through supported_versions. The spec is deliberate about not prescribing a deprecation schedule, calling version lifecycle a business policy decision.

Every request carries a UCP-Agent header using RFC 8941 dictionary syntax:

            POST /checkout-sessions HTTP/1.1
UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json"
Content-Type: application/json
          

That header is what makes UCP's "permissionless onboarding" work: any platform with a discoverable profile can transact with any business without prior registration. It also means you must verify that the authenticated principal is authorised to act for the profile named in UCP-Agent, and reject requests where the authenticated identity and claimed profile conflict. That is a real security control, and it is on you to implement.

Transports are an enum: rest, mcp, a2a, embedded. REST is the core binding. The same checkout capability can be exposed over MCP as a tools/call, over A2A as an agent extension, or embedded as a hosted interface reached through a continue_url.

The comparison that decides your architecture

Read the last row twice. Everything above it is engineering preference. That row is revenue.

Why one backend is enough

The reason a dual-protocol build does not need two backends is that both protocols model the same object. A checkout session has line items, a buyer, an address, fulfilment options, totals and a status. Both use integer minor units. Both express totals as typed, displayable components. Both put the order lifecycle behind webhooks or events. Neither one asks you to change how you price, tax, reserve inventory or fulfil.

So the split is clean. Your domain owns the state machine. Each protocol gets an adapter that translates inbound requests into domain commands and translates domain state back into that protocol's response shape.

If protocol names leak below the adapter, you have built the thing you were trying to avoid. A useful test: your domain layer should compile with every ACP and UCP type deleted.

A sketch of the shape, in TypeScript:

            // domain/checkout.ts - knows nothing about ACP or UCP
export type Money = number; // integer minor units

export interface DomainCheckout {
  id: string;
  status: "draft" | "payable" | "completed" | "cancelled";
  currency: string;
  lines: Array<{ id: string; sku: string; qty: number; unit: Money; tax: Money }>;
  buyer?: { firstName?: string; lastName?: string; email: string };
  totals: { subtotal: Money; discount: Money; shipping: Money; tax: Money; grand: Money };
}

export interface CheckoutService {
  create(input: CreateInput): Promise<DomainCheckout>;
  update(id: string, patch: PatchInput): Promise<DomainCheckout>;
  complete(id: string, payment: PaymentIntent): Promise<Order>;
}

// adapters/acp.ts
export function toAcp(c: DomainCheckout) {
  return {
    id: c.id,
    status: mapAcpStatus(c.status), // -> ready_for_payment | completed | ...
    currency: c.currency.toLowerCase(),
    line_items: c.lines.map((l) => ({
      id: l.id,
      item: { id: l.sku, quantity: l.qty },
      base_amount: l.unit * l.qty,
      discount: 0,
      subtotal: l.unit * l.qty,
      tax: l.tax,
      total: l.unit * l.qty + l.tax,
    })),
    totals: [
      { type: "subtotal", display_text: "Subtotal", amount: c.totals.subtotal },
      { type: "fulfillment", display_text: "Shipping", amount: c.totals.shipping },
      { type: "tax", display_text: "Tax", amount: c.totals.tax },
      { type: "total", display_text: "Total", amount: c.totals.grand },
    ],
    messages: [],
    links: [],
  };
}

// adapters/ucp.ts
export function toUcp(c: DomainCheckout) {
  return {
    ucp: { version: "2026-04-08", capabilities: [{ name: "dev.ucp.shopping.checkout", version: "2026-04-08" }] },
    id: c.id,
    currency: c.currency.toUpperCase(),
    buyer: c.buyer && { full_name: [c.buyer.firstName, c.buyer.lastName].filter(Boolean).join(" "), email: c.buyer.email },
    line_items: c.lines.map((l) => ({
      id: l.id,
      item: { id: l.sku, title: titleFor(l.sku), price: l.unit },
      quantity: l.qty,
      totals: [{ type: "subtotal", amount: l.unit * l.qty }],
    })),
    totals: [
      { type: "subtotal", amount: c.totals.subtotal },
      { type: "total", amount: c.totals.grand },
    ],
  };
}
          

Two details in that sketch are worth calling out because they bite in production.

Currency case is not cosmetic. ACP's specification says currency is a three-letter ISO code in lowercase and its examples show "usd". Google's UCP walkthrough shows "currency":"USD". Normalise at the adapter boundary or you will ship a bug that only appears on one surface.

Buyer names do not round-trip. ACP requires first_name and last_name as separate required fields. UCP's example carries full_name. Splitting a full name into two fields is lossy and culturally wrong for a large share of Indian buyers, where a single-token name or a name with multiple components is ordinary. Store what you were given, keep a canonical full_name, and derive the ACP fields only at the ACP boundary. Never write a naive split(" ") into your customer record.

Payment is the real divergence

Cart arithmetic is the easy half. Payment is where the two protocols are built on different beliefs.

ACP assumes a processor. The token arrives, provider says stripe, you charge. One lane, well paved.

UCP assumes a market. Its specification separates payment instruments, which are what is accepted, from payment handlers, which are the specifications for how instruments are processed. A payment credential provider such as Google Pay or Shop Pay is the participant; the handler such as com.google.pay or dev.shopify.shop_pay is the specification that provider authors. The business selects a handler and supplies configuration, public keys and merchant IDs. The platform executes the provider's logic to acquire a token and hands the opaque credential to the business. The lifecycle is three steps: negotiation, acquisition, completion.

Three rules in that model are non-negotiable in implementation. Credentials flow platform to business only, and businesses must not echo credentials back in responses. Platforms handle tokens, encrypted payloads or mandates, never raw PANs. And handler_id in the payload tells the business which provider key to use for decryption or charging, which the spec calls out explicitly as preventing key-confusion attacks.

Businesses must also filter the handler list against cart context, for example removing instalment options for subscription items or filtering regional methods by shipping address. That is business logic living in a protocol response, and it is easy to forget until a buyer is offered a payment method you cannot honour.

Then there is AP2. The optional AP2 Mandates Extension, dev.ucp.shopping.ap2_mandate, adds cryptographic proof of user authorisation for autonomous scenarios. The agent signs objects with the user's key on a non-agentic surface, and completion carries a top-level ap2 object with a signed checkout_mandate beside the payment instrument. The business must not accept a completion request lacking that mandate when the extension is in play. This is the part of UCP that actually earns the word "agentic", and ACP has no equivalent.

The engineering judgement here is simple. The real cost is not the checkout endpoints. It is the payment integration and the key management behind them.

What the March pullback should change in your roadmap

The temptation after 4 March 2026 is to conclude that agentic checkout was hype and do nothing. That is the wrong lesson, and Forrester's own advice is more precise: hold on to the checkout process and its data and margin protection, and treat answer engine optimisation as part of the playbook now.

The defensible reading is that discovery moved and checkout did not. Consumers are researching in answer engines at meaningful rates and buying elsewhere. That is a referral pattern, and the web has known how to make money from referral patterns for decades.

So the sequence that survives contact with reality:

Note what is not on that list: a second checkout backend, and a bet on either vendor's roadmap.

One more thing Forrester flagged that engineers should own rather than merchandisers: inventory. Because product data reached answer engines through crawling or generic feeds, the engines usually saw only what the website showed, with no channel-level allocation. That produced out-of-stock items on display and products surfaced that were never meant for the channel. If you expose a checkout capability, you are promising you can actually fulfil what the agent sees. Decide the allocation before you publish the profile.

India-specific considerations

Google's May 2026 announcement listed India among the first countries for the AI performance insights tool in Merchant Center, alongside Australia, Canada, New Zealand and the US. That tool compares your brand's share of voice on AI surfaces against similar brands, which is a discovery instrument, not a checkout one. UCP-powered checkout itself was announced as rolling out across Canada and Australia in the coming months with the UK later, and India was not named for checkout. Confirm eligibility in Merchant Center before you scope a sprint against it.

That gap is actually convenient. It means Indian D2C teams can do the valuable half now, product data quality and answer engine visibility, and defer the payment work until a surface exists to sell on. If you are building that visibility layer, our guide to AEO, GEO and SEO covers how these surfaces select sources, and the 2026 SEO guide covers the feed and markup groundwork underneath it.

On privacy, agentic checkout moves buyer identity and order data to your backend through a third party you do not control. India's Digital Personal Data Protection Act 2023 applies to that processing, and consent, purpose limitation and retention are your obligations regardless of which protocol carried the payload. Both protocols are designed to pass only what an order needs; that is a good default and not a compliance position. We design applications aligned with DPDP requirements rather than treating a protocol default as sufficient.

Payments add a second layer. UCP's handler model expects a payment credential provider with which you already hold a contract and API keys. For Indian merchants, the practical question is which handler covers UPI and domestic cards on a given surface, and today that answer comes from the surface operator rather than from the specification. If your team is planning the broader AI architecture around this, our enterprise generative AI strategy guide covers how to sequence the platform work.

What we would build first

If a client asked us to make them agentic-checkout ready this quarter, the build order would be: clean the product data, extract a checkout domain service with a protocol-free interface, publish a correct and cacheable UCP profile, implement POST /checkout-sessions and POST /checkout-sessions/{id}/complete against one payment handler, verify UCP-Agent properly, and stop. The ACP adapter is a small piece of work once the domain exists, and there is no consumer surface waiting for it today. Building it now is optimism, not architecture.

The one thing worth doing early that looks like overkill: version negotiation. UCP's intersection algorithm and supported_versions map are not decoration. The spec has already moved from 2026-01-11 to 2026-04-08 in three months and explicitly refuses to promise a deprecation schedule. Code that pins a single version string will break, and it will break silently, as a capability quietly dropping out of the intersection rather than as an error you can page on.

FAQ

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified engineering organisation in Gurugram, and our senior engineering teams build the checkout domain services and protocol adapters this article describes. We work with Shopify and Google as partners, which matters when the integration question is which handler and which surface rather than which framework. If you are deciding whether to spend a sprint on UCP now or wait for your market to open, talk to us and we will scope it against your actual catalogue, payment stack and target countries.

References

1. Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol, OpenAI, 29 September 2025.

1. Build the Agentic Commerce Protocol checkout endpoints, Stripe Documentation.

1. Agentic Commerce Protocol, Stripe Documentation.

1. Agentic Commerce Protocol specification site, OpenAI and Stripe.

1. agentic-commerce-protocol repository, GitHub.

1. Under the Hood: Universal Commerce Protocol (UCP), Amit Handa and Ashish Gupta, Google Developers Blog, 11 January 2026.

1. Universal Commerce Protocol specification overview, version 2026-04-08, ucp.dev.

1. AP2 Mandates Extension, ucp.dev.

1. Google Universal Commerce Protocol (UCP) integration guide, Google for Developers.

1. About the Universal Commerce Protocol and UCP-powered checkout on Google, Google Merchant Center Help.

1. How we're helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google, Google, 20 May 2026.

1. New tech and tools for retailers to succeed in an agentic shopping era, Google.

1. What It Means That The Leader In "Agentic Commerce" Just Pulled Back, Emily Pfeiffer and Sucharita Kodali, Forrester, 7 March 2026.

1. Power Couple OpenAI + Amazon May Have Just Won Consumer Agentic Commerce, Emily Pfeiffer, Forrester, 17 March 2026.

1. Agent Payments Protocol (AP2), AP2.

1. Developing an open standard for agentic commerce, Stripe.

Last updated: 16 July 2026.