Agentic Checkout

TL;DR — Agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. is the “press buy for me” part of AI shoppingAI shopping optimization is the practice of making a merchant's products discoverable, recommendable, and buyable across AI shopping surfaces — ChatGPT, Google AI Mode, Gemini, Copilot, and Perplexity — by treating the structured product feed as a first-class optimization surface alongside the human-facing webpage, not a replacement for it.. When an AI assistant finds a product and completes the purchase for you, that final transaction step is the agentic checkout. In OpenAI’s delegated-payment flow, the agent uses a scoped payment tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. instead of a raw card number, and for anything risky (a login, an extra verification) it stops and hands control back to a human. It’s one piece of the bigger protocols (ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. and UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp.), not a thing on its own.

What agentic checkout is

Most of “AI shopping” is discovery: you ask an assistant to find you something, and it reads merchants’ product feeds and suggests options. Agentic checkout is the step after that — the part where the agent actually creates the order: picks a shipping option, works out tax and shipping cost, passes along payment, and finalizes the purchase.

The key word is step. Agentic checkout isn’t a separate product or company. It’s the transaction-completion capability built into the two big agentic-commerce standards — the Agentic Commerce Protocol (ACP) from OpenAI and Stripe, and the Universal Commerce Protocol (UCP) from Google and Shopify. If you want the overview of those, the sibling write-ups on each cover them; this page zooms all the way in on the checkout mechanics.

The three things people get wrong

• “The AI buys with zero human involvement.” Not really. Both protocols have a built-in “stop and ask a human” step — for a login, an extra card verification, or a confirmation. Truly hands-off checkout isn’t how the specs are built.
• “The AI sees my credit card.” No. Payment is passed as a scoped token — a stand-in that’s locked to one merchant, one amount, one time window, and can only be used once. The raw card number never reaches the agent.
• “This is already normal — most stores have it.” Also no. As of mid-2026 it’s early: only about a dozen Shopify stores had gone live with ChatGPT checkout before OpenAI scaled back the fully in-chat version in March 2026.

Who’s responsible if something goes wrong?

The store you bought from is still the store — what’s called the merchant of record. They handle the order, refunds, and disputes, just like a normal online purchase. The genuinely messy part, which nobody has fully solved yet, is what happens with a disputed charge when the “shopper” was an AI agent. More on that in the Advanced tab.

Want the actual state machine, how the payment tokens are scoped, where a human has to step in, and what merchants must test before turning this on? Switch to Advanced.

TL;DR — Agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. is the transaction-completion capability of agentic commerce — create, update, complete/cancel a checkout session, delegate payment, confirm the order. It’s one building block of ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. and one of UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp., not a standalone protocol. The technical spine is a state machine: ACP walks a session through not_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required when needed) → completed, mirroring UCP’s incomplete → requires_escalation → ready_for_complete. The escalation states are the deliberate human-in-the-loop seam. Payment delegation uses scoped tokensA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. — merchant-locked, amount-capped, time-limited, single-use — so the agent never holds a raw card. Order confirmation is a push: merchants POST HMAC-signed, full-object webhooks. The merchant stays merchant-of-record, so settlement/refunds/chargebacks sit with the merchant and its PSP — but the chargeback evidentiary framework is genuinely unresolved as of mid-2026. Build and test for idempotency-safe retries, webhook signature verification, and the escalation paths before you flip it on.

Scope: this is the transaction step, not the whole protocol

Agentic checkout is one capability. In ACP it’s literally the Agentic Checkout block (one of five, alongside Product Feed, Delegate Payment, Delegate Authentication, and Orders/Webhooks). In UCP it’s the checkout capability inside a broader, capability-negotiated spec. The sibling articles on ACP and UCP cover the surrounding protocol and business context — feed quality, the /.well-known/ucp profile, the March 2026 pivot’s discovery implications. This page stays on the mechanics of completing the transaction: the session lifecycle, payment delegation, where a human intervenes, order confirmation, and liability.

One framing to carry in from the ACP sibling and not re-argue: agents transact against feeds and APIs, not your crawled HTML. So checkout reliability — not page copy — is what’s being optimized here.

The checkout session state machine

The single most differentiating thing to understand about agentic checkout, and the thing most write-ups skip, is that a checkout is a session with a status, and that status moves through a defined machine.

