What is agentic checkout?
Agentic checkout is the moment an autonomous AI agent finishes a purchase for someone. The agent assembles the order, applies shipping and tax, submits payment and returns a confirmation, all without the buyer clicking through a merchant's checkout flow. The distinction worth holding on to is that agentic checkout is the settlement step, not the whole shopping journey. The broader pattern of an agent searching, comparing and deciding is agentic commerce; agentic checkout is the narrow, technically demanding part at the end where money actually changes hands. It matters because the old model assumed a human was present at exactly that moment. Card networks, fraud systems, merchant terms and internal expense policy were all written around a person reading a total and pressing a button. Remove the person and a surprising number of quiet assumptions stop holding.
How does agentic checkout work?
Most agentic purchases run through four stages. Discovery: the agent searches across merchants, usually against structured product feeds rather than by reading web pages. Evaluation: it compares candidates on price, availability, delivery and whatever constraints the buyer stated. Checkout: it creates a checkout session with the chosen merchant, and the merchant returns the real total including shipping and tax. Payment and confirmation: a payment credential is passed, typically as a network token rather than a raw card number, the merchant captures payment and returns an order confirmation the agent relays back. The important structural point is that the merchant is doing the merchant things throughout. The agent is not scraping a storefront or filling in a form; it is calling documented endpoints, which is why the protocols below exist at all.
What are the agentic checkout protocols?
Two open standards dominate, and they solve overlapping problems from different directions. The Agentic Commerce Protocol (ACP) was co-developed by OpenAI and Stripe and released under Apache 2.0 on September 29, 2025, with the two companies as founding maintainers and date-based versioning. It debuted alongside ChatGPT Instant Checkout, which went live with Etsy and then added Shopify brands. ACP is checkout-first: it defines how an agent creates and completes a checkout session against a merchant. Google's Universal Commerce Protocol (UCP) was announced by Sundar Pichai at the NRF keynote on January 11, 2026, is also Apache-2.0, and is capability-first: a merchant publishes a profile at /.well-known/ucp describing what it supports, whether that is checkout, product search or returns, and agents identify themselves with a UCP-Agent header. We cover each in depth in the Agentic Commerce Protocol explainer and the Universal Commerce Protocol explainer. The table below is the practical comparison.
Do merchants have to choose between ACP and UCP?
No, and most serious commerce teams are planning to support both. They are not competing payment rails; they are competing interface conventions in front of the same store and the same processor. Supporting both is closer to supporting two API clients than to signing with two acquirers. The reason it feels like a choice is distribution: ACP is where ChatGPT traffic arrives and UCP is where Google's surfaces arrive, so the sequencing question is really about which assistant your customers already use. What you should not do is treat either as a reason to rebuild your checkout. Both designs deliberately leave the merchant as the seller of record, capturing payment through the processor already in place. If a vendor tells you agentic checkout requires replacing your payment stack, that is a product pitch rather than a protocol requirement.
How do merchants accept agentic checkout?
The work is less about payments than about making a store legible to software. In rough order of effort: publish a clean, current product feed, because an agent that cannot see accurate price, availability and variants will not select you, and a stale feed produces failed orders rather than lost impressions. Expose checkout as an API, so a session can be created, priced with real shipping and tax, and completed without a browser. Remove the human-only gates on that path: CAPTCHAs, interstitials and bot rules that assume a browser will decline legitimate agent orders. Accept tokenized agent payment credentials through your existing processor. Decide your policy on returns and disputes before volume arrives, because agent orders concentrate in exactly the categories where sizing and fit go wrong. The honest sequencing advice is to fix the feed first. Merchants who skip that step and rush the checkout integration end up with an endpoint that works perfectly and never gets called. If you sell on Shopify, most of this is already done for you and the remaining work is data quality, which we walk through in the Shopify agentic commerce guide. If you are on Adyen, its Agentic Feed, Cart and Payments layers do the same job for enterprise merchants, and we cost the whole stack out in Adyen agentic commerce pricing.
Who is the seller of record in an agentic checkout?
The merchant, in both ACP and UCP as designed. The assistant is an interface, not a reseller. The merchant sets the price, captures the payment, fulfills the order and owns the customer relationship afterwards, including returns and support. This is deliberate, because the alternative would drag assistants into merchant of record obligations across every tax jurisdiction their users live in. It has a practical consequence worth planning for: the customer service conversation about an agent-placed order still lands with you, and the buyer may have never seen your site. Order confirmations, return instructions and support contact details need to make sense to somebody encountering your brand for the first time in a shipping notification.
How does payment actually work in agentic checkout?
Payment credentials are passed as tokens scoped to the transaction rather than as raw card numbers held by an assistant. The card networks have built for this directly: Visa Intelligent Commerce, announced in April 2025 and expanded in June 2026 with Intelligent Commerce Connect, issues merchant-specific scoped tokens, and Mastercard Agent Pay uses Agentic Tokens extending MDES, with Citi and US Bank among the first issuers. The design goal is that a compromised or misbehaving agent holds a credential that is useless outside the transaction it was scoped to. Stablecoin settlement is the other live path, more common when the buyer is a machine paying for a machine service than when the buyer is a consumer buying a sweater. We compare the two in stablecoins versus virtual cards for agents. Either way the merchant's processor sees a payment it can capture, which is why merchants generally do not need a new acquirer to participate.
What agentic checkout removes on the buyer side
Here is the part most coverage skips, and it is the part that costs money. The checkout page was never only a payment interface. For most companies it was, informally, the last budget control: a human saw a total, noticed it was higher than expected, and stopped. Agentic checkout is specifically designed to remove that screen. When your procurement agent, travel agent or ad-buying agent completes a purchase, nobody reads the total. That is the entire point, and it is also the entire problem. The protocols do not solve it, because they are merchant-side standards. ACP and UCP describe how an order gets placed, not whether your company wanted to spend that money. Neither carries a buyer budget, and the scoped payment tokens above cap a single transaction rather than a cumulative total. An agent can therefore place forty individually reasonable orders that add up to something nobody would have approved. The control has to move to the payer, before the agent ever reaches a merchant.
Putting spend controls back where the checkout page used to be
If a human is no longer reading the total, the decision has to be made by policy in advance, and it has to be enforced at the instrument rather than in the prompt. In practice that means four things. A funded wallet with a hard cap, so the maximum loss from any failure mode is a number you chose. A merchant and category allowlist, so an agent that finds a cheaper unapproved supplier simply fails the authorization. An approval threshold, above which the transaction pauses and a named person gets a one-tap approve or deny, which restores the human check exactly where it is worth its latency and nowhere else. And an audit trail tying each authorization to the agent, the human owner, the task and the policy verdict, because the reconciliation problem is worse when there is no browser session and no expense report to reconstruct from. That is what AgentsPay does across card rails and stablecoins from one control plane, and you can see the same surfaces on agent spend controls and human approvals. The console at the top of this page runs the same policy engine.
Chargebacks, returns and who is liable
Liability sits with the human or company that owns the agent, because no jurisdiction treats an agent as a legal person capable of holding an obligation. Authority flows from whoever funded the instrument and set the policy. For merchants the practical exposure is disputes: an agent-placed order is easier for a consumer to disown than one they clicked through themselves, and "my assistant bought the wrong thing" is a conversation your support team will have. The mitigations are unglamorous and effective. Keep the confirmation the agent received, including the exact price and terms presented at session creation. Make returns easy enough that a dispute is the worse option for the buyer. On the buying side, prefer card rails over stablecoins for anything you might want to reverse, since card payments can be disputed and on-chain settlement generally cannot. We go deeper in who is liable when an AI agent buys the wrong thing.