Crossmint vs Visa Intelligent Commerce

Cart

1. ai-native userMy agent can create and update a cart or order draft through a documented protocol call

   weight 3 · round to Crossmint
   Crossmint✓fullprobed8/10

   Crossmint's Agent Checkouts API is a documented protocol call that lets an agent submit a product URL and spending cap to create an order/checkout, and runtime probing confirms the endpoint is live and agent-scoped (requiring ServerKeyAgent auth). The lifecycle supports polling for status updates, which functions as order-draft state updates, and agent cards similarly document order-intent creation/tracking (total, reserved, spent, available). missing for 10: no explicit 'update cart' verb or partial-order-edit API, no OpenAPI/schema confirmation (openapi.json probes 404), and no independent third-party corroboration beyond first-party docs and the vendor's own runtime probe.

   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed6/10

   Visa's REST APIs document creating a purchase-intent (POST /acp/v1/instructions) with mandate fields (amount, merchant, description) that functions like an order/cart draft, and revocation of that intent is documented as a follow-on call — but there is no explicit 'update/modify draft' endpoint, only initiate and cancel actions on the instruction/mandate object. Missing for 10: a documented update/modify-in-place endpoint for an existing cart/order object, and clearer mapping of Visa's 'instruction' concept to a literal cart/order draft rather than a payment-intent mandate.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “Capture consumer consent, set spending limits, and manage mandates for agent-initiated payments.”

   proof ↗⚑ flag

Checkout

1. ai-native userMy agent can complete a purchase end-to-end — checkout session, delegated payment credential, confirmed order

   weight 3 · round drawn
   Crossmint✓fullprobed8/10

   Crossmint's Agent Checkouts API lets an agent be handed a product URL and spending cap and complete checkout on the user's behalf, with delegated payment credentials (agent cards/order intents or delegated wallet signer permissions) and a poll-driven order lifecycle to confirm terminal state; runtime probe confirms the endpoint is live and enforces agent-scoped auth. missing for 10: independent/third-party confirmation of a fully completed order in production (docs note no staging/test environment and no webhooks in v1, so end-to-end success is self-reported), and no public case study of a real merchant purchase completing.

   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed8/10

   Visa's docs describe the full agent-checkout pipeline with concrete REST endpoints: card enrollment/tokenization (POST /acp/v1/tokens), a purchase-intent mandate with spend caps and expiry (POST /acp/v1/instructions), scoped delegated credential retrieval tied to merchant/amount (POST /acp/v1/instructions/{id}/credentials), passkey-based instruction authentication, and authorization-time enforcement plus payment outcome confirmation — covering checkout session, delegated credential, and confirmed order end-to-end. Missing for 10: independent/hands-on evidence of a completed real-world transaction (all evidence is first-party docs) and the product page's own maturity caveat that it is 'in the process of development and deployment'.

   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “Confirm payment outcomes and trigger post-purchase actions in real-time.”
   • [claimed-docs] “Controls to ensure that the agent’s purchasing actions and the related authorizations align with the user’s authenticated instruction”

   proof ↗⚑ flag

Embedded surfaces

1. merchantBuyers can complete purchases of my products inside chat and assistant surfaces (ChatGPT, Claude, Gemini, Copilot and peers)

   weight 2 · round to Visa Intelligent Commerce
   Crossmint~partialclaimed3/10

   Crossmint documents generic agent-payment infrastructure (Agent Cards, Agent Wallets, Agent Checkouts) that lets any AI agent buy from merchants via API, which could theoretically be wired into chat surfaces, but there is no evidence of concrete integration or partnership with ChatGPT, Claude, Gemini, Copilot or similar assistant surfaces. Missing for 10: named integrations/plugins with specific chat/assistant platforms, evidence of buyers actually completing purchases inside those surfaces, and any merchant-facing onboarding flow tied to those platforms.

   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed5/10

   Visa Intelligent Commerce provides the underlying payment rails for agent-initiated purchases (tokenization, mandate/consent controls, passkey step-up auth, Trusted Agent Protocol, and an MCP server for developers to plug into agentic experiences), which is the necessary plumbing for buyers to check out via AI agents. However, the evidence never names or demonstrates live integration with specific chat/assistant surfaces like ChatGPT, Claude, Gemini, or Copilot — it's generic 'agent' infrastructure plus a community-noted MCP server, with the core product itself flagged as still 'in the process of development and deployment.' Missing for 10: explicit evidence of shipped integrations or launch partnerships with ChatGPT/Claude/Gemini/Copilot, and independent confirmation that merchants can actually complete checkout flows inside those named surfaces today.

   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [claimed-docs] “the toolkit helps developers and non-technical users to work with AI agents using plain language — no coding required.”
   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”

   proof ↗⚑ flag

Protocol conformance

1. developerBuild against a versioned commerce protocol with a published schema and conformance or validation tooling

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   Crossmint documents payment flows (x402, MPP, agent checkouts) but there is no evidence of a versioned commerce protocol with a published schema or conformance/validation tooling — probes for OpenAPI/swagger specs all 404'd, and the live agent-checkouts endpoint is explicitly path-versioned as '/api/unstable/', signaling the opposite of a stable published protocol.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

   Visa publishes detailed REST API docs (endpoints, required fields, sample payloads) for Intelligent Commerce and a public spec with reference implementation for the Trusted Agent Protocol (RFC 9421 signatures, JWKS verification), plus a sandbox for testing. However, there's no evidence of a single unified 'commerce protocol' with an explicit version number, a published machine-readable schema (e.g. OpenAPI/JSON Schema spec file), or dedicated conformance/validation tooling beyond the sandbox and a reference implementation repo. missing for 10: explicit protocol versioning scheme, downloadable/published schema (OpenAPI or similar), dedicated conformance-test suite or validator tool, independent developer corroboration of building against the spec.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”
   • [claimed-docs] “including the cryptographic standards (RFC9421), required message signature fields, and the process for validating an agent's intent.”

   proof ↗⚑ flag

Service discovery