ACP’s Checkout reference lists the full status enum: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress, and expired. The happy path is short — not_ready_for_payment → ready_for_payment → in_progress → completed, with canceled as the other terminal state. Per ACP’s lifecycle concepts, providing a required fulfillment option is what transitions a session from not_ready_for_payment to ready_for_payment; a failed payment can drop it back to ready_for_payment for a retry.

The interesting states are the ones that aren’t the happy path:

• requires_escalation / authentication_required — the agent can’t proceed alone; something needs a human or an extra verification (see the next section).
• pending_approval — waiting on an approval, e.g. a B2B purchase-order sign-off.
• expired — the session timed out (CheckoutSession carries expires_at).

This is the same underlying design as UCP’s checkout, which runs incomplete → requires_escalation → ready_for_complete, where requires_escalation hands control back to a human via a continue_url (covered on the UCP sibling). Two separate protocols, one convergent pattern: a checkout can’t always finish without stopping to ask a human something. That’s not a limitation bolted on — it’s the core shape of the design.

A practical note for anyone building against ACP: a malformed request returns an HTTP-level error object (type of invalid_request, request_not_idempotent, processing_error, or service_unavailable). But a business-logic problem inside an otherwise-valid session comes back as a MessageError object in the session’s messages[] array, not an HTTP error. You have to handle both, and they’re easy to conflate in early integration work.

How payment delegation works

The whole point of the payment-delegation layer is that raw card data never reaches the agent. Instead of handing the agent a card number, the buyer’s payment details are turned into a scoped token.

Per OpenAI’s Delegated Payment spec, the delegated payment payload is sent to the merchant’s PSP or vault directly, and the PSP or vault returns a payment token scoped to the delegated payment outside of PCI scope. That token is bounded on four axes:

• reason — currently "one_time": single-use.
• max_amount — caps the charge to the checkout total; the token can’t be used to overcharge.
• expires_at (RFC 3339) — the token has a hard expiry.
• merchant_id + checkout_session_id — bound to one merchant and one session.

So a delegated token is merchant-locked, amount-capped, time-limited, and single-use. That’s the mechanism that lets an agent “spend money” without ever being trusted with a reusable card credential. On the ACP side, Stripe’s Shared Payment Token is described as the first Delegated Payment Spec–compatible implementation, with more PSPs coming. UCP uses a parallel decoupled model that separates payment instruments from handlers (covered on the UCP sibling).

PCI scope is a real decision here. OpenAI’s spec is explicit that directly integrating with the Delegated Payment Spec involves directly handling cardholder data and may affect your PCI scope, and direct integration requires PCI DSS Level 1 status. For most merchants the tokenized path (network tokens / a PSP that handles the delegation) is the way to keep cardholder data out of your environment. Choosing between “handle CHD directly” and “let the PSP tokenize” is the first architecture decision — the Decision tab walks it.

Where a human still has to step in

“The shopper still authorizes it” is true but vague. The protocol-level triggers are specific, and naming them is how you design the handoff instead of hitting a silent dead end:

• 3-D Secure / step-up. ACP models this with InterventionCapabilities (supported types include 3ds and address_verification), an enforcement level (always / conditional / optional), and a display_context (native / webview / modal / redirect). The outcome of a step-up comes back as an AuthenticationResult with values like authenticated, denied, rejected, abandoned, canceled, or not_supported.
• requires_escalation / authentication_required states. These are the session statuses that say “I need a human or an extra check before I can move on.”
• B2B approval_required. The PaymentData object carries B2B fields (purchase_order_number, payment_terms, due_date, approval_required) — agentic checkout isn’t only DTC.
• UCP’s continue_url handoff. UCP’s requires_escalation surfaces a continue_url the buyer finishes themselves (login, confirmation, age check). Same seam, different protocol.

The takeaway: a transaction that escalates cleanly is far better than one that silently dead-ends. Design the escalation paths as first-class flows, not error cases.

Order confirmation is a push, not a pull

Here’s a piece the competing explainers largely skip. After a purchase, the agent platform doesn’t sit there polling your API for order status. The merchant pushes signed webhooks.

Per ACP’s webhook reference, merchants POST order events so the agent platform can stay in sync with fulfillment-grade truth. Two event types carry it: order_create for new orders and order_update for state changes. Order status values referenced include created, manual_review, confirmed, canceled, shipped, and fulfilled. Three details matter for anyone implementing it:

