Some of your customers are not using a browser

Three modes, three failures

Mode A is marked not built here, and that is the honest state: distinguishing an agent-driven browser from a person by user agent alone does not work, and behavioural detection is scoped rather than shipped. Mode C classifies from request headers server-side today, before anything is stored.

Mode B, working

This property exposes a real ACP-shaped surface: a discovery document at /.well-known/acp/config.json, a structured product feed, and the specification’s five checkout endpoints - create, get, update, complete, cancel. The delegated payment token is a simulated shape scoped to one session and one amount, and it is re-minted whenever the basket changes, because a token authorised for one total must not settle another. No payment is taken and no card field exists anywhere in this codebase.

The same thing from a terminal, with no browser at all

Discovery and the feed are public. The checkout endpoints need the demo token, because a protocol order rides as verification traffic and therefore reaches billed vendors - an open endpoint would let a stranger spend our vendor allowance.

# 1. Discover the merchant. No page, no token.
curl -s https://store.webclat.com/.well-known/acp/config.json

# 2. Read the product feed. This is where an agent "browses".
curl -s https://store.webclat.com/api/acp/feed

# 3. Open a checkout session.
curl -s -X POST https://store.webclat.com/api/acp/checkout \
  -H 'content-type: application/json' \
  -H 'x-bulk-token: <demo token>' \
  -H 'x-agent-platform: acme-shopping-agent/1.0' \
  -d '{"line_items":[{"item_id":"WC-POL-003","quantity":1}]}'

# 4. Complete it with the delegated token the session returned.
curl -s -X POST https://store.webclat.com/api/acp/checkout/<id>/complete \
  -H 'content-type: application/json' \
  -H 'x-bulk-token: <demo token>' \
  -d '{"payment_token":"<token from step 3>"}'

Step 4 answers with the order and a measurement block: the canonical event we minted, both warehouse verdicts, and every server-side vendor’s own status code. A real deployment would not return that block - measurement is not the agent’s business - and it is here because the asymmetry is the exhibit.

Two things the order deliberately does not claim

“We already use Enhanced Conversions”

Almost everyone does, and they should - it is the right answer to the problem it solves. It is also the first thing raised when this channel comes up, so here is the distinction that matters: Enhanced Conversions feeds the bidder. It does not give you a report.

The conclusion is not “stop using it”. It is that every vendor-side fix is necessarily per-vendor, because each platform can only see its own agent - so the one place a single reconcilable number can exist is a warehouse you own. That is an argument about where measurement lives, not about which tag is best.