Agentic Commerce Detection

Measurement dimensions

A · Volume

Interactions per protocol
Requests vs. interactions (raw HTTP hits vs. business events — one checkout = many requests)

B · Interaction type

Distribution by bucket (Discover / Browse / Transact)
Per-protocol type mix (e.g. UCP = 70% browse, 20% cart, 10% complete)

D · Geography

By country
Merchant-geo vs. agent-geo
Protocol adoption by region

E · Who

Top-N domains
Top merchant platforms
Top agents / platforms

01The opportunity

Agentic commerce — AI agents autonomously discovering products, selecting fulfillment, and completing purchases — is generating real, measurable HTTP traffic on Cloudflare's network today.

Cloudflare is uniquely positioned to observe it. The WAF already decrypts and inspects HTTP request and response content at approximately 70 million requests per second across all customer zones. No new decryption infrastructure is required. What does not yet exist is the instrumentation to recognize, classify, and report agentic commerce interactions within that inspected stream.

Cloudflare's own agentic-commerce framing defines three stages, which we adopt as the primary segmentation: DISCOVER control who finds your store · BROWSE let agents read your catalog on your terms · TRANSACT let agents pay securely.

The honest methodology caveat

Cloudflare sits in front of the merchant / seller / facilitator, not the AI platform. We observe a request when an agent calls an origin we protect — not traffic to origins we do not front. Every number is therefore a Cloudflare network-share view, sampled, not a universal market census. This is exactly how Radar's existing bot/AI-crawler data works, and it is defensible — provided we always say "network share," never "total market."

02Master protocol matrix

● primary/strong signal ○ present, secondary $ value: Yes / Partial / No

Protocol	Discover	Browse	Transact cart	Transact authorize	Transact complete	Transport	$ value visible	Confidence
ACP (OpenAI)	○	●	●	○	●	REST	Yes	DEF
UCP (Google/Shopify/…)	●	●	●	○	●	REST + JSON-RPC	Yes	DEF
AP2 (Google → FIDO)	–	–	○	●	○	A2A / x402	Partial	PROB
x402 (LF / Coinbase)	–	–	–	●	●	HTTP-native	Yes	DEF
Skyfire / KYAPay	●	○	–	●	●	JWT tokens	Yes	DEF
Visa TAP	●	●	○	●	○	RFC 9421 sigs	Partial	PROB
Mastercard Agent Pay	●	–	○	●	●	MDES tokens (+MCP)	Partial	PROB
MPP (Tempo / Stripe)	–	–	–	●	●	HTTP-native (IETF)	Yes	DEF
MCP (transport)	○	●	●	○	–	JSON-RPC / SSE	via payload	DEF
A2A (transport)	○	●	●	○	–	JSON-RPC	via payload	DEF

Cross-protocol tie-in

Skyfire's pay token carries sti.type values visa_vic and mastercard_scof, and Mastercard Agent Pay runs on the same MDES / SCOF rails. The card networks, the identity-token platforms, and the crypto rails increasingly wrap each other — so a single interaction may match multiple protocols. Attribute by the outermost envelope, and record inner rails as a secondary tag.

03The three buckets

A protocol is not a bucket. Most protocols span several. We detect the bucket from the signal and attribute it to a protocol.

DISCOVER "Does an agent know you exist — and is it trusted?"

An identity question. Reuses existing Cloudflare products (Bot Management, Web Bot Auth). Near-zero new build.

Layer	Signal	Source	Confidence
Header (identity)	Signature-Agent + Signature + Signature-Input (RFC 9421)	Web Bot Auth	DEFINITIVE
Header (identity)	Merchant-bound, purpose-bound, time-bound signature	Visa TAP	DEFINITIVE
Token / step	ID&V (verify cardholder) + registered Token Requestor	Mastercard Agent Pay	PROBABLE
Token	typ: kya+jwt	Skyfire / KYAPay	DEFINITIVE
Header (UA)	GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, ClaudeBot, Gemini, Google-Extended	Platform UAs	PROBABLE
CF signal	Bot score + verified-bot catalog	Bot Management	PROBABLE

Bucket metric: count of verified agent identities per domain (lead with Web Bot Auth + TAP — non-spoofable).