• Requests must be signed with an HMAC signature in the Merchant-Signature header. Unsigned or badly-signed requests get a 401.
• The data field must contain the full Order object, not incremental deltas. You send the whole state every time.
• Response codes to handle: 200 success, 401 invalid signature, 429 rate-limited.

So “how does the platform know the order went through?” has a concrete answer: you tell it, with a signed, full-object POST, and you handle the platform’s 429 back-pressure.

Fraud, chargebacks, and liability — what’s settled and what isn’t

This is the most honest and most differentiating section, so I’ll be plain about where the line between “settled” and “open” actually is.

What’s settled: the merchant of record. OpenAI’s own payment spec states that OpenAI is not the merchant of record — under ACP, merchants bring their own PSP, and settlement, refunds, chargebacks, and compliance remain with the merchant and their PSP. Rye’s Arjun Bhargava corroborates this independently: both protocols keep the merchant as the merchant of record, responsible for fulfillment, chargebacks, and disputes. This is consistent with the merchant-of-record framing on both sibling pages — carry it forward, don’t re-derive it.

What’s not settled: the chargeback evidentiary framework. Merchant-of-record tells you who eats a dispute by default. It does not tell you how you win one when the “customer” was mediated by an AI agent. Traditional chargeback defense leans on human-generated evidence trails (IP, device, browsing behavior, a human clicking “buy”). Agent-generated authorization logs are a different kind of evidence, and the card-network dispute rules weren’t written for them. Chargeflow’s fraud specialist Ben Herut frames it as agentic commerce bringing a new layer of fraud and confusion that legacy systems can’t interpret, and Chargeflow’s analysis is blunter still: there are no clean answers yet — card networks, issuers, and platform providers are all working through these questions.

The emerging frameworks are emerging, not finished. Visa’s Trusted Agent Protocol is described as a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience. Mastercard’s Agent Pay (announced April 2025) uses “Agentic Tokens,” an extension of its Digital Enablement Service. Per third-party reporting (Fintech Wrap Up / Finextra), Mastercard’s liability is said to follow the same rules as standard tokenized transactions — the issuer carrying fraud liability when the token is validly issued and honored at authorization — but I’d treat that specific allocation as reported, not confirmed until it’s in Mastercard’s own docs. And note that Visa’s consumer-facing zero-liability guarantee protects cardholders from unauthorized charges; it does not resolve the merchant-side dispute question, which is the actual open one. Don’t conflate the two.

What merchants need to implement and test

Existing content gives strategic prep advice (clean feeds, loyalty programs). Here’s the operational layer — what to actually build and verify before flipping this on:

• Decide your PCI posture. Tokenized/network-token path vs. direct CHD handling (Level 1). Most merchants want the PSP to hold the delegation.
• Make retries idempotency-safe. ACP has a request_not_idempotent error type for a reason. An agent (or a flaky network) will retry a create/complete call; send an idempotency key and make repeated calls with the same key safe, so you don’t double-charge or double-create an order.
• Verify webhook signatures. Validate the Merchant-Signature HMAC on every inbound order webhook, reject on mismatch, and confirm you return 200/429 correctly under load.
• Simulate the escalation paths in sandbox. Force requires_escalation / authentication_required, run a 3DS step-up, and confirm your AuthenticationResult handling covers denied/rejected/abandoned, not just authenticated.
• Reconcile feed/checkout price parity. If the agent sees one price in the feed and checkout returns another, trust erodes fast — the ACP sibling makes this point about feeds; it bites hardest at checkout.
• Stand up agent-order attribution. A completed agentic checkout can land with no GA4 session. Track it at the order/OMS level, not by waiting for a website visit.

TIP Clear the public data handoff before live checkout testing

This check stops at public discovery and sampled feed shape. It cannot verify payment, tax, shipping, authentication, idempotency, webhooks, or order state transitions.

Catch a discovery-to-feed identity mismatch before starting the credentialed test pass with my free AI Commerce Validator Free

1. Compare public discovery with the feed URL and merchant identity you intend agents to use.
2. Resolve identity and sampled feed-shape warnings before testing carts and payments.
3. Run the full sandbox state-machine, retry, escalation, webhook, and order-reconciliation tests separately.

Tap to enlarge

The validator passes its local JSON, endpoint, and sampled feed checks, but warns that the feed URL declared in discovery data differs from the expected feed URL. It states that adjacent schema, crawler, and live checkout checks are not evaluated.

