# Why agents stall at checkout

Challenges, required sign-in and card authentication: what the vendors’ documents say each does, how UCP and ACP handle sign-in, how ACP handles 3-D Secure, and what OAuth metadata tells an agent.

By Valerii Checha, 19 Oct 2026

The checkout pages described in the documents below are built for a person in a browser. On the way to a placed order they can ask that person to show they are not a program, to sign in to an account, or to confirm the card payment with their bank. An AI shopping agent may not be able to do some of these, and each is a point where a purchase can stop. This article goes through what the vendors' own documents say each mechanism does, how the commerce protocols UCP and ACP handle sign-in, how ACP handles card authentication, what OAuth metadata is, and what a store owner can look up in their own settings.

It belongs to a series. [The hub article](https://storewalk.ai/blog/why-agents-cant-buy) sets out five walls between an agent and a finished purchase; checkout is the fourth. Whether a store can tell who an agent is comes earlier and is the subject of [Bots, crawlers and agents](https://storewalk.ai/blog/bots-crawlers-agents). Paying once checkout is through is covered in [How an agent pays without seeing your card](https://storewalk.ai/blog/how-agents-pay).

Where we explain a term in plain words, the explanation is ours, not any specification's. Everything else comes from the documents linked in the text and listed under sources.

## Where a checkout can stop an agent

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.

Where an agent is stopped at checkout, case by case.

Cloudflare challenge:

1. Store → Agent: Challenge page. A WAF, Bot Management or Rate limiting rule can trigger a Cloudflare challenge, and the visitor cannot reach the page without passing it. The challenge fails when the client expects a non-HTML response, such as a fetch request. Source: [Cloudflare docs: challenge pages](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/).

Shopify sign-in:

1. Store → Agent: Sign in before checking out. Shopify lets a store require customers to sign in to their customer account before checking out. The page states no default for the setting. Source: [Shopify Help Center: checkout form options](https://help.shopify.com/en/manual/checkout-settings/checkout-form-options).

BigCommerce account:

1. Store → Agent: Account required to check out. One of BigCommerce’s three settings is “Customers must have or create an account to check out”. The page states no default. Source: [BigCommerce Help: guest customers and checkout](https://support.bigcommerce.com/articles/Public/Guest-Customers-and-Checkout).

UCP, no guest checkout:

1. Store → Agent: Profile: checkout needs a user. The UCP spec’s B2B wholesaler example has “No guest checkout — every transaction requires an authenticated user”: its profile lists dev.ucp.shopping.checkout:manage among the identity-linking scopes. Source: [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).

UCP identity linking:

1. Agent → Store: Scope-gated request (e.g. order history). When the agent calls an operation that a scope in the store’s identity-linking config gates, without a valid user identity token. The spec’s example is reading order history. Source: [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).
2. Store → Agent: 401 identity_required + resource_metadata. A UCP business must then return 401 with a WWW-Authenticate challenge and code identity_required; the spec’s example points to /.well-known/oauth-protected-resource. Source: [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).
3. Agent → Store: GET /.well-known/oauth-protected-resource. Step 1 of UCP discovery: the platform fetches the protected-resource metadata (RFC 9728) and uses the selected authorization_servers entry as the issuer. With none published, the issuer is the store’s own domain. Source: [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).
4. Agent → Authorization server: GET /.well-known/oauth-authorization-server. Step 2: RFC 8414 metadata at that issuer, which may be on another origin. On a 404 the platform tries /.well-known/openid-configuration; any other error must abort. Source: [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).
5. Authorization server → Agent: Authorization server metadata. RFC 8414 metadata names the issuer and the authorization_endpoint and token_endpoint. Step 3 of UCP discovery: the issuer must match the one from Step 1 byte for byte. Sources: [RFC 8414, OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).
6. Agent → Authorization server: Authorization request, PKCE S256. Next in the spec’s account-linking diagram: an Authorization Code request (RFC 6749 §4.1) with a PKCE S256 code challenge; the user then authenticates and consents at the business. Source: [UCP Identity Linking, v2026-08-25](https://ucp.dev/latest/specification/common/identity-linking/).

ACP sign-in error:

1. Store → Agent: message code requires_sign_in. In ACP 2026-04-17 sign-in appears as the error code requires_sign_in and as the buyer authentication_status value requires_signin, neither with a description. ACP defines no OAuth account linking yet; its discovery RFC, a proposal, lists it as a future extension. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml).

ACP 3-D Secure (draft):

1. Store → Agent: status: authentication_required. Per the draft Agentic Checkout RFC, the server must set this status when authentication such as 3DS is required. The draft Delegate Authentication RFC covers 3DS2 only, in the browser channel only. Sources: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md) and [ACP RFC: Delegate Authentication (Draft, 2026-01-28)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md).
2. Agent → Store: POST …/complete + authentication_result. Per the same draft, the client must attempt authentication and return authentication_result in the Complete request, whatever the outcome. Source: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md).

## Challenges and CAPTCHAs

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](https://developers.cloudflare.com/cloudflare-challenges/) 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](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/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](https://developers.cloudflare.com/bots/get-started/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](https://help.shopify.com/en/manual/checkout-settings/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](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) 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](https://storewalk.ai/blog/how-agents-read-a-page) covers.

Two agent vendors write about challenges. Anthropic's [crawler page](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler) says its bots respect anti-circumvention technologies: "we will not attempt to bypass CAPTCHAs for the sites we crawl." AWS's [AgentCore Browser documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-web-bot-auth.html) 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".

## Sign-in before checkout

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

Shopify's page [Editing the checkout form options](https://help.shopify.com/en/manual/checkout-settings/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](https://support.bigcommerce.com/articles/Public/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.

## How UCP handles sign-in

UCP's [Identity Linking](https://ucp.dev/latest/specification/common/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.

Which operations a UCP profile puts behind a signed-in user.

The two example business profiles on UCP’s Identity Linking page (version 2026-08-25); only their config.scopes differ.

B2C retailer: “Public catalog, guest checkout (no scope required), user-bound order operations gated”

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

- Browse the catalog: No user sign-in needed. Not listed in config.scopes: “Public/agent-authenticated access.”
- Create, update, complete or cancel a checkout: No user sign-in needed. Not listed: “anyone can start a guest session.”
- Read order history: Needs a signed-in user. dev.ucp.shopping.order:read is listed: “user auth required to obtain.”
- Manage orders: Needs a signed-in user. dev.ucp.shopping.order:manage is listed: “user auth required to obtain.”

B2B wholesaler: “No guest checkout — every transaction requires an authenticated user”

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

- Browse the catalog: No user sign-in needed. In our reading, open: no catalog scope is listed, and config.scopes are the “hard gates”. The page’s B2B text speaks only of checkout.
- Create, update, complete or cancel a checkout: Needs a signed-in user. dev.ucp.shopping.checkout:manage is listed: the merchant “requires the user to be authenticated for all checkout operations — create, update, complete, and cancel.”
- Read order history: Needs a signed-in user. dev.ucp.shopping.order:read is listed.
- Manage orders: Needs a signed-in user. dev.ucp.shopping.order:manage is listed.

When a gated operation arrives without a valid user identity token, UCP says the business MUST answer 401 with code identity_required. The challenge header SHOULD point to the store’s protected-resource document, and the body MAY carry a continue_url for steps such as creating an account. Source: [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).

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.

## OAuth metadata in plain words

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](https://www.rfc-editor.org/rfc/rfc8414), "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](https://www.rfc-editor.org/rfc/rfc9728), "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`.

The two OAuth metadata documents, field by field.

Protected resource, served at /.well-known/oauth-protected-resource. The example response in section 3.2 of RFC 9728, as printed there. It describes an example resource, not a shop.

```json
{
 "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"
}
```

Its fields:

- "resource". In our words: The address of the thing being protected, here an API. A client checks that it is the address it asked about; if not, it must ignore the document. Required. What the source says: RFC 9728: “REQUIRED. The protected resource’s resource identifier”, “a URL that uses the https scheme and has no fragment component.” “If these values are not identical, the data contained in the response MUST NOT be used.” Source: [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728).
- "authorization_servers". In our words: Which authorization servers can grant access to this resource. UCP’s discovery takes the issuer from this list, and that server may be on another domain. What the source says: RFC 9728: “OPTIONAL. JSON array containing a list of OAuth authorization server issuer identifiers, as defined in \[RFC8414], for authorization servers that can be used with this protected resource”. UCP: platforms “use the selected entry from authorization_servers as the AS issuer.” Sources: [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "bearer_methods_supported". In our words: Where in a request the client may put its access token: a header, the body or the query string. What the source says: RFC 9728: “OPTIONAL. JSON array containing a list of the supported methods of sending an OAuth 2.0 bearer token \[RFC6750] to the protected resource. Defined values are \["header", "body", "query"]”. Source: [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728).
- "scopes_supported". In our words: The scopes a client can ask for to use this resource. A scope names one kind of access, such as reading order history. What the source says: RFC 9728: “RECOMMENDED. JSON array containing a list of scope values … that are used in authorization requests to request access to this protected resource.” Source: [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728).
- "resource_documentation". In our words: A page for developers. Software does not need it to sign in. What the source says: RFC 9728: “OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the protected resource.” Source: [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728).

RFC 9728, OAuth 2.0 Protected Resource Metadata: Standards Track, April 2025. Its default address is /.well-known/oauth-protected-resource. UCP says a business SHOULD publish it. Sources: [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).

Authorization server, served at /.well-known/oauth-authorization-server. The example in the “Authorization Server Metadata” section of UCP’s Identity Linking page (version 2026-08-25), for an example merchant, keys and values as printed there.

```json
{
  "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"
}
```

Its fields:

- "issuer". In our words: The server’s own name, as an address. It must be the address the client asked, character for character, or the client must not use the document. What the source says: RFC 8414: “REQUIRED. The authorization server’s issuer identifier, which is a URL that uses the "https" scheme”; it “is used to prevent authorization server mix-up attacks”. UCP: “The issuer value in the discovered metadata MUST byte-for-byte match the AS issuer selected in Step 1”. Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "authorization_endpoint". In our words: The page where the shopper signs in at the store and agrees to what the agent asks for. The agent sends the shopper there. What the source says: RFC 8414: “REQUIRED unless no grant types are supported that use the authorization endpoint.” UCP’s account-linking diagram: “\[user authenticates and grants consent at business]”. Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "token_endpoint". In our words: Where the agent’s software trades the one-time code from the sign-in for an access token. What the source says: RFC 8414: “REQUIRED unless only the implicit grant type is supported.” UCP’s diagram ends with “(4) Token Request”. Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "jwks_uri". In our words: Where the server publishes the public keys a client uses to check the server’s signatures. What the source says: RFC 8414: “OPTIONAL. URL of the authorization server’s JWK Set \[JWK] document. The referenced document contains the signing key(s) the client uses to validate signatures from the authorization server”. Source: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414).
- "scopes_supported". In our words: Every scope this server will grant. RFC 8414 recommends the field; UCP requires it, so an agent can see before the sign-in whether what it wants is on offer. What the source says: RFC 8414: “RECOMMENDED.” UCP: businesses “MUST populate scopes_supported in RFC 8414 metadata to allow platforms to detect scope mismatches before initiating an authorization flow”; it “declares the accepted scope vocabulary”. Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "response_types_supported". In our words: What the sign-in step can hand back. "code" is the one-time code of the Authorization Code flow, the flow UCP requires. What the source says: RFC 8414: “REQUIRED. JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports.” UCP’s diagram sends response_type=code. Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "code_challenge_methods_supported". In our words: Which forms of PKCE the server accepts. PKCE ties the one-time code to the program that asked for it, so someone who intercepts the code cannot redeem it without a secret that program kept. Optional in RFC 8414; UCP requires it. What the source says: RFC 8414: “OPTIONAL. JSON array containing a list of Proof Key for Code Exchange (PKCE) \[RFC7636] code challenge methods supported by this authorization server”. UCP: “code_challenge_methods_supported: \["S256"] signals PKCE.” “Both MUST be present in UCP-compliant metadata.” Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "token_endpoint_auth_methods_supported". In our words: How the agent’s software proves who it is when it asks for a token. "none" is for software that cannot keep a secret, such as an agent running on a device; it then relies on PKCE alone. What the source says: UCP: businesses “MUST declare supported client authentication methods in token_endpoint_auth_methods_supported (RFC 8414)”. Public clients, including “on-device agent runtimes”, “MUST use none and rely on PKCE with S256”. Source: [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).
- "authorization_response_iss_parameter_supported". In our words: Says the server names itself, as iss, when it sends the shopper back with the code, so the agent can check which server answered. UCP requires it. What the source says: UCP: “authorization_response_iss_parameter_supported: true advertises RFC 9207 support.” Businesses “MUST return the iss parameter in the authorization response (RFC 9207)”. Source: [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).

RFC 8414, OAuth 2.0 Authorization Server Metadata: Standards Track, June 2018. Its default address is /.well-known/oauth-authorization-server. UCP says a business MUST publish it. Sources: [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414) and [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).

UCP reads the two in order. The issuer comes from the protected-resource document’s authorization_servers; if a store publishes none, the issuer is the store’s own domain. The platform then fetches the issuer’s RFC 8414 document, trying /.well-known/openid-configuration only after a 404, and the issuer inside must match byte for byte. Source: [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/).

## How ACP handles sign-in and 3-D Secure

ACP's [README](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) says the protocol "is currently in `beta`", and its latest released version is 2026-04-17. In the released [checkout API](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml), 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](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.discovery.md), 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](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md), "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](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md), 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.

ACP interventions: what the agent can handle, what the seller requires.

The agent can list: 3ds, biometric, address_verification. The seller can require: 3ds, biometric, with enforcement always, conditional, optional. The agent’s starting list is the example in the released file; the seller’s starting settings are ours.

- capabilities.interventions.supported. Agent request: “Interventions the agent can handle”.
- capabilities.interventions.required: “Intervention methods required for this session (seller only).”
- capabilities.interventions.enforcement: “When required interventions are enforced (seller only).” The three values have no description of their own.

What the documents say for each case:

- Nothing required. The seller requires no intervention, so the RFC’s intervention_required rule does not apply. Source: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md).
- Agent covers what is required. Every required type is one the agent says it can handle, so the RFC’s intervention_required rule does not apply. Source: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md).
- Seller should send intervention_required. The Draft RFC: “the merchant SHOULD include a message with code: "intervention_required"”, the code for “an intervention that the agent cannot handle”. Source: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md).
- No rule given. The Draft RFC gives its intervention_required rule only for enforcement always. For conditional and optional it states no rule. Source: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md).