BROWSE "Is an agent reading the catalog?"

Detection is a request/response format & behavior question, not a URL question. The formats below (llms.txt, markdown, JSON-LD, MCP) are open standards any origin can implement — they are not Cloudflare-proprietary. What is Cloudflare-specific is the vantage point: the edge observes these signals across all fronted zones regardless of who built the endpoint, and can additionally generate markdown on-the-fly. Agents browse plenty of catalogs over plain REST/GraphQL/HTML too — so this bucket must catch generic API/feed reads, not just the agent-native formats.

Layer	Signal	Note	Confidence
Path (well-known)	GET /llms.txt, /llms-full.txt	Open format (llmstxt.org) — "sitemap for agents"; any origin can serve it	DEFINITIVE
Request header	Accept: text/markdown	Open content-negotiation; agent asks for agent-native format	DEFINITIVE
Response Content-Type	text/markdown on product path	Edge observes (and can generate) the representation served where a human gets text/html — vantage, not format, is CF-specific	DEFINITIVE
MCP (JSON-RPC)	tools/call: search_catalog / get_product; Mcp-Session-Id; SSE	Live catalog query — one browse method; MCP is not required to browse	DEFINITIVE (MCP)
Body (response)	Schema.org Product / Offer JSON-LD; product-feed JSON	Structured catalog read over any transport	PROBABLE
Generic API / feed	agent UA/identity + REST/GraphQL product endpoint or feed	The common case: agents read catalogs over ordinary APIs with no agent-native format at all	PROBABLE
Behavioral	Agent UA + product path + no CSS/JS/image sub-requests	Machine reading, not rendering — catches plain-HTML scraping	INFERRED

Bucket metric: agent-attributed catalog reads/domain across all methods — llms.txt + markdown-served + MCP catalog calls (Definitive) plus generic API/feed reads by identified agents (Probable). CF's edge is the only place all of these are visible in one stream; the formats themselves are open.

TRANSACT "Did the agent buy?"

One bucket with an optional stage attribute — not every protocol populates every stage. Distinguish attempt from sale.

Stage	Meaning	Detection	Protocols that populate it
cart	Agent negotiating / building cart (optional)	Session create/update, cart object pre-complete	ACP, UCP, (Agent Pay: Intent Creation)
authorize	Payment initiated / mandate presented	`402`, payment token, signed mandate	x402, MPP, AP2, Skyfire, TAP, Agent Pay
complete	Sale confirmed	Order object + status `completed` / settlement / Receipt	ACP, UCP, x402, MPP, Agent Pay

Bucket metric: completed transactions + $ value per protocol. Value coverage is high for ACP / UCP / x402 / MPP / Skyfire; partial for AP2 / TAP / Agent Pay (tokenized or opaque).

04The agentic funnel

The single most compelling Radar story is the conversion funnel: how many agents discovered, browsed, then transacted — and where they dropped off.

DISCOVER

Verified agent identity
Web Bot Auth / TAP sig
Bot-score classification

BROWSE

llms.txt / markdown (open formats)
MCP catalog queries
generic API / feed reads

TRANSACT cart → authorize → complete

checkout complete (SALE)
payment / settlement
$ value captured

Full-funnel protocols (traceable end-to-end): UCP (identity→catalog→checkout→order), Visa TAP (its Agent-Intent field literally flips browse→pay), ACP (feeds→session→complete), Mastercard Agent Pay (ID&V→Intent→Checkout). Payment-only protocols: x402, MPP. Identity-first, escalating: Skyfire (kya→pay/kya-pay).

05Quick reference: which protocol, which phase, what to match

The at-a-glance answer to "what runs where, and which signal do I actually use." Read the phase table top-to-bottom to see who competes at each phase; read a protocol row in the coverage grid left-to-right to see its span.

A. Phase-by-phase — who operates here & the one signal to match

