Stripe Agentic Commerce vs Visa Intelligent Commerce

Cart

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialclaimed7/10

   Stripe's ACP-style custom checkout documents an explicit reverse-API contract where sellers implement create/update/confirm endpoints and sessions move through documented statuses (incomplete | ready_for_payment | requires_escalation | processing | completed | canceled), directly matching cart/order-draft creation and update via a documented protocol call; the embedded OCA flow also covers 'cart management' end-to-end. However this is gated behind private preview, US-only availability, and a waitlist, with no independent/hands-on evidence of a successful cart-update call in the pack. Missing for 10: independent/hands-on verification of a live create/update call succeeding, and confirmation the feature is generally available rather than waitlisted preview.

   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed6/10

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

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

   proof ↗⚑ flag

Checkout

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

   weight 3 · round drawn
   Stripe Agentic Commerce✓fullprobed8/10

   Stripe documents the full end-to-end agent checkout: sellers publish catalogs via ACS, agents complete checkout via ACP/UCP or embedded flows, shared payment tokens serve as delegated payment credentials with scoped usage limits, and completion is confirmed via checkout.session.completed events with agent attribution; runtime probes confirm the MCP server, Link CLI, and MPP infra are live. missing for 10: independent hands-on end-to-end purchase report (community evidence is speculative/skeptical, not a confirmed successful transaction), and several flows (ACS custom checkout, OCA embedding) remain private-preview/waitlisted rather than generally available.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases.”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Embedded surfaces

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

   weight 2 · round drawn
   Stripe Agentic Commerce~partialclaimed5/10

   Stripe's ACP/ACS clearly enables in-chat browsing and checkout, with concrete evidence tied to ChatGPT (OpenAI co-developed ACP, 'first AI platform to implement ACP with ChatGPT', and merchant onboarding/CSV catalog/checkout-session flows), plus SPT tokenization and human-approval gates. However, evidence names only ChatGPT as a live surface — there is no documentation or proof of live integration with Claude, Gemini, or Copilot — and the embedded/agent-as-intermediary checkout mode is explicitly gated as 'private preview' and limited to 'US, Canada, and select European countries,' with ChatGPT participation requiring an application rather than being open by default. Community threads raise trust/incentive concerns but don't concretely contradict that checkout works for ChatGPT. missing for 10: evidence of live checkout support in Claude/Gemini/Copilot, and proof the private-preview gating has lifted to general availability.

   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”
   • [claimed-docs] “"ACP is open source and community-designed under the Apache 2.0 license. Businesses can implement the specification to transact with any AI …”
   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed5/10

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

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

   proof ↗⚑ flag

Protocol conformance

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialprobed6/10

   Stripe documents an open, community-governed protocol (ACP, Apache 2.0, published spec at agenticcommerce.dev) and, for the sibling Machine Payments Protocol, an explicit conformance CLI ('mppx validate' tests discovery, challenge formats, error handling, and the full payment flow) plus a public spec site (mpp.dev) confirmed live by probe. However, there's no evidence of a formally versioned schema (e.g., semver, changelog) for ACP itself, no OpenAPI/JSON schema found (probe explicitly 404s for openapi.json/swagger.json), and no ACP-specific validator analogous to mppx validate — conformance tooling is documented only for MPP, not the core commerce checkout protocol. missing for 10: versioned ACP schema/spec artifact, ACP-specific conformance/validation tool, published machine-readable OpenAPI schema.

   • [claimed-docs] “"ACP is open source and community-designed under the Apache 2.0 license. Businesses can implement the specification to transact with any AI …”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

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

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

   proof ↗⚑ flag

