Agentic Checkout Is Broken: Why Most AI Agents Can't Complete a Purchase (and How to Fix It)

By 2030, McKinsey QuantumBlack projects agentic commerce will orchestrate $900 billion to $1 trillion in US B2C retail revenue and $3 trillion to $5 trillion globally (October 2025 report). The infrastructure needed to actually capture that flow is mostly not built yet.

Specifically: AI agents have gotten good at product discovery and recommendation. They have not gotten good at completing the purchase. Analysis by Alhena AI of three leading shopping agents (OpenAI's Operator, Google's Project Mariner, and Perplexity's in-chat checkout) found the same pattern across all of them. The agent wins the recommendation, then chokes at checkout.

The breaking points are well-documented:

• Forced account creation with unpredictable password requirements
• Email verification loops the agent can't navigate
• 2FA via SMS or bank app, where the agent has to hand control back to the human
• Form fields with non-standard names that break agent-side form-filling
• 3D Secure and strong customer authentication, which require human-in-the-loop authentication
• CAPTCHAs, which are explicitly designed to keep agents out

For a brand running a transaction-heavy business in 2026, this is structurally bad. Adobe Analytics' Q1 2026 report on US retail sites found AI-driven traffic up 393% year-over-year, and in March 2026 that AI traffic converted 42% better than non-AI traffic when the checkout actually worked. But the checkout often doesn't work, and the brand never knows because the agent silently abandoned.

This piece is about why agentic checkout fails in 2026 and what the structural fix looks like.

Why human-optimized checkout fails for agents

Three specific patterns.

Pattern 1: Forced account creation

Baymard Institute's cart-abandonment research shows that 19% of US shoppers abandon when forced to create an account, and another 18% abandon because the checkout is too long or complicated. The flow:

• Agent reaches checkout
• Site requires email + password to continue
• Agent has to generate a password meeting unpredictable requirements (some sites require uppercase + symbol + 12 chars, some require exactly 8-16 chars, some block password managers)
• Site sends a verification email
• Agent has to access the email, find the verification link, click it
• Agent returns to the original site, has to log in fresh
• Now the agent can complete checkout

Steps 4-6 are where most agents break. Reading email is increasingly within agent capabilities, but doing it reliably while maintaining session state on the original site is fragile. Operator and Project Mariner both hand control back to the human at the email-verification step.

The fix at the site level is guest checkout. Sites with frictionless guest checkout convert agentic traffic at meaningfully higher rates than sites with forced registration. This also reduces human cart abandonment as a side benefit.

Pattern 2: 2FA at payment

Strong customer authentication is mandated for online card payments above certain thresholds in the EU under PSD2. PSD3 and the new Payment Services Regulation (PSR) were provisionally adopted in 2026 and are expected to apply from 2027-2028. The UK and parts of Asia have similar SCA regimes. The implementation usually involves SMS verification, an authenticator app, or a bank-app push notification.

Agents fundamentally cannot complete this step. SMS goes to a phone the agent isn't on. Authenticator apps are on devices the agent doesn't control. Bank apps require human approval through the bank's flow.

The result: every transaction above the SCA threshold has to hand control back to the human. For impulse purchases or low-friction shopping, this defeats the agentic advantage.

The fix is delegated authentication via cryptographically-signed mandates, an approach Stripe, Mastercard, and Visa all launched variants of in 2025-2026. The user pre-authorizes the agent for purchases under a certain threshold. The agent's payments are tokenized to the agent identity. The SCA flow only triggers for purchases above the threshold or for unfamiliar transaction patterns.

Pattern 3: Form field unpredictability

Agentic form-filling depends on field naming conventions. The standard is name="email", id="email", autocomplete="email". The majority of sites follow these conventions. A meaningful minority use custom names, hidden fields, or JavaScript-driven inputs that break naive form-filling.

Even when the fields are conventional, the layout can break agents. Some sites use multi-step checkout where each step is a JS-rendered modal. The agent has to detect when one modal finishes and the next is ready, which is error-prone.

The fix is structured product feeds and checkout APIs that bypass the form layer entirely. ChatGPT's Instant Checkout (built on the Agentic Commerce Protocol, co-developed with Stripe) and Google's Universal Commerce Protocol both work this way. The agent calls a structured /checkout endpoint with a JSON body, the merchant returns a payment session, and the agent completes payment via tokenized credentials. No forms involved.

The structural fix: agent-tier APIs

The pattern that's emerging in 2026 is a separate purchase API for agents, distinct from the human checkout flow.

The shape:

• Merchant exposes a POST /api/agent/purchase endpoint (or equivalent via ACP, UCP, or proprietary).
• The agent calls the endpoint with the desired product, shipping address, and a tokenized payment credential issued by the user's payment provider.
• The merchant validates the payment token, charges via Stripe (or equivalent), and returns a confirmation.
• The user receives a real-time notification that the agent purchased on their behalf.

For purchases under a pre-authorized threshold, this completes without further user interaction. For purchases above the threshold, the merchant returns a "confirmation required" response, the user gets a push notification, and the purchase completes after the user approves.

This is the same shape that Stripe's Agentic Commerce Suite, Mastercard's Agent Pay (with Agentic Tokens), Visa's Intelligent Commerce, ChatGPT's Instant Checkout, and Google's Universal Commerce Protocol all implement. The pattern removes the human-optimized checkout from the agent's path entirely. Instead of fighting through forced account creation, 2FA, and form fields, the agent calls a clean API designed for agent-to-merchant transactions.

Why merchants haven't adopted this faster

Three reasons.

Reason 1: Replatforming is expensive

Most enterprise commerce stacks were designed for browser-driven sessions. Adding an agent-tier API means either retrofitting the existing stack or building a parallel one. The retrofit is technically doable but politically hard. It requires alignment across infrastructure, payments, fraud prevention, and customer experience teams.

The alternative is using an "Agentic Commerce Adapter" layer (Invisible Technologies' ACA, Stripe's adapter integrations) that exposes the existing backend in agent-compatible formats without rebuilding the stack. This is the path most enterprise retailers are taking in 2026.

Reason 2: Fraud detection wasn't built for agents

Agents generate transaction patterns that look unusual: speed, concurrency, sometimes geographic mismatch with the user. Fraud detection systems trained on human transaction patterns flag agent activity as suspicious and decline transactions.

The fix is retraining fraud models on agent-specific signals: velocity that's expected for agent traffic, time-of-day patterns that don't match human shopping rhythms, concurrent purchases across multiple sessions. This is happening but slowly.

Reason 3: Brand defensive instincts

Some merchants explicitly don't want agents disintermediating them from the customer relationship. The classic argument: "We invested heavily in checkout optimization, personalization, and loyalty programs. Agents bypass all of that and turn us into fungible suppliers."

This is a real concern, and it explains why some merchants resist agent-friendly checkout. The counter-argument is that being agent-unfriendly doesn't keep agents out. It just means agents recommend competitors who are easier to transact with. The resistance accelerates the disintermediation rather than preventing it.

What "agent-ready" actually means at the technical level

A merchant that's truly agent-ready exposes:

• Structured product data with Schema.org markup or equivalent feeds. Price, availability, shipping options, and return policy as machine-readable fields.

• A discovery API that lets agents query inventory and availability programmatically.

• A cart/checkout API that accepts JSON bodies with product, quantity, shipping, and payment-token fields.

• Tokenized payment support with agent-tied tokens from Mastercard Agentic Tokens, Visa Intelligent Commerce, or equivalent. The merchant validates the token's link to the agent and the user's pre-authorized parameters.

• Webhook notifications for purchase events, so the user's notification system can alert them in real-time.

• Refund and dispute APIs that support agent-initiated returns within scope.

Most large retailers have item 1 (structured data) and item 5 (webhooks). Most don't yet have items 2-4. The 2026 winners will be the ones that close the gap fastest.

A reference implementation pattern

The cleanest expression of this pattern, regardless of which protocol underneath, looks like:

• The agent calls a scoped purchase endpoint with the product and amount.
• The endpoint validates a purchase permission and a daily spend cap pre-authorized by the user.
• The user receives a notification with a one-click confirmation link.
• The user confirms.
• The payment processor charges and the purchase completes.

For purchases under the pre-authorized cap, this is fast. For purchases above, the user is in the loop. The agent never has unilateral spending authority.

The same shape applies whenever an agent needs to make a transaction inside a platform: separate auth tier, scoped permissions, two-step confirmation, hard spending cap. Mastercard Agentic Tokens encode this at the network layer. Stripe's Agentic Commerce Suite handles it at the processor layer. Application-layer protocols like ACP and UCP standardize it at the merchant-API layer.

What to do now if you're a merchant

Three steps in priority order:

• Enable guest checkout. Removes the biggest friction point for agents, and improves human conversion as a side benefit.

• Adopt structured product feeds. Schema.org Product markup, OpenGraph metadata, and a clean product detail page for every SKU. This makes you discoverable to agents in the first place.

• Evaluate Stripe's Agentic Commerce Suite, or an equivalent, for your payment stack. This is the lowest-friction path to agent-tier checkout for most merchants. Google's UCP and the Agentic Commerce Protocol (ACP) are open-protocol alternatives if you'd rather not tie the implementation to a single processor.

For brands selling primarily through marketplaces (Amazon, Walmart), the strategy is different. The marketplaces own the agent-checkout layer. For DTC brands, the agent-tier API is the new competitive primitive.

What to do now if you're a user

Two practical defenses while the ecosystem matures:

• Pre-authorize agent purchases at platforms that support scoped agent tokens with hard caps. Payment-network token issuers (Mastercard Agentic Tokens, Visa Intelligent Commerce), processor-tier suites (Stripe), and a small but growing set of platforms that have shipped scoped agent purchasing already.

• Don't grant unscoped purchasing authority to consumer agents (Operator, Project Mariner) for important purchases. The risk-reward isn't there yet for high-value transactions. For low-stakes purchases (subscriptions, plan upgrades, small consumables), it's fine.

The agentic-commerce stack is maturing fast. Within 18-24 months, properly-scoped agent purchasing will be standard. Until then, design around the gaps.

The recommendation half of agentic commerce is mostly solved. The purchase half is the next frontier.