Commerce phase	Bucket · stage	Protocols active here	Primary signal to match	Best confidence
Identity / trust "is this a real, authorized agent?"	DISCOVER	Web Bot Auth · Visa TAP · Skyfire `kya` · Mastercard Agent Pay (ID&V) · Bot Mgmt (UA)	Signature-Agent (RFC 9421) · TAP sig · typ:kya+jwt	DEFINITIVE
Product discovery / browse "agent reading the catalog"	BROWSE	UCP (Catalog Search) · ACP (feeds) · MCP · A2A · Visa TAP (Agent-Intent=retrieve) · + any plain REST/GraphQL/HTML catalog	GET /llms.txt · text/markdown · tools/call get_product · or agent UA + product API/feed	DEF (agent-native) · PROB (generic API)
Cart / negotiation "building the order"	TRANSACT `cart`	ACP · UCP · Mastercard Agent Pay (Intent Creation)	POST /checkout_sessions · "ucp":{} envelope	DEFINITIVE
Payment authorization "money committed / mandate"	TRANSACT `authorize`	x402 · MPP · AP2 · Skyfire `pay`/`kya-pay` · Visa TAP · Mastercard Agent Pay	402 + X-Payment · Credential · SD-JWT mandate (vct) · pay+jwt (amt/cur)	DEFINITIVE (x402/MPP/Skyfire) · PROB (AP2/TAP/Agent Pay)
Checkout complete (SALE) "the sale + $ value"	TRANSACT `complete`	ACP · UCP · x402 · MPP · Mastercard Agent Pay	status:"completed"+order · /settle · 200+Receipt	DEFINITIVE
Post-purchase "tracking, refunds, disputes"	TRANSACT `complete` (ext.)	UCP (order events) · ACP (order webhooks) · AP2 (dispute Receipts)	fulfillment.events[] · order.updated webhook · Payment Receipt	DEFINITIVE

B. Coverage grid — where each protocol lives

Protocol	Identity	Browse	Cart	Authorize	Complete	Post	In one line
ACP	–	●	●	○	●	●	ChatGPT checkout, feeds→session→complete
UCP	●	●	●	○	●	●	The full-lifecycle standard; use as spine
AP2	–	–	○	●	○	○	Payment trust/mandate layer inside UCP/A2A
x402	–	–	–	●	●	–	Crypto micropayment, pure payment
MPP	–	–	–	●	●	–	402 + Credential/Receipt, any rail
Skyfire	●	○	–	●	●	–	JWT identity→payment token
Visa TAP	●	●	○	●	○	–	Signed trust across browse+pay (Agent-Intent)
MC Agent Pay	●	–	○	●	●	–	Tokenized card rail, ID&V→checkout
MCP / A2A	○	●	●	○	–	–	Transport — carries the others; not commerce itself

C. Decision guide — "which do I look for?"

If you want the biggest coverage first

Instrument UCP and ACP — between them they cover Identity→Browse→Cart→Complete for the largest merchant ecosystems, and both have DEFINITIVE body signals (ucp envelope / API-Version).

If you want cheapest "money moved" proof

Match x402 and MPP via response 402 — a single status-code rule, layer ③, no body parse. Highest signal-to-cost.

If you want verified agent identity

Match Web Bot Auth + Visa TAP via RFC 9421 Signature-Agent — non-spoofable, reuses one verify path, feeds the Discover count.

If you're chasing a payment rail specifically

Crypto/stablecoin → x402 · card networks → Visa TAP / MC Agent Pay (also surfaced inside Skyfire sti.type) · any rail, neutral → MPP · mandate/consent trust → AP2.

Don't over-index on agent-native formats for browse

llms.txt, markdown and MCP are open standards, not CF features, and most agents still read catalogs over ordinary REST/GraphQL/HTML. Catch generic API/feed reads by identified agents (Probable) alongside the agent-native formats (Definitive) or you undercount Browse badly. CF's edge is the shared vantage point, not the format owner.

Mental model in one sentence

UCP/ACP are the commerce spine (discover→buy), MCP/A2A are the pipes they travel through, and x402 · MPP · AP2 · Skyfire · Visa TAP · Mastercard Agent Pay are the payment layers that plug into the authorize/complete phase — several of which wrap each other.

06Per-protocol deep reference

Each card: transport · unique constant (coarse filter) · stage map · value field + units · completion signal · confidence · source. Order: Transact/commerce protocols, then transport, then CF-native signals.