A separate rule covers 3-D Secure once it starts. In the Draft Agentic Checkout RFC, the seller sets the session to authentication_required, and the agent MUST attempt authentication and return authentication_result with Complete. A Complete without it gets a 4XX error with code requires_3ds. The Draft Delegate Authentication RFC covers 3DS2 only, in the browser channel only. Sources: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md) and [ACP RFC: Delegate Authentication (Draft, 2026-01-28)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md).

## When the shopper has to finish

Both protocols plan for steps the agent cannot take. In UCP's [checkout capability](https://ucp.dev/latest/specification/shopping/checkout/), 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](https://storewalk.ai/blog/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](https://storewalk.ai/blog/acp-explained) covers the checkout session these belong to.

## What you can check in your own settings

- 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.

## What is not settled

- 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](https://storewalk.ai/blog/why-agents-cant-buy). The fifth, paying on the shopper's behalf, is the subject of [How an agent pays without seeing your card](https://storewalk.ai/blog/how-agents-pay).

## Sources

- [Cloudflare docs: Challenges](https://developers.cloudflare.com/cloudflare-challenges/)
- [Cloudflare docs: Interstitial Challenge Pages](https://developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/)
- [Cloudflare docs: Bot Fight Mode](https://developers.cloudflare.com/bots/get-started/bot-fight-mode/)
- [Shopify Help Center: Bot protection](https://help.shopify.com/en/manual/checkout-settings/bot-protection)
- [Shopify Help Center: Editing the checkout form options](https://help.shopify.com/en/manual/checkout-settings/checkout-form-options)
- [BigCommerce Support: Guest Customers and Checkout](https://support.bigcommerce.com/articles/Public/Guest-Customers-and-Checkout)
- [Google: JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [Anthropic: Does Anthropic crawl data from the web?](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler)
- [AWS: Reducing CAPTCHAs with Web Bot Auth (AgentCore Browser)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-web-bot-auth.html)
- [UCP Identity Linking](https://ucp.dev/latest/specification/common/identity-linking/)
- [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/)
- [RFC 8414: OAuth 2.0 Authorization Server Metadata](https://www.rfc-editor.org/rfc/rfc8414)
- [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728)
- [ACP repository and README](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol)
- [Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml)
- [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md)
- [ACP RFC: Delegate Authentication (Draft, 2026-01-28)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md)
- [ACP RFC: Discovery (Proposal, unreleased)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.discovery.md)
- [ACP RFC: Payment Handlers (Draft, 2026-01-22)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md)

Last checked 22 Oct 2026