The Testing SOP and Cheat Sheet tabs turn this into a concrete pass.

Where this stands in mid-2026

Ground yourself in the adoption reality, not the pitch deck. Shopify’s president Harley Finkelstein indicated only about a dozen Shopify merchants were actively using AI checkout tools — negligible against Shopify’s overall merchant base — and OpenAI itself scaled the fully-in-chat version of Instant Checkout back to discovery-plus-redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. in March 2026 after running into onboarding, accuracy, and multi-item-cart difficulties. Semrush’s Leigh McKenzie put the friction well: real-time catalog normalization across tens of millions of SKUs is a decade-scale problem, and consumers still default to checkout flows they trust — Apple Pay, Google Wallet, Amazon one-click.

None of that means agentic checkout is vaporware. The protocol capability — create/update/complete a session programmatically, with delegated payment and signed order webhooks — is real, specified, and worth building against. It just isn’t “already normal,” and whether the final step closes in-chat or on your site is an implementation detail that has already changed once and may change again.

AI summary

A condensed take on the Advanced version:

• Agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. = the transaction-completion step of agentic commerceThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website.: an agent creates, updates, completes, or cancels a checkout session on a shopper’s behalf. It’s one building block of ACP and one of UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp. — not a standalone protocol.
• It’s a state machine. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed, with canceled, expired, pending_approval off the happy path. Mirrors UCP’s incomplete → requires_escalation → ready_for_complete.
• The escalation states are the human-in-the-loop seam — login, 3DS step-up, address check, B2B approval_required, UCP continue_url. Fully autonomous zero-human checkout is not how the specs are built.
• Payment = scoped tokensA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory.: merchant-locked (merchant_id + checkout_session_id), amount-capped (max_amount), time-limited (expires_at), single-use (reason: one_time). The agent never holds a raw card. Direct CHD handling affects PCI scope (Level 1); most merchants use the PSP/tokenized path.
• Order confirmation is a push: merchants POST HMAC-signed (Merchant-Signature), full-object webhooks (order_create/order_update), handle 200/401/429.
• Liability: merchant stays merchant-of-record (settlement/refunds/chargebacks with merchant + PSP, per OpenAI’s spec) — but the chargeback evidentiary question (disputing a purchase an AI agent made) is unresolved as of mid-2026. Visa TAP / Mastercard Agent Pay are emerging frameworks, not finished ones.
• Test: idempotency-safe retries (request_not_idempotent), webhook signature verification, simulated escalation/3DS paths, feed/checkout price parity, agent-order attribution (no GA4 session).
• Adoption is early: ~a dozen live Shopify merchants before OpenAI’s March 2026 pivot to discovery-plus-redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't..

Official documentation

Primary-source documentation for the checkout mechanics.

ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. — checkout, lifecycle, webhooks

• ACP Checkout API reference — the checkout-session endpoints, the full status enum, CheckoutSession fields, error/MessageError objects, RiskSignals, AuthenticationResult, and InterventionCapabilities.
• ACP Checkout lifecycle / concepts — the state transitions (fulfillment-option → ready_for_payment; failed payment retry).
• ACP Order webhooks — order_create/order_update, the Merchant-Signature HMAC requirement, full-object payloads, response codes.
• ACP spec on GitHub — the OpenAPI/JSON Schema and date-based versions.

OpenAI / Stripe — payment delegation

• OpenAI Delegated Payment spec — scoped tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. flow, the allowance object (max_amount, expires_at, merchant_id, checkout_session_id, reason), PCI-scope note, merchant-of-record language.
• OpenAI Commerce docs — merchant integration overview.
• Stripe — Agentic Commerce (ACP) — Shared Payment Token, the first Delegated-Payment-compatible implementation.
• Stripe — ACP protocol specification — building the checkout endpoints.

UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp. (parallel checkout machine)

• Google for Developers — UCP guide — the merchant-of-record and eligibility framing on the Google/Shopify side.

Platform / payment-network

• Shopify — Agentic Storefronts requirements — the Supplemental Terms and (as of research) Google AI Mode/Gemini early-access status.
• Visa — Agentic Commerce: Threats and Risks — the Trusted Agent Protocol framing.

Quotes from the source