ACP — Agentic Commerce Protocol

OpenAI / ChatGPT-driven checkout

BROWSETRANSACT

DEFINITIVE

Transport: REST (JSON over HTTPS). MCP-server support stated as coming.
Unique constant: Header API-Version: 2025-09-12 — strongest single fingerprint. Corroborated by the required trio Signature + Idempotency-Key + Request-Id + Timestamp and UA ChatGPT/2.0 (…).
Stage map: POST /checkout_sessions = cart (create) · POST /checkout_sessions/{id} = cart (update) · POST …/complete = complete · …/cancel, GET …/{id}. Direction: OpenAI → Merchant.
Value field: totals[] entry where type:"total" → amount (integer, minor units: 330 = $3.30); currency ISO 4217 lowercase.
Completion signal: status:"completed" + presence of order object in /complete response = confirmed sale. payment_data.token (stripe/adyen/braintree) = delegated payment.

Source: developers.openai.com/commerce/specs/checkout.md · developers.openai.com/commerce

UCP — Universal Commerce Protocol

Google / Shopify / Walmart / Target / Etsy / Wayfair / Amazon / Microsoft / Meta / Salesforce / Stripe

DISCOVERBROWSETRANSACT

DEFINITIVE

Transport: REST + JSON-RPC. MCP, A2A, and AP2 support built in.
Unique constant: Top-level "ucp": {…} envelope in the JSON body — no other protocol wraps in ucp. Object IDs prefixed chk_, order_, li_.
Stage map: Identity: /.well-known/oauth-authorization-server with scope dev.ucp.shopping.checkout · Browse: Catalog Search / Lookup · Cart: checkout object, status:"ready_for_complete" · Complete: order + payment (via AP2) · Post: fulfillment.events[], refunds/adjustments.
Value field: totals[] where type:"total" → amount (minor units, e.g. 26550); currency ISO 4217.
Completion signal: order object with fulfillment.events[] (e.g. type:"delivered"). Merchant remains Merchant of Record.

Source: ucp.dev · spec at ucp.dev/latest/specification/overview · github.com/Universal-Commerce-Protocol/ucp (JSON schemas)

AP2 — Agent Payments Protocol

Google → donated to FIDO Alliance; A2A / UCP extension

TRANSACT

PROBABLE

Transport: Not a URL set — Verifiable Digital Credentials (VDCs) carried inside A2A messages or x402. Compatible with, and rides on top of, UCP.
Unique constant: SD-JWT Mandate objects with a vct claim identifying schema + version: mandate.checkout.open.1 / mandate.payment.1. Implementations MUST match the exact vct string.
Stage map: authorize: Checkout Mandate (open=constraints / closed=finalized cart, shared with Merchant) and Payment Mandate (shared with Credential Provider, Network, Merchant Payment Processor). Modes: Human Present (direct) / Human Not Present (autonomous, agent-signed with cnf public key).
Value field: Amount lives inside the signed Payment Mandate. Often selectively-disclosed / opaque — may only detect that a Payment Mandate exists, not its value.
Completion signal: Signed Checkout Receipt + Payment Receipt JWTs; binding via checkout_hash and transaction_id. ECDSA (not deterministic) required on the Checkout JWT.

Source: ap2-protocol.org/ap2/specification · ap2-protocol.org · github.com/google-agentic-commerce/AP2

x402 — HTTP-native crypto micropayments

Linux Foundation project; Coinbase; Cloudflare listed as adopter

TRANSACT

DEFINITIVE

Transport: HTTP-native — built into existing requests, no side channel. Blockchain-agnostic (EVM, Solana); stablecoin-primary.
Unique constant: Response status 402 Payment Required — nearly unique on today's web (402 was historically unused). The single cheapest definitive signal in the whole system.
Stage map: authorize: client retries with a payment payload after the 402 challenge · complete: facilitator /verify + /settle endpoints confirm on-chain. Batch settlement on EVM for high-volume redemption.
Value field: Amount + asset + network in the 402 response / payment payload (stablecoin amount, chain ID). Cross-check publicly against x402scan.com.
Completion signal: Successful /settle + subsequent 200 OK serving the resource.

