Why agents stall at checkout

Three kinds of request come up in the documents below. A challenge asks the visitor to show it is a person. A sign-in requirement asks for a customer account. Card authentication asks the cardholder to confirm the payment, and the form the documents below name is 3-D Secure, a step in which the bank that issued the card checks that the cardholder approves the payment. We take the three in no particular order. A store may use one, several or none of them, so the figure shows each source's case on its own.

A CAPTCHA is a small test meant to tell a person from a program, such as choosing the right picture from a set. Cloudflare, a company whose service sits in front of a website and filters its traffic, uses a different kind of check. Its challenges documentation says: "Challenges are security mechanisms used by Cloudflare to verify whether a visitor to your site is a real human and not a bot or automated script." It adds that "Cloudflare does not use CAPTCHA puzzles or visual tests".

The page on challenge pages says what happens to the request: "The visitor cannot reach their destination without passing the challenge." Challenges "are triggered by a rule in the Web Application Firewall (WAF), Bot Management, or Rate limiting", three Cloudflare products that filter requests. A non-interactive challenge is decided "via an injected JavaScript", and "The visitor must wait until their browser finishes processing the JavaScript". With a managed challenge, "if Cloudflare detects non-human attributes from the visitor's browser, they may be required to interact with the challenge". And: "This mechanism fails when the browser expects a non-HTML response, such as an AJAX or XHR (fetch) request." In our reading, a program that does not run JavaScript cannot complete the non-interactive kind, and a request for data rather than a page, the fetch case Cloudflare names, gets a challenge it cannot complete.

Cloudflare's Bot Fight Mode "Issues computationally expensive challenges that force the requesting client to perform CPU-intensive calculations". The same page says "You cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules." As we read it, a store with it turned on cannot use those two kinds of rule to exempt a particular agent.

Shopify offers a different control. Its bot protection "is available only for merchants on a Shopify Plus plan" and "acts as a fairness control by blocking known bots from your checkout". The merchant schedules it as an event of at most 60 minutes, and "you must select a checkpoint challenge": "reCAPTCHA, powered by Google" or "hCaptcha".

Google's JavaScript SEO guide says "not all bots can run JavaScript". A checkout page that builds its form in the browser would, as we read it, have the same problem as any other page built that way, which How an AI agent reads a web page covers.

Two agent vendors write about challenges. Anthropic's crawler page says its bots respect anti-circumvention technologies: "we will not attempt to bypass CAPTCHAs for the sites we crawl." AWS's AgentCore Browser documentation says "AI agents frequently encounter anti-bot mechanisms when browsing websites, including CAPTCHA challenges, rate limiting, and request blocking", and that its browser "reduces CAPTCHA challenges through Web Bot Auth", a draft standard for signing an agent's requests. The same page says "Domain owners retain full control over their bot policies and may block, monitor, or rate-limit agent traffic regardless of cryptographic signatures".

A store can require an account before checkout, and both platforms below make it a setting.

Shopify's page Editing the checkout form options lets a store "require customers to sign in to their customer account before checking out." Two things follow from turning it on. "Customers can only use an email address to check out when signing in is required", and "accelerated checkout options such as Apple Pay aren't displayed in the online store cart". The page states defaults for several other options on new stores, the contact method among them, but none for this one.

BigCommerce's page Guest Customers and Checkout offers three choices: "Customers are not required to have an account to check out", the same but "automatically create one after ordering", and "Customers must have or create an account to check out". Where guests are allowed, a store can still "Prompt existing accounts to sign in, but still allow them to check out as guests" or "Require existing accounts to sign in". With guest checkout off, payment wallets such as PayPal and Apple Pay "are only available for signed in customers on product and cart pages". The page states no default.

In our reading, an agent filling in a checkout the way a person would has to sign in as the shopper when sign-in is required, for example with their password. OAuth is a way around that, and it is the one UCP uses. In plain words, OAuth lets one program get limited access to an account held somewhere else: the person signs in at the place that holds the account, and the program receives a token, a credential that carries only the access the person agreed to.

UCP's Identity Linking capability "enables a platform to obtain authorization to perform actions on behalf of a user on a business's … site." In UCP's terms the platform is the AI app or agent acting for the shopper, and the business is the store. The page defines three access levels. Public needs no authentication, for example "Browse a public catalog". Agent-authenticated uses "Platform credentials (client_id / client_secret)", for example "Guest checkout, create a cart". User-authenticated adds a user identity token, for "Saved addresses, full order history, personalized pricing". The page says "identity linking upgrades the experience, it does not gate it."