On-the-record statements on how agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. works and where the open questions are. Deep links jump to the quoted passage where the source page supports it.

ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. / OpenAI — the spec

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” — ACP Checkout API reference. Jump to quote
• The checkout status enum, verbatim: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” — ACP Checkout API reference. Jump to quote
• “OpenAI is not the merchant of record.” Under ACP, merchants bring their own PSP, and settlement, refunds, chargebacks, and compliance remain with the merchant and their PSP. — OpenAI Delegated Payment spec. Jump to quote
• On the tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. flow: the PSP or vault returns a “payment token scoped to the delegated payment” outside PCI scope. — OpenAI Delegated Payment spec. Jump to quote

Industry voices — the liability question

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” — Ben Herut, Fraud and Chargeback Strategist, Chargeflow. Read the coverage
• On whether the rules are settled: per Chargeflow’s analysis, “there are no clean answers yet” — card networks, issuers, and platform providers are all working through these questions. Read the coverage
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” — Arjun Bhargava, Co-founder & CEO, Rye. Read the coverage

Payment networks — emerging frameworks

• On Visa’s approach: the Trusted Agent Protocol is “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” — Visa, Agentic Commerce: Threats and Risks. Jump to quote

Adoption reality

• On why fully-autonomous checkout is slower than the hype: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant CenterGoogle Merchant Center (GMC) is a free platform where retailers upload and manage product data so their products can appear across Google — Shopping, organic Search product grids, Images, Lens, and AI surfaces. Since 2020 it powers free (organic) product listings, not just paid Shopping ads., and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” — Leigh McKenzie, Director of Online Visibility, Semrush, via Search Engine Land. Read the coverage

Which payment-integration path should you take?

The first real architecture decision in agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. is how payment gets delegated — because it directly determines your PCI scope and how much you have to build. Walk it:

Pre-launch test pass for agentic checkout

Run this in sandbox/test mode before enabling agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. in production. It’s the operational layer the strategic “clean your feed” advice skips.

1. Create a checkout session and walk the happy path. POST /checkout_sessions, confirm you get a 201 and a session in not_ready_for_payment (or incomplete). Add a fulfillment option; confirm the status transitions to ready_for_payment.
2. Verify totals are authoritative. Confirm the session’s totals[] (subtotal / tax / fulfillment / discounts / total) match what your backend computes — and that the price equals what’s in your feed. A feed/checkout price mismatch is a trust killer.
3. Complete the session. POST /checkout_sessions/{id}/complete; confirm payment processes and an order is created, and the status lands on completed.
4. Cancel a session. POST /checkout_sessions/{id}/cancel; confirm inventory is released so you don’t leak held stock.
5. Force the escalation paths. Simulate requires_escalation / authentication_required. Run a 3DS step-up and confirm your AuthenticationResult handling covers the failure outcomes (denied, rejected, abandoned, canceled, not_supported) — not just authenticated.
6. Test idempotency. Send the same create/complete request twice with the same idempotency key; confirm you get one order, not two, and that a genuinely non-idempotent retry surfaces request_not_idempotent rather than double-charging.
7. Test business-logic errors vs. HTTP errors. Trigger an in-session problem (e.g. an out-of-stock line item) and confirm it comes back as a MessageError in messages[], and that a malformed request comes back as an HTTP-level error object — your client must handle both.
8. Verify webhook signatures. Send a valid order_create webhook and confirm you validate the Merchant-Signature HMAC and return 200. Send a tampered one and confirm you reject with 401. Confirm you emit the full Order object, not a delta.
9. Test webhook back-pressure. Confirm your sender handles a 429 from the platform with a retry/backoff rather than dropping the event.
10. Confirm attribution capture. Verify the completed order is tagged as agent-originated at the OMS level, since no GA4 session will exist for it.

Common mistakes (and what to do instead)

Assuming “agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site.” means fully autonomous, zero-human purchasing. Why it’s wrong: every credible implementation keeps an authorization/escalation seam — requires_escalation, authentication_required, 3DS step-up, B2B approval_required. Full autonomy without a human-in-the-loop authorization is neither how the specs are built nor how card networks currently treat these transactions. Do instead: design the escalation paths (continue_url, 3DS, approval) as first-class flows so a transaction that needs a human escalates cleanly instead of dead-ending.

Treating this as already-normal because the headlines are loud. Why it’s wrong: only about a dozen Shopify merchants had gone live with ChatGPT checkout before OpenAI scaled the in-chat version back in March 2026. Do instead: build against the protocol capability (it’s real and specified), but plan and staff as if you’re an early adopter, not a laggard catching up.

