---
title: Agentic Checkout Architecture for Merchants (2026)
description: Checkout for a shopping agent is your cart math behind a contract, not a prompt. ACP specifies five endpoints. UCP checkout is a select-merchant program. Pin the spec date. Idempotency stops the double order.
url: https://www.factualminds.com/blog/agentic-checkout-architecture-2026/
datePublished: 2026-09-25T00:00:00.000Z
dateModified: 2026-09-25T00:00:00.000Z
author: palaniappan-p
category: AI Agents
tags: ai-agents, ecommerce, agentic-commerce, security
---

# Agentic Checkout Architecture for Merchants (2026)

> Checkout for a shopping agent is your cart math behind a contract, not a prompt. ACP specifies five endpoints. UCP checkout is a select-merchant program. Pin the spec date. Idempotency stops the double order.

On **25 September 2026**, agentic checkout means a **merchant-hosted cart** that an assistant can call. It does not mean the model invents a price and a payment. OpenAI's [checkout spec](https://developers.openai.com/commerce/specs/checkout) and Google's [UCP guide](https://developers.google.com/merchant/ucp) agree on that split even though the programs differ.

**Who this is for.** A CTO or commerce architect. Executives who only need the channel choice should read [ChatGPT shopping](/blog/chatgpt-shopping-for-merchants-2026/) or [Gemini shopping](/blog/google-gemini-shopping-for-merchants-2026/) and the [ACP vs UCP comparison](/compare/acp-vs-ucp/).

**Our take:** one commerce engine remains the price authority. Protocol handlers are adapters. If two adapters compute tax differently, you have two checkouts.

## Responsibilities

| Step | Protocol | Merchant | Platform (Shopify, Adobe, BigCommerce, custom) | Shopper-facing assistant |
| --- | --- | --- | --- | --- |
| Discovery | Feed shape | Attribute truth | Catalog sync | Ranks and explains |
| Cart create | Session schema | Line items that exist | Inventory read | Asks for size or address |
| Tax, shipping, promos | Carries your numbers | Rules | Engine that already runs the website | Displays your totals |
| Payment | Scoped token or wallet contract | Charges through your processor | Payment settings | Must not see a raw PAN |
| Order write | Complete call | OMS record | Order APIs | Confirmation you return |
| Fulfillment | Optional later status | Warehouse | WMS | Only if you push updates |
| After-sale change | UCP talks about it; ACP checkout stops | Policy and a person | Returns APIs | Do not grant write by default |

The AWS sketch for hosting adapters is the pattern [agentic commerce on AWS](/patterns/agentic-commerce-on-aws/). Hosting does not make you protocol-compliant.

## ACP shape

Pin **2026-01-30** unless you have deliberately moved to the **2026-04-17** tree. The merchant implements five routes under checkout sessions: create (HTTP 201 plus cart state), update, retrieve, complete, cancel. Complete applies the payment instrument and must create the order or return an error. Retries need `Idempotency-Key`.

Payment is a scoped credential (shared payment token or the delegate-payment path in the Stripe-oriented docs), limited to that merchant and that total. The agent does not become your payment vault. Log the session id. Do not log the credential.

Instant Checkout inside ChatGPT is **approved partners**. If you are not approved, this section is a design you are not cleared to ship. Discovery can still use a feed. See the ChatGPT post.

## UCP shape

Google's implementation targets AI Mode and Gemini for **select** merchants in the **United States, Canada, and Australia**, with Buy buttons only on listings marked `native_commerce` checkout-eligible. You remain merchant of record. Google Pay is the wallet on that implementation. Participating accounts get Merchant Center onboarding and a sandbox.

Publish the profile the guide asks for (`/.well-known/ucp` in the integration docs) and implement the checkout operations against **your** totals. Embedded checkout exists if you must keep your own UI. Native is the path Google describes as default.

MCP can carry tool calls alongside this. An MCP server is not the checkout. The comparison page draws that line.

## Failure handling

- **Downstream timeout.** Return an error state. Do not let a model estimate shipping.
- **Price drift.** Re-price on update. If the feed price and the engine price differ past a threshold you set, fail the session.
- **Partial failure.** Payment captured, order write failed: that is a reconciliation job with a person, not a second `complete`.
- **Duplicate complete.** Idempotency store keyed by the header plus the session id.
- **Wrong customer.** Do not attach the order to a logged-in account unless identity linking succeeded under your rules.

> **What broke** — A handler treated HTTP 500 from tax service as "zero tax" so the demo could finish. **Detection:** a completed session with tax 0 and a jurisdiction that is never zero. **Fix:** map tax failure to a checkout error and alert. **Lesson:** a green demo that swallows tax is a ledger incident.

## Security

Separate credentials for the protocol handler. No Shopify admin token, no Adobe admin bearer, no BigCommerce token with order-write beyond what complete needs — and even that write should be your order service, not a general admin client. Prompt injection does not apply the same way as a support bot, but a poisoned product description can still try to steer the assistant. Your totals must ignore merchant-supplied text that is not a price field. More on store-side agents: [securing agents](/blog/secure-ai-agents-ecommerce-store-2026/).

Stamp `source` on the order for [attribution](/blog/agentic-commerce-attribution-2026/). Unknown is allowed. Guessed is not.

## If you only do one thing

Draw the box that calculates tax. If that box is "the model," stop and point it at the engine that already runs your website.

## What to do this week

1. Confirm partner or pilot status. No status, no endpoint project.
2. Write the idempotency rule and the tax-failure rule before code.
3. Reuse the integration boundary in [Shopify, ERP, CRM, and WMS](/blog/ai-agent-ecommerce-integration-2026/) so checkout does not grow a second admin client.
4. Read the glossary entry [agent checkout](/glossary/agent-checkout/) for the short definition, then this page for the split.
5. [Discuss the architecture](/contact-us/?focus=ai-agents) with [agentic commerce readiness](/services/agentic-commerce-readiness/) if you want the adapter scoped. The library of agent patterns stays at [/resources/ecommerce-ai-agents/](/resources/ecommerce-ai-agents/).

## What this post doesn't cover

- Sample request JSON from a future spec revision. Pin the file you implement; the GitHub tree moves.
- Fraud-model tuning. We have not published a false-positive rate for agent sessions.
- Marketplace checkout (Amazon, eBay). Out of scope.

## FAQ

### When should you NOT build a custom agentic checkout?
When your platform is about to ship the endpoint, when you are not an approved ACP partner and not a selected UCP merchant, or when price and inventory already disagree. A custom handshake on bad data fails in public.

### What could go wrong if complete is not idempotent?
The agent retries a timeout and you create two orders for one payment credential. The ACP spec includes an Idempotency-Key. Honor it. Return the original order on replay.

### What could go wrong if the model computes tax?
The shopper sees a total your ledger cannot post. Tax, shipping, and discounts come from your commerce engine. The protocol transports them. It does not calculate them.

### Does AgentCore Payments replace this?
No. AgentCore Payments, GA 18 August 2026, is for an agent paying a metered API. ACP and UCP are a shopping agent buying a product for a person. Different money.

### Who is merchant of record?
You are, on both Google's UCP description and OpenAI's checkout guide. The assistant is not the seller. Your fraud, tax, and fulfillment obligations do not move.

---

*Source: https://www.factualminds.com/blog/agentic-checkout-architecture-2026/*