Source: docs.x402.org (core-concepts/http-402, client-server, facilitator) · x402.org · explorer x402scan.com

Skyfire — KYAPay tokens

Open KYAPay protocol; agent identity + payment; has a Cloudflare Worker/WAF integration guide

DISCOVERTRANSACT

DEFINITIVE

Transport: Signed JWTs exchanged directly between buyer agent and seller (Skyfire not in the exchange path). Flow: Present → Verify → Deliver → Settle.
Unique constant: Header typ = kya+jwt (identity → Discover) / pay+jwt / kya-pay+jwt (payment → Transact). Signature verified via iss → /.well-known/jwks.json.
Stage map: Discover: kya token (verified identity, auto-account creation) · authorize/complete: pay / kya-pay token, seller charges via Skyfire Charge API. Common claims: iss, aud (seller agent ID), sub, jti, iat, exp, env, sdm (seller domain), ssi.
Value field: amt (currency units), cur (ISO 4217), val (settlement-network units), stp (coin/card/bank), sti.type (usdc / visa_vic / mastercard_scof). Pricing: sps, spr, mnr.
Completion signal: Seller Charge Token API call succeeds → Skyfire moves funds buyer → seller wallet.

Source: common-token-claims · pay-token · kyapay-tokens · docs.skyfire.xyz (incl. Cloudflare integration doc)

Visa TAP — Trusted Agent Protocol

Visa Intelligent Commerce; signature-based agent trust

DISCOVERBROWSETRANSACT

PROBABLE

Transport: RFC 9421 HTTP Message Signatures (same family as Web Bot Auth). Reference implementation verifies at a CDN-proxy layer — directly relevant to Cloudflare's edge position.
Unique constant: Signature bound to merchant domain + specific operation; components include timestamp, unique session ID, key ID, algorithm ID (anti-replay / anti-relay). Public-key lookup via an Agent Registry.
Stage map: Agent Intent field routes the bucket: "retrieve details about a product" → Browse; "purchase" → Transact. Consumer Recognition (merchant-account token, device IDs, country/postal), Payment Info as distinct verifiable elements.
Value field: Passed via query parameters at authorize: PAR (Payment Account Reference), Key-Entry hashed VIC credential + card metadata, API/protocol payment fields, or IOU balances. Partial — amount depends on merchant processing method.
Completion signal: Merchant-side signature verification + downstream checkout on the merchant's own rails.

Source: github.com/visa/trusted-agent-protocol (agent-registry, cdn-proxy, merchant-backend) · developer.visa.com/capabilities/trusted-agent-protocol

Mastercard Agent Pay

Remote Commerce Tokenization Program; partners incl. Microsoft/Copilot, Braintree, Checkout.com, IBM watsonx

DISCOVERTRANSACT

PROBABLE

Transport: Network tokenization via Mastercard Digital Enablement Service (MDES); strong auth via Mastercard Payment Passkeys. Explicitly applies MCP to Secure Remote Commerce (SCOF).
Unique constant: Agentic Commerce Identifiers: Digital Service Provider ID + Digital Commerce Solution Indicators — explicitly designed so issuers/acquirers can identify agentic transactions. Integrators register as Token Requestors.
Stage map (6-step workflow): Credential Enrollment (setup) · ID&V = Discover (verify cardholder) · Bind (setup) · Intent Creation = Transact:cart (capture purchase intent) · Authentication = Transact:authorize · Checkout = Transact:complete (receive tokenized payload).
Value field: Inside the tokenized payload. Token types: DSRP (Digital Secure Remote Payment — enhanced token data) and DTVC (Dynamic Token Verification Code — fallback for non-DSRP merchants). Partial: value carried in the token, exact byte-layout gated.
Completion signal: Checkout step returns tokenized payload; downstream authorization on Mastercard rails (recognizable via the DSP-ID / DCSI indicators).

Source: developer.mastercard.com/mastercard-checkout-solutions/documentation/use-cases/agent-pay (SPA; captured content) · product page · Apr 2025 press release

MPP — Machine Payments Protocol

Tempo Labs + Wevm; IETF-track (co-authored w/ Stripe); spec at paymentauth.org

