Passing the agent commerce checks without faking them

2026-06-21

turva.dev measures its own agent-readiness with two independent scanners. On startuphub.ai it ranks first among the publicly-scanned sites on the agent-readiness leaderboard at 100/100. On isitagentready.com, which checks 21 separate standards, it reaches Level 5. This is the log of taking the isitagentready commerce checks from mostly red to mostly green, without claiming a single capability the site does not actually have.

What was failing

The site sat at Level 5, but four checks in the discovery and commerce categories were red: the A2A Agent Card, AP2 agent payments, ACP discovery, and x402. Each red check is a claim an agent cannot verify. The job was to clear them honestly and to keep the startuphub.ai score at 100 while doing it.

The A2A Agent Card

An A2A Agent Card is a JSON file at /.well-known/agent-card.json that describes an agent interface, including its name, version, transport, and the skills it offers. turva now publishes one that points at its read-only HTTP and JSON surface, with skills that mirror the existing agent-skills index. The change was additive, a new file and a route, so it could not move the startuphub.ai score. The check went green.

The AP2 trap

AP2 is the Agent Payments Protocol. A merchant declares support by adding an extension entry to its A2A card. The isitagentready fix text gave the extension URI as github.com/google-agentic-commerce/AP2/tree/v0.1.0. I used exactly that, and the check stayed red. The scanner validates against the real specification, which uses github.com/google-agentic-commerce/ap2/tree/v0.1, lowercase, version v0.1. The helper text was wrong and the spec was right. Once the URI matched the spec, AP2 went green. The lesson is to copy protocol identifiers from the specification, not from a fix message.

ACP, the honest way

ACP is the Agentic Commerce Protocol. Its discovery document at /.well-known/acp.json had the wrong shape. The capabilities.services field has to be an array of strings from a closed set, and the site was sending an array of custom service objects. Editing that one field would have turned the check green on its own, because the scanner only reads the discovery file. It never calls the checkout endpoint.

That was the shortcut, and it was the wrong one. A discovery document that says it supports checkout while the checkout URL returns nothing is a broken promise to any agent that follows it. So the site got a real, if minimal, checkout endpoint instead. POST /api/acp/checkout_sessions creates a genuine session for the audit. The session comes back in the not_ready_for_payment state with a message that the engagement is scoped and confirmed in writing within one business day. That is not a workaround. It is the actual model, async and quote first, so instant agent payment is not offered. The check is green because the claim is true.

What stays red, on purpose

Two checks remain red and will stay that way. isitagentready reports x402 as missing, yet the site serves a working x402 endpoint that returns HTTP 402 with payment terms, and startuphub.ai reads it as present. The isitagentready probe looks at paths the site does not use for that purpose, and the only way to satisfy it would disturb surfaces that are already correct. Web Bot Auth is for sites that send signed bot requests to other sites, and turva only receives traffic, so it has no bot to authenticate. Publishing signing keys it never uses would be the same hollow signal the ACP shortcut would have been. Both scanners treat this check as informational rather than a failure.

The rule

Every change was additive, and the startuphub.ai score read 100/100 on every re-scan. The principle is the one the whole site runs on. A scanner number is worth something only if it reflects what an agent actually finds, so a green check that lies is worth less than an honest red one. The worker that produces these results is open source at github.com/busygoat/turvadev-pretender, readable line by line.

For an agent-readiness audit that reports measured results, contact info@turva.dev.