A store can still put operations behind a signed-in user. Its profile lists scopes under config.scopes, which the page calls "hard gates: scopes that require user authentication for the operations they cover". A scope, in our words, names one kind of access, such as reading order history. The page gives two example profiles, and the figure lets you switch between them.

"config": {
  "scopes": {
    "dev.ucp.shopping.order:read": {},
    "dev.ucp.shopping.order:manage": {}
  }
}

"config": {
  "scopes": {
    "dev.ucp.shopping.checkout:manage": {},
    "dev.ucp.shopping.order:read": {},
    "dev.ucp.shopping.order:manage": {}
  }
}

The page also defines a softer signal. A business "SHOULD include" the code identity_optional in a successful response "when authentication is available and would meaningfully unlock additional capabilities", with the example "Sign in for member pricing and personalized results."

The sign-in itself uses OAuth. Platforms "MUST implement the OAuth 2.0 Authorization Code flow (RFC 6749 §4.1) as the account linking mechanism" and "MUST use PKCE (RFC 7636) with code_challenge_method=S256". In the spec's diagram, the platform sends an authorization request, then "[user authenticates and grants consent at business]", the business sends back a code, and the platform makes a token request. In our reading, the password is typed at the store and never reaches the agent. PKCE, in our words, ties the one-time code to the program that asked for it, so someone who intercepts the code cannot redeem it.

Before it can send the shopper to sign in, the agent needs the address of the store's sign-in page and of the address that issues tokens. Two IETF standards publish these in a fixed place, under /.well-known/, a path on a domain where software knows to look without being told.

RFC 8414, "OAuth 2.0 Authorization Server Metadata" (Standards Track, June 2018), defines "a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server", served at /.well-known/oauth-authorization-server. The authorization server, in our words, is the part of the store's systems that signs people in and issues tokens. Its document must name an issuer, "a URL that uses the "https" scheme", and gives an authorization_endpoint and a token_endpoint. If the issuer in the document differs from the one the client asked about, "the data contained in the response MUST NOT be used."

RFC 9728, "OAuth 2.0 Protected Resource Metadata" (Standards Track, April 2025), does the same for "an OAuth 2.0 protected resource", served at /.well-known/oauth-protected-resource. The protected resource is the API a token opens, such as a store's order history. Its document can list, under authorization_servers, which servers can grant access to it. RFC 9728 also lets a refusal point the way: a 401 Unauthorized response can carry a WWW-Authenticate header with a resource_metadata parameter that gives this document's address.

UCP builds on both. Businesses "MUST publish authorization server metadata via RFC 8414" and "SHOULD publish protected resource metadata" via RFC 9728, which becomes a MUST when the authorization server is not on the business's own domain. They "MUST populate scopes_supported", so that a platform can "detect scope mismatches before initiating an authorization flow". When an operation gated by a scope arrives without a valid user token, the business "MUST return: HTTP 401 Unauthorized" with code identity_required.

{ "resource":   "https://resource.example.com", "authorization_servers":   ["https://as1.example.com",    "https://as2.example.net"], "bearer_methods_supported":   ["header", "body"], "scopes_supported":   ["profile", "email", "phone"], "resource_documentation":   "https://resource.example.com/resource_documentation.html"}

{  "issuer": "https://merchant.example.com",  "authorization_endpoint": "https://merchant.example.com/oauth2/authorize",  "token_endpoint": "https://merchant.example.com/oauth2/token",  "revocation_endpoint": "https://merchant.example.com/oauth2/revoke",  "jwks_uri": "https://merchant.example.com/oauth2/jwks",  "scopes_supported": [    "dev.ucp.shopping.order:read",    "dev.ucp.shopping.order:manage"  ],  "response_types_supported": ["code"],  "grant_types_supported": [    "authorization_code",    "refresh_token",    "urn:ietf:params:oauth:grant-type:jwt-bearer"  ],  "code_challenge_methods_supported": ["S256"],  "token_endpoint_auth_methods_supported": [    "private_key_jwt",    "tls_client_auth",    "client_secret_basic",    "none"  ],  "authorization_response_iss_parameter_supported": true,  "service_documentation": "https://merchant.example.com/docs/oauth2"}