1. ai-native userMy agent can discover payable services and APIs through a published directory or discovery index

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   The evidence covers Crossmint's payment rails (cards, wallets, x402, MPP, checkouts) but nothing describes a published directory or discovery index of payable services/APIs that an agent could browse or query; llms.txt is a docs-crawling aid, not a service discovery index. This is a fair axis for an agent-payments platform, but no capability is evidenced.

   ⚑ flag

   Visa Intelligent Commerce~partialprobed5/10

   Visa provides discovery surfaces for its own developer APIs — an official MCP server (visa-intelligent-commerce-docs-8, probe-2), a public npm package (visa-ic-probe-rt-2), and a machine-readable llms.txt index (visa-intelligent-commerce-probe-1) — which let an agent discover and call its payment/commerce endpoints. However this is discovery of Visa's own API surface, not a broader directory/index of third-party payable services or merchants that an agent could browse; the TAP agent-registry is for verifying agent identity, not for service discovery. Missing for 10: a published directory/marketplace of payable third-party services, evidence of cross-vendor service discovery, independent confirmation the MCP/llms.txt are used for live service discovery rather than just docs.

   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.visaacceptance.com/llms.txt # VisaAcceptance Developer Center > This developer documentation …”
   • [probe] “official MCP server documented at https://github.com/visaacceptance/agent-toolkit”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Crossmint✓fullprobed9/10

   Crossmint serves a live llms.txt (confirmed by direct probe returning HTTP 200 with agent-oriented content) and every docs page is also available as markdown via the same URL + .md suffix, directly matching the story of pointing an agent at llms.txt or agent-oriented docs. Missing for 10: no independent third-party report of an agent successfully consuming these docs end-to-end, and no OpenAPI spec (all candidates 404) to complement the llms.txt for structured agent consumption.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”
   • [probe] “PROBE runtime (recorded 2026-09-14): docs.crossmint.com serves llms.txt keylessly — '# Crossmint... checkout for onchain and physical-world …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed9/10

   A probe confirms llms.txt returns HTTP 200 with structured content at developer.visaacceptance.com/llms.txt, and Visa also publishes an official MCP server (agent-toolkit) confirmed live on npm, giving agents both a machine-readable docs entry point and a programmatic tool interface. Missing for 10: independent third-party confirmation that agents actually consume llms.txt successfully in practice beyond the HTTP probe.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.visaacceptance.com/llms.txt # VisaAcceptance Developer Center > This developer documentation …”
   • [probe] “official MCP server documented at https://github.com/visaacceptance/agent-toolkit”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”
   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [claimed-docs] “It offers a specialized set of tools designed to help you manage invoices, create payment links, and perform other Visa Acceptance-related o…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Crossmint~partialprobed6/10

   Crossmint's core products are REST/headless APIs (explicit 'headless checkout API', agent checkouts API, wallet API) designed for programmatic, UI-less automation, and probes confirm keyless API-key-based auth suitable for scripted/CI calls. However there is no explicit documentation of CI pipeline usage, SDK examples for automated test suites, or non-interactive auth setup, and agent-checkouts testing is noted as production-only with no staging environment, complicating CI use. Missing for 10: documented CI/automation examples, staging/sandbox support for safe automated testing, and explicit non-interactive credential provisioning guidance.

   • [claimed-docs] “Crossmint's headless checkout API is a set of REST APIs that allow you to integrate credit card and cross-chain crypto payments inside your …”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed6/10

   The product is fundamentally API/protocol-driven (REST endpoints for tokens, instructions, credentials) with a published MCP server and npm-distributed agent-toolkit, plus a self-serve sandbox for test transactions — all of which are inherently headless and scriptable without a UI. However, there is no explicit documentation or example of CI/CD pipeline integration, automated test harnesses, or non-interactive credential/authentication flows (since the design requires passkey/step-up human authentication at key points), which limits true unattended automation. Missing for 10: explicit CI/CD pipeline examples, documentation on running fully unattended (given passkey step-up requirements), automated test suite integration guidance.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [probe] “official MCP server documented at https://github.com/visaacceptance/agent-toolkit”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”
   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”

   proof ↗⚑ flag

3. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Crossmint✓fullprobed8/10

   Crossmint exposes a documented REST API surface (wallets, agent cards, agent checkouts, payment flows) with quickstarts and runtime probes confirming the endpoints are live and API-key/agent-key authenticated, and llms.txt/markdown docs are served for machine consumption. The main gap is the absence of a discoverable formal OpenAPI/Swagger spec (probe-2 shows all standard OpenAPI paths 404), so full machine-readable API introspection isn't confirmed. Missing for 10: a published OpenAPI/Swagger schema, independent third-party confirmation of API robustness beyond Crossmint's own docs.

   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [probe] “PROBE runtime (recorded 2026-09-14): docs.crossmint.com serves llms.txt keylessly — '# Crossmint... checkout for onchain and physical-world …”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed8/10

   Visa publishes a documented REST API (POST /acp/v1/instructions, /acp/v1/tokens, /acp/v1/instructions/{id}/credentials) with field-level specs, sandbox sign-up, and an official MCP server/agent-toolkit for AI-native access, corroborated by npm registry presence and a live gateway probe. missing for 10: independent third-party developer confirmation of building against the API and broader SDK/language coverage beyond the documented endpoints.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [probe] “official MCP server documented at https://github.com/visaacceptance/agent-toolkit”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”
   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”

   proof ↗⚑ flag

4. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Crossmint
   Crossmint✓fullprobed7/10

   Crossmint documents explicit least-privilege delegation for agents: user-owned wallets grant an agent a bound signer key with a spend cap, allowed counterparties, and a time window, all enforced onchain and revocable at any time; agent cards similarly use order-intent 'fixed allowance' credentials with amount/expiration limits and network-level enforcement. A runtime probe further shows an agent-specific credential type (ServerKeyAgent) is live on the Agent Checkouts API, confirming agent-scoped API keys exist in practice, not just in docs. Missing for 10: independent/third-party corroboration of these scoping guarantees, and clearer documentation of general-purpose (non-payment) API key scoping/role management beyond the wallet/card/checkout domain.

   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialcommunity7/10

   Visa Intelligent Commerce issues agent-specific payment tokens/credentials scoped by merchant name, amount, and decline thresholds via mandates, gated behind passkey-authenticated user instructions (visa-ic-supp-1, visa-ic-supp-3, visa-ic-supp-5, visa-ic-supp-2). This is a concrete least-privilege credential model for payments, but it is payment-specific rather than a general API-credential scoping mechanism, and the platform page itself carries a maturity caveat ('in the process of development and deployment') plus community skepticism that standardized agent identity/permission scoping is still immature (visa-intelligent-commerce-comm-1). Missing for 10: evidence of granular scoping beyond amount/merchant (e.g., category-level or time-window least privilege), independent/production validation of the scoping enforcement, and confirmation the maturity caveat has been resolved.

   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [community] “The Visa/Mastercard announcements are interesting but feel premature. The missing piece is standardized agent identity and capability declar…”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Visa Intelligent Commerce
   Crossmint~partialprobed5/10

   Crossmint's docs show a single REST API accessed via quickstarts (agent checkouts, cards, stablecoin wallets) and protocol-specific clients like @x402/core and mppx, implying SDK-style tooling, but no evidence names an official multi-language SDK package (e.g., npm/pip installable Crossmint SDK) and the OpenAPI probe found no published spec, undercutting a clean 'official SDK' story. missing for 10: explicit official SDK package names/install instructions, multi-language SDK coverage, and a discoverable OpenAPI/schema reference.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed8/10

   Visa documents official REST APIs (with concrete endpoints for enrollment, credential retrieval, purchase-intent mandates), an official MCP server (published on npm as @visaacceptance/mcp with a GitHub repo), and an open-source Trusted Agent Protocol reference implementation, giving AI-native developers multiple official SDK/tooling surfaces to build against. Missing for 10: dedicated language-specific SDKs (Python/Node/Java client libraries) beyond the MCP/toolkit and REST docs, and independent third-party corroboration of SDK developer experience.

   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [claimed-docs] “It offers a specialized set of tools designed to help you manage invoices, create payment links, and perform other Visa Acceptance-related o…”
   • [probe] “official MCP server documented at https://github.com/visaacceptance/agent-toolkit”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”

   proof ↗⚑ flag

6. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Crossmint—none0/10

   The only explicit evidence about webhooks states the opposite of the story: Agent Checkouts documentation says 'no webhooks in v1' and requires polling until a terminal state is reached, with no other evidence pack item describing a webhook subscription mechanism anywhere in Crossmint's API.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   The evidence pack describes payment instructions, tokenization, mandates, and the Trusted Agent Protocol, but nowhere documents a webhook subscription mechanism for AI agents to receive event notifications. The closest mention, 'Confirm payment outcomes and trigger post-purchase actions in real-time' (visa-intelligent-commerce-docs-5), does not specify webhooks or any pub/sub API.

   ⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Crossmint~partialclaimed5/10

   Crossmint lets agents transact autonomously once delegated: onchain-enforced spend limits, counterparties, and time windows mean the agent acts 'with no user prompt per action' and checkouts/x402/MPP payments proceed without human intervention ([crossmint-supp-4], [crossmint-supp-6], [crossmint-supp-7]). However this is scoped strictly to payment/checkout automation, not a general-purpose background job/workflow scheduler, and agent checkouts require manual polling with no webhooks or staging ('no webhooks in v1', 'no staging environment') ([crossmint-supp-7]). Missing for 10: general-purpose automation/scheduling framework beyond payments, webhook/event-driven triggers, and evidence of autonomous background operation outside the payment domain.

   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

   Visa Intelligent Commerce provides the payment-authorization infrastructure (mandates, spend caps, tokens, passkey-anchored consent) that enables agents to transact autonomously within user-set limits, and the purchase-intent mandate mechanism (decline thresholds, effectiveUntilTime) supports background/recurring authorization without per-transaction human sign-off. However, this is a payments-rail product, not an automation/scheduling platform — there's no evidence of the product itself offering a UI or API for users to configure recurring/background 'automations' (e.g., scheduled tasks, triggers, workflows) beyond the payment-instruction mandate; that capability lives in whatever agent/orchestrator integrates with Visa's APIs. missing for 10: first-party evidence of an automation/scheduling interface for background-running tasks, independent hands-on confirmation of autonomous mandate execution in production, and clarity on how recurring (not just one-off) purchase intents are managed.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Capture consumer consent, set spending limits, and manage mandates for agent-initiated payments.”
   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   Crossmint's evidence describes REST APIs, SDKs, and agent-delegated payment flows (cards, wallets, checkouts, x402/MPP), but nothing shows a natural-language command interface for the human/AI-native user to directly operate Crossmint itself — no chat UI, NL-to-API translation layer, or documented conversational control surface. The axis is fair to ask of a product marketed as 'payment infrastructure for AI agents,' but no such capability is evidenced.

   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed6/10

   The Visa Acceptance Agent Toolkit (MCP server) is documented as letting 'developers and non-technical users work with AI agents using plain language — no coding required,' and probes confirm the toolkit is a real, published npm package with an MCP server rather than just a marketing claim. However, natural-language operation is really mediated through AI agents (e.g., Claude/ChatGPT) calling the toolkit's tools, not a native NL interface Visa itself ships, and there's no independent hands-on report of a user issuing plain-language commands successfully. Missing for 10: independent/hands-on demonstration of NL command usage, and clarity on how much of the NL experience is Visa-built vs. reliant on third-party agent UIs.

   • [claimed-docs] “the toolkit helps developers and non-technical users to work with AI agents using plain language — no coding required.”
   • [claimed-docs] “It offers a specialized set of tools designed to help you manage invoices, create payment links, and perform other Visa Acceptance-related o…”
   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”
   • [probe] “official MCP server documented at https://github.com/visaacceptance/agent-toolkit”
   • [probe] “PROBE runtime (recorded 2026-09-14): Visa's developer gateway is live and credential-gated exactly as documented — a keyless GET to https://…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Crossmint—none0/10

   The evidence shows only markdown-based docs and an llms.txt feed; explicit probes for an OpenAPI/Swagger spec (openapi.json, swagger.json, etc.) all returned 404, and no evidence mentions an interactive API console, sandbox, or runnable code examples.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”
   • [probe] “PROBE runtime (recorded 2026-09-14): docs.crossmint.com serves llms.txt keylessly — '# Crossmint... checkout for onchain and physical-world …”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Evidence shows detailed REST endpoint documentation with sample JSON payloads (mandates, enroll-card, retrieve-credentials) and a separate sandbox signup form for sending test transactions, but nothing describes an interactive API reference (e.g., a Swagger/Postman-style 'try it' console) where examples can be run directly from the docs page. missing for 10: an interactive/try-it-now console embedded in API docs, evidence of one-click runnable code samples, any UI screenshot or independent report of in-docs execution.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.visaacceptance.com/llms.txt # VisaAcceptance Developer Center > This developer documentation …”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   A direct probe found no OpenAPI/Swagger spec at any standard path (all 404s), and while an llms.txt/markdown docs format exists, that is not a machine-readable API spec. missing for 10: an OpenAPI/Swagger JSON or YAML spec, any documented spec download link, or equivalent machine-readable API schema.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed6/10

   Visa documents concrete REST endpoints (e.g., POST /acp/v1/instructions, /acp/v1/tokens, /acp/v1/instructions/{id}/credentials) with detailed field-level specs, an MCP server, and an llms.txt-served developer portal, indicating machine-readable interfaces exist, but no evidence explicitly confirms a downloadable OpenAPI/Swagger spec file. missing for 10: an explicit OpenAPI/Swagger JSON or YAML artifact, a documented download link or spec generation endpoint, independent confirmation the spec is machine-parseable rather than just REST prose docs.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.visaacceptance.com/llms.txt # VisaAcceptance Developer Center > This developer documentation …”
   • [claimed-docs] “Developers can now connect to Visa Intelligent Commerce APIs through the MCP Server, making it faster and easier for builders to bring intel…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Visa Intelligent Commerce
   Crossmint~partialclaimed4/10

   Crossmint documents genuine testnet sandboxes for some flows (e.g., the stablecoin wallet quickstart runs on Base Sepolia, crossmint-docs-3), but for Agent Checkouts the docs explicitly state 'there is no staging environment for it' and testing is production-only (crossmint-supp-7). So sandboxed testing exists for part of the agent stack but is explicitly absent for another major agent capability. missing for 10: a unified sandbox/staging environment across all agent products (cards, checkouts, wallets), independent confirmation of testnet behavior beyond docs, and any sandbox coverage for Agent Cards/Checkouts specifically.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed8/10

   Visa documents a dedicated sandbox: a self-serve 'Intelligent Commerce Sandbox Sign up' form that lets developers 'send test transactions,' separate test endpoints (https://apitest.visaacceptance.com vs production https://api.visaacceptance.com), and explicit fee terms stating 'Free to use in Sandbox. Contact Visa for fees in Production.' This directly satisfies testing without touching production data or paying production fees. Missing for 10: independent/hands-on confirmation that the sandbox behaves as documented (no third-party report of actually using it), and no detail on sandbox data reset/isolation guarantees.

   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   No evidence pack item documents API versioning conventions or a deprecation policy; the only version-related signal is an endpoint path containing 'unstable' (crossmint-probe-rt-1), which if anything suggests unversioned/experimental APIs rather than a documented deprecation policy.

   ⚑ flag

   Visa Intelligent Commerce~partialclaimed3/10

   API endpoints show explicit versioning (e.g., POST /acp/v1/instructions, /acp/v1/tokens) indicating a versioning scheme, but no evidence anywhere in the pack documents a deprecation policy, sunset timeline, or version-lifecycle commitment for these APIs. missing for 10: documented deprecation/versioning policy, migration guidance between versions, changelog or version-lifecycle commitments.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Crossmint—none0/10

   The evidence pack covers single-item agent payment flows (cards, wallets, checkouts, x402/MPP) and mentions managing funds 'at scale' in passing, but there is no documented batch/bulk API, bulk wallet creation, or multi-item transaction endpoint that would let a user perform operations across many items at once.

   • [claimed-docs] “Secure, programmable wallets to manage and move company funds at scale.”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   The evidence describes per-transaction flows (single card enrollment, single purchase-intent mandate, single credential retrieval, single invoice/payment link creation) with no mention of batch or bulk APIs for processing many items/transactions at once. While bulk operations are a plausible axis for a commerce/payments platform, there is no documentation of batch enrollment, bulk credential issuance, or multi-item transaction processing.

   • [claimed-docs] “It offers a specialized set of tools designed to help you manage invoices, create payment links, and perform other Visa Acceptance-related o…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Visa Intelligent Commerce
   Crossmint~partialclaimed4/10

   Crossmint lets users define scoped rules (spend caps, counterparty allow-lists, time windows) that once set let an agent act autonomously without per-action prompts, and states 'Transaction rules enforced onchain' — a form of automatic rule-based action. However this is closer to pre-authorized permission bounds than true event-triggered automation, and the docs explicitly note agent checkouts have 'no webhooks in v1', meaning event-driven triggering isn't supported there. Missing for 10: an explicit rules/automation engine that fires actions on arbitrary external or on-chain events, webhook/event-subscription support, and independent confirmation of automated rule execution beyond spend-limit enforcement.

   • [claimed-docs] “Transaction rules enforced onchain”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

   Visa Intelligent Commerce lets users set mandate-based rules such as decline thresholds, expiry times, and consumer prompts that constrain agent-initiated purchases, and documents automatic post-purchase actions triggered on payment confirmation events. This is rule-based automation but scoped narrowly to payment authorization and consent, not a general event-trigger-action framework a user can freely define. missing for 10: broader event types beyond payment confirmation, arbitrary custom action definitions beyond spend caps and expiry, independent evidence of the rule engine executing complex conditional logic

   • [claimed-docs] “Confirm payment outcomes and trigger post-purchase actions in real-time.”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”

   proof ↗⚑ flag

Fees transparency

1. merchantThe fees for agent-originated transactions are published — I can price agentic channels without asking sales

   weight 2 · round drawn
   Crossmint—none0/10

   Crossmint publishes general wallet MAU overage pricing and checkout fee tiers, but the evidence pack explicitly states 'No agent-card- or agent-checkout-specific price is published on the pricing page' (crossmint-supp-9), meaning a merchant cannot price the agent-specific channels (Agent Cards, Agent Checkouts) without contacting sales.

   • [claimed-docs] “Published pricing: wallets are "Free 1,000 Monthly Active Wallets" then "Overages start at $0.05 per MAU. Volume discounts available."; onra…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Visa's own documentation states fees are 'Free to use in Sandbox. Contact Visa for fees in Production' — meaning production pricing is explicitly not published and requires contacting Visa directly, the opposite of the story's ask for a self-serve published rate card.

   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Payouts

1. merchantAgent-originated payments settle through documented payout and reporting flows, reconcilable like any other channel

   weight 1 · round to Visa Intelligent Commerce
   Crossmint~partialclaimed3/10

   Evidence shows transaction-lifecycle tracking (order intents track total/reserved/spent/available amounts) and a documented authorization-hold/capture and dispute-management model for card checkout, which are reconciliation-adjacent, plus tiered per-transaction pricing. But there is no documented merchant payout schedule, settlement-to-bank-account flow, transaction reporting dashboard, or export/reconciliation tooling specific to agent-originated payments, and the agent-checkouts flow explicitly lacks webhooks ('no webhooks in v1' — poll until terminal state), undermining real-time reconciliation. Missing for 10: merchant payout/settlement documentation, reporting/dashboard or export tools, reconciliation-specific guidance for agent transactions, and webhook-based confirmation.

   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”
   • [claimed-docs] “Published pricing: wallets are "Free 1,000 Monthly Active Wallets" then "Overages start at $0.05 per MAU. Volume discounts available."; onra…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed4/10

   Visa Intelligent Commerce documents authorization, tokenization, mandates, and dispute-relevant 'commerce signals' capture, and notes settlement/IOU concepts in TAP, but there is no documented merchant payout/settlement schedule, reconciliation file/report format, or statement-level breakdown distinguishing agent-originated transactions from other channels — it's treated as a standard card-rail authorization with evidence signals for disputes, not a distinct reconciliable payout flow. missing for 10: documented payout/settlement cadence, merchant reconciliation reports or statement descriptors specific to agent transactions, dispute/chargeback API (vs. just evidence capture), independent merchant confirmation of reconciling agent payments like other channels.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “TAP's signed Agentic Payment Container adapts to the merchant's rail: for guest-checkout key entry it carries a credential hash — "If the ha…”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Attribution analytics

1. merchantOrders are attributed to the originating agent and I can report on or filter transactions by agent

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   The evidence describes agent payment mechanisms (cards, wallets, checkouts, spending rules) but contains no mention of merchant-facing reporting, dashboards, or transaction filtering by originating agent — the core of this story. Order intents and delegated signers are documented for controlling agent spend, not for merchant attribution/reporting.

   ⚑ flag

   Visa Intelligent Commerce~partialclaimed4/10

   Visa Intelligent Commerce provides agent-scoped tokens, TAP signatures identifying an agent per interaction, and commerce-signal capture for dispute resolution, which implies some technical basis for attributing a transaction to an agent, but there is no documented merchant-facing reporting/dashboard feature or API to filter or report transactions specifically by agent identity. missing for 10: a merchant reporting/analytics dashboard or API endpoint that lets merchants filter/query transactions by agent identifier, explicit documentation of agent-ID fields surfaced in settlement/reporting data, and independent evidence merchants actually use this for reporting.

   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”
   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”

   proof ↗⚑ flag

Onboarding to agents

1. merchantI have a documented self-serve path to start accepting agent traffic — enable a setting, sign an agreement, or publish an endpoint

   weight 3 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   Evidence covers agent-side integrations (agent wallets, agent cards, x402/MPP payment flows, agent checkouts) but nothing documents a merchant-facing onboarding step — no setting to enable, agreement to sign, or endpoint-publishing guide aimed at merchants who want to accept agent traffic. The 'buy from any merchant' framing implies merchants need no explicit action, but this is never documented as a self-serve merchant enablement path.

   ⚑ flag

   Visa Intelligent Commerce~partialclaimed7/10

   Visa documents a genuine self-serve onboarding flow: a public 'Intelligent Commerce Sandbox Sign up' form with terms acceptance that immediately unlocks test transactions (visa-ic-supp-10), plus an open, publishable Trusted Agent Protocol reference implementation merchants can deploy to declare/verify agent traffic (visa-ic-supp-9, visa-intelligent-commerce-gh-1/2). However, production enablement is explicitly gated — 'Contact Visa for fees in Production' (visa-ic-supp-8) — meaning the fully self-serve path only covers sandbox/dev, not live acceptance. Missing for 10: a documented self-serve production activation step (no sales contact), and independent merchant confirmation that the sandbox-to-production path works without manual Visa involvement.

   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [github] “By presenting a secure digital signature with every interaction, a merchant can verify that an agent is legitimate and has the user's permis…”
   • [github] “This allows you to confidently welcome agent-driven commerce while protecting your site from harmful bots.”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Traffic controls

1. merchantRate-limit, allow, or deny specific agents and agent platforms accessing my catalog and checkout

   weight 2 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   The evidence details user-side and agent-side spending controls (spend caps, counterparties, time windows, order intents) but nothing about merchants controlling which agents/agent platforms may access their catalog or checkout, nor any rate-limiting/allow-deny mechanism exposed to merchants. Crossmint's agent-checkout flow treats the merchant as an arbitrary third-party target ('buy from any merchant'), not as a Crossmint customer configuring agent access policies.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

   Trusted Agent Protocol gives merchants a way to cryptographically verify agent legitimacy, distinguish credentialed agents from anonymous bots via an agent-registry, and reject stale/replayed signed requests, which supports an allow/deny posture at checkout. However there is no documented merchant-facing control for rate-limiting specific agents or blocking by agent platform/brand — the evidence is about identity verification and anti-bot protection, not policy-based throttling or platform-level allow/deny lists. missing for 10: explicit rate-limiting mechanism, per-platform allow/deny configuration UI or API, documented throttling/quota controls.

   • [github] “By presenting a secure digital signature with every interaction, a merchant can verify that an agent is legitimate and has the user's permis…”
   • [github] “This allows you to confidently welcome agent-driven commerce while protecting your site from harmful bots.”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”

   proof ↗⚑ flag

Order events

1. developerMy agent or backend can subscribe to order lifecycle events — created, updated, fulfilled, canceled — pushed programmatically

   weight 3 · round drawn
   Crossmint—none0/10

   Crossmint's own docs explicitly state agent checkouts have 'no webhooks in v1' and require polling until a terminal state is reached, meaning there is no programmatic push-based subscription to order lifecycle events (created/updated/fulfilled/canceled). No other product area (wallets, cards) documents webhook/event subscription either.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Evidence covers card enrollment, credential/token retrieval, purchase-intent mandates, and Trusted Agent Protocol signing, but no documentation of a webhook or event-subscription API for order lifecycle states (created/updated/fulfilled/canceled) pushed to developer systems — only a vague mention of confirming payment outcomes and triggering post-purchase actions, without any subscription mechanism.

   • [claimed-docs] “Confirm payment outcomes and trigger post-purchase actions in real-time.”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Post purchase status

1. ai-native userMy agent can query the status and tracking of an order it placed, after the purchase

   weight 2 · round to Crossmint
   Crossmint~partialclaimed6/10

   Docs explicitly describe agent checkouts as poll-driven — 'no webhooks in v1... you poll until it reaches a terminal state' — and order intents/rails each carry their own status, so an agent can query order status after purchase via polling. However, this is documented only for the Agent Checkouts flow (not agent cards or wallet payments), lacks any true package/shipment tracking detail, and has no independent or hands-on corroboration beyond first-party docs. Missing for 10: shipment/delivery tracking detail, webhook or push-based status updates, and third-party verification of the polling flow actually working in production.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “An order intent can have multiple rails, each with its own status, credential formats, and verification.”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Visa Intelligent Commerce's documented post-purchase capabilities cover confirming payment outcomes, triggering post-purchase actions, and collecting signals for dispute resolution, but there is no evidence of an API or capability letting an agent query order status or shipment/tracking information after a purchase — that is fulfillment/logistics data outside Visa's payment-rail scope as documented. missing for 10: any order-status/tracking query endpoint, evidence of integration with merchant fulfillment/tracking data, or documentation describing post-purchase order lifecycle visibility for agents.

   • [claimed-docs] “Confirm payment outcomes and trigger post-purchase actions in real-time.”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Delegated credentials

1. ai-native userHand my agent a scoped, limited-use payment credential — amount limits, expiry, merchant restrictions — instead of a raw card number

   weight 3 · round drawn
   Crossmint✓fullprobed9/10

   Crossmint's Agent Cards give agents a one-time card number, expiration, and CVC scoped by an order intent with amount, description, merchant lock, and expiration — never exposing the real card number — enforced via Visa/Mastercard network rails (crossmint-supp-2, crossmint-supp-3, crossmint-supp-8). This is corroborated by a live runtime probe showing the agent-scoped checkout endpoint requiring agent-specific credentials (crossmint-probe-rt-1). Missing for 10: independent third-party (non-vendor) verification of the card-scoping behavior in production beyond the docs and single runtime probe.

   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Credentials are one-time and network-verified: minting returns "the secure one-time card number, expiration, and CVC", and verification is a…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Give agents permission to pay with a user's card using Crossmint's Agentic Payments API.”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed9/10

   Extensive first-party docs describe exactly this: agent-specific pass-through payment tokens, purchase-intent mandates with declineThreshold amount/currency and effectiveUntilTime expiry, and credential retrieval requests scoped to a specific merchantName/merchant descriptor and amount — all gated behind passkey-authenticated user instructions. This directly matches 'scoped, limited-use credential with amount limits, expiry, merchant restrictions instead of raw card number.' missing for 10: independent third-party (non-Visa) hands-on confirmation that these scoped credentials work end-to-end in production rather than sandbox, since the product itself carries a documented maturity caveat.

   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”

   proof ↗⚑ flag

Machine payments

1. developerMonetize an API or service with HTTP 402 machine payments that agents pay per call without a checkout UI

   weight 3 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   All Crossmint evidence describes agents/wallets *paying* x402 or MPP-protected endpoints (client/payer side) — e.g. crossmint-supp-6 and crossmint-supp-5 explain how a Crossmint wallet reads a 402 challenge and retries with payment proof. There is no evidence of tooling for a developer to stand up their own API/service that returns HTTP 402 challenges and receives/settles per-call agent payments (the monetization/merchant side of x402). Missing for 10: any docs or API for creating/serving a 402-gated endpoint, receiving settlement, or configuring per-call pricing as a service provider — evidence only covers the consuming side.

   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “This guide shows how to pay x402-protected endpoints using a Crossmint wallet.”
   • [claimed-docs] “This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet.”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

   Visa's Trusted Agent Protocol spec explicitly describes an HTTP 402 flow where a merchant/service returns a 402 with a 'payment IOU,' and after verifying the signed agent payload, 'the Merchant can grant access with the expectation that the funds will be available when settlement occurs' — a genuine machine-payable, checkout-less mechanism (visa-ic-supp-7, visa-ic-supp-6). However, all documentation and the reference implementation (agent-registry, cdn-proxy, merchant-backend) frame this around e-commerce/merchant checkout rather than generic API/service monetization or per-call billing, and there's no dedicated guide for developers wanting to gate an arbitrary API endpoint this way. Missing for 10: explicit API-monetization framing/tutorial, per-call billing/metering support, and independent/hands-on evidence of the 402 flow being used outside merchant checkout scenarios.

   • [claimed-docs] “TAP's signed Agentic Payment Container adapts to the merchant's rail: for guest-checkout key entry it carries a credential hash — "If the ha…”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [github] “Securely receive key information needed for checkout via query parameters. This can include, as consented by the consumer, verifiable consum…”

   proof ↗⚑ flag

Settlement rails

1. developerSettle agent-initiated payments in stablecoins over documented rails

   weight 2 · round to Crossmint
   Crossmint✓fullprobed8/10

   Crossmint documents stablecoin settlement for agent payments via user-owned wallets with delegated signer permissions (USDXM/USDC), and explicit rails including x402 and MPP protocols with runtime-verified endpoint behavior, giving strong first-party and probe corroboration of documented stablecoin rails. missing for 10: independent (non-vendor) real-world case studies of production stablecoin settlement volume, and confirmation the x402/MPP flows work beyond testnet/Base Sepolia examples.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “This guide shows how to pay x402-protected endpoints using a Crossmint wallet.”
   • [claimed-docs] “This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet.”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   All evidence describes Visa Intelligent Commerce's card-network rails (tokenized cards, network tokens, VisaNet authorization, passkey-anchored mandates) — there is no mention anywhere of stablecoin settlement, crypto rails, or any non-card settlement currency. The axis applies to a payments product but no evidence supports stablecoin settlement specifically.

   • [claimed-docs] “Secure retrieval and management of network tokens, supporting seamless agentic commerce across multiple payment networks.”
   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”

   proof ↗⚑ flag

Wallets

1. ai-native userProvision a wallet my agent holds and spends from — funded and controlled by me, with balance visibility

   weight 3 · round to Crossmint
   Crossmint~partialclaimed7/10

   Crossmint's Agent Wallets docs show a user-owned, non-custodial wallet that a user funds and controls, with the agent authorized as a scoped, revocable delegated signer (spend cap, counterparties, time window) enforced onchain, and a working stablecoin-wallet quickstart (crossmint-docs-3, crossmint-supp-4, crossmint-supp-5). However, the evidence never explicitly documents a balance-visibility feature (e.g., a balance/dashboard API for the funding user) — missing for 10: explicit balance-check/visibility API or UI evidence, independent/hands-on corroboration of the wallet flow.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

   Visa IC lets a consumer enroll/tokenize their card for agent use, set decline-threshold spend limits via mandates, and authenticate/control every agent payment instruction via Passkey — covering 'funded and controlled by me' reasonably well (visa-ic-supp-1, visa-ic-supp-2, visa-ic-supp-3, visa-ic-supp-4). But this is card-linkage/tokenization infrastructure, not a stored-value 'wallet' with its own balance, and there is no evidence of a balance-visibility feature for the end user or agent. Missing for 10: an actual funded wallet construct (vs. tokenized card-on-file), explicit balance-visibility UI/API, and independent confirmation beyond Visa's own docs.

   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Capture consumer consent, set spending limits, and manage mandates for agent-initiated payments.”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Crossmint—none0/10

   No evidence anywhere in the pack mentions data residency, region selection, or storage location controls; Crossmint's docs focus on wallets, payments, and blockchain infra with no data-residency/GDPR-region options mentioned. This is a fair question for a platform handling user data/payments, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   Visa Intelligent Commerce—none0/10

   The evidence pack covers tokenization, consent, mandates, and the Trusted Agent Protocol but contains no mention of data residency, regional storage options, or geographic controls over where consumer/agent data is held. This is a plausible axis for a payments platform (as compliance/residency is common in enterprise payment products), but nothing in the docs, GitHub, or probes addresses it.

   ⚑ flag

Ecosystem adoption

1. developerAt least two independent parties beyond the vendor implement the protocol or platform — it is an ecosystem, not a private integration

   weight 2 · round drawn
   Crossmint—none0/10

   Evidence describes Crossmint as a single-vendor proprietary API/platform (wallets, checkout, agent cards) — even where it interoperates with external protocols like x402 or MPP, those are third-party specs Crossmint merely consumes, not evidence that independent parties implement Crossmint's own protocol/platform. No evidence pack item shows any other company or independent implementer building a competing or parallel implementation of Crossmint's infrastructure.

   ⚑ flag

   Visa Intelligent Commerce—none0/10

   All evidence is first-party Visa documentation, GitHub repos owned by Visa, and Visa's own MCP/agent-toolkit; none names a second independent implementer (merchant platform, other network, AI vendor, etc.) building on the protocol. Community commentary even frames the initiative as still 'premature' with no adoption signals cited, so there's no evidence of an ecosystem beyond the vendor.

   • [community] “The Visa/Mastercard announcements are interesting but feel premature. The missing piece is standardized agent identity and capability declar…”
   • [community] “The Visa/Mastercard moves are interesting but I'd bet the real unlock is when businesses start issuing agent-specific cards with embedded po…”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Trusted Agent Protocol is published in the open — https://raw.githubusercontent.com/visa/trusted-ag…”

   proof ↗⚑ flag

Spec publication

1. developerThe commerce protocol this product speaks is published as an open, versioned specification I can read and implement without signing anything

   weight 3 · round to Visa Intelligent Commerce
   Crossmint—none0/10

   Crossmint documents its own REST/agent APIs (cards, wallets, checkouts) but the evidence shows no open, versioned specification of its own commerce protocol — the OpenAPI/swagger probe returned 404 on all candidate paths, and no spec repository or versioning scheme is mentioned. While Crossmint implements external protocols like x402 and MPP, it does not publish its own commerce protocol as an open spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed5/10

   Visa's Trusted Agent Protocol (TAP) is published openly on GitHub with a runnable reference implementation and keyless README access, satisfying 'read without signing' for that layer (visa-ic-probe-rt-1, visa-ic-supp-9, visa-ic-supp-6). However, the core Intelligent Commerce payment protocol (ACP instructions, tokens, credentials) requires a sandbox sign-up form with terms acceptance and 'Contact Visa for fees in Production' for real use, meaning the actual commerce protocol is gated behind registration/agreements, not a freely implementable open spec (visa-ic-supp-10, visa-ic-supp-8). Missing for 10: a single unified, explicitly versioned spec document covering the full commerce protocol (not just TAP) that can be implemented end-to-end without any sandbox registration or production agreement.

   • [probe] “PROBE runtime (recorded 2026-09-14): the Trusted Agent Protocol is published in the open — https://raw.githubusercontent.com/visa/trusted-ag…”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “Merchant-side onboarding starts with a self-serve "Intelligent Commerce Sandbox Sign up" form (Organization ID, company, contact details, te…”
   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Disputes

1. developerDisputes and chargebacks on agent transactions can be handled via API — evidence submission, status, outcomes

   weight 2 · round drawn
   Crossmint—none0/10

   The only relevant evidence states that Crossmint itself absorbs dispute risk and manages chargebacks directly with the bank on the user's behalf (crossmint-supp-10), which is for the general Checkout product, not agent-specific. There is no documentation of any developer-facing API for submitting dispute evidence, checking dispute status, or retrieving outcomes. Missing for 10: any dispute-management API endpoints, evidence-submission workflow, or status/outcome reporting for agent transactions.

   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Evidence explicitly states Visa's docs stop at collecting 'commerce signals' to aid dispute resolution, not a dedicated dispute/chargeback API with evidence submission, status, or outcome endpoints (visa-ic-supp-8). No other citation shows any dispute-specific API surface.

   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”

   proof ↗⚑ flag

Refunds

1. developerRefunds on agent-placed orders can be initiated and tracked programmatically

   weight 2 · round drawn
   Crossmint—none0/10

   Evidence covers dispute/chargeback risk absorption for general card Checkout (crossmint-supp-10), but this describes Crossmint handling bank disputes, not a developer-facing refund API for initiating/tracking refunds on agent-placed orders. No refund endpoint, refund object, or tracking mechanism is documented anywhere for Agent Cards, Agent Wallets, or Agent Checkouts. Missing for 10: any refund API/endpoint, refund status tracking, and agent-order-specific refund workflow documentation.

   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Evidence explicitly states Visa Intelligent Commerce docs 'stop at evidence capture, not a dispute API' — there's only an optional 'policies.refundPolicy' metadata field attached to a credential request and generic 'commerce signals' for dispute resolution, not a programmatic refund initiation/tracking endpoint or status API for agent-placed orders.

   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”

   proof ↗⚑ flag

Agent identity

1. merchantAgents identify themselves verifiably — registered profiles, signatures, or trust tiers — so I can tell trusted agent traffic from anonymous bots

   weight 3 · round to Visa Intelligent Commerce
   Crossmint~partialprobed5/10

   Crossmint's agent stack does embed verifiable-identity mechanisms — onchain delegated signer keys with scoped, revocable permissions (crossmint-supp-4), card-network verified 'Agent Cards' secured by Visa VIC/Mastercard Agent Pay (crossmint-supp-1, -3), and a distinct 'ServerKeyAgent' credential type confirmed live at the Agent Checkouts endpoint (crossmint-probe-rt-1). These give merchants some cryptographic/network-level basis to distinguish agent-initiated, permissioned transactions from anonymous traffic. However, there is no documented merchant-facing registry, trust-tier system, or API for merchants to look up/verify an agent's identity or reputation directly — the verification lives inside Crossmint/card-network infrastructure rather than being exposed as a merchant-consumable signal. Missing for 10: an explicit merchant-facing agent identity/reputation lookup or trust-tier classification, and independent confirmation that merchants can actually distinguish trust levels using this data.

   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “Credentials are one-time and network-verified: minting returns "the secure one-time card number, expiration, and CVC", and verification is a…”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed8/10

   Visa's Trusted Agent Protocol gives merchants a concrete verifiable-identity mechanism: RFC9421 HTTP message signatures tagged 'agent-browser-auth'/'agent-payer-auth', anti-replay nonces/timestamps, verification against Visa's public JWKS, and an open reference implementation that includes an 'agent-registry' component explicitly described as letting merchants 'instantly distinguish a legitimate, credentialed agent from an anonymous bot' and confirm it acts on behalf of an authenticated user. This is corroborated by a runtime probe showing the spec and reference repo are live and publicly accessible, going beyond marketing copy. Missing for 10: independent/production adoption evidence beyond Visa's own repo and probes, and clearer merchant-facing tooling for classifying agents into explicit 'trust tiers' rather than a binary signed/unsigned check.

   • [github] “By presenting a secure digital signature with every interaction, a merchant can verify that an agent is legitimate and has the user's permis…”
   • [github] “This allows you to confidently welcome agent-driven commerce while protecting your site from harmful bots.”
   • [claimed-docs] “including the cryptographic standards (RFC9421), required message signature fields, and the process for validating an agent's intent.”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “TAP's signed Agentic Payment Container adapts to the merchant's rail: for guest-checkout key entry it carries a credential hash — "If the ha…”
   • [claimed-docs] “The TAP spec is public with a runnable reference implementation: "Establishing a universal standard of trust between AI agents and merchants…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Trusted Agent Protocol is published in the open — https://raw.githubusercontent.com/visa/trusted-ag…”

   proof ↗⚑ flag

Human oversight

1. ai-native userSensitive agent spending requires my documented approval — a confirmation step, signed mandate, or per-purchase consent — before money moves

   weight 3 · round to Visa Intelligent Commerce
   Crossmint~partialclaimed6/10

   Crossmint documents strong pre-authorized consent mechanisms — user-signed onchain delegation with spend caps, counterparties, and time windows, plus order-intent 'agent cards' with fixed allowances and expiration — enforced without a per-purchase prompt, and revocable at any time. However, the story asks for documented approval INCLUDING per-purchase consent or signed mandate at time of spend, and Crossmint's model explicitly favors upfront scoped delegation with 'no user prompt per action' rather than a per-transaction confirmation step; this is a deliberate design tradeoff, not a failure, so it's partial rather than disputed. missing for 10: evidence of an optional per-purchase confirmation/step-up flow, independent/hands-on verification of the delegation and revocation actually working in production, and clarity on how disputes/approval work for agent checkouts specifically (dispute coverage is only confirmed for general checkout, not agent checkouts).

   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed8/10

   Visa Intelligent Commerce documents passkey-anchored authentication of payment instructions, per-purchase mandates with declineThreshold caps and consumerPrompt confirmation text, credential requests scoped to specific merchant/amount, and a Trusted Agent Protocol signature scheme validating agent intent before authorization — collectively a documented consent/mandate flow gating money movement. missing for 10: independent hands-on verification that the consent/mandate flow works end-to-end in production (product still carries a 'in process of development and deployment' caveat) and no third-party audit of the passkey step-up UX.

   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “"Your agents can enroll a customer's card for tokenization during the customer's account registration or when the customer begins a new purc…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”
   • [claimed-docs] “Controls to ensure that the agent’s purchasing actions and the related authorizations align with the user’s authenticated instruction”
   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”

   proof ↗⚑ flag

Liability

1. merchantThe fraud, liability, and chargeback rules for agent-initiated transactions are documented so I know who bears the risk

   weight 2 · round to Crossmint
   Crossmint~partialclaimed4/10

   Crossmint documents dispute handling for its general Checkout product (Crossmint absorbs card dispute risk via authorization holds, per crossmint-supp-10) and describes spend caps/order-intent controls for agent cards and wallets, but explicitly notes this chargeback/liability coverage is not specific to agent-initiated transactions. There is no dedicated documentation defining fraud/liability/chargeback allocation rules for agent checkouts or agent-card/agent-wallet flows. missing for 10: explicit agent-transaction-specific liability/chargeback policy, merchant-facing dispute-resolution terms for agent checkouts, and clarity on who bears risk when an agent-initiated purchase is fraudulent or disputed.

   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed3/10

   Docs describe extensive fraud-prevention plumbing (passkey authentication, mandates, TAP signatures) but the only mention of chargebacks/disputes explicitly stops at 'commerce signals... allow for quick resolution of most disputes' rather than a documented liability-shift or chargeback-allocation policy, and explicitly notes there is no dispute API. Missing for 10: explicit statement of who bears fraud/chargeback liability (merchant vs. issuer vs. cardholder) for agent-initiated transactions, documented dispute resolution process/API, and any liability-shift terms analogous to EMV rules.

   • [claimed-docs] “Fees, verbatim from FEES & TERMS: "Free to use in Sandbox. Contact Visa for fees in Production." On refunds/disputes the docs stop at eviden…”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “The Trusted Agent Protocol's agent recognition signature is HTTP Message Signatures "defined by RCF 9421" (typo in original), "aligned with …”

   proof ↗⚑ flag

Spend controls

1. ai-native userSet per-agent spend caps and usage limits and revoke an agent's payment authority instantly

   weight 2 · round to Crossmint
   Crossmint✓fullprobed8/10

   Crossmint documents onchain-enforced per-agent spend caps, allowed counterparties, and time windows for agent wallets, plus order-intent allowances with amount/expiration for agent cards, and explicitly states permissions are revocable at any time by the user. This is corroborated by detailed docs on delegation mechanics and a runtime probe confirming agent-scoped auth is live in production. Missing for 10: independent (non-vendor) confirmation that revocation is instantaneous in practice, and no evidence of a unified dashboard/UI for setting caps or revoking across all three agent products (cards, wallets, checkouts) in one place.

   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed7/10

   Docs show concrete mandate mechanics — declineThreshold spend caps, effectiveUntilTime, and a documented 'cancel a purchase intent' revocation path — plus passkey-gated instruction authentication and per-request credential scoping to merchant/amount, which together implement caps and a revocation-like control. However, evidence covers per-purchase-intent caps/cancellation rather than a persistent 'agent-wide spend cap + instant kill-switch' dashboard, and the product itself is flagged as still 'in the process of development and deployment.' Missing for 10: consumer-facing UI/API for setting ongoing per-agent usage limits (not just per-transaction mandates), explicit 'revoke all future authority instantly' mechanism beyond canceling a single intent, and independent/hands-on confirmation of revocation latency.

   • [claimed-docs] “Spend caps live in the purchase-intent mandate: Initiate a Purchase Intent (POST /acp/v1/instructions) exists "to verify that your agent is …”
   • [claimed-docs] “Human approval is passkey-anchored end to end: provisioning includes "step up verification of the cardholder as well as setting up a Passkey…”
   • [claimed-docs] “Agent-scoped credentials are the core primitive: "Provisioning and life cycle management of agent-specific payment tokens that can be used b…”
   • [claimed-docs] “Credentials are scoped to an authenticated instruction: retrieval is POST /acp/v1/instructions/{instructionID}/credentials, and the request …”
   • [claimed-docs] “Capture consumer consent, set spending limits, and manage mandates for agent-initiated payments.”

   proof ↗⚑ flag