Service discovery

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed7/10

   Stripe publishes a live, machine-readable discovery surface: the 'Stripe Directory' explicitly helps 'developers and AI agents find the best external providers for a task and follow the best supported path to provision or use them' (docs-13), backed by a probed live well-known skills/services index (stripe-ac-probe-rt-3) and the open mpp.dev spec index for machine-payable APIs (stripe-ac-probe-rt-2), plus per-endpoint discovery via HTTP 402 challenges (docs-9/18/19). Missing for 10: concrete evidence that the Directory itself indexes specifically 'payable' services/APIs (vs. general providers) and an end-to-end example of an agent using the directory to find and pay for a service.

   • [claimed-docs] “Stripe Directory helps developers and AI agents find the best external providers for a task and follow the best supported path to provision …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the machine-readable skills catalog is live at the documented keyless well-known URL — https://docs.str…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [claimed-docs] “x402 is a protocol for internet payments... your server returns an HTTP 402 response with payment details, including a Stripe deposit addres…”
   • [claimed-docs] “Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed5/10

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

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

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   Stripe Agentic Commerce✓fullprobed9/10

   Stripe confirms a live llms.txt (HTTP 200 probe) and extensive agent-oriented markdown docs (.md endpoints, skills.json well-known catalog, MCP server, link-cli --llms-full), all directly consumable by an agent pointed at these URLs. missing for 10: independent third-party confirmation that agents actually consume/parse these files effectively in the wild beyond Stripe's own probes.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/agentic-commerce.md # Agentic commerce Sell through agents, or embed commerce into your …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the machine-readable skills catalog is live at the documented keyless well-known URL — https://docs.str…”
   • [claimed-docs] “Install instructions that help AI agents create more accurate Stripe integrations.”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Visa Intelligent Commerce
   Stripe Agentic Commerce~partialclaimed5/10

   Stripe ships CLI/API primitives that could run headlessly — anonymous CI sandbox creation via `stripe sandbox create` (no account registration), an `mppx validate` conformance CLI for automated end-to-end testing of MPP integrations, and REST/MCP APIs that are inherently non-interactive. However, the core agentic-commerce and Link CLI wallet flows are explicitly gated by mandatory human approval ("Stripe requires human confirmation before it takes certain stripe_api_write actions"; "Customers approve each request on the Link website or in the mobile app"), which blocks fully unattended CI automation of actual payment execution. Missing for 10: explicit CI/pipeline documentation or examples, a documented way to bypass/automate the human-approval step for testing, and evidence of headless operation for the core checkout/SPT flows rather than just sandbox/dev tooling.

   • [claimed-docs] “Coding agents should install the Stripe CLI (npm i -g @stripe/cli) and run the command stripe sandbox create --help to provision an anonymou…”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed6/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed9/10

   Stripe documents and runtime-verifies a first-party hosted MCP server (mcp.stripe.com) with clear auth (OAuth 401 challenge observed live) and documented tools for AI agents to interact with the Stripe API, plus human-approval gating for sensitive actions. This is corroborated by both docs and a runtime probe confirming the endpoint is live and gated exactly as documented. Missing for 10: independent third-party (non-Stripe) hands-on report of connecting an agent to the MCP server in production use.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed8/10

   Stripe ships the official Link CLI (@stripe/link-cli, published on npm and confirmed live in a runtime probe, v0.19.2) for agent wallet access, plus the Stripe CLI for sandbox provisioning and mppx CLI for MPP conformance testing, all documented and agent-legible (--llms-full docs). missing for 10: no independent/community hands-on review of the CLI's usability, and multiple overlapping CLIs (stripe, link-cli, mppx) rather than one unified official CLI.

   • [claimed-docs] “Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to comple…”
   • [github] “The CLI can produce one of three credential types: A virtual card (PAN)... A Link Pay Token (LPT)... A Shared Payment Token (SPT)”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [probe] “official CLI documented at https://docs.stripe.com/agentic-commerce/link-cli”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”
   • [claimed-docs] “Coding agents should install the Stripe CLI (npm i -g @stripe/cli) and run the command stripe sandbox create --help to provision an anonymou…”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed9/10

   Stripe publishes extensive, concrete public API documentation for agentic commerce — ACS seller/agent endpoints, shared payment tokens, machine payments (MPP/x402), a hosted MCP server, and a CLI — all with runtime-verified live endpoints (401-gated MCP server, live mppx package, live skills.json, live link-cli npm package), giving AI-native users clear documented ways to drive the product programmatically. Missing for 10: a discoverable formal OpenAPI/swagger schema (probe-3 shows all candidate spec URLs 404) and independent third-party hands-on API integration reports beyond Stripe's own docs.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the machine-readable skills catalog is live at the documented keyless well-known URL — https://docs.str…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”
   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “"Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullclaimed8/10

   Stripe documents Restricted API Keys (RAKs) as 'the recommended type of key for API keys you give to AI agents' with granular permission scoping, plus scoped Shared Payment Tokens with currency/amount/expiration limits and revocation, and MCP server actions gated by human approval tokens — together giving strong least-privilege credentialing for agents. missing for 10: independent/hands-on verification of RAK permission granularity in practice, and no evidence of automated credential rotation or audit-logging specifics for agent-issued keys.

   • [claimed-docs] “RAKs are the recommended type of key for API keys you give to AI agents.”
   • [claimed-docs] “Stripe recommends always using RAKs instead of unrestricted secret keys, especially when giving a key to an AI agent. Use RAK permissions to…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “Coding agents should install the Stripe CLI (npm i -g @stripe/cli) and run the command stripe sandbox create --help to provision an anonymou…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialcommunity7/10

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

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

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed9/10

   Stripe ships extensive official SDK/CLI/protocol tooling for AI-native builders: a hosted MCP server (docs + runtime probe confirming live OAuth-gated endpoint), Link CLI published on npm with runtime verification, agent skills catalog served at a well-known JSON endpoint, restricted API keys guidance for agents, MPP/x402 machine-payment protocols with open spec and mppx conformance CLI, and one-prompt agent build flows. This is corroborated by independent runtime probes (npm resolution, live endpoint checks), not just vendor docs. missing for 10: no independent third-party developer testimonial/case study of building against these SDKs (only Stripe-run runtime probes and docs), and ACP/MCP write actions still require human approval gating rather than fully autonomous agent operation.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
   • [claimed-docs] “Install instructions that help AI agents create more accurate Stripe integrations.”
   • [claimed-docs] “RAKs are the recommended type of key for API keys you give to AI agents.”
   • [claimed-docs] “Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to comple…”
   • [github] “The CLI can produce one of three credential types: A virtual card (PAN)... A Link Pay Token (LPT)... A Shared Payment Token (SPT)”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the machine-readable skills catalog is live at the documented keyless well-known URL — https://docs.str…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed8/10

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

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullclaimed8/10

   Multiple agentic-commerce flows emit dedicated webhooks that a developer/agent-builder can subscribe to: order completion (`checkout.session.completed` tagged with agent), catalog import status (`v2.commerce.product_catalog.imports.*`), OCA embedded checkout completion (`delegated_checkout.requested_session.completed`), and SPT state transitions (`shared_payment.issued_token.used`, etc.), all part of Stripe's standard event/webhook infrastructure applied to agentic commerce. Missing for 10: explicit doc snippet on creating/registering a webhook endpoint for these events and independent hands-on confirmation of subscription setup.

   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialclaimed4/10

   Evidence shows narrow instances of AI-generated insight/suggestion from user data — buyers get 'personalized recommendations' during chat commerce, and the Link CLI wallet lets an agent 'retrieve permissioned financial data to answer questions about spending, balances, and trends' (e.g., 'What did I spend on dining this month?'). This is real but thin — it's a side feature of a payments/commerce infra product, not a dedicated insights/analytics capability with elaboration or hands-on validation. Missing for 10: dedicated in-product analytics/insights surface beyond brief doc mentions, detail on recommendation quality/methodology, and independent corroboration that these insight features work as described.

   • [claimed-docs] “Buyers can browse products, get personalized recommendations, and complete purchases without leaving the conversation.”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [claimed-docs] “retrieve permissioned financial data to answer questions about spending, balances, and trends.”
   • [claimed-docs] ““What did I spend on dining this month?””

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

   Visa Intelligent Commerce's evidence is entirely about enabling agent-initiated payments (tokens, mandates, passkeys, credential scoping, trusted agent protocol) — there is no mention of surfacing AI-generated insights or suggestions derived from a user's data within the product. While a payments platform could plausibly offer spending insights, none are documented here.

   ⚑ flag

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

   weight 2 · round drawn
   Stripe Agentic Commerce~partialclaimed5/10

   Machine payments (x402, MPP) let agents transact programmatically without a human in the loop for each call, and SPTs allow scoped, usage-limited autonomous spending — supporting some background automation. However, the same evidence pack documents pervasive human-approval gates for higher-value or write actions ('Stripe requires human confirmation before it takes certain stripe_api_write actions' and 'Customers approve each request on the Link website or in the mobile app'), which directly limits true unattended background autonomy for most commerce flows. Missing for 10: a documented persistent/scheduled automation or workflow feature that runs entirely without any human approval step across the product's full scope, and independent evidence of such automations running successfully unattended.

   • [claimed-docs] “"Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid…”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Agentic Commerce~partialprobed6/10

   Stripe's agentic-commerce stack is built around natural-language-driven flows: buyers can browse, get recommendations, and 'complete purchases without leaving the conversation,' Link CLI supports natural queries like 'Buy me this book from Stripe Press' and 'What did I spend on dining this month?', and the MCP server/skills let AI agents interact with the API conversationally. However, this is fundamentally an API/protocol/SDK product for developers and agent-builders, not an end-user interface itself — the 'natural language' surface is provided by the calling LLM/agent (ChatGPT, etc.), and most interactions (SPT issuance, key management, catalog feeds, checkout hooks) are structured API/CLI calls rather than NL commands to Stripe itself. Missing for 10: evidence of Stripe's own product surface directly accepting free-form natural-language commands (as opposed to relying on a third-party agent/LLM to translate NL into API calls), and independent hands-on confirmation that the documented NL examples work end-to-end in production rather than as illustrative docs snippets.

   • [claimed-docs] “Buyers can browse products, get personalized recommendations, and complete purchases without leaving the conversation.”
   • [claimed-docs] ““Buy me this book from Stripe Press””
   • [claimed-docs] ““What did I spend on dining this month?””
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
   • [claimed-docs] “Install instructions that help AI agents create more accurate Stripe integrations.”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed6/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialprobed4/10

   Evidence shows agent-facing tooling that lets an AI actually exercise the API — a sandbox CLI that provisions working keys ("stripe sandbox create --help"), an MCP server exposing callable API tools, and a machine-readable skills/llms.txt catalog — but nothing in the pack describes a classic interactive API reference page with inline runnable code examples; the docs are plain markdown (per the .md probes) and the openapi.json/swagger.json spec paths all 404. missing for 10: a documented interactive reference UI (e.g. try-it/run-in-browser code samples), an OpenAPI/Swagger spec for the agentic-commerce endpoints, independent confirmation that examples execute against live data.

   • [claimed-docs] “Coding agents should install the Stripe CLI (npm i -g @stripe/cli) and run the command stripe sandbox create --help to provision an anonymou…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the machine-readable skills catalog is live at the documented keyless well-known URL — https://docs.str…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/agentic-commerce.md # Agentic commerce Sell through agents, or embed commerce into your …”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

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

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

   The evidence pack shows a direct probe for an OpenAPI/Swagger spec at all standard locations (openapi.json, swagger.json, etc.) returning 404 across the board, and no other citation surfaces a downloadable machine-readable API spec for the Agentic Commerce endpoints. While Stripe ships llms.txt, a skills.json index, and an MCP server, none of these constitute a downloadable OpenAPI/equivalent spec for the story as written.

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

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed6/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round to Visa Intelligent Commerce
   Stripe Agentic Commerce✓fullclaimed7/10

   Stripe explicitly documents a sandbox provisioning flow for coding agents: 'run stripe sandbox create --help to provision an anonymous Stripe sandbox with working API keys. No account registration required,' which directly satisfies testing without touching production data. Missing for 10: independent/hands-on confirmation that agentic-commerce-specific flows (ACS, SPTs, machine payments) work in this sandbox, and documentation on how test-mode agent transactions differ from production before going live.

   • [claimed-docs] “Coding agents should install the Stripe CLI (npm i -g @stripe/cli) and run the command stripe sandbox create --help to provision an anonymou…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

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

   The evidence pack covers extensive agentic-commerce features (SPTs, MCP, MPP, Link CLI, ACP) but contains no documentation of API version strings, an upgrade/versioning scheme, or a deprecation policy for these agentic-commerce endpoints — several features are explicitly flagged as 'private preview' or waitlisted rather than versioned/stable, but no deprecation policy is cited anywhere.

   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialclaimed5/10

   Stripe provides some bulk-like primitives — sellers can upload a whole product catalog via CSV feed (up to 4GB) and 'bulk fulfill orders' via the List CheckoutSessions endpoint — but these are seller-side backend operations, not an AI-native user-facing bulk operation across many purchases/items in one agent action. There's no evidence of an agent being able to, e.g., issue one command to buy/refund/manage many items or transactions at once as an end-user capability. missing for 10: agent-facing bulk purchase/checkout across many items in one call, bulk SPT/token operations, batch API endpoints exposed to AI agents beyond seller catalog upload and fulfillment listing, independent hands-on confirmation of bulk agent workflows.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

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

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

   Evidence shows Stripe emits webhooks (checkout.session.completed, SPT state-transition events, import success/failure events) that developers can build on, but there is no documented feature letting an AI-native user define custom rules/conditions that automatically trigger actions on events — in fact, agent write-actions via MCP explicitly require human approval before execution, the opposite of automatic rule-triggered action.

   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

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

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

   proof ↗⚑ flag

