# Agentic checkout, explained for ecommerce teams **Published:** September 18, 2026 | **Updated:** September 21, 2026 | **Authors:** Gladly Team | **Categories:** Trends and expert opinions > Agentic checkout lets AI agents finish a purchase on their own. See how ACP, UCP, and AP2 handle payment, fraud, and trust. Explore the guide. --- Shoppers used to click through a cart, a shipping form, and a payment page one at a time. Now some of them are asking an AI agent to just handle it: compare two jackets, pick the one that fits the return policy they care about, and complete the purchase without touching the checkout page at all. That handoff, from a person clicking buttons to an agent completing the transaction on their behalf, is what "agentic checkout" refers to. And it's arriving faster than most ecommerce teams have had time to plan for. [Our last post](/blog/making-sense-of-agentic-commerce/) walked through four protocols at a high level: MCP, the Model Context Protocol; ACP, the Agentic Commerce Protocol; UCP, the Universal Commerce Protocol; and A2A, the Agent2Agent protocol. It touched on checkout as one of four places agentic commerce shows up in the funnel. This one stays on that single stage: what happens the moment an agent finishes the purchase, where the money and the trust questions get hard, and what to watch before you decide how much of your checkout flow to open up to it. ## What agentic checkout means in practice Agentic checkout is the part of [agentic commerce](/glossary/agentic-commerce/) where an AI agent, acting with a shopper's authorization, completes a transaction: selecting the final item and variant, applying or declining a promotion, entering payment and shipping details, and confirming the order. No human clicks through each step. That's narrower than [agentic commerce](/glossary/agentic-commerce/) as a whole. Discovery, comparison, and product Q&A can all happen conversationally without an agent ever touching a payment method. Checkout is the specific moment where an agent moves from recommending to spending, and a wrong guess there costs real money. Three things have to work together for that moment to hold up: - The agent needs a live, accurate view of price, inventory, and shipping cost. - The agent needs a way to pass payment and order details to the merchant without exposing raw card data. - The agent needs clear limits on what it's authorized to spend, with a rule for checking back with the shopper whenever a decision falls outside those limits. ## How it differs from guided checkout, one-click checkout, and saved payment flows A guided or [conversational checkout](/blog/ai-driven-conversational-commerce/) still puts a person in the loop for every decision. A [chatbot](/glossary/chatbot/) might collect a shipping address and confirm a size, but the shopper is still the one clicking "place order." One-click checkout and saved payment methods go further by removing repeated data entry. Even so, the shopper is still the one who initiates each purchase and reviews the final cart before it happens. Agentic checkout removes that final click. The agent decides, within limits the shopper already set, that this is the right item at the right price, and it submits the order. The distinction matters for two reasons. First, liability and dispute handling change: a "wrong item" complaint after a one-click purchase is a fulfillment issue, but the same complaint after an agent-initiated purchase raises a harder question about whether the agent misread the shopper's intent. That question doesn't have a single owner yet. The shopper who set the spending limit, the agent platform that executed the purchase, and the merchant who fulfilled it can each point somewhere else, and most merchant agreements haven't caught up to say who's right. Second, the technical requirements are heavier. Saved payment methods only need a stored card token. Agentic checkout adds a second layer on top of that: the merchant has to verify that this specific purchase, on this specific occasion, was authorized. ## What an agentic system can actually do at the point of purchase At the checkout stage specifically, an agent that's properly connected to a merchant's systems can typically read live price and availability, apply a promo code or flag one that doesn't qualify, select shipping and confirm delivery windows against the shopper's stated priorities such as fastest versus cheapest, and hand off cleanly to a person the moment something falls outside its authorization, a payment fails, or an item goes out of stock mid-transaction. What it shouldn't be doing, in any implementation worth trusting, is inventing a total, guessing at tax and shipping, or completing a purchase the shopper never authorized in scope or amount. Every credible protocol in this space builds in a way for the shopper to set a spending ceiling and for the merchant to confirm the request matches it before money moves. ## Protocols, APIs, and identity None of this works through custom, one-off integrations between every agent and every merchant. A handful of protocols have emerged to standardize it instead. [Making sense of agentic commerce protocols](/blog/making-sense-of-agentic-commerce/) covers all four in more depth if you want the broader picture; at the checkout stage specifically, three things matter most. If you're a small or mid-sized ecommerce team, this doesn't mean hiring engineers to implement a payments protocol from scratch. UCP support is rolling out through Shopify directly, and ACP support runs through Stripe, Wix, WooCommerce, and BigCommerce among others. For most SMB brands, the real work is knowing which of your existing platforms are shipping this and turning it on. ### Payment delegation Payment delegation needs a way to hand an agent spending authority without handing it a card number. ACP, from OpenAI and Stripe, uses Stripe's Shared Payment Token, so the agent carries a token, never the raw card data, and the merchant stays merchant of record for fulfillment and chargebacks. UCP, from Google and Shopify, takes a similar approach across a wider set of payment processors, and as of March 2026 it supports full multi-item carts. A related approach, used by some card networks and payment processors outside these two protocols, issues the agent a single-use or merchant-locked virtual card. The agent still never holds a number a fraudster could reuse. ### Authorization Authorization has to be provable: a record the agent can produce on request, generated at the moment consent was given. Google's Agent Payments Protocol, AP2, addresses this with cryptographically signed "mandates": a Checkout Mandate that references the items and purchase details, and a Payment Mandate that authorizes a specific amount to a specific processor. Each can be "open," setting constraints the shopper agreed to in advance, or "closed," tied to one finalized transaction. Chained together, they create an audit trail that answers the question a merchant's fraud team will always ask: did the actual account holder authorize this, or is an agent improvising? ### Identity Identity is the piece most existing fraud systems weren't built for. A lot of automated-purchasing detection exists specifically to block exactly this kind of traffic. Merchants adopting agentic checkout need a way to tell a legitimate, authorized agent request apart from that traffic and let it through. That's a policy decision as much as a technical one, and it's usually the slowest part of standing this up. ## Where trust, fraud, and payment verification come into play [The trust layer](/blog/trust-layer-ai-agents-commerce/) goes deeper on why trust in agentic commerce comes from architecture, more than from any vendor's claims. At checkout, that question gets concrete fast. It's the one point where an agent's mistake costs real money. The tokenized approach that ACP and UCP both use limits the blast radius of a compromised agent. It never holds a raw card number, so a leak doesn't expose payment credentials the way a database breach would. AP2's mandate structure limits it further by tying every transaction to a specific, provable authorization. Neither eliminates the harder questions merchants are still working through: who absorbs a chargeback for a wrong-variant purchase the agent made on its own, and how a merchant's existing fraud model learns to tell a legitimate agent purchase from a scripted attack using the same protocol. Those questions don't have settled answers across the industry yet. What's already clear is that a merchant enabling agentic checkout is trusting three things at once: the protocol's verification, the payment processor's fraud tooling, and its own policy for what an agent is allowed to do unsupervised. Configure all three deliberately, since none of them arrive with sensible defaults already built in. ## Implications for cart abandonment and checkout completion Checkout abandonment is already a large, well-documented problem. Baymard Institute's aggregation of 50 studies puts the average documented cart abandonment rate at just over 70%. The reasons are specific: about 40% of shoppers cite extra costs such as shipping, tax, or fees revealed too late, 19% cite security concerns about sharing card details, 18% cite being forced to create an account, and 17% cite a checkout process that felt too long or complicated. Agentic checkout has a real shot at several of those. An agent that already knows the total cost before initiating checkout removes the late-surprise problem. Tokenized payment removes the friction of manually re-entering card details, and for the security-conscious segment, it removes the moment of typing a card number into a form altogether. A checkout that completes inside a conversation the shopper already trusts skips the account-creation wall. It also creates a metrics problem worth planning for now. A purchase completed entirely through an agent may never fire the pixels your retargeting and cart-abandonment email flows depend on, and it may not show up in your session-based conversion rate the way a normal visit does. The purchase still happened. Your existing funnel reporting just wasn't built to see it. Segment agent-initiated orders as their own line, separate from blended session-to-purchase conversion, before agent traffic is large enough to quietly distort your numbers. ## Brand and merchandising control in an agent-mediated checkout An agent completing checkout on your behalf is still representing your brand at the exact moment money changes hands. That raises questions a lot of merchants haven't had to answer before. Does the agent apply a promo code correctly, or decline one that doesn't qualify, the way your own site does? Does it offer the same upsell or bundle logic your merchandising team built for the human checkout flow, or does it just process whatever's in the cart? If an item goes out of stock mid-transaction, does the substitution it offers match your policy? None of the current protocols solve this for you. ACP, UCP, and AP2 handle the plumbing: the payment token, the mandate, the API call. What promotions apply, what substitutions are acceptable, and how the agent should describe your product when it's the one closing the sale are policy decisions your team still owns. The merchants furthest ahead on this are treating it the way they'd treat training a new hire on the checkout desk. They write the rules down explicitly, in detail, before any agent ever touches a live order. ## Evaluating readiness as standards mature Neither ACP nor UCP has won. Both have live implementations and major retail partners behind them, and the realistic near-term picture is that most merchants end up supporting both. That picture is still shifting month to month, so treat any specific coverage numbers or dates in a protocol comparison, including this one, as a snapshot. [An AI agent readiness checklist for ecommerce teams](/blog/ai-agent-readiness-checklist-ecommerce/) walks through the fuller set of data, policy, and monitoring questions worth working through before you turn any of this on. At the checkout stage specifically, the shortlist is shorter: is your [product and pricing data](/blog/product-feed-ai-agents/) accurate enough for an agent to quote a total without guessing, does your payment processor already support ACP or UCP through your existing platform, and does your team have an actual answer for who handles a dispute when an agent's purchase goes wrong. Answer those three, and you have a working sense of where you stand. --- *This content is provided by Gladly. Visit [gladly.com](https://gladly.com) for more information.*