Visa Intelligent Commerce vs Skyfire

Cart

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

   weight 3 · round to Visa Intelligent Commerce
   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

   Skyfire—none0/10

   Skyfire's documented protocol (tokens, kya/pay/kya-pay, MCP tools like find-sellers/create-*-token) covers identity verification and payment authorization/settlement, but there is no documented call for creating or updating a cart or order draft — order/cart state is left to the seller's own system, not exposed via Skyfire's API or MCP server.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”

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

   Skyfire✓fullprobed8/10

   Skyfire documents the full agent-checkout loop: MCP tools let an agent discover sellers, create kya/pay/kya-pay tokens (delegated payment+identity credential), and sellers charge the token post-delivery with funds moved between wallets, completing a confirmed order/settlement. missing for 10: independent/hands-on end-to-end transaction proof (evidence is vendor docs plus a narrow auth-only runtime probe, not a full live purchase trace) and no example of an explicit 'confirmed order' object/receipt returned to the buyer.

   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Sellers can use a `kya-pay` token to enable a guest checkout experience for buyer agents.”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”

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

   Skyfire—none0/10

   Skyfire's evidence documents a generic agent-to-agent payment/identity protocol (tokens, MCP server for 'find-sellers' and token creation) but nowhere mentions ChatGPT, Claude, Gemini, Copilot or any named chat/assistant surface, nor any commerce-in-chat integration or app-store listing. The MCP server is a generic protocol endpoint, not documented evidence of embedding within these specific consumer assistant surfaces.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”

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

   Skyfire~partialprobed4/10

   Skyfire points to an external 'open' KYAPay protocol (KYAPay.org) with JWT-based tokens that all Skyfire tokens conform to, giving a nominal published spec, but the evidence pack shows no OpenAPI/schema file for Skyfire's own API (all standard OpenAPI paths 404) and no conformance/validation tooling (test suites, schema validators, certification) is documented anywhere. Missing for 10: a published machine-readable schema for the Skyfire API itself, explicit protocol versioning, and any conformance/validation tooling a developer could run against.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”

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

   Skyfire~partialclaimed6/10

   Skyfire's MCP server exposes a 'find-sellers' tool that lets an agent query for payable services/sellers programmatically, and sellers register services through an approval-gated catalog, giving agents a discovery mechanism (skyfire-docs-6, skyfire-supp-9, skyfire-docs-3). However, there's no evidence of a publicly browsable directory/index outside the MCP tool call, nor documentation of how the directory is structured, filtered, or how comprehensive/curated it is. Missing for 10: a documented public directory/catalog UI or API endpoint separate from the MCP tool, details on search/filter capabilities, and independent confirmation of discovery breadth.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Visa Intelligent Commerce
   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

   Skyfire✓fullprobed8/10

   Skyfire's docs site serves a working llms.txt (HTTP 200, agent-oriented summary) confirmed by both a probe and a runtime check, and its full docs are structured as agent-consumable markdown (.md endpoints throughout). This directly satisfies pointing an agent at llms.txt/agent-oriented docs. Missing for 10: no independent third-party report of an agent successfully consuming llms.txt end-to-end, and no OpenAPI spec (all candidate paths 404) which would further strengthen machine-readability.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.skyfire.xyz/llms.txt # Skyfire Developer Portal Documentation > Skyfire is the open identity and p…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Skyfire~partialprobed6/10

   Skyfire is API-first: agents authenticate via scoped API keys (no interactive login) and all core operations (token creation, introspection, charging) are REST endpoints, confirmed live and key-gated by a runtime probe, plus an MCP server for programmatic agent workflows. However, there's no explicit CI/CD example, headless setup guide, or CLI/SDK documentation showing automation-pipeline usage. missing for 10: explicit CI/headless usage guide, CLI or SDK tooling, and independent confirmation of non-interactive automation beyond API-key auth.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Skyfire
   Visa Intelligent Commerce✓fullprobed7/10

   Visa explicitly ships an official MCP server (visaacceptance/agent-toolkit, published on npm as @visaacceptance/mcp) that lets developers/agents connect to Visa Intelligent Commerce APIs for payment-enabled operations like invoices and payment links, corroborated by a runtime probe confirming the npm package exists with Visa-staff maintainers. Missing for 10: independent hands-on usage reports/reviews of the MCP server beyond Visa's own announcement and npm registry check, and more detail on the full tool surface exposed via MCP.

   • [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] “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://…”

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

   Skyfire documents an official hosted MCP server (https://mcp.skyfire.xyz/mcp, plus sandbox) with documented tools (find-sellers, create-kya-token, create-pay-token, create-kya-payment-token) and auth via API key header, letting agents connect and execute commerce workflows. missing for 10: independent/third-party corroboration of the MCP server working in practice, and no public OpenAPI/schema for deeper verification.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Visa Intelligent Commerce—none0/10

   Evidence shows an MCP server and an npm-published 'agent-toolkit' with tool bindings, but nothing describes an official CLI binary or command-line interface for AI-native users to interact with Visa Intelligent Commerce.

   • [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://…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Skyfire's docs describe REST APIs, MCP server integration, and a dashboard/Playground, but no evidence pack item mentions an official CLI tool for developers or agents. Missing for 10: any documented CLI binary, npm/pip package, or command-line reference.

   ⚑ flag

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

   weight 3 · round drawn
   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

   Skyfire✓fullprobed8/10

   Skyfire ships a documented public REST API (tokens, introspect, charge-token) gated by per-agent API keys, confirmed live via runtime probe returning a structured auth error rather than a 404, plus llms.txt-served docs. Missing for 10: a published OpenAPI/swagger spec (probe found all candidate spec URLs 404) and independent third-party corroboration beyond vendor docs/probes.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.skyfire.xyz/llms.txt # Skyfire Developer Portal Documentation > Skyfire is the open identity and p…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”

   proof ↗⚑ flag

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

   weight 2 · round to Visa Intelligent Commerce
   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

   Skyfire~partialclaimed6/10

   Skyfire API keys are scoped per-agent (Buyer/Seller) and pay tokens carry committed amounts with hard balance ceilings, and KYA-gated tokens enforce identity requirements, which together give agent-level least-privilege credentials. However, this is scoped to payment/identity tokens rather than granular API permission scopes (e.g., no fine-grained action/resource-level scoping or role-based permission sets), and there is no documented per-token revocation API. missing for 10: fine-grained permission/action scoping beyond agent+amount+identity, documented revocation controls, independent/hands-on verification of scoping enforcement.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Visa Intelligent Commerce
   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

   Skyfire—none0/10

   Evidence shows Skyfire has REST API reference docs, a Playground, and an MCP server for agent integration, but nowhere does it mention or link to an official language SDK (e.g., Python/JS client library). The openapi.json probe even returned 404, undermining any inference of auto-generated SDK tooling.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   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

   Skyfire—none0/10

   Evidence covers token issuance, charging, MCP tools, and identity verification, but nowhere mentions webhooks or any event subscription/callback mechanism for developers to receive notifications. Missing for 10: any webhook endpoint registration, event types, or push-notification documentation.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   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

   Skyfire~partialclaimed5/10

   Skyfire's MCP server lets an agent autonomously discover sellers, mint kya/pay tokens, and execute commerce transactions without human-in-the-loop approval up to committed token limits (skyfire-docs-6, skyfire-supp-9, skyfire-supp-4), which supports autonomous background operation for agent commerce specifically. But Skyfire is a payment/identity layer, not a general automation/orchestration platform — there's no documented scheduler, trigger system, or persistent background-job mechanism for setting up broader autonomous workflows beyond commerce transactions. missing for 10: evidence of a scheduling/trigger system, persistent background job execution beyond per-call MCP invocations, and support for non-commerce automation tasks.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Skyfire~partialclaimed6/10

   Skyfire ships an MCP server exposing tools (find-sellers, create-kya-token, create-pay-token, create-kya-payment-token) that let an LLM-driven agent translate natural-language requests into commerce actions like discovering sellers and issuing/charging tokens, which is the standard mechanism for natural-language operation in agentic products. Missing for 10: no evidence of a first-party conversational interface, no examples of actual natural-language prompts mapped to tool calls, and no independent/hands-on confirmation of NL-driven usage beyond the docs.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   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

   Skyfire—none0/10

   The evidence shows Skyfire has structured reference docs (charge-token, introspect-token, etc.) but the openapi probe found no machine-readable spec (404s on all candidate paths), and there is no mention of an interactive console, 'try it' feature, or runnable code examples anywhere in the pack — only static markdown-style API reference pages.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”

   proof ↗⚑ flag

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

   weight 2 · round to Visa Intelligent Commerce
   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

   Skyfire—none0/10

   The docs contain structured API reference pages (e.g., charge-token, introspect-token) suggesting an underlying spec, but a direct probe for machine-readable OpenAPI/Swagger files at all standard locations returned 404 for every candidate path, and no evidence shows a downloadable spec file or link.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”

   proof ↗⚑ flag

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

   weight 1 · round to Visa Intelligent Commerce
   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

   Skyfire~partialclaimed5/10

   The MCP server docs explicitly reference a separate sandbox endpoint (mcp-sandbox.skyfire.xyz) distinct from the production mcp.skyfire.xyz, showing a dedicated test environment exists. However, there's no broader documentation of a sandbox for the core token/payment APIs, wallets, or KYA flows outside the MCP context, and no detail on how sandbox data is isolated from production. Missing for 10: dedicated sandbox docs for REST/token APIs beyond MCP, explicit guidance on test credentials/test wallets, independent confirmation the sandbox fully mirrors production without touching real funds.

   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

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

   weight 2 · round to Visa Intelligent Commerce
   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

   Skyfire—none0/10

   While the API path shows a v1 prefix (skyfire-probe-rt-1) and an OpenAPI spec probe returned 404s (skyfire-probe-2), there is no documentation of a versioning scheme, deprecation timeline, or migration policy anywhere in the evidence pack. Missing for 10: any deprecation policy page, versioning changelog, or migration guide.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Skyfire—none0/10

   Skyfire's documented API is single-item/token-centric (create one token, charge one token, introspect one token) with no documented batch or bulk endpoints for processing many items in one call. No evidence of any bulk-operation capability across tokens, sellers, or charges.

   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”

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

   Skyfire—none0/10

   Evidence shows sellers set their own service pricing when configuring a service, but there is no published fee schedule for Skyfire's own transaction/take-rate fees on agent-originated payments — nothing lets a merchant price agentic channels without contacting sales.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

Payouts

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

   weight 1 · round to Skyfire
   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

   Skyfire~partialclaimed5/10

   Skyfire documents the settlement mechanics merchants need — charge-token API, committed/ceiling amounts, multi-charge until balance exhausted, defined settlement windows (up to 51 hours), and overcharge rejection (402) — which supports reconciliation of individual transactions. However, there is no documented merchant-facing payout flow (e.g., withdrawal to bank/external accounts), no statement/reporting/export API, and no mention of standard accounting artifacts (invoices, ledgers, CSV/webhook reporting) that would let a merchant reconcile against other channels. missing for 10: documented payout/withdrawal mechanism to real-world funds, merchant reporting/statement or export API, reconciliation tooling or ledger export, independent confirmation of reporting flows.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”

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

   Skyfire~partialclaimed5/10

   Skyfire ties every transaction to a specific Buyer Agent via KYA identity tokens and per-agent API keys, so orders are technically attributable to the originating agent (skyfire-docs-1, skyfire-supp-2, skyfire-supp-7), and introspect/charge-token APIs let a seller programmatically check token/agent status (skyfire-docs-4, skyfire-docs-5). However, there is no evidence of a merchant-facing report or dashboard view that lets a merchant filter/aggregate transactions by agent — only a general 'Agent Dashboard' for key management is mentioned. Missing for 10: documented merchant reporting/analytics UI or API for filtering transactions by agent, evidence of aggregate order-to-agent attribution reporting.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”

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

   Skyfire~partialclaimed7/10

   Skyfire documents a concrete merchant-facing path: create a Seller Agent, generate a scoped API key, click 'Create Service' with pricing/identity requirements, and use the Charge Token API to collect payment — all via the Agent Dashboard (skyfire-docs-3, skyfire-supp-8, skyfire-docs-4). However, service creation is explicitly 'Submit for approval,' meaning it's gated rather than a pure self-serve flip-a-switch flow. Missing for 10: confirmation of approval turnaround/criteria, an explicit merchant agreement/ToS signing step, and independent verification that the approval process is lightweight rather than a manual sales gate.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

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

   Skyfire~partialclaimed4/10

   Skyfire lets sellers set per-service identity requirements (KYA verification levels) that gate token creation and thus checkout access, and its payment-card flow lets a merchant's bot manager identify and allow known agents rather than block them — giving coarse allow/deny-by-identity control. However there is no documented rate-limiting feature, no explicit deny-list or per-agent/platform blocking mechanism, and no console for merchants to enumerate specific agents/platforms to throttle or reject. Missing for 10: rate-limiting controls, explicit allow/deny list management UI/API, granular per-agent-platform policy enforcement beyond identity-level gating.

   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “The site, or the bot manager in front of it, can then identify the agent/agent platform and allow it through rather than block it.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

1. ai-native userRead the product's source under an open license

   weight 2 · round to Visa Intelligent Commerce
   Visa Intelligent Commerce~partialprobed4/10

   Visa Intelligent Commerce itself (the core enrollment/token/mandate platform) is a closed, proprietary financial service with no source release, but the related Trusted Agent Protocol spec and reference implementation, plus the agent-toolkit, are published openly on GitHub with a runnable sample ecosystem (agent-registry, cdn-proxy, merchant-backend, tap-agent). This only covers peripheral protocol/toolkit components, not the core Intelligent Commerce platform's own source. Missing for 10: an explicit open-source license grant for the core Intelligent Commerce platform itself, not just the TAP spec/toolkit sidecars.

   • [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…”
   • [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…”
   • [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

   Skyfire—none0/10

   Evidence shows Skyfire is a closed, key-gated commercial API/platform (identity+payments infrastructure) with only a published token spec (KYAPay) being open, not the product's own source code; no repo, license, or open-source claim appears anywhere in the pack.

   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”

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

   Skyfire—none0/10

   Skyfire's docs cover token creation, charging, and introspection (pull-based checks), but there is no evidence of any webhook, event subscription, or push notification mechanism for order lifecycle events (created/updated/fulfilled/canceled). Developers must poll introspect-token rather than subscribe to pushed events.

   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”

   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 to Visa Intelligent Commerce
   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

   Skyfire✓fullclaimed8/10

   Skyfire issues scoped pay/kya-pay tokens with committed amount ceilings, expiry windows (10s-24h plus grace period), and merchant/identity-requirement gating rather than raw card numbers, all documented via API and MCP server tooling. Missing for 10: independent third-party/hands-on corroboration beyond vendor docs, and explicit merchant-restriction scoping details (evidence shows identity/amount/time limits clearly but merchant-lock-in specifics are thinner).

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

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

   Skyfire~partialclaimed7/10

   Skyfire lets sellers register a service, gate access with kya/pay tokens, and charge per call via the Charge Token API after delivery — with no checkout UI, matching most of the story's intent, and the docs explicitly note overcharges are rejected with an HTTP 402 PAYMENT_ERROR. However, the evidence shows Skyfire's core mechanism is its own token/JWT (KYAPay) issuance-and-charge flow rather than a standard HTTP 402 challenge-response loop as the primary payment protocol. Missing for 10: explicit documentation that HTTP 402 is used as the initial payment-required response/handshake (not just an overcharge error code), and independent confirmation of the 402-based flow in production use.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Settlement rails

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

   weight 2 · round to Skyfire
   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

   Skyfire~partialclaimed3/10

   Skyfire documents thorough payment settlement rails — wallets, pay/kya-pay tokens, committed amounts, charge-token API, settlement timing windows, and open KYAPay token spec — but none of the evidence explicitly states that settlement occurs in stablecoins or names any specific blockchain/stablecoin rail. Missing for 10: explicit stablecoin currency mention, underlying blockchain/rail specification, and confirmation that wallet balances/settlement are denominated in a stablecoin rather than fiat/credit abstraction.

   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”
   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”

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

   Skyfire✓fullclaimed7/10

   Docs describe a Buyer Agent wallet auto-created and pre-funded on signup, scoped per-agent via API keys that the user controls, with committed-amount enforcement against the wallet balance and an introspect-token API to check remaining balance. This covers user-provisioned/funded/controlled wallet plus balance visibility, but missing for 10: dashboard UI screenshots showing balance, explicit mechanism for manually topping up/funding beyond initial pre-fund, and independent/hands-on corroboration.

   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Visa Intelligent Commerce—none0/10

   Visa Intelligent Commerce documents consent capture, mandates, spend caps, and even cancellation of a purchase intent, but none of the evidence addresses a user's ability to control data retention periods or request deletion of stored consumer data, tokens, or consent records. Revocation of a 'purchase intent' (visa-ic-supp-3) is a transactional control, not a data-retention/deletion mechanism, so the specific privacy-posture story is unaddressed.

   • [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] “Capture consumer consent, set spending limits, and manage mandates for agent-initiated payments.”
   • [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…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Skyfire's docs describe identity verification (KYA), token issuance/expiry, and payment settlement, but nothing in the evidence pack addresses user-controlled data retention policies or deletion of stored identity/verification/payment data. Given Skyfire handles real-world identity data via KYA, this is a fair privacy axis to expect, but no retention or deletion controls are documented.

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

   Skyfire—none0/10

   Skyfire claims tokens conform to an 'open KYAPay protocol' hosted at KYAPay.org, but every operational piece — charging, wallets, settlement, MCP server, verification — runs exclusively through Skyfire's own APIs and infrastructure per the evidence pack. There is no mention of any independent vendor, competitor, or third party implementing the protocol or running their own compatible service/settlement layer.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

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

   Skyfire~partialprobed4/10

   Skyfire claims tokens conform to "the open KYAPay protocol, an industry specification for identity-linked payment credentials" (referencing KYAPay.org), suggesting a published spec exists, but the evidence pack itself notes that charging, wallets, and settlement all run through Skyfire's own gated APIs, and every other capability (creating tokens, MCP server, seller services) requires an API key and account signup — no evidence of a version number, a standalone spec document, or an implementation path that doesn't require signing up with Skyfire. missing for 10: a link to a versioned KYAPay spec document, confirmation it can be implemented independently of Skyfire's account/API-key system, and independent corroboration of the spec's openness.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

Disputes

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

   weight 2 · round drawn
   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

   Skyfire—none0/10

   The evidence pack documents token creation, charging, introspection, settlement timing, and revocation limits, but nowhere describes a dispute or chargeback mechanism — no evidence-submission endpoint, dispute status API, or outcome reporting is mentioned. Payment guarantees are described as ceiling-bound token commitments rather than a dispute-resolution workflow, so this applicable axis has no supporting evidence.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”

   proof ↗⚑ flag

Refunds

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

   weight 2 · round drawn
   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

   Skyfire—none0/10

   The evidence pack covers token creation, charging, settlement, and revocation bounds in detail, but nowhere documents a refund API, refund initiation flow, or refund status/tracking endpoint. Since Skyfire is a payments platform, refunds are a plausible feature, but no evidence of programmatic refund support exists — missing for 10: any refund/dispute API reference, refund status tracking, or documented refund workflow.

   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”

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

   Skyfire✓fullclaimed8/10

   Skyfire's KYA/KYA-Pay tokens give merchants a verifiable, signed identity credential (JWT) per agent, with optional real-world identity attachment and hard gating ('token creation fails and the transaction does not proceed' if verification level is insufficient), plus per-agent scoped API keys and a documented merchant/bot-manager flow to identify and admit agent traffic instead of blocking it. This directly addresses distinguishing trusted, verified agent traffic from anonymous bots via a signature-based, tiered identity system. Missing for 10: independent/third-party corroboration of real-world merchant adoption or trust-tier enforcement outside Skyfire's own docs, and no public API schema (openapi probes 404) to verify signature/verification details externally.

   • [claimed-docs] “Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agent…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “The site, or the bot manager in front of it, can then identify the agent/agent platform and allow it through rather than block it.”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

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

   Skyfire~partialclaimed5/10

   Skyfire's pay/kya-pay tokens are signed JWT 'mandates' that commit a specific spending ceiling at creation time, and that ceiling is a hard cap enforced by the buyer's wallet balance and cardholder consent ('agent can never spend more than the cardholder approved'), giving a documented, auditable authorization trail per token. However, the evidence shows token creation is an agent/API-driven action, not a human-facing confirmation prompt or explicit per-purchase human sign-off — there's no documented UI step where a person approves each individual transaction before it fires, only the pre-set balance/identity gating. Missing for 10: an explicit human-in-the-loop confirmation/approval UI or workflow per purchase, and documentation of configurable spend policies beyond wallet pre-funding and KYA identity requirements.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”

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

   Skyfire~partialclaimed6/10

   Skyfire's docs explicitly allocate payment risk: sellers are guaranteed payment up to a token's committed amount and 'do not carry buyer non-payment risk' (skyfire-supp-4), overcharges are rejected, and even after account deactivation in-flight tokens are still honored so sellers get paid (skyfire-supp-6). Card-based flows also state the agent can never exceed cardholder-approved amounts and purchases are never anonymous to the merchant (skyfire-supp-7). However, there is no dedicated chargeback/dispute-resolution policy, no explicit statement of who bears fraud losses when credentials are stolen or a buyer disputes via their bank, and no formal merchant-facing liability/ToS document. Missing for 10: explicit chargeback/dispute process, stolen-credential fraud liability terms, formal merchant liability agreement or ToS reference.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”

   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 Visa Intelligent Commerce
   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

   Skyfire~partialclaimed4/10

   Skyfire supports per-agent scoping and spend caps: keys are scoped to a single agent, and pay tokens carry a committed amount ceiling that bounds spend and rejects overcharges. However, the docs explicitly state there is no per-token revocation API and that deactivating an account does not void already-issued tokens — in-flight tokens remain chargeable until expiry plus a 24-hour grace window — directly contradicting 'instant' revocation of payment authority. missing for 10: a documented instant per-agent/per-token revocation mechanism, independent or hands-on confirmation of revocation behavior, and granular usage-limit controls beyond token amount/expiry.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

   proof ↗⚑ flag