Believing fraud liability is fully solved because “merchant-of-record” is settled. Why it’s wrong: merchant-of-record is confirmed for settlement/refunds/compliance, but the chargeback evidentiary framework — proving a disputed transaction was properly authorized when the buyer was an AI agent — is explicitly described by industry fraud specialists as unresolved. Do instead: capture agent authorization logs and risk signals now, treat Visa TAP/Mastercard Agent Pay as emerging (not finished) frameworks, and don’t assume your existing chargeback-defense evidence transfers.

Assuming the agent skips your website, so on-site checkout doesn’t matter. Why it’s wrong: “always skips the merchant’s site” was the original ChatGPT Instant Checkout pitch, but ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website.’s flagship implementation itself moved to discovery-plus-redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. in March 2026. The protocol capability is implementation-agnostic. Do instead: keep your own hosted checkout solid and support the programmatic session flow — you may be closing either in-chat or on-site depending on the surface.

Thinking the agent handles the customer’s card number. Why it’s wrong: raw card data never reaches the agent by design — scoped/delegated tokensA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. (Shared Payment Token, UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp.’s decoupled instrument/handler model) are the whole point of the payment-delegation layer. Do instead: route delegation through your PSP so a merchant-locked, amount-capped, single-use token does the work — and keep your PCI scope small.

Non-idempotent retry handling. Why it’s wrong: agents and networks retry. ACP has a request_not_idempotent error type precisely because naive retries double-charge or double-create orders. Do instead: require idempotency keys on create/complete and make repeated same-key calls safe.

Agentic checkout — cheat sheet

ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. checkout session status enum

UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp.’s parallel machine: incomplete → requires_escalation (human via continue_url) → ready_for_complete.

Checkout endpoints (ACP)

• POST /checkout_sessions — create (201)
• GET /checkout_sessions/{id} — retrieve
• POST /checkout_sessions/{id} — update
• POST /checkout_sessions/{id}/complete — process payment + create order
• POST /checkout_sessions/{id}/cancel — cancel + release inventory

Scoped payment tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. — the four bounds

• merchant_id + checkout_session_id → merchant- and session-locked
• max_amount → amount-capped
• expires_at (RFC 3339) → time-limited
• reason: "one_time" → single-use

Order webhooks (ACP)

• Events: order_create, order_update
• Signed: Merchant-Signature HMAC header (required)
• Payload: full Order object, not deltas
• Responses: 200 ok · 401 bad signature · 429 rate-limited
• Order statuses: created · manual_review · confirmed · canceled · shipped · fulfilled

Human-intervention triggers

• requires_escalation / authentication_required states
• InterventionCapabilities (3ds, address_verification; enforcement always/conditional/optional)
• AuthenticationResult outcomes (authenticated/denied/rejected/abandoned/…)
• B2B approval_required; UCP continue_url

Liability at a glance

• Merchant = merchant-of-record → settlement/refunds/chargebacks with merchant + PSP ✅ settled
• Chargeback evidence rules for agent buyers ⚠️ unresolved (mid-2026)
• Visa TAP / Mastercard Agent Pay → emerging frameworks, not finished

Snippets for working with agentic checkout

These are for inspecting and testing your own integration — not for driving live purchases. Use sandbox/test credentials.

Verify a webhook signature (Node.js, HMAC)

Reject anything whose Merchant-Signature doesn’t match. Compare in constant time.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Poll a checkout session’s status (shell)

Watch a sandbox session walk the state machine while you test.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Send a create call with an idempotency key (Python)

Prove that a retry with the same key yields one order, not two.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Console snippet — scan a rendered page for a .well-known UCP profile

Quick DevTools Console check of whether a merchant exposes UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp. discovery (paste in the browser console on the merchant’s origin):

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet — jump to the checkout status enum in the ACP docs

Drop this in a bookmark to open the ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. Checkout reference at the status list:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Common agentic checkout failures

A retry creates two orders or charges

Symptom: the same checkout session produces duplicate orders after a timeout or network retry. Likely cause: create or complete calls are not keyed and replay-safe. Fix: require an idempotency key, return the original result for a same-key retry, and confirm two identical sandbox calls produce one session and one order.

Checkout never becomes ready for payment