ACP's README says the protocol "is currently in beta", and its latest released version is 2026-04-17. In the released checkout API, every request carries an Authorization header, a "Bearer token for API authentication" in the "API Key" format. In our reading, that key identifies the agent's platform to the merchant; the shopper's account does not come into it.

For the shopper, sign-in shows up in two values. The error code list includes requires_sign_in, and the buyer object has an authentication_status whose values are authenticated, guest and requires_signin. Neither value has a description of its own. We searched the README, that file, and the Agentic Checkout, Delegate Authentication and Payment Handlers RFCs for "oauth", "8414" and "9728" and found no match. ACP's discovery RFC, marked "Status: Proposal", lists under future extensions "Declaring supported authentication mechanisms (e.g., OAuth 2.0 identity linking) when those capabilities are added to ACP."

Card authentication gets more text. The Agentic Checkout RFC, "Status: Draft", "Version: 2026-01-16", says the "Server MUST set session.status to authentication_required when authentication (e.g., 3DS) is required". The client then "MUST attempt authentication … and MUST return the authentication_result in the POST /complete request body, regardless of the authentication outcome." The Delegate Authentication RFC, also "Status: Draft", "Version: 2026-01-28", is about the same step: "Delegate consumer authentication to merchant-specified providers for agent-driven checkout flows". It covers "3D Secure 2 (3DS2) authentication only" and the "Browser channel only". By that scope, it does not cover signing in to an account.

The released file also lets each side say what it can handle. In capabilities.interventions, the agent lists the interventions it supports and the seller lists the ones it requires, with an enforcement level. The figure runs the rule the draft RFC gives for that.

Both protocols plan for steps the agent cannot take. In UCP's checkout capability, the status requires_escalation means the checkout "requires information that cannot be provided via API, or buyer input is required", and "Businesses MUST provide continue_url" with it. That address "enables checkout handoff from platform to business UI, allowing the buyer to continue and finalize the checkout session." The same page says a checkout "has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported." It does not say whether or how the platform hears back once the buyer finishes. UCP explained walks through these statuses.

ACP's draft RFC gives each message a resolution. requires_buyer_input means "Buyer must provide information the API cannot collect programmatically", and requires_buyer_review means "Buyer must authorize before order placement". ACP explained covers the checkout session these belong to.

• If your store is behind Cloudflare, look at which WAF, Bot Management or Rate limiting rules issue a challenge, and whether any of them cover checkout pages or the addresses your checkout calls in the background. Check whether Bot Fight Mode is on, since WAF custom rules and Page Rules cannot skip it.
• On Shopify Plus, check whether a bot protection event is scheduled and which checkpoint challenge it uses.
• On Shopify, the sign-in requirement is described with the customer contact method options, which the page reaches through Settings > Checkout. On BigCommerce, the page puts guest checkout under Settings › Checkout, in the Customer accounts part of General settings. Neither page states a default, so the only way to know is to look.
• If your store publishes a UCP profile at /.well-known/ucp, see whether it lists dev.ucp.common.identity_linking and which scopes sit in config.scopes. In the spec's B2B example, a checkout scope there means every checkout operation needs a signed-in user.
• Open https://your-domain/.well-known/oauth-protected-resource. UCP takes the issuer from its authorization_servers, and that issuer's host serves /.well-known/oauth-authorization-server; with no protected-resource document, the issuer is your own domain. UCP requires the authorization-server document, with scopes_supported and code_challenge_methods_supported containing S256.
• If your platform supports ACP, ask which interventions it requires and with what enforcement, and whether it returns authentication_required when a card needs 3-D Secure.

• The ACP documents we searched define no OAuth account linking. Its sign-in values have no description, and the discovery RFC that lists identity linking as a future extension is a Proposal.
• ACP's 3-D Secure rules sit in Draft RFCs. Delegate Authentication covers 3DS2 in the browser channel only, and the checkout RFC's intervention_required rule is given for enforcement always only.
• UCP's checkout text does not say how the platform learns that a buyer finished at continue_url.
• Neither the Shopify page nor the BigCommerce page states a default for required sign-in.
• The vendor statements quoted here are Anthropic's, about its crawlers, and AWS's, about a preview feature of one browser product. The documents we checked do not say how other agents treat a challenge.

Checkout is the fourth wall in the hub. The fifth, paying on the shopper's behalf, is the subject of How an agent pays without seeing your card.