TRANSACT

DEFINITIVE

Transport: HTTP-native; pay for a service in the same HTTP request. Neutral to underlying payment method (stablecoins, cards, bank transfers). SDKs: mppx (TS), pympp, mpp-rs, mpp-go. Docs MCP server at mpp.dev/api/mcp.
Unique constant: Response 402 Payment Required + Challenge; retry carries a Credential (proof of payment); response carries a Receipt (proof of delivery). Idempotency + Receipts are first-class primitives.
Stage map: authorize: 402 Challenge → retry with Credential · complete: 200 OK + Receipt. Off-chain sessions with on-chain settlement for micropayments.
Value field: Amount + currency in the Challenge / Credential (any asset: USD, EUR, BRL, USDC.e, BTC).
Completion signal: Receipt returned with the 200.

Source: mpp.dev/overview · IETF spec paymentauth.org
Naming note: "MPP" here = Machine Payments Protocol. AP2 separately uses "MPP" for the Merchant Payment Processor role — unrelated; disambiguate in the data model.

MCP — Model Context Protocol

Transport / tool substrate — not a commerce protocol; UCP/ACP/AP2/Agent Pay all ride it

DISCOVERBROWSETRANSACT

DEFINITIVE

Transport: JSON-RPC 2.0, often over SSE (text/event-stream) with paired /sse + /messages routes, or /.well-known/mcp. Cloudflare hosts MCP servers on Workers.
Unique constant: Body "jsonrpc":"2.0" with "method":"tools/call" / "tools/list" / "initialize"; header Mcp-Session-Id.
Stage map: Browse: catalog tool calls (search_catalog, get_product, check_inventory) · cart / authorize: commerce tool calls. Detect the envelope cheaply, then inspect the payload for a commerce protocol (a UCP ucp key, an AP2 mandate).
Value field: Only via the wrapped commerce payload — MCP itself carries no price.
Completion signal: N/A at transport layer; defer to the wrapped protocol.

Source: developers.cloudflare.com/agents (MCP tools, hosted MCP servers) · modelcontextprotocol.io

A2A — Agent2Agent

Transport for agent-to-agent delegation; carries AP2 as an extension

DISCOVERBROWSETRANSACT

DEFINITIVE

Transport: JSON-RPC task methods between agents. UCP and AP2 both ride on it.
Unique constant: Agent card at /.well-known/agent.json; JSON-RPC task-lifecycle methods.
Stage map: Browse / cart: task delegation between a shopping agent and a merchant/other agent · authorize: carries AP2 mandates.
Value field: Only via wrapped payload (e.g. AP2 Payment Mandate).
Completion signal: N/A at transport layer; defer to wrapped protocol.

Source: referenced by ap2-protocol.org & ucp.dev · a2a-protocol.org

Cloudflare-native Discover / Browse signals

Web Bot Auth

RFC 9421 HTTP Message Signatures — Cloudflare co-authored

DISCOVER

DEFINITIVE

Unique constant: Headers Signature, Signature-Input, Signature-Agent — cryptographically verified, non-spoofable agent identity. The crown jewel of the Discover bucket.
Bucket: Discover. Same RFC 9421 machinery as Visa TAP → one verification path serves both.

Source: developers.cloudflare.com/bots/…/web-bot-auth

Markdown-for-agents & llms.txt

Cloudflare on-the-fly agent-native rendering

BROWSE

DEFINITIVE

Unique constant: GET /llms.txt / /llms-full.txt; request Accept: text/markdown; response Content-Type: text/markdown on a product path where a human gets text/html — a signal only the edge can see.
Bucket: Browse. Cheapest, most defensible "agents are reading here" metric.

Source: cloudflare.com/get-started-agentic-commerce · markdown-for-agents

Bot Management (bot score + verified-bot catalog)

Existing Cloudflare classification

DISCOVER

PROBABLE

Unique constant: Bot score; verified-bot catalog; agent UAs (GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Gemini, Google-Extended). Spoofable → Probable unless paired with a signature.
Bucket: Discover (also a corroborating filter for Browse behavioral inference).

Source: developers.cloudflare.com/bots/…/bot-management