Fees transparency

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullcommunity7/10

   Stripe explicitly publishes the flat card-processing rates (2.9%+30¢ domestic, plus documented adders for manual entry/international/currency conversion) and states these standard rates are what agent-originated orders inherit, with 'no separate agentic-channel fee schedule disclosed' — meaning a merchant can price ACS-driven sales from the public pricing page without a sales call. Missing for 10: no dedicated line-item fee schedule specifically labeled for agent/ACS transactions (only an inference that standard rates apply), and no clarity on whether third-party platform fees (e.g., ChatGPT's own merchant commission referenced in community discussion) stack on top for ACP-routed orders.

   • [claimed-docs] “stripe.com/pricing publishes the flat rates that agent-driven orders inherit, with no separate agentic-channel fee schedule disclosed: Stand…”
   • [community] “"Merchants pay a small fee on completed purchases, but the service is free for users, doesn't affect their prices, and doesn't influence Cha…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Payouts

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

   weight 1 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullclaimed8/10

   Agent-originated orders flow through standard Stripe primitives - checkout.session.completed events, Dashboard transaction tagging/filtering by agent, an agent_details field, bulk fulfillment, and standard Refunds API - with pricing docs confirming no separate agentic fee schedule and machine payments explicitly stating settlement/reporting 'work the same as any other payment in Stripe'. missing for 10: independent/third-party confirmation that reconciliation works in practice, and removal of the 'Private preview' gate on agent_details

   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “"Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid…”
   • [claimed-docs] “stripe.com/pricing publishes the flat rates that agent-driven orders inherit, with no separate agentic-channel fee schedule disclosed: Stand…”
   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed4/10

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

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

   proof ↗⚑ flag

Attribution analytics

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullclaimed8/10

   Stripe's seller docs explicitly state that agent-driven orders generate a unique checkout.session.completed event, appear on the Dashboard Transactions page 'tagged with the originating agent,' and merchants 'can filter transactions by agent names,' with a documented agent_details field and bulk-fulfillment support via the CheckoutSessions API. Missing for 10: independent/hands-on confirmation of the attribution UI in practice, and the agent_details field is noted as Private preview rather than GA.

   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed4/10

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

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

   proof ↗⚑ flag

Onboarding to agents

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

   weight 3 · round drawn
   Stripe Agentic Commerce~partialclaimed7/10

   Stripe documents a genuine self-serve merchant path: onboard as a seller in the Dashboard, review and accept per-agent terms, publish a CSV product catalog via presigned-URL API, and receive human-approval-gated agent orders tagged in the Transactions page. However this is explicitly gated - Agentic Commerce Suite is private preview and restricted to US, Canada, and select European countries, and the custom ACP-style integration explicitly requires joining a waitlist rather than pure self-serve enablement. Missing for 10: evidence of unrestricted GA availability outside private preview, and a self-serve (non-waitlist) path for the custom checkout-endpoint integration.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”
   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed7/10

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

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

   proof ↗⚑ flag

Traffic controls

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

   weight 2 · round drawn
   Stripe Agentic Commerce~partialclaimed5/10

   Merchants get agent-level allow/deny control via OCA consent ("Find the agent you want to sell through and review its terms", approval requests, and either party can terminate an OCA at any time) plus per-agent order attribution/filtering in the Dashboard, but there is no documented rate-limiting mechanism for specific agents or platforms. missing for 10: explicit per-agent or per-platform rate-limit/throttling controls, granular allow/deny at the platform (vs individual agent) level, and any dashboard UI for setting quotas.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Agentic Commerce~partialprobed4/10

   The core Agentic Commerce Suite (checkout backend, SPT infrastructure, MCP server) is proprietary Stripe infrastructure with no published source, but the Agentic Commerce Protocol is explicitly 'open source and community-designed under the Apache 2.0 license,' and the Link CLI client has a public GitHub repo (stripe/link-cli). This gives an AI-native user real, licensed source to read for parts of the ecosystem, but not for the product's core commerce/payment engine. Missing for 10: open-licensed source for the actual ACS backend/checkout service, MCP server implementation, and MPP/x402 server-side code — only the protocol spec and a thin CLI client are open.

   • [claimed-docs] “"ACP is open source and community-designed under the Apache 2.0 license. Businesses can implement the specification to transact with any AI …”
   • [github] “The CLI can produce one of three credential types: A virtual card (PAN)... A Link Pay Token (LPT)... A Shared Payment Token (SPT)”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”

   proof ↗⚑ flag

   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

Order events

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialclaimed5/10

   Stripe documents at least one lifecycle push event for agent orders — checkout.session.completed fires when an agent completes an order, tagged with agent attribution and filterable in the Dashboard — plus a delegated_checkout.requested_session.completed webhook for embedded checkout completion, and separate webhooks exist for catalog-import and SPT-token state changes. However, there is no documented event set covering the full requested lifecycle (created, updated, fulfilled, canceled) for orders themselves; canceled/fulfilled-specific webhooks aren't shown, and bulk fulfillment is presented as a pull (List CheckoutSessions) rather than a push mechanism. Missing for 10: explicit order.created/updated/canceled webhook events, a documented order-events reference, and independent/hands-on confirmation of subscription reliability.

   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Post purchase status

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

   weight 2 · round drawn
   Stripe Agentic Commerce—none0/10

   Evidence covers checkout completion, order attribution in the Stripe Dashboard, and bulk fulfillment tools for sellers, but nothing shows an agent being able to query order status or shipping/tracking information after a purchase is placed — no order-status API, webhook, or tool is documented for the agent side post-purchase.

   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Delegated credentials

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

   weight 3 · round to Visa Intelligent Commerce
   Stripe Agentic Commerce✓fullprobed8/10

   Stripe ships exactly this: Shared Payment Tokens grant sellers scoped access with explicit usage_limits (currency, max_amount, expires_at), merchant/seller scoping, and revocation, and Link CLI issues one-time-use virtual cards/LPTs/SPTs to agents rather than raw PANs, with human approval gates on spend. This is corroborated by docs, GitHub source, and live npm/runtime probes. missing for 10: independent hands-on third-party audit of the credential-scoping mechanics (only vendor docs + probes, no external security review), and broader geographic/GA availability (features are private preview / US-Canada-EU only).

   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [github] “The CLI can produce one of three credential types: A virtual card (PAN)... A Link Pay Token (LPT)... A Shared Payment Token (SPT)”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [claimed-docs] “Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to comple…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Machine payments

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed9/10

   Stripe explicitly documents HTTP 402 machine payments (x402 and MPP) letting agents pay per API call with no checkout UI, backed by a runtime probe confirming the MPP spec and mppx SDK are live, plus a conformance CLI (mppx validate) and one-prompt build path. missing for 10: independent/hands-on developer report of a working 402 integration beyond Stripe's own docs and probes.

   • [claimed-docs] “Machine payments let agents pay for APIs and services programmatically.”
   • [claimed-docs] “x402 is a protocol for internet payments... your server returns an HTTP 402 response with payment details, including a Stripe deposit addres…”
   • [claimed-docs] “"Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid…”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

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

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

   proof ↗⚑ flag

Settlement rails

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialprobed6/10

   Stripe explicitly documents stablecoin-denominated agent payments over documented rails (MPP on Tempo/USDC.e and Solana/USDC, x402 on Base/USDC) with published minimums (0.01 USDC) and geographic scope, and a runtime probe confirms the MPP spec and mppx SDK are live. However, the same docs state payments 'settle in fiat' into the Stripe balance rather than being settled to the developer in stablecoins, so the 'settle in stablecoins' half of the story is not actually delivered — it's stablecoin-denominated payment collection with fiat settlement. Missing for 10: actual stablecoin-denominated settlement (not fiat conversion), independent/hands-on developer corroboration beyond Stripe's own docs.

   • [claimed-docs] “"Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid…”
   • [claimed-docs] “x402 is a protocol for internet payments... your server returns an HTTP 402 response with payment details, including a Stripe deposit addres…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [claimed-docs] “You can build an API that uses MPP with a single prompt to your coding agent”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Wallets

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed8/10

   Link CLI documents a customer-controlled wallet from which the agent retrieves one-time-use payment credentials, with balance/transaction visibility ('reads transaction history, balances, and account details') and human approval on every spend via the Link app/website, and is confirmed live on npm by runtime probe. missing for 10: independent/hands-on user reports of actually funding and using the wallet end-to-end (only vendor docs and a package-registry probe, no third-party usage account).

   • [claimed-docs] “Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to comple…”
   • [claimed-docs] “Your agent reads transaction history, balances, and account details from connected bank accounts and credit cards.”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [github] “The CLI can produce one of three credential types: A virtual card (PAN)... A Link Pay Token (LPT)... A Shared Payment Token (SPT)”
   • [github] “A virtual card (PAN) for use with a standard web checkout form. The issued card works anywhere, and is not restricted to Link-enabled seller…”
   • [claimed-docs] “Customers approve each request on the Link website or in the mobile app.”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed5/10

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

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

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Agentic Commerce—none0/10

   The evidence pack covers token/authorization revocation (SPT revocation, OCA termination) and human-approval gates for payment actions, but nothing about user-controlled data retention policies, data export, or deletion of stored personal/transaction data. Privacy-posture around retention/deletion is a fair question for a payments platform handling PII and financial data, but no documentation addresses it.

   ⚑ flag

   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

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 to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialprobed6/10

   Stripe documents ACP as "open source and community-designed under the Apache 2.0 license" co-developed with OpenAI (who implemented it in ChatGPT as "the first AI platform"), and MPP as an open protocol "co-authored by Stripe and Tempo," with x402/network-token integrations naming Mastercard's Agent Pay and Visa's Intelligent Commerce as third-party implementers. Independent runtime probes confirm mpp.dev is a separate, non-Stripe-branded spec site with governance and SDK on public npm, supporting genuine multi-party involvement rather than a private integration. Missing for 10: independent (non-Stripe-authored) case studies or hands-on reports of a third seller/agent platform beyond OpenAI/Tempo actually running the protocol in production, and clearer separation of protocol governance from Stripe's own docs.

   • [claimed-docs] “"ACP is open source and community-designed under the Apache 2.0 license. Businesses can implement the specification to transact with any AI …”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Spec publication

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

   weight 3 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce✓fullprobed8/10

   Stripe explicitly documents that the Agentic Commerce Protocol (ACP) it speaks is "open source and community-designed under the Apache 2.0 license" and that "businesses can implement the specification to transact with any AI agent or payment processor" with no signup required to read or implement it — only optional ChatGPT marketplace participation needs an application, which is a separate distribution channel, not the spec itself. This is corroborated by similar open-protocol framing for MPP ("an open protocol... co-authored by Stripe and Tempo", live spec at mpp.dev) and x402, and a runtime probe confirms the MPP spec is publicly fetchable without auth. Missing for 10: explicit version-numbering/changelog evidence for the spec, and independent (non-Stripe) confirmation that implementers never need a signed agreement to build against the published spec.

   • [claimed-docs] “"ACP is open source and community-designed under the Apache 2.0 license. Businesses can implement the specification to transact with any AI …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Machine Payments Protocol is published in the open — https://mpp.dev/ answers a plain GET with the …”
   • [claimed-docs] “MPP "is an open protocol that lets agents pay for your APIs and services programmatically without a checkout UI, co-authored by Stripe and T…”
   • [claimed-docs] “x402 is a protocol for internet payments... your server returns an HTTP 402 response with payment details, including a Stripe deposit addres…”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialprobed5/10

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

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

   proof ↗⚑ flag

Disputes

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

   weight 2 · round drawn
   Stripe Agentic Commerce—none0/10

   The evidence pack documents refunds via the standard Refunds API/Dashboard for machine payments, and general agent-approval workflows for actions like refunds, but contains no mention of a disputes/chargebacks API, evidence submission, dispute status tracking, or outcome reporting for agent-initiated transactions specifically.

   ⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Refunds

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

   weight 2 · round to Stripe Agentic Commerce
   Stripe Agentic Commerce~partialclaimed5/10

   Evidence shows refunds are available through Stripe's standard Refunds API/Dashboard (inherited by agent-driven orders) and that the Stripe MCP server explicitly supports refunds as a stripe_api_write action, gated by human approval before an agent can execute or retry it. However, there's no agent-specific refund tracking mechanism (e.g., dedicated refund status webhooks tied to agent_details, or refund reporting in the agent-tagged Transactions view) beyond the standard Stripe rails. Missing for 10: dedicated refund tracking/webhooks scoped to agent orders, explicit API examples for programmatic refund initiation on SPT-based orders, and independent/hands-on confirmation of the refund flow working end-to-end.

   • [claimed-docs] “"Machine payments let agents pay for APIs and services programmatically. Your server returns a payment challenge, the agent presents a valid…”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”

   proof ↗⚑ flag

   Visa Intelligent Commerce—none0/10

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

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

   proof ↗⚑ flag

Agent identity

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

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

   Stripe's ACS onboarding shows a real per-agent registration/approval flow ('review its terms' and 'send the agent an approval request that the agent must accept') and an OCA connection that both parties must confirm before commerce flows, plus order-level attribution ('tagged with the originating agent', filterable by agent name) and scoped, revocable SPT grants — all of which let a merchant distinguish known, approved agents from anonymous traffic. However there is no documented cryptographic signature scheme, public agent identity registry, or explicit trust-tier/reputation system merchants can query independently of the approval workflow. Missing for 10: cryptographic agent signatures/verifiable credentials, a public or queryable trust-tier/reputation system, and independent (non-vendor) evidence that merchants can reliably detect spoofed or unregistered agent traffic.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “RAKs are the recommended type of key for API keys you give to AI agents.”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullprobed8/10

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

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

   proof ↗⚑ flag

Human oversight

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

   weight 3 · round drawn
   Stripe Agentic Commerce✓fullprobed8/10

   Stripe documents multiple concrete consent gates before money moves: MCP requires explicit human 'Approve' confirmation with an approval token before write actions like refunds/outbound payments (expiring in 24h), Link CLI requires the customer to 'approve each request on the Link website or in the mobile app' before releasing one-time-use credentials, and Shared Payment Tokens carry issuer-set usage_limits (currency, max_amount, expiration) plus revocation and a documented state machine with webhooks. Runtime probes corroborate the MCP OAuth-gated approval flow and the live Link CLI package. missing for 10: independent/hands-on evidence of the approval UX actually blocking a real transaction end-to-end (only docs/runtime probes, no third-party test), and no evidence of a 'signed mandate' artifact akin to AP2's cryptographic mandates.

   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Stripe's hosted MCP server is live and gated exactly as documented — a keyless JSON-RPC initialize POST…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Link CLI — the agent-wallet client documented for retrieving one-time-use payment credentials and p…”
   • [claimed-docs] “Customers approve each request on the Link website or in the mobile app.”

   proof ↗⚑ flag

   Visa Intelligent Commerce✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Liability

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

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

   The evidence pack covers SPT scoping/revocation, checkout session lifecycle, human-approval gates for refunds, and network Agent Pay/Intelligent Commerce token programs, but nowhere states explicit fraud-liability or chargeback-allocation rules (e.g., who bears loss on a disputed agent-initiated charge, liability-shift terms, or chargeback responsibility between merchant/agent/Stripe). This is a fair question for a payments platform (trust-safety axis clearly applies), but no documentation in the pack addresses it.

   ⚑ flag

   Visa Intelligent Commerce~partialclaimed3/10

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

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

   proof ↗⚑ flag

Spend controls

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

   weight 2 · round drawn
   Stripe Agentic Commerce~partialclaimed7/10

   Shared Payment Tokens explicitly support per-token usage_limits (currency, max_amount, expiration) and can be revoked at any time so sellers can't use them ('Sellers can't create a payment with a revoked SPT'), and Restricted API Keys (RAKs) let a developer scope what an agent's key can do, while MCP write actions require human approval tokens that expire in 24h. However, these are per-token/per-key controls rather than a single unified 'per-agent' spend-cap dashboard, and there's no evidence of one-click instant revocation of an agent's entire payment authority across all rails (card, machine payments, x402, Link wallet) at once. missing for 10: a unified per-agent spend-cap/limit management UI or API (vs. per-SPT/per-key limits), evidence of instantly revoking ALL of an agent's payment methods/authority in one action, and independent/hands-on confirmation that revocation works as documented in production.

   • [claimed-docs] “"Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases." The issuing agent mu…”
   • [claimed-docs] “RAKs are the recommended type of key for API keys you give to AI agents.”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “Shared payment tokens (SPTs) grant sellers scoped access to customers’ payment methods for agent-initiated purchases.”

   proof ↗⚑ flag

   Visa Intelligent Commerce~partialclaimed7/10

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

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

   proof ↗⚑ flag