Symptom: a session remains not_ready_for_payment or incomplete. Likely cause: a required fulfillment choice, address field, or business rule is unresolved. Fix: inspect the session’s required fields and messages[], supply the missing choice, and confirm the state advances to ready_for_payment or ready_for_complete.

A valid request appears to succeed but the cart cannot complete

Symptom: the HTTP request succeeds while the session contains an out-of-stock or other business error. Likely cause: the client only handles HTTP errors and ignores MessageError entries. Fix: process both transport errors and session messages, then confirm the user or agent sees the actionable failure.

Human verification silently dead-ends

Symptom: checkout enters requires_escalation or authentication_required and never returns. Likely cause: the 3DS, login, approval, or continue_url handoff was treated as an exceptional error instead of a supported state. Fix: persist the session through the handoff, handle every authentication outcome, and confirm both successful and abandoned flows resolve cleanly.

Order status stops updating after payment

Symptom: the merchant has the order but the agent surface remains pending or stale. Likely cause: a webhook signature fails, only a delta was sent, or 429 responses were dropped. Fix: sign the exact payload, send the full Order object, retry rate-limited events with backoff, and confirm the receiver accepts the event.

Mental models for agentic checkout

Checkout is a state machine, not a single API call

Every response should move the session to a known state or expose a known reason it cannot move. Design clients around transitions, terminal states, retries, and escalations rather than around a single “buy” request.

Authority stays with the merchant

The agent expresses intent, but the merchant remains authoritative for price, inventory, tax, fulfillment, order state, and merchant-of-record obligations. Treat the agent’s requested cart as input and the merchant-returned cart as truth.

Delegation narrows permission

A scoped payment tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. is safe because it is merchant-locked, session-bound, amount-capped, time-limited, and single-use. Evaluate every delegated capability by asking what it can do, for whom, for how much, and for how long.

Escalation is a successful branch

Human intervention is not a failed autonomous checkout. A clean 3DS, login, address, or B2B approval handoff is the protocol working as designed.

Delivery is asynchronous after completion

Payment completion does not end the integration. Signed, full-object webhooks carry order truth after checkout, so signature verification, replay safety, and retry handling are part of checkout reliability.

Metrics for agentic checkout

Checkout completion by terminal state

• Metric: sessions completed, canceled, or expired as a share of initiated sessions.
• What it tells you: where the checkout state machine ends and how much intent is lost before an order exists.
• How to pull it: aggregate checkout-session state changes from the commerce API or order platform, segmented by protocol and merchant surface.
• Benchmark / realistic range: establish a baseline for your own product mix and compare like-for-like flows; no universal rate is defensible at this adoption stage.
• Cadence: daily monitoring with weekly trend review.

Escalation recovery rate

• Metric: escalated sessions that return and complete after 3DS, login, address, or approval intervention.
• What it tells you: whether the human handoff is a usable path or a dead end.
• How to pull it: join escalation events to later state transitions using the checkout session ID.
• Benchmark / realistic range: baseline each intervention type separately because authentication and B2B approval have different friction.
• Cadence: weekly and after any handoff-flow change.

Duplicate-order and webhook failure rate

• Metric: duplicate orders from same-key retries plus rejected or exhausted webhook deliveries.
• What it tells you: whether idempotency and asynchronous order synchronization are safe under failure.
• How to pull it: compare idempotency keys, order IDs, signature failures, 401s, 429s, retries, and dead-letter events in application logs.
• Benchmark / realistic range: duplicate orders should be zero; establish a normal transient-retry baseline and investigate sustained deviation.
• Cadence: alert immediately, summarize weekly.

Resources worth your time

My related writing

• The two protocols agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. sits inside are covered in depth on this site — see the Agentic Commerce Protocol (ACP)The Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. and Universal Commerce Protocol (UCP)The Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp. write-ups; this page is the checkout-mechanics deep dive that sits under both.
• The Beginner’s Guide to Ecommerce SEO — where agent-facing checkout fits into the bigger ecommerce picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of discovery, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking; useful background for how an agent-mediated transaction layer sits on top of it. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Agentic Commerce Protocol — Checkout reference (OpenAI/Stripe) — the authoritative status enum, session fields, and intervention/authentication objects.
• OpenAI Delegated Payment spec — the scoped-tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. flow and the merchant-of-record / PCI-scope language.
• ACP Order webhooks reference (OpenAI/Stripe) — the push-based, HMAC-signed, full-object order-sync mechanics.
• Agentic Commerce Chargebacks: Who’s Liable When AI Buys? (Chargeflow) — the honest “no clean answers yet” take on the evidentiary problem.
• Agentic Commerce: Threats and Risks (Visa) — the Trusted Agent Protocol and agent-identity framing.
• OpenAI’s big ChatGPT Instant Checkout plan just changed (Search Engine Land) — the March 2026 pivot and the adoption-reality quotes.
• What Is Agentic Checkout? (Rye) — a clear independent definition and the merchant-of-record corroboration.
• Deep Dive: Mastercard Verifiable Intent vs Visa Trusted Agent Protocol (Fintech Wrap Up / Finextra) — the payment-network frameworks compared (treat the specific liability allocation as reported, not confirmed).

Stats worth citing

Numbers that frame where agentic checkoutAgentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site. actually is — treat merchant-reported and relayed figures as directional, and verify before leaning on them.

• About a dozen Shopify merchants were actively using AI checkout tools — described as negligible against Shopify’s overall merchant base — per Shopify’s president, relayed through Search Engine Land’s coverage of the March 2026 pivot. Coverage
• March 2026: the pivot. OpenAI moved ChatGPT’s Instant Checkout from full in-chat purchase completion to discovery-plus-redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., after onboarding, accuracy, and multi-item-cart friction. Coverage
• TokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. scope = 4 bounds. A delegated payment token is capped on max_amount, expires_at, merchant_id/checkout_session_id, and reason: one_time — the concrete mechanism that keeps a raw card away from the agent. Source
• Webhook rule: full object, always. ACPThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. requires the webhook data field to carry the full Order object rather than incremental deltas, and every request to be HMAC-signed. Source

Test yourself: Agentic Checkout

Five quick questions on the checkout mechanics. Pick an answer for each, then check.

Agentic Checkout

Agentic checkout is the transaction-completion step of agentic commerce: the mechanism by which an AI agent creates, updates, and finalizes a purchase on a shopper's behalf — selecting fulfillment, calculating tax and shipping, passing a scoped payment token, and triggering order creation — often without the shopper visiting the merchant's site.

Related: Agentic Commerce Protocol (ACP), Universal Commerce Protocol (UCP)

Agentic Checkout

Agentic checkout is the specific transaction-completion capability inside agentic commerceThe Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. — the part where an AI agent (not a human clicking through a cart page) creates a checkout session, updates it with fulfillment and buyer details, calculates tax and shipping, passes a scoped payment credential, and triggers order creation. It’s one building block of the larger protocols: it’s the Agentic Checkout block of OpenAI and Stripe’s Agentic Commerce Protocol (ACP)The Agentic Commerce Protocol (ACP) is an open standard/protocol whose first implementing AI platform is OpenAI and first compatible payment provider is Stripe, defining how AI shopping agents discover products, manage carts, and complete purchases on a buyer's behalf — by reading a merchant's product feed and APIs instead of crawling the website. and the checkout capability of Google and Shopify’s Universal Commerce Protocol (UCP)The Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp..

Under the hood it’s a state machine. In ACP a checkout session moves through statuses like not_ready_for_payment, ready_for_payment, requires_escalation / authentication_required, completed, and canceled; UCPThe Universal Commerce Protocol (UCP) is an open-source standard (Apache 2.0) led by Google and co-developed with Shopify, Etsy, Wayfair, Target, and Walmart that lets AI agents, merchants, and payment providers transact through a common language instead of bespoke integrations. Merchants advertise their capabilities at /.well-known/ucp. runs a parallel incomplete → requires_escalation → ready_for_complete machine. The requires_escalation / authentication_required states are the built-in seam where a human still has to step in — for login, 3-D Secure step-up, an address check, or B2B approval — so “fully autonomous, zero-human checkout” isn’t how either spec is actually built.

Two things worth keeping straight: the agent never touches a raw card number (payment runs through delegated, scoped tokensA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. — merchant-locked, amount-capped, time-limited, single-use), and the merchant stays merchant-of-record, so settlement, refunds, and chargebacks remain with the merchant and its PSP. Whether the purchase closes fully in-chat or redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. to the merchant’s own site is an implementation detail that has already changed once — ACP’s flagship implementation pivoted from in-chat completion to discovery-plus-redirect in March 2026.

Related: Agentic Commerce Protocol (ACP), Universal Commerce Protocol (UCP)