[ { "productId": "coinbase-x402", "storyId": "agent-cart-create", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "x402 documents per-request HTTP 402 payment flows (quote price, sign payment, verify, settle) but nothing in the evidence describes a cart or order-draft object that an agent can create/update via a protocol call — the protocol is stateless pay-per-request, not cart/order management, and even the 'merchant checkout' integration mention (doc-13) only says agents can 'authorize payment sessions,' not manage draft orders. Missing for 10: any documented cart/order object, create/update API or protocol verbs, and evidence of persisted order state across calls.", "evidenceIds": [ "coinbase-x402-docs-13", "coinbase-x402-supp-1" ] }, { "productId": "coinbase-x402", "storyId": "agent-catalog-search", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "The x402 Bazaar provides a public, keyless discovery API and MCP-tool-call interface for agents to search payable services across merchants without any partnership or API key, and a live runtime probe confirms the keyless GET returned real payable-service listings exactly as documented. Docs also detail self-service alternative (CDP API key) and automatic listing without registration, and community sources corroborate agents using x402 to discover/pay for services without prior accounts. Missing for 10: independent third-party evaluation of discovery relevance/quality beyond Coinbase's own docs and the single runtime probe.", "evidenceIds": [ "coinbase-x402-docs-5", "coinbase-x402-docs-6", "coinbase-x402-docs-14", "coinbase-x402-supp-5", "coinbase-x402-supp-6", "coinbase-x402-probe-rt-1", "coinbase-x402-comm-6" ] }, { "productId": "coinbase-x402", "storyId": "agent-checkout-complete", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs describe a complete flow — an agent hitting a 402 response, resolving payment terms, signing with an agentic wallet/account (delegated credential), the CDP Facilitator verifying and settling onchain, and the resource server returning the confirmed resource — and probes confirm the discovery and facilitator endpoints behave live as documented. However this is a per-request HTTP payment handshake rather than a traditional multi-step 'checkout session', and there is no independent/hands-on trace of an agent completing a full purchase (discovery→credential→confirmed order) end-to-end; community commentary even flags unresolved trust gaps in confirming delivered work post-payment. Missing for 10: independent third-party demonstration of a full agent purchase transcript, and clarity on session-like continuity versus single-request settlement.", "evidenceIds": [ "coinbase-x402-supp-1", "coinbase-x402-supp-7", "coinbase-x402-supp-5", "coinbase-x402-docs-11", "coinbase-x402-probe-rt-1", "coinbase-x402-probe-rt-2", "coinbase-x402-comm-10" ] }, { "productId": "coinbase-x402", "storyId": "agent-fraud-liability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers OFAC/KYT screening for sanctioned addresses and onchain settlement finality, but nowhere documents fraud liability allocation, chargeback rules, or who bears risk for disputed/unauthorized agent-initiated transactions. Community comments even flag unresolved 'verify work was done' and settlement trust problems, but no merchant-facing liability/dispute-resolution policy is cited.", "evidenceIds": [ "coinbase-x402-docs-7", "coinbase-x402-comm-10" ] }, { "productId": "coinbase-x402", "storyId": "agent-identity-tiers", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "x402 verifies and screens the *payment* (signed payment proof, OFAC/KYT checks on wallet addresses) but has no mechanism for merchants to identify or tier *agents* themselves — no registered agent profiles, agent-level signatures/identity credentials, or trust tiers are described; the protocol is explicitly designed for signup-free, pseudonymous access ('No signups or approvals required'), the opposite of verifiable agent identity.", "evidenceIds": [ "coinbase-x402-docs-17", "coinbase-x402-supp-3", "coinbase-x402-docs-7" ] }, { "productId": "coinbase-x402", "storyId": "agent-order-attribution", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers payment settlement, discovery (Bazaar), wallets, screening, and fees, but nowhere describes agent-identity attribution on orders or a merchant-facing report/filter-by-agent capability. No dashboard, transaction log, or agent-ID field is documented.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agent-order-tracking", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol for machine-to-machine per-request payments (HTTP 402 flow, facilitator settlement, discovery of payable services); it has no concept of 'orders' with post-purchase status/tracking like an e-commerce fulfillment system. Order lifecycle tracking is a category mismatch for a payment-rail protocol, so this axis does not apply.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agent-traffic-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows built-in OFAC/KYT screening for sanctioned addresses and general facilitator validation, but nothing about merchants configuring per-agent or per-platform allow/deny lists or rate limits. Access control in the docs is limited to compliance screening, not merchant-defined agent-level policies.", "evidenceIds": [ "coinbase-x402-docs-7", "coinbase-x402-supp-3" ] }, { "productId": "coinbase-x402", "storyId": "agent-wallet-provisioning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Coinbase's Agentic Accounts docs explicitly describe giving an agent a CDP wallet that holds USDC and pays for x402 services, and note the account is user/organization-controlled via a Coinbase account or wallet — directly matching the 'agent holds/spends' and 'user-controlled' parts of the story. However, there is no documentation describing an explicit funding flow or a balance-visibility dashboard/API for monitoring the agent's wallet spend, which is a core part of the story. missing for 10: explicit funding mechanism for the agent wallet, balance/spend visibility UI or API for the controlling user.", "evidenceIds": [ "coinbase-x402-docs-11", "coinbase-x402-supp-7" ] }, { "productId": "coinbase-x402", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Probes confirm a live llms.txt at docs.cdp.coinbase.com/llms.txt (200) and per-page .md docs (e.g. x402/welcome.md) that explicitly point agents to the llms.txt index, plus docs explicitly describe agent/MCP-oriented discovery flows. missing for 10: no independent third-party report of an agent actually consuming llms.txt to complete a task, and no OpenAPI spec (404s) as a complementary machine-readable format.", "evidenceIds": [ "coinbase-x402-probe-1", "coinbase-x402-probe-2", "coinbase-x402-docs-14", "coinbase-x402-supp-5" ] }, { "productId": "coinbase-x402", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a machine-to-machine payment protocol/infrastructure for gating and settling API payments, not a data product with a UI that surfaces AI-generated insights or suggestions from user data; none of the evidence describes such a feature, and this axis is a category mismatch for this kind of product.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "x402 enables agent wallets to autonomously discover and pay for services mid-task (agentic accounts, Bazaar discovery, MCP tool-call discovery, batch settlement for high-frequency loops), which supports background autonomous payment automations, but the product itself is a payment protocol/infrastructure layer, not a scheduler or automation orchestrator — there's no evidence of triggers, cron-like scheduling, or persistent background task management outside of payment transactions. missing for 10: evidence of actual task/workflow scheduling or orchestration beyond payment execution, independent hands-on validation of autonomous background operation over time, and details on error handling/retry logic for unattended long-running agent loops.", "evidenceIds": [ "coinbase-x402-docs-11", "coinbase-x402-docs-14", "coinbase-x402-docs-15", "coinbase-x402-docs-16", "coinbase-x402-supp-7", "coinbase-x402-supp-10", "coinbase-x402-supp-5" ] }, { "productId": "coinbase-x402", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Coinbase x402 is a payment protocol/infrastructure layer that lets AI agents pay for services via HTTP 402 — it is not itself an AI assistant or agent product with a built-in assistant persona to delegate tasks to. The evidence describes agentic *buyers* using x402 to pay, not a built-in assistant shipped by x402 itself, so this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "x402 is an HTTP-based payment protocol designed to be invoked programmatically by servers/agents (e.g., 'agent purchasing a tool call mid-task', SDK-based integration, MCP tool-call discovery), which implies it can run in automated/headless contexts like CI, but there is no explicit evidence of a CLI, CI pipeline example, or headless automation harness/test suite. missing for 10: explicit CI/headless automation examples, a documented CLI, non-interactive test/dev workflow guidance, and independent confirmation of running x402 flows unattended in build pipelines.", "evidenceIds": [ "coinbase-x402-docs-15", "coinbase-x402-docs-17", "coinbase-x402-docs-14", "coinbase-x402-docs-11", "coinbase-x402-supp-7" ] }, { "productId": "coinbase-x402", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol/infrastructure layer, not an agent or client application that consumes tools; the evidence shows x402 exposing a Bazaar MCP server for *other* agents to call into (the reverse role), not x402 itself acting as an MCP client that plugs in external MCP servers to gain new tool capabilities. This axis is a category error for a payment-rail product.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly describe an official 'Bazaar MCP server' letting MCP-compatible agents discover payment-gated x402 services via tool calls, which is a genuine first-party MCP server integration for the agentic discovery flow. However, the MCP server appears scoped to discovery only (finding payable resources), not the full pay/settle transaction flow, and there's no independent/hands-on corroboration of the MCP server itself (only docs mention it). Missing for 10: evidence that payment execution (not just discovery) can be driven through the MCP server, and independent/community verification of the MCP server working end-to-end.", "evidenceIds": [ "coinbase-x402-docs-14", "coinbase-x402-supp-5", "coinbase-x402-supp-6" ] }, { "productId": "coinbase-x402", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a machine-to-machine HTTP payment protocol/SDK consumed by servers and agents via code, headers, and API calls — it has no end-user interface for issuing natural-language commands to 'operate' it. This axis is a category error for a protocol/infrastructure product rather than an interactive assistant or application.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions an official CLI tool for x402; the documentation focuses on SDKs, facilitator APIs, MCP integration, and discovery, but nothing describes a CLI product. missing for 10: any mention of an x402 CLI, its commands, or install instructions.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "x402 exposes a documented HTTP-based protocol (402 flow, discovery APIs, facilitator endpoints) that AI agents can drive programmatically, with runtime probes confirming the discovery endpoint is live and keyless and the facilitator auth-gates as documented. However this is a payment/discovery protocol, not a general product API — there's no OpenAPI spec (probe-3 shows 404s across candidate paths), and full programmatic control (e.g., managing wallets, settlement, compliance rules) still routes through CDP SDKs rather than a single unified public API surface. missing for 10: a formal OpenAPI/swagger spec, independent hands-on confirmation of the full request/pay/retry loop beyond discovery, and evidence of broader API coverage beyond payments/discovery.", "evidenceIds": [ "coinbase-x402-docs-1", "coinbase-x402-docs-6", "coinbase-x402-docs-14", "coinbase-x402-probe-rt-1", "coinbase-x402-probe-rt-2", "coinbase-x402-probe-3", "coinbase-x402-supp-1", "coinbase-x402-supp-5" ] }, { "productId": "coinbase-x402", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "x402 replaces API keys with pay-per-request payments rather than issuing scoped API credentials, so there's no OAuth-style scope/permission system; however, 'Agentic accounts'/'Agentic Wallet' let a user give an agent a wallet to autonomously pay for services, and batch-settlement escrow includes cryptographically signed spending limits and defined refund/withdrawal semantics, which functions as a loose least-privilege spend-limit mechanism for the agent's payment authority. Missing for 10: explicit API-credential scoping (read/write/resource-level permissions), granular per-service access control beyond payment limits, and independent confirmation that these spend-limit controls are enforced in practice.", "evidenceIds": [ "coinbase-x402-docs-11", "coinbase-x402-supp-7", "coinbase-x402-supp-10" ] }, { "productId": "coinbase-x402", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs reference SDK building blocks (CDP SDK's x402 building blocks, TypeScript SDK discovery functions, npm package x402 confirmed live at v1.2.0 with SLSA provenance) and MCP/AgentCore integrations, showing real SDK-based build paths for AI agents. However, evidence lacks concrete SDK code samples, comprehensive language coverage, or independent developer corroboration beyond one HN comment expressing intent to try it with FastAPI. missing for 10: actual SDK code examples/API reference beyond npm existence, multi-language SDK coverage evidence, independent hands-on developer reports of building with the SDK successfully.", "evidenceIds": [ "coinbase-x402-docs-5", "coinbase-x402-docs-14", "coinbase-x402-supp-5", "coinbase-x402-probe-rt-2", "coinbase-x402-comm-9" ] }, { "productId": "coinbase-x402", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol for HTTP requests/agent transactions, not an event-notification or webhook subscription system; nothing in the evidence describes subscribing to or receiving webhook events. Webhooks are a wrong-axis capability for this product's category.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows extensive text documentation but no mention of an interactive API reference or runnable examples; a probe explicitly found no OpenAPI/Swagger spec at any candidate path (404s), indicating no interactive reference tooling is exposed.", "evidenceIds": [ "coinbase-x402-probe-3" ] }, { "productId": "coinbase-x402", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe for OpenAPI/swagger specs at all standard paths on the CDP docs site returned 404s, and no other evidence pack item points to a downloadable machine-readable API spec; the docs only offer markdown/llms.txt style documentation, not an OpenAPI equivalent.", "evidenceIds": [ "coinbase-x402-probe-3" ] }, { "productId": "coinbase-x402", "storyId": "api-sandbox", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only sandbox-relevant evidence is a passing mention that the facilitator's supported-network table includes Base Sepolia (a public testnet) alongside mainnet networks, implying developers could test payments without real funds — but there is no dedicated 'sandbox mode', test facilitator, or explicit developer guidance for testing against non-production data. missing for 10: explicit sandbox/testnet documentation or tutorial, dedicated test facilitator or test-mode API keys, guidance on faucet/test USDC usage, and any community/hands-on confirmation of a working testnet flow.", "evidenceIds": [ "coinbase-x402-supp-3" ] }, { "productId": "coinbase-x402", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows a 'v2' support table for the facilitator API but nowhere documents an API versioning scheme, backward-compatibility guarantees, or a deprecation policy for x402 endpoints/SDKs; no changelog, sunset timeline, or version-support-window language appears anywhere in the docs or probes.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "x402's batch-settlement scheme is documented specifically to let agents perform 'thousands of granular interactions' bundled into a single onchain settlement, which is the protocol's version of bulk/batch operations across many payment items (vouchers redeemed together). This is first-party documented with mechanics (escrow, cryptographic vouchers, refund semantics) but there is no independent or hands-on verification that this batching works at scale in production, and no evidence of bulk operations outside the payment-settlement context (e.g., bulk discovery or bulk resource management). Missing for 10: third-party/hands-on confirmation of batch settlement at scale, and evidence of bulk operations beyond payment batching.", "evidenceIds": [ "coinbase-x402-docs-8", "coinbase-x402-docs-16", "coinbase-x402-supp-10" ] }, { "productId": "coinbase-x402", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "x402 has some built-in event→action automation (a 402 response auto-triggers a client to sign and retry with payment; unpaid resources are auto-removed from the Bazaar after 30 days without settlement), but there is no evidence of a general rules engine where an AI-native user can define arbitrary custom triggers/conditions and actions — the automation is hardwired protocol behavior, not user-configurable rule authoring. missing for 10: a rule-definition interface or config, support for arbitrary event types beyond payment/settlement, user-set conditional logic (if/then) beyond the protocol's fixed retry-and-settle flow.", "evidenceIds": [ "coinbase-x402-docs-1", "coinbase-x402-supp-6", "coinbase-x402-docs-16", "coinbase-x402-supp-10" ] }, { "productId": "coinbase-x402", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol/facilitator for per-request HTTP payments between agents and services, not a workflow orchestration or job-scheduling system; scheduling recurring jobs/workflows is outside its product category (batch settlement refers to payment vouchers, not task scheduling).", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol for machine-to-machine microtransactions, not an automation/workflow builder; there is no concept of 'automations' with version history, review, or rollback in this product's scope.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "catalog-feed-publish", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "x402 Bazaar auto-lists any x402-enabled endpoint into a discoverable catalog (23,000+ resources) accessible via API, TypeScript SDK, or MCP tool calls, with no registration form needed once payment settles — this functions as a merchant discovery feed for agents. However, it is not a true 'catalog/import API' in the product-catalog sense: listing requires actually running a live payable endpoint and a successful settled payment (not a bulk import of a product list), items expire after 30 days without settlement, and there's no support for describing multiple SKUs/services or rich product metadata beyond price/asset/network. Missing for 10: a genuine bulk catalog-import or feed format for multiple products/services at once, richer product metadata (descriptions, categories) beyond payment terms, and independent hands-on confirmation that discovery surfaces reliably drive agent traffic to listed merchants.", "evidenceIds": [ "coinbase-x402-docs-5", "coinbase-x402-docs-6", "coinbase-x402-supp-5", "coinbase-x402-supp-6", "coinbase-x402-probe-rt-1" ] }, { "productId": "coinbase-x402", "storyId": "chat-surface-checkout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "x402 documents agent-to-agent/API payment infrastructure (MCP-compatible tool-call discovery, AWS Bedrock AgentCore, Agentic Wallets) but there is no evidence of integration with named consumer chat/assistant surfaces like ChatGPT, Claude, Gemini, or Copilot enabling buyers to complete purchases inside those chat UIs. The protocol targets machine-to-machine settlement, not consumer chat checkout flows in these specific products.", "evidenceIds": [ "coinbase-x402-docs-12", "coinbase-x402-docs-14", "coinbase-x402-supp-5", "coinbase-x402-supp-7" ] }, { "productId": "coinbase-x402", "storyId": "checkout-spec-versioned", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "x402 is documented as a versioned protocol under open Linux Foundation governance (v2 support tables, TSC oversight, npm package with SLSA provenance) and has clear spec docs (how-it-works, facilitator support tables), but there is no published formal schema (e.g., JSON Schema/OpenAPI) or explicit conformance/validation test suite in evidence — the openapi probe returned 404s and no conformance-testing tool is mentioned. missing for 10: published machine-readable schema (OpenAPI/JSON Schema), an official conformance or validation test suite/tool, and independent confirmation of protocol versioning practices beyond npm version numbers.", "evidenceIds": [ "coinbase-x402-supp-3", "coinbase-x402-supp-8", "coinbase-x402-supp-9", "coinbase-x402-probe-3", "coinbase-x402-probe-rt-2" ] }, { "productId": "coinbase-x402", "storyId": "dispute-handling-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence describes a dispute/chargeback API, evidence-submission workflow, or outcome/status tracking; x402 payments settle irreversibly onchain via the Facilitator, and community comments even flag 'verify work was done' as an unresolved trust problem with no built-in resolution mechanism. Missing for 10: any dispute-filing API, evidence submission, adjudication process, or chargeback/refund status endpoint.", "evidenceIds": [ "coinbase-x402-comm-10", "coinbase-x402-supp-3", "coinbase-x402-supp-10" ] }, { "productId": "coinbase-x402", "storyId": "fees-transparency-agent-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Coinbase publishes a concrete, self-serve fee schedule for the CDP Facilitator (first 1,000 onchain transactions/month free, then $0.001 per additional transaction, verification always free, batch settlement amortizing costs further), letting a merchant price agentic payment flows without contacting sales. Missing for 10: independent/third-party verification of real-world billed fees, and any published fee variance across supported networks (Base, Polygon, Arbitrum, Solana) beyond the flat headline rate.", "evidenceIds": [ "coinbase-x402-docs-10", "coinbase-x402-supp-4", "coinbase-x402-docs-7" ] }, { "productId": "coinbase-x402", "storyId": "http-402-machine-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "x402 directly implements HTTP 402-based per-request payments with a one-line integration, hosted facilitator for verification/settlement, fixed/usage/batch pricing schemes, and agent-to-agent payment flows with no checkout UI, corroborated by runtime probes showing live discovery and facilitator endpoints and community reports of real deployments (httpay.xyz, Apiosk). missing for 10: independent hands-on verification of the exact developer 'one-line' integration experience beyond docs, and clearer resolution of community concerns about KYC/AML friction potentially affecting the 'no checkout UI' promise.", "evidenceIds": [ "coinbase-x402-docs-1", "coinbase-x402-docs-2", "coinbase-x402-docs-8", "coinbase-x402-supp-1", "coinbase-x402-supp-3", "coinbase-x402-probe-rt-1", "coinbase-x402-probe-rt-2", "coinbase-x402-comm-10", "coinbase-x402-comm-11" ] }, { "productId": "coinbase-x402", "storyId": "human-approval-gate", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "x402's own documentation frames the protocol as removing friction rather than adding human oversight — 'AI agent pays instantly with stablecoins, No signups or approvals required' (docs-17) — and the signing step in the handshake is the agent's wallet cryptographically authorizing payment (supp-1, comm-7), not a documented user-facing confirmation, mandate, or per-purchase consent screen. Compliance checks (OFAC/KYT) screen counterparties for sanctions risk, not spending authorization by the user, so there is no evidence of the confirmation/consent mechanism the story requires.", "evidenceIds": [ "coinbase-x402-docs-17", "coinbase-x402-supp-1", "coinbase-x402-comm-7", "coinbase-x402-docs-7" ] }, { "productId": "coinbase-x402", "storyId": "merchant-agent-onboarding", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs give a concrete self-serve merchant path: add one line of code (or use CDP SDK x402 building blocks) to require payment, receive at any wallet address (custodial, self-custody, Business, Prime), and Bazaar discovery/listing happens automatically with no registration form or API call once payments settle — confirmed live via runtime probe of the discovery endpoint. missing for 10: no independent hands-on merchant onboarding report/case study corroborating the frictionless claim beyond docs+probe, and no explicit merchant-facing 'agreement' or ToS acceptance step is documented.", "evidenceIds": [ "coinbase-x402-docs-1", "coinbase-x402-docs-3", "coinbase-x402-docs-5", "coinbase-x402-docs-6", "coinbase-x402-supp-5", "coinbase-x402-supp-6", "coinbase-x402-probe-rt-1" ] }, { "productId": "coinbase-x402", "storyId": "multi-implementer-adoption", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "x402 was contributed to the vendor-neutral Linux Foundation x402 Foundation, with 40+ member organizations (AWS, American Express, Cloudflare, Google, Mastercard, Shopify, Stripe, Visa, Solana Foundation, etc.) and a named Governing Board/Technical Steering Committee independent of Coinbase, plus independent implementations like httpay.xyz and Apiosk running their own x402 endpoints/gateways. This is clear evidence of multiple independent parties beyond Coinbase implementing and governing the protocol, though community commentary notes Coinbase/US firms still dominate influence. Missing for 10: deeper technical detail on independent (non-Coinbase) facilitator implementations or interoperability testing between competing implementations, and stronger independent audit of the foundation's actual decentralization in practice.", "evidenceIds": [ "coinbase-x402-supp-8", "coinbase-x402-supp-9", "coinbase-x402-comm-5", "coinbase-x402-comm-10", "coinbase-x402-comm-11", "coinbase-x402-comm-1" ] }, { "productId": "coinbase-x402", "storyId": "open-spec-published", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "x402 is documented as an open, versioned protocol now governed by the vendor-neutral x402 Foundation under the Linux Foundation, with a public spec site (x402.org), published governance/TSC structure, and no signup, API key, or account required to read the spec or implement the handshake (docs, discovery APIs, and npm SDK are all keyless per probes). Community evidence corroborates that it's self-hostable on any chain/token and not gated behind Coinbase agreements, though some skepticism exists about de facto Coinbase influence. Missing for 10: an explicit versioned spec document/changelog (e.g., semver spec repo) directly cited, and stronger independent confirmation that implementers never need to sign any agreement with Coinbase or the Foundation.", "evidenceIds": [ "coinbase-x402-supp-8", "coinbase-x402-supp-9", "coinbase-x402-comm-5", "coinbase-x402-comm-1", "coinbase-x402-probe-rt-1", "coinbase-x402-probe-rt-2", "coinbase-x402-docs-6" ] }, { "productId": "coinbase-x402", "storyId": "openness-api-parity", "verdict": "na", "quality": 0, "confidence": "medium", "rationale": "x402 is an open, API/protocol-first payment standard (HTTP 402 handshake, facilitator, Bazaar discovery) with no dedicated end-user UI described anywhere in the evidence pack — the entire product surface is the API/SDK itself, so a 'parity between UI and API' story is a category error rather than a capability gap.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "openness-full-export", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol/facilitator for machine-to-machine HTTP payments, not a data-hosting or content-storage product with a user data corpus to export — the 'export data and leave' axis is a category error here, not a missing capability.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "openness-open-license", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "The evidence shows x402 was contributed to the Linux Foundation and is now developed under 'open, vendor-neutral governance' with public docs and an npm-published SDK (v1.2.0) with SLSA provenance, implying source availability, but no citation ever names a specific open-source license (MIT/Apache/etc.) or points to a public repository. Missing for 10: explicit license text/repo citation, confirmation of source-code (not just protocol spec) openness, and independent verification that the code itself (not just governance) is freely licensed.", "evidenceIds": [ "coinbase-x402-supp-8", "coinbase-x402-supp-9", "coinbase-x402-probe-rt-2", "coinbase-x402-comm-5" ] }, { "productId": "coinbase-x402", "storyId": "openness-self-host", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "x402 is an open protocol with an open-source SDK (npm x402 package, Linux Foundation governance), and the protocol's own author states 'anyone can self-host the same mechanics on any network, with any token/crypto asset,' confirming self-hosting is technically possible outside Coinbase's hosted CDP Facilitator. However, all first-party docs describe usage of the hosted CDP Facilitator (validation, screening, settlement, discovery via Bazaar) rather than providing a step-by-step self-hosting guide for running your own facilitator/discovery stack. Missing for 10: official self-hosting documentation/tutorial for running a facilitator independently, and evidence of production self-hosted deployments outside Coinbase's infrastructure.", "evidenceIds": [ "coinbase-x402-comm-1", "coinbase-x402-supp-8", "coinbase-x402-probe-rt-2", "coinbase-x402-docs-2" ] }, { "productId": "coinbase-x402", "storyId": "order-event-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a per-request stateless payment protocol (HTTP 402 challenge/response settled per call), not an order-management or e-commerce backend with persistent 'order' objects that progress through created/updated/fulfilled/canceled states. There is no order entity or webhook/event-subscription model in any of the evidence — payments are individual signed/settled transactions, not lifecycle-tracked orders, so this story is a category error for this product.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "payable-service-directory", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "The x402 Bazaar is a documented, keyless, public discovery index (23,000+ resources) that agents can query via search API, TypeScript SDK, or MCP tool calls, and a runtime probe confirmed live discovery results without an API key. missing for 10: independent (non-Coinbase) hands-on confirmation of agents successfully using the discovery index end-to-end in production beyond the single runtime probe.", "evidenceIds": [ "coinbase-x402-docs-5", "coinbase-x402-docs-6", "coinbase-x402-docs-14", "coinbase-x402-supp-5", "coinbase-x402-supp-6", "coinbase-x402-probe-rt-1" ] }, { "productId": "coinbase-x402", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol for HTTP requests, not a data storage/hosting service; data residency/region choice is not an applicable capability for this product category.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "x402 is a payment protocol for API/agent micropayments; it has no relationship to AI model training data usage or data privacy controls, so this axis is a category error for this product.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers payment mechanics, facilitator screening, discovery, and governance, but nothing addresses user-controlled data retention or deletion policies for transaction/KYT data collected by the CDP Facilitator. Given onchain settlement is inherently immutable and off-chain screening data governance is unaddressed, there is no evidence of any retention/deletion controls for AI-native users.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry or usage-tracking opt-out settings for x402 SDKs, facilitator, or Bazaar; the documentation focuses on payment flows, compliance screening (OFAC/KYT), and discovery, not client-side telemetry controls.", "evidenceIds": [] }, { "productId": "coinbase-x402", "storyId": "refund-via-api", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only refund-relevant evidence is a single line about the batch-settlement scheme stating that 'buyers retain defined refund and withdrawal semantics,' but this is not elaborated into an actual API, dashboard, or programmatic tracking mechanism, and no other docs address refunds/disputes for standard (non-batch) x402 payments. missing for 10: a documented refund API or endpoint, dispute-resolution workflow, refund status tracking, and coverage for non-batch payment flows.", "evidenceIds": [ "coinbase-x402-supp-10" ] }, { "productId": "coinbase-x402", "storyId": "scoped-payment-tokens", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "x402 lets an agent's wallet make cryptographically signed, per-request payments with authorized-but-not-exceeded amounts (the 'upto' scheme) and batch-settlement vouchers where 'limits are cryptographically signed' and buyers retain 'refund and withdrawal semantics' — functioning like a scoped, capped credential rather than a raw card number. However, there is no documented mechanism for setting an explicit expiry window or restricting a credential to specific merchants; the wallet/agentic account simply holds USDC and signs payments to whatever service it calls. Missing for 10: explicit credential expiry configuration, merchant/service allow-listing, and a unified 'issue a scoped credential' UX rather than per-request signing.", "evidenceIds": [ "coinbase-x402-supp-3", "coinbase-x402-supp-7", "coinbase-x402-supp-10", "coinbase-x402-docs-8", "coinbase-x402-docs-11" ] }, { "productId": "coinbase-x402", "storyId": "settlement-payout-clarity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm the CDP Facilitator validates and settles payments onchain and 'reports the result to your resource server,' and sellers can receive to custodial or self-custody wallets, giving a baseline settlement/reporting hook comparable to other channels. However there's no documented merchant-facing statement/ledger/dashboard, refund/chargeback handling, or tax/accounting reconciliation tooling, and community reports (comm-10) note real-world friction around verifying settlement timing for variable-length agent tasks. Missing for 10: dedicated payout statements or ledger exports, refund/dispute reconciliation flow, and independent confirmation that merchants can reconcile x402 settlements against traditional accounting systems.", "evidenceIds": [ "coinbase-x402-docs-2", "coinbase-x402-docs-3", "coinbase-x402-supp-3", "coinbase-x402-supp-4", "coinbase-x402-comm-10" ] }, { "productId": "coinbase-x402", "storyId": "spend-caps-revocation", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "x402 documents per-transaction spend limits via the 'upto' authorize-and-settle scheme and batch-settlement's cryptographically signed voucher limits/escrow, and agentic accounts let an agent hold a funding source — but there is no documented mechanism to set a persistent per-agent spend cap/usage quota across sessions or to instantly revoke an agent's payment authority; a community commenter even suggests pairing x402 with a third-party 'budget SDK' for spending ceilings, implying it's not native. missing for 10: native per-agent spend-cap configuration, usage-limit dashboards, and an instant revocation/kill-switch mechanism for agent payment authority.", "evidenceIds": [ "coinbase-x402-docs-11", "coinbase-x402-supp-7", "coinbase-x402-supp-10", "coinbase-x402-comm-11" ] }, { "productId": "coinbase-x402", "storyId": "stablecoin-settlement", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "x402 is purpose-built for agent-initiated stablecoin (USDC/ERC-20/SPL) payments over a documented HTTP 402 protocol, with a hosted CDP Facilitator that verifies, screens (OFAC/KYT), and settles onchain across Base, Solana, Polygon, Arbitrum and World, and agent wallet integrations (Agentic Accounts, AgentCore, MCP) for autonomous payment flows. Runtime probes confirm the discovery API is live and keyless and the facilitator auth-gates as documented, and community hands-on reports (124 live x402 endpoints, HN builders using it with FastAPI) corroborate real-world settlement usage.\n\nmissing for 10: independent large-scale audit of settlement finality/reliability, and resolution of the community-flagged 'verify work was done before settling' friction reported by production operators.", "evidenceIds": [ "coinbase-x402-docs-2", "coinbase-x402-docs-7", "coinbase-x402-docs-9", "coinbase-x402-docs-11", "coinbase-x402-supp-1", "coinbase-x402-supp-3", "coinbase-x402-supp-7", "coinbase-x402-probe-rt-1", "coinbase-x402-probe-rt-2", "coinbase-x402-comm-7", "coinbase-x402-comm-10" ] }, { "productId": "coinbase-x402", "storyId": "structured-offer-data", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "The x402 Bazaar discovery API/SDK returns machine-readable listings for payable services — price (USDC amount), network/asset/scheme, timeout, and a resource endpoint that itself acts as the 'checkout' call — and this was independently confirmed live via a keyless GET returning real listings (probe-rt-1), matching docs on public discovery with no API key needed (docs-6, supp-5, supp-6). Availability is implicit (30-day settlement pruning keeps the catalog live) but the docs never explicitly frame data as 'variants' or provide a distinct 'checkout link' field beyond the resource URL itself. Missing for 10: explicit variant/option metadata in listings, an explicit checkout-link field distinct from the resource endpoint, and independent (non-Coinbase) confirmation of listing completeness/accuracy.", "evidenceIds": [ "coinbase-x402-docs-5", "coinbase-x402-docs-6", "coinbase-x402-supp-5", "coinbase-x402-supp-6", "coinbase-x402-probe-rt-1" ] }, { "productId": "crossmint", "storyId": "agent-cart-create", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Crossmint's Agent Checkouts API is a documented protocol call that lets an agent submit a product URL and spending cap to create an order/checkout, and runtime probing confirms the endpoint is live and agent-scoped (requiring ServerKeyAgent auth). The lifecycle supports polling for status updates, which functions as order-draft state updates, and agent cards similarly document order-intent creation/tracking (total, reserved, spent, available). missing for 10: no explicit 'update cart' verb or partial-order-edit API, no OpenAPI/schema confirmation (openapi.json probes 404), and no independent third-party corroboration beyond first-party docs and the vendor's own runtime probe.", "evidenceIds": [ "crossmint-docs-4", "crossmint-supp-7", "crossmint-probe-rt-1", "crossmint-supp-8", "crossmint-supp-2" ] }, { "productId": "crossmint", "storyId": "agent-catalog-search", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Crossmint's agent products (Agent Cards, Agent Wallets, Agent Checkouts) are all payment/execution infrastructure that require the agent to already have a specific product URL or merchant endpoint — 'hand it a product URL and a spending cap' — none of the evidence describes a search or product-discovery API across merchants. There is no documented catalog search, product query, or merchant-discovery endpoint; discovery is assumed to happen elsewhere before Crossmint is invoked.", "evidenceIds": [ "crossmint-supp-7", "crossmint-docs-4", "crossmint-supp-1" ] }, { "productId": "crossmint", "storyId": "agent-checkout-complete", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Crossmint's Agent Checkouts API lets an agent be handed a product URL and spending cap and complete checkout on the user's behalf, with delegated payment credentials (agent cards/order intents or delegated wallet signer permissions) and a poll-driven order lifecycle to confirm terminal state; runtime probe confirms the endpoint is live and enforces agent-scoped auth. missing for 10: independent/third-party confirmation of a fully completed order in production (docs note no staging/test environment and no webhooks in v1, so end-to-end success is self-reported), and no public case study of a real merchant purchase completing.", "evidenceIds": [ "crossmint-docs-4", "crossmint-supp-7", "crossmint-supp-8", "crossmint-supp-4", "crossmint-probe-rt-1" ] }, { "productId": "crossmint", "storyId": "agent-fraud-liability", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Crossmint documents dispute handling for its general Checkout product (Crossmint absorbs card dispute risk via authorization holds, per crossmint-supp-10) and describes spend caps/order-intent controls for agent cards and wallets, but explicitly notes this chargeback/liability coverage is not specific to agent-initiated transactions. There is no dedicated documentation defining fraud/liability/chargeback allocation rules for agent checkouts or agent-card/agent-wallet flows. missing for 10: explicit agent-transaction-specific liability/chargeback policy, merchant-facing dispute-resolution terms for agent checkouts, and clarity on who bears risk when an agent-initiated purchase is fraudulent or disputed.", "evidenceIds": [ "crossmint-supp-10", "crossmint-supp-2", "crossmint-supp-4", "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "agent-identity-tiers", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Crossmint's agent stack does embed verifiable-identity mechanisms — onchain delegated signer keys with scoped, revocable permissions (crossmint-supp-4), card-network verified 'Agent Cards' secured by Visa VIC/Mastercard Agent Pay (crossmint-supp-1, -3), and a distinct 'ServerKeyAgent' credential type confirmed live at the Agent Checkouts endpoint (crossmint-probe-rt-1). These give merchants some cryptographic/network-level basis to distinguish agent-initiated, permissioned transactions from anonymous traffic. However, there is no documented merchant-facing registry, trust-tier system, or API for merchants to look up/verify an agent's identity or reputation directly — the verification lives inside Crossmint/card-network infrastructure rather than being exposed as a merchant-consumable signal. Missing for 10: an explicit merchant-facing agent identity/reputation lookup or trust-tier classification, and independent confirmation that merchants can actually distinguish trust levels using this data.", "evidenceIds": [ "crossmint-supp-1", "crossmint-supp-3", "crossmint-supp-4", "crossmint-probe-rt-1" ] }, { "productId": "crossmint", "storyId": "agent-order-attribution", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes agent payment mechanisms (cards, wallets, checkouts, spending rules) but contains no mention of merchant-facing reporting, dashboards, or transaction filtering by originating agent — the core of this story. Order intents and delegated signers are documented for controlling agent spend, not for merchant attribution/reporting.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "agent-order-tracking", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly describe agent checkouts as poll-driven — 'no webhooks in v1... you poll until it reaches a terminal state' — and order intents/rails each carry their own status, so an agent can query order status after purchase via polling. However, this is documented only for the Agent Checkouts flow (not agent cards or wallet payments), lacks any true package/shipment tracking detail, and has no independent or hands-on corroboration beyond first-party docs. Missing for 10: shipment/delivery tracking detail, webhook or push-based status updates, and third-party verification of the polling flow actually working in production.", "evidenceIds": [ "crossmint-supp-7", "crossmint-docs-11", "crossmint-docs-4" ] }, { "productId": "crossmint", "storyId": "agent-traffic-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence details user-side and agent-side spending controls (spend caps, counterparties, time windows, order intents) but nothing about merchants controlling which agents/agent platforms may access their catalog or checkout, nor any rate-limiting/allow-deny mechanism exposed to merchants. Crossmint's agent-checkout flow treats the merchant as an arbitrary third-party target ('buy from any merchant'), not as a Crossmint customer configuring agent access policies.", "evidenceIds": [ "crossmint-supp-7", "crossmint-supp-4", "crossmint-supp-8" ] }, { "productId": "crossmint", "storyId": "agent-wallet-provisioning", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Crossmint's Agent Wallets docs show a user-owned, non-custodial wallet that a user funds and controls, with the agent authorized as a scoped, revocable delegated signer (spend cap, counterparties, time window) enforced onchain, and a working stablecoin-wallet quickstart (crossmint-docs-3, crossmint-supp-4, crossmint-supp-5). However, the evidence never explicitly documents a balance-visibility feature (e.g., a balance/dashboard API for the funding user) — missing for 10: explicit balance-check/visibility API or UI evidence, independent/hands-on corroboration of the wallet flow.", "evidenceIds": [ "crossmint-docs-3", "crossmint-supp-1", "crossmint-supp-4", "crossmint-supp-5", "crossmint-supp-6" ] }, { "productId": "crossmint", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Crossmint serves a live llms.txt (confirmed by direct probe returning HTTP 200 with agent-oriented content) and every docs page is also available as markdown via the same URL + .md suffix, directly matching the story of pointing an agent at llms.txt or agent-oriented docs. Missing for 10: no independent third-party report of an agent successfully consuming these docs end-to-end, and no OpenAPI spec (all candidates 404) to complement the llms.txt for structured agent consumption.", "evidenceIds": [ "crossmint-probe-1", "crossmint-probe-rt-2", "crossmint-probe-2" ] }, { "productId": "crossmint", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is blockchain/payments infrastructure (wallets, agent payments, checkout APIs) for developers, not an analytics or data product that surfaces AI-generated insights/suggestions from a user's own data; this axis is a category error for its product type.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Crossmint lets agents transact autonomously once delegated: onchain-enforced spend limits, counterparties, and time windows mean the agent acts 'with no user prompt per action' and checkouts/x402/MPP payments proceed without human intervention ([crossmint-supp-4], [crossmint-supp-6], [crossmint-supp-7]). However this is scoped strictly to payment/checkout automation, not a general-purpose background job/workflow scheduler, and agent checkouts require manual polling with no webhooks or staging ('no webhooks in v1', 'no staging environment') ([crossmint-supp-7]). Missing for 10: general-purpose automation/scheduling framework beyond payments, webhook/event-driven triggers, and evidence of autonomous background operation outside the payment domain.", "evidenceIds": [ "crossmint-supp-4", "crossmint-supp-6", "crossmint-supp-7", "crossmint-supp-5" ] }, { "productId": "crossmint", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is infrastructure/API (wallets, payments, agent checkout tooling) for developers to build agentic payment flows into their own apps — it is not itself a product with a built-in AI assistant that a user interacts with directly. The evidence describes enabling external agents to transact, not delegating tasks to an in-product assistant, so this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Crossmint's core products are REST/headless APIs (explicit 'headless checkout API', agent checkouts API, wallet API) designed for programmatic, UI-less automation, and probes confirm keyless API-key-based auth suitable for scripted/CI calls. However there is no explicit documentation of CI pipeline usage, SDK examples for automated test suites, or non-interactive auth setup, and agent-checkouts testing is noted as production-only with no staging environment, complicating CI use. Missing for 10: documented CI/automation examples, staging/sandbox support for safe automated testing, and explicit non-interactive credential provisioning guidance.", "evidenceIds": [ "crossmint-docs-7", "crossmint-docs-4", "crossmint-supp-7", "crossmint-probe-rt-1", "crossmint-docs-1" ] }, { "productId": "crossmint", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a wallet/payments infrastructure API for agents (wallets, cards, checkouts), not an AI agent product that consumes tools via MCP client integration; no evidence addresses plugging MCP servers into Crossmint. This is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a wallet/payments infrastructure API for agents, not itself an agent, but the evidence contains no mention of an official MCP server offering — all APIs are REST/SDK based (agent cards, wallets, checkouts). Since Crossmint is a service provider (not an agent), an MCP server would be a plausible axis, but there is zero evidence of one; however this story specifically concerns 'connecting an agent via an MCP server' which for a payments infrastructure product without any MCP-server evidence should be judged as no capability shown.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Crossmint's evidence describes REST APIs, SDKs, and agent-delegated payment flows (cards, wallets, checkouts, x402/MPP), but nothing shows a natural-language command interface for the human/AI-native user to directly operate Crossmint itself — no chat UI, NL-to-API translation layer, or documented conversational control surface. The axis is fair to ask of a product marketed as 'payment infrastructure for AI agents,' but no such capability is evidenced.", "evidenceIds": [ "crossmint-docs-1", "crossmint-supp-1", "crossmint-probe-2" ] }, { "productId": "crossmint", "storyId": "agentic-official-cli", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is an API/infrastructure platform for wallets, payments, and agent checkouts, not a developer tool whose primary interface is a CLI; the evidence is entirely about REST APIs, SDKs, and docs, with no CLI mentioned or implied. This axis is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Crossmint exposes a documented REST API surface (wallets, agent cards, agent checkouts, payment flows) with quickstarts and runtime probes confirming the endpoints are live and API-key/agent-key authenticated, and llms.txt/markdown docs are served for machine consumption. The main gap is the absence of a discoverable formal OpenAPI/Swagger spec (probe-2 shows all standard OpenAPI paths 404), so full machine-readable API introspection isn't confirmed. Missing for 10: a published OpenAPI/Swagger schema, independent third-party confirmation of API robustness beyond Crossmint's own docs.", "evidenceIds": [ "crossmint-docs-1", "crossmint-docs-4", "crossmint-probe-1", "crossmint-probe-2", "crossmint-probe-rt-1", "crossmint-probe-rt-2", "crossmint-supp-1" ] }, { "productId": "crossmint", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Crossmint documents explicit least-privilege delegation for agents: user-owned wallets grant an agent a bound signer key with a spend cap, allowed counterparties, and a time window, all enforced onchain and revocable at any time; agent cards similarly use order-intent 'fixed allowance' credentials with amount/expiration limits and network-level enforcement. A runtime probe further shows an agent-specific credential type (ServerKeyAgent) is live on the Agent Checkouts API, confirming agent-scoped API keys exist in practice, not just in docs. Missing for 10: independent/third-party corroboration of these scoping guarantees, and clearer documentation of general-purpose (non-payment) API key scoping/role management beyond the wallet/card/checkout domain.", "evidenceIds": [ "crossmint-supp-4", "crossmint-supp-2", "crossmint-supp-8", "crossmint-probe-rt-1", "crossmint-supp-1" ] }, { "productId": "crossmint", "storyId": "agentic-sdks", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Crossmint's docs show a single REST API accessed via quickstarts (agent checkouts, cards, stablecoin wallets) and protocol-specific clients like @x402/core and mppx, implying SDK-style tooling, but no evidence names an official multi-language SDK package (e.g., npm/pip installable Crossmint SDK) and the OpenAPI probe found no published spec, undercutting a clean 'official SDK' story. missing for 10: explicit official SDK package names/install instructions, multi-language SDK coverage, and a discoverable OpenAPI/schema reference.", "evidenceIds": [ "crossmint-docs-3", "crossmint-docs-4", "crossmint-supp-5", "crossmint-supp-6", "crossmint-probe-2" ] }, { "productId": "crossmint", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The only explicit evidence about webhooks states the opposite of the story: Agent Checkouts documentation says 'no webhooks in v1' and requires polling until a terminal state is reached, with no other evidence pack item describing a webhook subscription mechanism anywhere in Crossmint's API.", "evidenceIds": [ "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows only markdown-based docs and an llms.txt feed; explicit probes for an OpenAPI/Swagger spec (openapi.json, swagger.json, etc.) all returned 404, and no evidence mentions an interactive API console, sandbox, or runnable code examples.", "evidenceIds": [ "crossmint-probe-2", "crossmint-probe-1", "crossmint-probe-rt-2" ] }, { "productId": "crossmint", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe found no OpenAPI/Swagger spec at any standard path (all 404s), and while an llms.txt/markdown docs format exists, that is not a machine-readable API spec. missing for 10: an OpenAPI/Swagger JSON or YAML spec, any documented spec download link, or equivalent machine-readable API schema.", "evidenceIds": [ "crossmint-probe-2", "crossmint-probe-1" ] }, { "productId": "crossmint", "storyId": "api-sandbox", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Crossmint documents genuine testnet sandboxes for some flows (e.g., the stablecoin wallet quickstart runs on Base Sepolia, crossmint-docs-3), but for Agent Checkouts the docs explicitly state 'there is no staging environment for it' and testing is production-only (crossmint-supp-7). So sandboxed testing exists for part of the agent stack but is explicitly absent for another major agent capability. missing for 10: a unified sandbox/staging environment across all agent products (cards, checkouts, wallets), independent confirmation of testnet behavior beyond docs, and any sandbox coverage for Agent Cards/Checkouts specifically.", "evidenceIds": [ "crossmint-docs-3", "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents API versioning conventions or a deprecation policy; the only version-related signal is an endpoint path containing 'unstable' (crossmint-probe-rt-1), which if anything suggests unversioned/experimental APIs rather than a documented deprecation policy.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers single-item agent payment flows (cards, wallets, checkouts, x402/MPP) and mentions managing funds 'at scale' in passing, but there is no documented batch/bulk API, bulk wallet creation, or multi-item transaction endpoint that would let a user perform operations across many items at once.", "evidenceIds": [ "crossmint-docs-10", "crossmint-docs-4", "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Crossmint lets users define scoped rules (spend caps, counterparty allow-lists, time windows) that once set let an agent act autonomously without per-action prompts, and states 'Transaction rules enforced onchain' — a form of automatic rule-based action. However this is closer to pre-authorized permission bounds than true event-triggered automation, and the docs explicitly note agent checkouts have 'no webhooks in v1', meaning event-driven triggering isn't supported there. Missing for 10: an explicit rules/automation engine that fires actions on arbitrary external or on-chain events, webhook/event-subscription support, and independent confirmation of automated rule execution beyond spend-limit enforcement.", "evidenceIds": [ "crossmint-docs-12", "crossmint-supp-4", "crossmint-supp-2", "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a wallet/payments infrastructure API for agents, not a job scheduler or workflow orchestrator; the evidence pack covers wallets, cards, checkouts, and payment protocols with no mention of scheduling, cron-like jobs, or recurring workflow triggers. This axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a payments/wallet infrastructure API for agents, not a workflow/automation-builder product; there is no concept of versioning, reviewing, or rolling back 'automations' (e.g., no workflow definitions, change history, or rollback of agent logic) in the evidence. This story targets automation-builder platforms, which is a different product category than wallet/payment infrastructure.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "catalog-feed-publish", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a payments/wallet infrastructure platform for enabling agents to pay merchants — it is not a merchant catalog/product-feed publishing tool. The evidence is entirely about agent payment rails (cards, wallets, checkouts, x402/MPP), not about merchants publishing product listings for agent discovery, so this axis is a category error for this product.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "chat-surface-checkout", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Crossmint documents generic agent-payment infrastructure (Agent Cards, Agent Wallets, Agent Checkouts) that lets any AI agent buy from merchants via API, which could theoretically be wired into chat surfaces, but there is no evidence of concrete integration or partnership with ChatGPT, Claude, Gemini, Copilot or similar assistant surfaces. Missing for 10: named integrations/plugins with specific chat/assistant platforms, evidence of buyers actually completing purchases inside those surfaces, and any merchant-facing onboarding flow tied to those platforms.", "evidenceIds": [ "crossmint-docs-4", "crossmint-supp-1", "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "checkout-spec-versioned", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Crossmint documents payment flows (x402, MPP, agent checkouts) but there is no evidence of a versioned commerce protocol with a published schema or conformance/validation tooling — probes for OpenAPI/swagger specs all 404'd, and the live agent-checkouts endpoint is explicitly path-versioned as '/api/unstable/', signaling the opposite of a stable published protocol.", "evidenceIds": [ "crossmint-probe-2", "crossmint-probe-rt-1", "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "dispute-handling-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The only relevant evidence states that Crossmint itself absorbs dispute risk and manages chargebacks directly with the bank on the user's behalf (crossmint-supp-10), which is for the general Checkout product, not agent-specific. There is no documentation of any developer-facing API for submitting dispute evidence, checking dispute status, or retrieving outcomes. Missing for 10: any dispute-management API endpoints, evidence-submission workflow, or status/outcome reporting for agent transactions.", "evidenceIds": [ "crossmint-supp-10" ] }, { "productId": "crossmint", "storyId": "fees-transparency-agent-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Crossmint publishes general wallet MAU overage pricing and checkout fee tiers, but the evidence pack explicitly states 'No agent-card- or agent-checkout-specific price is published on the pricing page' (crossmint-supp-9), meaning a merchant cannot price the agent-specific channels (Agent Cards, Agent Checkouts) without contacting sales.", "evidenceIds": [ "crossmint-supp-9" ] }, { "productId": "crossmint", "storyId": "http-402-machine-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "All Crossmint evidence describes agents/wallets *paying* x402 or MPP-protected endpoints (client/payer side) — e.g. crossmint-supp-6 and crossmint-supp-5 explain how a Crossmint wallet reads a 402 challenge and retries with payment proof. There is no evidence of tooling for a developer to stand up their own API/service that returns HTTP 402 challenges and receives/settles per-call agent payments (the monetization/merchant side of x402). Missing for 10: any docs or API for creating/serving a 402-gated endpoint, receiving settlement, or configuring per-call pricing as a service provider — evidence only covers the consuming side.", "evidenceIds": [ "crossmint-supp-6", "crossmint-supp-5", "crossmint-docs-5", "crossmint-docs-6" ] }, { "productId": "crossmint", "storyId": "human-approval-gate", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Crossmint documents strong pre-authorized consent mechanisms — user-signed onchain delegation with spend caps, counterparties, and time windows, plus order-intent 'agent cards' with fixed allowances and expiration — enforced without a per-purchase prompt, and revocable at any time. However, the story asks for documented approval INCLUDING per-purchase consent or signed mandate at time of spend, and Crossmint's model explicitly favors upfront scoped delegation with 'no user prompt per action' rather than a per-transaction confirmation step; this is a deliberate design tradeoff, not a failure, so it's partial rather than disputed. missing for 10: evidence of an optional per-purchase confirmation/step-up flow, independent/hands-on verification of the delegation and revocation actually working in production, and clarity on how disputes/approval work for agent checkouts specifically (dispute coverage is only confirmed for general checkout, not agent checkouts).", "evidenceIds": [ "crossmint-supp-4", "crossmint-supp-2", "crossmint-supp-8", "crossmint-supp-1", "crossmint-supp-10" ] }, { "productId": "crossmint", "storyId": "merchant-agent-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers agent-side integrations (agent wallets, agent cards, x402/MPP payment flows, agent checkouts) but nothing documents a merchant-facing onboarding step — no setting to enable, agreement to sign, or endpoint-publishing guide aimed at merchants who want to accept agent traffic. The 'buy from any merchant' framing implies merchants need no explicit action, but this is never documented as a self-serve merchant enablement path.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "multi-implementer-adoption", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence describes Crossmint as a single-vendor proprietary API/platform (wallets, checkout, agent cards) — even where it interoperates with external protocols like x402 or MPP, those are third-party specs Crossmint merely consumes, not evidence that independent parties implement Crossmint's own protocol/platform. No evidence pack item shows any other company or independent implementer building a competing or parallel implementation of Crossmint's infrastructure.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "open-spec-published", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Crossmint documents its own REST/agent APIs (cards, wallets, checkouts) but the evidence shows no open, versioned specification of its own commerce protocol — the OpenAPI/swagger probe returned 404 on all candidate paths, and no spec repository or versioning scheme is mentioned. While Crossmint implements external protocols like x402 and MPP, it does not publish its own commerce protocol as an open spec.", "evidenceIds": [ "crossmint-probe-2" ] }, { "productId": "crossmint", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Crossmint is built API-first — wallets, agent cards, agent checkouts, and headless checkout are all exposed as REST APIs, with headless checkout explicitly positioned as the API-only alternative to Crossmint's embedded iframe UI, giving 'full control of the user experience' (crossmint-docs-1, crossmint-docs-7, crossmint-docs-8, crossmint-supp-1). However, there's no explicit claim or evidence of full UI/API feature parity across the whole platform, and the probe found no discoverable OpenAPI spec (404s on all candidate paths), suggesting some API surface may be undocumented or incomplete relative to the dashboard. Missing for 10: an explicit parity statement or audit showing every dashboard/UI action (account/team management, dispute handling, analytics) has an API equivalent, and a published OpenAPI spec confirming full API surface.", "evidenceIds": [ "crossmint-docs-1", "crossmint-docs-7", "crossmint-docs-8", "crossmint-supp-1", "crossmint-probe-2" ] }, { "productId": "crossmint", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Crossmint's wallet, checkout, and agent-payment APIs in depth, but nothing addresses data export, open-format portability, or account/data takeout for users leaving the platform. Missing for 10: any documented data export feature, open-format (e.g., CSV/JSON) export tooling, or explicit portability/exit guarantees for user data.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a closed, commercial API/SaaS platform for wallets and agent payments; there is no evidence of an open-source codebase or open license, and this is not the type of product where source-code openness is a typical offering axis for a hosted infrastructure/API service.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a hosted API/SaaS platform for wallets, payments, and agent commerce, not open-source software distributed for self-hosting; no evidence pack item mentions self-hosting or an installable core product, and the category (managed infra reliant on card-network/onchain integrations) is not the kind of product that ships a self-hostable core.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "order-event-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Crossmint's own docs explicitly state agent checkouts have 'no webhooks in v1' and require polling until a terminal state is reached, meaning there is no programmatic push-based subscription to order lifecycle events (created/updated/fulfilled/canceled). No other product area (wallets, cards) documents webhook/event subscription either.", "evidenceIds": [ "crossmint-supp-7" ] }, { "productId": "crossmint", "storyId": "payable-service-directory", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence covers Crossmint's payment rails (cards, wallets, x402, MPP, checkouts) but nothing describes a published directory or discovery index of payable services/APIs that an agent could browse or query; llms.txt is a docs-crawling aid, not a service discovery index. This is a fair axis for an agent-payments platform, but no capability is evidenced.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack mentions data residency, region selection, or storage location controls; Crossmint's docs focus on wallets, payments, and blockchain infra with no data-residency/GDPR-region options mentioned. This is a fair question for a platform handling user data/payments, so absence of evidence means 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a blockchain wallet/payments infrastructure product for agents; AI model training data usage opt-out is unrelated to its wallet/payment API category and not a fair axis for this product type.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a wallet/payments infrastructure product for blockchain and agent transactions, not a data-processing or AI-assistant product that stores conversational/user data; the evidence pack contains no mention of personal data retention policies or deletion controls, and this axis (data retention/deletion for AI-native privacy posture) is a category mismatch for a payments/wallet API.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Crossmint is a wallet/payments infrastructure API for blockchain and agent commerce, not a tool that collects telemetry from an AI-native user's own usage/development activity; opting out of vendor telemetry tracking is not a relevant axis for this product category and no evidence pack material addresses telemetry at all.", "evidenceIds": [] }, { "productId": "crossmint", "storyId": "refund-via-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers dispute/chargeback risk absorption for general card Checkout (crossmint-supp-10), but this describes Crossmint handling bank disputes, not a developer-facing refund API for initiating/tracking refunds on agent-placed orders. No refund endpoint, refund object, or tracking mechanism is documented anywhere for Agent Cards, Agent Wallets, or Agent Checkouts. Missing for 10: any refund API/endpoint, refund status tracking, and agent-order-specific refund workflow documentation.", "evidenceIds": [ "crossmint-supp-10", "crossmint-supp-7", "crossmint-supp-2" ] }, { "productId": "crossmint", "storyId": "scoped-payment-tokens", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Crossmint's Agent Cards give agents a one-time card number, expiration, and CVC scoped by an order intent with amount, description, merchant lock, and expiration — never exposing the real card number — enforced via Visa/Mastercard network rails (crossmint-supp-2, crossmint-supp-3, crossmint-supp-8). This is corroborated by a live runtime probe showing the agent-scoped checkout endpoint requiring agent-specific credentials (crossmint-probe-rt-1). Missing for 10: independent third-party (non-vendor) verification of the card-scoping behavior in production beyond the docs and single runtime probe.", "evidenceIds": [ "crossmint-supp-2", "crossmint-supp-3", "crossmint-supp-8", "crossmint-probe-rt-1", "crossmint-docs-2" ] }, { "productId": "crossmint", "storyId": "settlement-payout-clarity", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence shows transaction-lifecycle tracking (order intents track total/reserved/spent/available amounts) and a documented authorization-hold/capture and dispute-management model for card checkout, which are reconciliation-adjacent, plus tiered per-transaction pricing. But there is no documented merchant payout schedule, settlement-to-bank-account flow, transaction reporting dashboard, or export/reconciliation tooling specific to agent-originated payments, and the agent-checkouts flow explicitly lacks webhooks ('no webhooks in v1' — poll until terminal state), undermining real-time reconciliation. Missing for 10: merchant payout/settlement documentation, reporting/dashboard or export tools, reconciliation-specific guidance for agent transactions, and webhook-based confirmation.", "evidenceIds": [ "crossmint-supp-2", "crossmint-supp-7", "crossmint-supp-10", "crossmint-supp-9" ] }, { "productId": "crossmint", "storyId": "spend-caps-revocation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Crossmint documents onchain-enforced per-agent spend caps, allowed counterparties, and time windows for agent wallets, plus order-intent allowances with amount/expiration for agent cards, and explicitly states permissions are revocable at any time by the user. This is corroborated by detailed docs on delegation mechanics and a runtime probe confirming agent-scoped auth is live in production. Missing for 10: independent (non-vendor) confirmation that revocation is instantaneous in practice, and no evidence of a unified dashboard/UI for setting caps or revoking across all three agent products (cards, wallets, checkouts) in one place.", "evidenceIds": [ "crossmint-supp-2", "crossmint-supp-4", "crossmint-supp-1", "crossmint-supp-8", "crossmint-probe-rt-1" ] }, { "productId": "crossmint", "storyId": "stablecoin-settlement", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Crossmint documents stablecoin settlement for agent payments via user-owned wallets with delegated signer permissions (USDXM/USDC), and explicit rails including x402 and MPP protocols with runtime-verified endpoint behavior, giving strong first-party and probe corroboration of documented stablecoin rails. missing for 10: independent (non-vendor) real-world case studies of production stablecoin settlement volume, and confirmation the x402/MPP flows work beyond testnet/Base Sepolia examples.", "evidenceIds": [ "crossmint-docs-3", "crossmint-docs-5", "crossmint-docs-6", "crossmint-supp-4", "crossmint-supp-5", "crossmint-supp-6", "crossmint-probe-rt-1" ] }, { "productId": "crossmint", "storyId": "structured-offer-data", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Crossmint's docs describe agent checkout as handing it a merchant product URL and letting Crossmint execute the purchase, but nowhere is there evidence that Crossmint itself exposes machine-readable offer data (price, availability, variants, checkout links) for developers to read — it's a payment/checkout executor, not a product-data or listing API. Missing for 10: any API/schema returning structured product price/availability/variant data, any catalog or listing endpoint, any documentation of reading offer metadata rather than just completing a purchase given a URL.", "evidenceIds": [ "crossmint-supp-7", "crossmint-docs-4" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-cart-create", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal documents a concrete, callable cart protocol: POST /merchant-cart createcart to create a cart from a PayPalCart object and getcart to retrieve/update cart status, validation issues, and totals, explicitly invoked by AI agents/PayPal Shopping Cart during checkout; the agent toolkit also exposes create_order and related order-management tools callable by AI agents via MCP/LangChain/etc. Missing for 10: no independent hands-on developer report confirming a live end-to-end agent-driven cart creation/update flow beyond PayPal's own docs, and cart update (vs. only create/get) isn't explicitly documented as a separate call.", "evidenceIds": [ "paypal-agent-commerce-docs-11", "paypal-agent-commerce-docs-12", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-getcart", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-agent-toolkit" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-catalog-search", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "PayPal frames agentic commerce as 'connect once to reach many platforms', but access to Store Sync/agentic commerce services is explicitly form-gated ('merchants must complete a form... to request access... PayPal AI team will follow up to guide onboarding'), Agent Ready requires an existing Braintree merchant relationship, and UCP requires separate Google merchant registration — none of this is keyless or self-service, and runtime probing confirms the live MCP server itself demands OAuth Bearer authentication (401 + www-authenticate) rather than allowing keyless discovery calls. This contradicts the story's requirement of keyless or self-service, no-partnership product search across merchants. Missing for 10: keyless/anonymous cross-merchant product search, a genuinely self-serve onboarding path without a sales/approval form, and evidence of catalog search working without a pre-existing Braintree/PayPal merchant relationship.", "evidenceIds": [ "paypal-ac-supp-acs-gate", "paypal-ac-supp-store-sync", "paypal-ac-supp-agent-ready", "paypal-ac-probe-rt-1" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-checkout-complete", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs describe a real end-to-end path: agent-initiated checkout session (ACP requestCheckout / UCP checkout-session), a delegated one-time-use payment credential (Braintree nonce / Google Pay token), and order confirmation flowing into the merchant's existing order system, backed by a cart API and agent toolkit tools (create_order, pay_order). However this is gated behind Braintree accounts, PayPal's form-based approval, Google's separate merchant enablement, and Store Sync's narrow scope (US, physical goods only) — all from first-party docs with no independent or hands-on confirmation of a completed purchase. Missing for 10: independent/hands-on evidence of an actual completed agent purchase, broader (non-gated) merchant eligibility, and real-world confirmation beyond sandbox/spec descriptions.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-store-sync", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-acs-gate", "paypal-ac-probe-rt-1" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-fraud-liability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows general dispute-management and refund tools (list_disputes, accept_dispute_claim, create_refund) and standard PayPal fee/webhook docs, but nothing documents fraud, liability, or chargeback allocation specifically for agent-initiated transactions (e.g., who bears risk when a delegated token or AI agent purchase is disputed). The delegated-token docs mention tokens are 'bound to your merchant ID' but stop short of stating liability shift or chargeback rules for agent-driven checkouts.", "evidenceIds": [ "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-fees", "paypal-ac-supp-webhooks" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-identity-tiers", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "PayPal's docs describe payment-token authentication (Braintree single-use tokens bound to merchant ID), PayPal-issued JWTs for verifying that requests come from PayPal's own Shopping Cart service, and webhook signature verification — but none of this constitutes a verifiable agent identity system (no registered agent profiles, agent-level signatures, or trust tiers that would let a merchant distinguish which specific AI agent or bot is originating traffic). The authentication documented is merchant-to-PayPal or PayPal-to-merchant channel security, not agent-to-merchant identity/trust signaling.", "evidenceIds": [ "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-webhooks", "paypal-ac-probe-rt-1" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-order-attribution", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers agent-initiated checkout flows (ACP/UCP/Store Sync/cart API/agent toolkit) but nowhere describes orders being tagged with an originating-agent identifier, nor any merchant dashboard/report/filter capability by agent; in fact Store Sync docs state orders arrive 'just as it would from any other channel,' suggesting no special agent attribution.", "evidenceIds": [ "paypal-ac-supp-store-sync", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-getcart" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-order-tracking", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's agent toolkit and REST surface explicitly advertise agent access to 'orders...shipment tracking, transaction details' for post-purchase queries, and the agent-tools page lists concrete order-related functions (create_order, pay_order, create_shipment) alongside webhooks for order events. However, no specific 'get_order_status' or 'track_shipment' tool call is named or demonstrated end-to-end, so the tracking-query capability is asserted at a high level rather than shown working. Missing for 10: an explicitly named order-status/tracking query tool/function, and independent or hands-on confirmation that an agent can actually retrieve tracking info post-purchase.", "evidenceIds": [ "paypal-agent-commerce-docs-10", "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-webhooks", "paypal-ac-probe-rt-2" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-traffic-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows PayPal gates agentic-commerce access at the platform/onboarding level (Braintree account, Google UCP registration, PayPal AI-team approval form) and gives merchants brand/communication control, but nothing describes merchant-configurable rate limits or per-agent/per-platform allow/deny controls over catalog or checkout access.", "evidenceIds": [ "paypal-ac-supp-agent-ready", "paypal-ac-supp-acs-gate", "paypal-ac-supp-store-sync" ] }, { "productId": "paypal-agent-commerce", "storyId": "agent-wallet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "All evidence describes merchant-side infrastructure (Agent Ready, Store Sync, agent toolkit, cart APIs) that lets AI agents check out with merchants or lets merchants build agents for order/refund/dispute management — none of it describes a consumer-provisioned wallet that a user funds, an agent holds/spends from, with balance visibility. The delegated tokens in ACP/UCP are single-use, merchant-bound checkout credentials, not a persistent user wallet.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "There's a confirmed live llms.txt at developer.paypal.com/llms.txt (HTTP 200) plus per-page .md agent-readable docs (e.g. agent-ready/overview.md), and the docs are explicitly agent-oriented (MCP server, agent toolkit, ACP/UCP guides) that an AI agent could consume directly. Missing for 10: no independent third-party report of an agent actually consuming llms.txt successfully in the wild, just first-party probes.", "evidenceIds": [ "paypal-agent-commerce-probe-1", "paypal-agent-commerce-probe-2", "paypal-agent-commerce-probe-3", "paypal-ac-probe-rt-1" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence documents PayPal's agentic commerce stack (Agent Ready, Store Sync, cart APIs, agent toolkit, MCP server) purely as infrastructure enabling AI agents to browse catalogs, create carts, and complete transactions on a merchant's behalf — none of it shows PayPal analyzing a user's/merchant's own data to surface AI-generated insights or suggestions inside the product (e.g., analytics dashboards, business recommendations). The dispute/order/refund tools are action endpoints for agents to execute tasks, not insight-generation features.", "evidenceIds": [ "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-refund-dispute-tools", "paypal-agent-commerce-docs-9" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal provides the building blocks for background automation — an agent toolkit with pre-built functions (orders, refunds, disputes, subscriptions) usable in LangChain/CrewAI/Bedrock workflows, an MCP server for natural-language triggered actions, and webhooks that fire asynchronously with retry logic — enabling autonomous background agent workflows. However, PayPal's own docs explicitly recommend keeping 'human oversight in areas where personal judgment matters most,' and much of the deeper commerce automation (Store Sync, agentic commerce services) is gated behind manual application forms rather than self-serve autonomous setup. Missing for 10: evidence of a fully autonomous, unattended scheduling/orchestration layer, independent confirmation of agents running unattended in production, and self-serve (non-form-gated) enablement.", "evidenceIds": [ "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-webhooks", "paypal-ac-probe-rt-1", "paypal-ac-probe-rt-2", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-acs-gate" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack is entirely about PayPal enabling external AI agents (ChatGPT, Gemini, third-party MCP clients, or developer-built agents via the Agent Toolkit) to transact through PayPal/Braintree — it is infrastructure for other assistants to use PayPal, not a built-in AI assistant inside PayPal's own product that an end user delegates tasks to. No citation shows a first-party PayPal assistant a user converses with directly.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's agent toolkit (npm/PyPI packages) and REST APIs, plus the sandbox environment, can be scripted headlessly and invoked from CI pipelines via SDKs (LangChain, CrewAI, OpenAI Agents SDK, MCP) without a UI; webhooks and sandbox credentials support automated testing. However the remote MCP server requires interactive OAuth/PKCE authorization flow (dynamic client registration, bearer auth), which complicates pure headless/CI use, and there's no explicit CI/automation guide or example pipeline in the evidence. missing for 10: documented headless auth flow for CI (service-account/client-credentials for MCP), explicit CI/automation examples, and independent confirmation of unattended operation.", "evidenceIds": [ "paypal-ac-supp-agent-toolkit", "paypal-ac-probe-rt-2", "paypal-ac-supp-sandbox", "paypal-ac-probe-rt-1", "paypal-ac-supp-rest-overview" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal Agentic Commerce is a payments/commerce platform that exposes its own APIs as tools to AI agents (via its MCP server and agent toolkit) — it is not itself an agent or orchestrator that a user configures with external MCP servers to expand its own tool access. The story's premise (plugging MCP servers into the product so it can use their tools) is a category error for a commerce backend/tool-provider like this.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal documents and runtime-probes an official MCP server (developer.paypal.com/ai-tools/mcp-server) plus a published agent-toolkit npm/PyPI package explicitly listing MCP as a supported integration, and a live probe confirms the remote MCP endpoint (mcp.paypal.com/mcp) responds with proper OAuth-protected-resource metadata. missing for 10: independent/community hands-on confirmation of a successful end-to-end MCP client connection (beyond PayPal's own docs and the auth-handshake probe), and clearer documentation of the full tool list exposed over MCP.", "evidenceIds": [ "paypal-agent-commerce-docs-9", "paypal-agent-commerce-probe-3", "paypal-ac-probe-rt-1", "paypal-ac-probe-rt-2", "paypal-ac-supp-agent-toolkit" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal supports natural-language operation via its MCP server and agent toolkit (LangChain, OpenAI Agents SDK, CrewAI, etc.), letting AI agents issue commands for orders, refunds, disputes, and shopping carts in conversational form, and a runtime probe confirms the MCP endpoint is live. However, the 'user' operating this isn't typically an end consumer speaking to PayPal directly — most flows are merchant-hosted or gated behind Braintree/Google/form approval, and the natural-language surface is mediated through third-party chat assistants (ChatGPT, Gemini) or developer-built agents rather than a native PayPal NL interface. missing for 10: independent/hands-on evidence of an end user directly issuing free-form natural-language commands to PayPal itself (not via a third-party chat assistant or developer-built agent), and confirmation the MCP server/agent toolkit works smoothly without heavy setup/gating.", "evidenceIds": [ "paypal-agent-commerce-docs-9", "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-probe-rt-1", "paypal-ac-probe-rt-2", "paypal-ac-supp-agent-ready", "paypal-ac-supp-acs-gate" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents PayPal's Agent Toolkit, MCP server, REST APIs, and SDKs, but nowhere mentions an official command-line interface (CLI) tool for developers or AI-native users to interact with PayPal's agentic commerce services. Since PayPal is a developer-facing platform with APIs and SDKs, a CLI would be a plausible product offering, but none is evidenced here.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal publishes extensive, concrete developer documentation (REST API reference, Agent Toolkit, MCP server, agentic-commerce cart API, Store Sync, ACP/UCP guides) with runtime confirmation of a live MCP endpoint and published npm/PyPI SDK packages, giving AI-native developers a genuinely documented public API surface to build against. Missing for 10: some flows are form-gated/partner-gated (Braintree, Store Sync approval) rather than fully self-serve, slightly limiting pure API-driven access.", "evidenceIds": [ "paypal-agent-commerce-docs-8", "paypal-agent-commerce-docs-9", "paypal-agent-commerce-docs-11", "paypal-agent-commerce-docs-12", "paypal-ac-supp-agent-toolkit", "paypal-ac-probe-rt-1", "paypal-ac-probe-rt-2", "paypal-ac-supp-rest-overview", "paypal-ac-supp-sandbox" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "There's no explicit 'issue a scoped API key/token for an agent' feature for the general Agent Toolkit or REST API surface, but agent-specific payment tokens are documented as scoped/least-privilege by design — the ACP delegated token is 'bound to your merchant ID and includes amount and time restrictions that you can configure,' and the MCP server enforces OAuth with PKCE and dynamic client registration rather than static keys. This shows some least-privilege credentialing pattern for agent checkout flows but not a general-purpose scoped-credential system for arbitrary agent API access. Missing for 10: documented scope/permission tiers (e.g., read-only vs write) for the Agent Toolkit or REST OAuth tokens, and any self-serve UI/API to mint restricted credentials per agent.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-probe-rt-1", "paypal-ac-supp-cart-reverse-api" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal publishes an official Agent Toolkit SDK (npm/PyPI, versioned and actively published) integrating with MCP, OpenAI Agents SDK, LangChain, CrewAI, Vercel AI SDK, and Bedrock, plus documented pre-built functions for orders, invoices, subscriptions, refunds, disputes, and catalog management, backed by REST API docs, sandbox testing, and webhooks. This is corroborated by runtime probes confirming the toolkit is live on public registries and the MCP server is reachable. Missing for 10: independent third-party developer reviews/case studies of building against these SDKs beyond PayPal's own docs and registry probes.", "evidenceIds": [ "paypal-agent-commerce-docs-8", "paypal-agent-commerce-docs-9", "paypal-agent-commerce-docs-10", "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-probe-rt-2", "paypal-ac-probe-rt-1", "paypal-ac-supp-sandbox", "paypal-ac-supp-rest-overview", "paypal-agent-commerce-gh-1" ] }, { "productId": "paypal-agent-commerce", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PayPal's webhook API is explicitly documented: merchants can subscribe up to 10 webhook URLs per app, scoped to specific event types, with durable retry (25 attempts over 3 days) and signature verification guidance — enabling event-driven, agentic integrations. Missing for 10: explicit agentic-commerce-specific event types (e.g., cart/order events tied to AI checkout flows) and independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "paypal-ac-supp-webhooks", "paypal-ac-supp-rest-overview" ] }, { "productId": "paypal-agent-commerce", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows static API reference pages (createcart, getcart) and REST API docs, plus a sandbox environment for testing, but nothing describing an interactive reference with embedded runnable/try-it-out examples (e.g., live code execution in docs, Swagger-style console). Missing for 10: any mention of an interactive API console, embedded runnable code snippets, or in-docs request execution.", "evidenceIds": [ "paypal-agent-commerce-docs-11", "paypal-agent-commerce-docs-12", "paypal-ac-supp-rest-overview", "paypal-ac-supp-sandbox" ] }, { "productId": "paypal-agent-commerce", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents REST API references, SDKs, webhooks, and endpoint descriptions (e.g., createcart/getcart docs), but nowhere mentions a downloadable OpenAPI/Swagger file or other machine-readable spec artifact for the agentic-commerce or general PayPal APIs. This axis is clearly applicable to an API-based commerce product, but no evidence shows PayPal exposing such a spec for download.", "evidenceIds": [ "paypal-ac-supp-rest-overview", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-getcart" ] }, { "productId": "paypal-agent-commerce", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal documents a dedicated sandbox that mirrors production, allowing developers/agents to test agent-toolkit tools, cart API, and checkout flows without touching live accounts, and confirms the same REST rails (Orders, cart API) run against sandbox credentials. Missing for 10: no independent/hands-on verification of sandbox parity for agentic-commerce-specific flows (cart API, ACP/UCP checkout) and no explicit documentation of sandbox mode for the MCP server or agent toolkit specifically.", "evidenceIds": [ "paypal-ac-supp-sandbox", "paypal-ac-supp-rest-overview", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-agent-toolkit" ] }, { "productId": "paypal-agent-commerce", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack documents PayPal's agentic-commerce APIs (createcart, getcart, agent toolkit, REST APIs) including a versioned path like /v1/createcart, but nowhere is there any documented deprecation policy, versioning strategy, or backward-compatibility commitment for AI agents to rely on. The axis is clearly applicable (PayPal is an API-first commerce platform) but no supporting evidence exists.", "evidenceIds": [ "paypal-agent-commerce-docs-11", "paypal-agent-commerce-docs-12", "paypal-ac-supp-rest-overview" ] }, { "productId": "paypal-agent-commerce", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows only single-item agent tools (create_order, create_refund, get_dispute, etc.) and a one-time bulk catalog feed upload for merchant setup, but no documented bulk/batch operation capability (e.g., batch refunds, batch order processing, multi-item transaction endpoints) that an AI agent could invoke across many items at once.", "evidenceIds": [ "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-create-catalog" ] }, { "productId": "paypal-agent-commerce", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows PayPal offers webhooks (event notifications) and an agent toolkit with individual API tools, but nothing resembling a rules engine where a user defines 'if event X then action Y' automation — webhooks merely deliver raw event notifications that require the merchant to write custom code to act on, not a rule-definition interface. Missing for 10: any rule-builder/automation-trigger UI or API, conditional logic definition, and evidence of automatic action execution tied to rules rather than manual webhook handling.", "evidenceIds": [ "paypal-ac-supp-webhooks" ] }, { "productId": "paypal-agent-commerce", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers PayPal's agent toolkit for orders, invoices, subscriptions, refunds, disputes, and MCP/agent-framework integrations, but none of it describes any capability for an AI-native user to schedule recurring jobs or automated workflows (e.g., cron-like triggers, recurring agent task execution). 'Subscriptions' access is a payment-billing object type merchants can query, not a workflow-scheduling feature for AI agents themselves. missing for 10: any scheduling/cron mechanism, recurring workflow orchestration, or documented recurring-task automation for AI-native users.", "evidenceIds": [ "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-refund-dispute-tools", "paypal-agent-commerce-docs-10" ] }, { "productId": "paypal-agent-commerce", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers payment protocols, catalog sync, agent toolkit tools, and webhooks, but nothing addresses versioning, reviewing, or rolling back agent-configured automations themselves — no changelog, audit history, or rollback mechanism for automation workflows is documented.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "catalog-feed-publish", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal documents a real catalog-publishing path (Store Sync with feed specs like Google Product Feed/OpenAI ACP Product Feed, CSV/TSV/PSV, field requirements) that explicitly targets AI-agent discovery, plus partner-based catalog connections (Wix, Cymbio, BigCommerce/Feedonomics, Shopware). However, access is form-gated (not self-serve), scope is narrow (US-only, physical goods, USD only), and eligibility requires an existing PayPal/Braintree merchant account with compatible setup. missing for 10: self-serve onboarding without a sales-gated form, broader product-type/geography coverage, independent merchant confirmation the feed import actually surfaces products in live agent surfaces (ChatGPT/Gemini) rather than only demo/spec documentation.", "evidenceIds": [ "paypal-agent-commerce-docs-4", "paypal-agent-commerce-docs-5", "paypal-agent-commerce-docs-6", "paypal-ac-supp-acs-gate", "paypal-ac-supp-store-sync", "paypal-ac-supp-create-catalog" ] }, { "productId": "paypal-agent-commerce", "storyId": "chat-surface-checkout", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal offers real infrastructure for in-chat checkout: ACP for ChatGPT (via Braintree delegated tokens), UCP for Google AI Mode/Gemini (via Google Pay tokens), and Store Sync for broader catalog/agent discovery, plus an MCP server and agent toolkit. However, coverage is fragmented and gated — Store Sync is US-only, physical-goods-only, and access is form-gated with manual onboarding; ACP/UCP require an existing Braintree relationship or separate Google merchant registration; no evidence of Claude or Copilot checkout support is present. Missing for 10: broader platform coverage beyond ChatGPT/Google (Claude, Copilot), self-serve enablement without form gating, and independent/hands-on confirmation of live buyer transactions completing in-chat.", "evidenceIds": [ "paypal-ac-supp-agent-ready", "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-store-sync", "paypal-ac-supp-acs-gate", "paypal-ac-supp-create-catalog", "paypal-ac-probe-rt-1" ] }, { "productId": "paypal-agent-commerce", "storyId": "checkout-spec-versioned", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "PayPal does version its agentic-commerce cart API (v1 createcart/getcart) and provides catalog-feed validation tooling for Store Sync ('a validated product catalog file' against Google/OpenAI ACP feed specs), and it interoperates with external versioned protocols (ACP, UCP). But there's no evidence of a published, standalone schema (e.g., OpenAPI/JSON Schema) for PayPal's own agentic-commerce protocol nor a formal conformance/test suite for developers to validate protocol implementations beyond feed-file field checks. Missing for 10: published protocol schema/spec document, dedicated conformance or validation test suite for the cart/checkout API (not just catalog feed format), and independent evidence of developers using such tooling.", "evidenceIds": [ "paypal-agent-commerce-docs-11", "paypal-agent-commerce-docs-12", "paypal-ac-supp-create-catalog", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-getcart" ] }, { "productId": "paypal-agent-commerce", "storyId": "dispute-handling-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "The agent toolkit exposes dispute tools — list_disputes, get_dispute, and accept_dispute_claim — plus the general REST API surface explicitly lists 'disputes' alongside orders/payments, giving developers programmatic access to dispute status and resolution outcomes. However, no evidence-submission endpoint (e.g., uploading documents/evidence for a dispute) is documented anywhere in the pack, so the 'evidence submission' part of the story is unsupported. missing for 10: documented evidence-submission API/tool for disputes, and any hands-on/independent confirmation that these dispute tools work end-to-end in production.", "evidenceIds": [ "paypal-ac-supp-refund-dispute-tools", "paypal-agent-commerce-docs-10", "paypal-ac-supp-rest-overview", "paypal-ac-supp-agent-toolkit" ] }, { "productId": "paypal-agent-commerce", "storyId": "fees-transparency-agent-payments", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Evidence shows agent-originated transactions run through existing Braintree/PayPal Checkout rails and thus inherit the standard published US commercial fee schedule (2.99–4.99% + fixed fee), so merchants aren't quoted a hidden or sales-negotiated rate for the payment processing itself. However, the same evidence explicitly states 'No separate agentic/AI-channel fee schedule is published,' and access to Agent Ready/Store Sync/ACS is gated behind a sales-contact form, leaving open whether any additional platform or enablement fee applies to the agentic channel — so a merchant cannot fully price the agentic channel without engaging sales for onboarding. Missing for 10: an explicit agentic-channel fee page or fee line item, and self-serve (non-form-gated) enrollment that would let a merchant confirm total costs without sales contact.", "evidenceIds": [ "paypal-ac-supp-fees", "paypal-ac-supp-acs-gate", "paypal-ac-supp-store-sync" ] }, { "productId": "paypal-agent-commerce", "storyId": "http-402-machine-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "All evidence describes PayPal's agentic commerce as checkout-flow based (carts, ACP/UCP delegated tokens, Store Sync, agent toolkit for orders/refunds/disputes) — none of it describes HTTP 402 status-code machine payments or per-call API monetization without a checkout UI, which is a distinct technical pattern. Since PayPal is a payments platform, this axis could plausibly apply, but there is no evidence it ships or supports the 402 pay-per-call mechanism described in the story.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "human-approval-gate", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's ACP/UCP flows use single-use, time- and amount-bound delegated tokens tied to a specific merchant and transaction, and the toolkit docs explicitly recommend 'human oversight' for judgment-sensitive actions — both suggest transaction-level guardrails rather than fully autonomous spending. However, the evidence never documents an explicit user-facing confirmation screen, signed mandate artifact, or per-purchase consent UI shown to the end user before the token is used to move money; the checkout flow (requestCheckout/Instant Checkout) is described only at a technical/token level, not from the consent-UX perspective. Missing for 10: an explicit documented consent/confirmation step or mandate artifact shown to the payer, and any independent/hands-on confirmation that this consent step actually blocks unauthorized charges.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-cart-reverse-api" ] }, { "productId": "paypal-agent-commerce", "storyId": "merchant-agent-onboarding", "verdict": "partial", "quality": 5, "confidence": "high", "rationale": "There is documented onboarding material (Agent Ready guides, Store Sync docs, catalog feed specs), but the path is explicitly gated rather than self-serve: PayPal's own docs state that agentic commerce services access is 'form-gated, not self-serve' requiring a form submission and manual follow-up from PayPal's AI team, Store Sync eligibility requires an existing Braintree/Orders v2 account plus the same approval gate, and the UCP/Google Pay path requires separate 'merchant registration with Google. Contact Google for enablement.' Agent Ready itself assumes an existing Braintree merchant relationship rather than a simple toggle or self-issued agreement. Missing for 10: a true no-approval self-serve enablement (setting flip, standard clickthrough agreement, or endpoint publish without a contact-form/manual review step), and confirmation of approval turnaround time.", "evidenceIds": [ "paypal-ac-supp-acs-gate", "paypal-ac-supp-agent-ready", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-store-sync", "paypal-ac-supp-create-catalog" ] }, { "productId": "paypal-agent-commerce", "storyId": "multi-implementer-adoption", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows PayPal/Braintree acting as an implementer of protocols defined by other parties (OpenAI's ACP, Google's UCP, and the Anthropic-originated MCP), but nothing shows independent third parties implementing PayPal's own agentic-commerce platform (Cart API, Store Sync, agent toolkit) as an open ecosystem. Merchants and partners (Wix, Shopware, BigCommerce) are consumers/integrators of PayPal's platform, not independent implementers of its protocol.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-store-sync", "paypal-ac-supp-acs-gate" ] }, { "productId": "paypal-agent-commerce", "storyId": "open-spec-published", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows PayPal implements OpenAI's ACP and Google's UCP protocols and tells developers to 'follow the ACP agentic checkout specification,' but never provides or links a version number, license, or spec document for ACP/UCP that a developer could read independently of PayPal. Instead, everything documented is gated: Braintree merchant account required, PayPal AI team form-approval required for agentic commerce services, and separate Google merchant registration required for UCP enablement — none of this evidences an open, versioned, sign-nothing spec.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-acs-gate", "paypal-ac-supp-agent-ready" ] }, { "productId": "paypal-agent-commerce", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's agent toolkit and REST APIs expose a broad set of merchant operations (orders, invoices, subscriptions, refunds, disputes, shipment tracking, catalog management) that mirror much of what's doable in the PayPal/Braintree dashboards, and there's a documented MCP server, SDKs, and sandbox for building against these. However, the flagship agentic-commerce paths are heavily gated rather than self-serve: Agent Ready requires a Braintree account, Store Sync and Agentic Commerce Services require a manual form-based approval process, UCP requires separate Google merchant registration, and Store Sync itself is scoped only to US physical goods in USD — none of which are pure API-driven equivalents of UI actions. Missing for 10: explicit UI-vs-API feature-parity mapping, self-serve (non-gated) access to the agentic commerce APIs, and confirmation that all dashboard-level configuration/reporting is API-accessible without approval gates.", "evidenceIds": [ "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-acs-gate", "paypal-ac-supp-store-sync", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-rest-overview", "paypal-ac-supp-sandbox" ] }, { "productId": "paypal-agent-commerce", "storyId": "openness-full-export", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal Agentic Commerce is a payments/commerce integration platform for merchants and AI agents, not a personal data-holding service with a user data-export/portability feature; no evidence pack item concerns exporting personal account data or leaving the platform.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "PayPal's agentic commerce services (Store Sync, ACP/UCP integrations, agent toolkit) are proprietary hosted APIs and closed-source integrations; the agent-toolkit SDK is published on npm/PyPI but no evidence indicates an open-source license for its source, and core commerce services (Store Sync, cart API, MCP server backend) are entirely closed, gated behind forms and merchant accounts. No evidence pack item shows an open-license repository for the product's source.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal Agentic Commerce is a hosted payments/commerce SaaS platform tied to PayPal's merchant accounts, processing infrastructure, and proprietary services (Braintree, Store Sync, hosted Agentic Commerce APIs) — self-hosting the core product is a category error since the core value is PayPal's regulated payment processing, which cannot be run independently by a customer.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "order-event-webhooks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's generic webhooks system (developer.paypal.com/api/webhooks/overview) lets a merchant subscribe up to 10 URLs to specific event types, with durable retry (up to 25 attempts/3 days) and signature verification — and the agent-toolkit/cart API run on the same REST/order rails, so this infrastructure would carry order events. However, no evidence pack item explicitly names order-lifecycle event types (ORDER.CREATED/UPDATED/CANCELLED/fulfilled) tied to the agentic-commerce cart or Store Sync flows — those docs describe merchant-hosted reverse endpoints (createcart/getcart) rather than push-based lifecycle events for agents. Missing for 10: explicit order-lifecycle event-type list for agentic commerce, confirmation that Store Sync/cart orders emit standard webhook events, and any hands-on/independent proof of an agent successfully subscribing to these events.", "evidenceIds": [ "paypal-ac-supp-webhooks", "paypal-ac-supp-rest-overview", "paypal-ac-supp-cart-reverse-api", "paypal-ac-supp-getcart" ] }, { "productId": "paypal-agent-commerce", "storyId": "payable-service-directory", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal provides discovery mechanisms — Store Sync product-catalog feeds (Google Product Feed / OpenAI ACP Product Feed) that let AI agents 'discover your products' and a live MCP server discoverable via RFC 9728 well-known metadata — but there is no published cross-merchant directory or marketplace index of payable services/APIs; discovery is scoped to a single merchant's catalog after form-gated onboarding, and Store Sync itself is limited to US physical goods only. missing for 10: a cross-merchant/public discovery index of payable services or APIs, evidence of self-serve (non form-gated) discoverability, and support beyond US physical goods.", "evidenceIds": [ "paypal-agent-commerce-docs-5", "paypal-ac-supp-store-sync", "paypal-ac-supp-create-catalog", "paypal-ac-supp-acs-gate", "paypal-ac-probe-rt-1", "paypal-agent-commerce-probe-3" ] }, { "productId": "paypal-agent-commerce", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal Agentic Commerce is a payments/checkout API and agent-toolkit product, not a data storage/hosting platform; data residency/region selection is not a capability category this kind of product offers or that buyers would compare it on. No evidence pack item addresses residency at all, confirming it's outside scope rather than a gap.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal Agentic Commerce is a payments/commerce integration product, not an AI model provider or data controller for AI training; controlling whether personal data is used to train AI models is outside its product category and not addressed anywhere in the evidence.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers agentic commerce protocols, cart APIs, webhooks, fees, and toolkit integrations, but contains no mention of data retention policies, deletion controls, or privacy settings that an AI-native user could invoke to manage stored data. This axis plausibly applies to a payments platform handling AI agent transaction data, but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal Agentic Commerce is a payments/commerce infrastructure product for merchants and AI agent developers, not a data-collecting SaaS tool with user-facing telemetry settings; the concept of an end-user 'opting out of telemetry/usage tracking' as a privacy control does not map onto this product's category. No evidence pack item addresses telemetry opt-out, so the axis is a category mismatch rather than an unmet capability.", "evidenceIds": [] }, { "productId": "paypal-agent-commerce", "storyId": "refund-via-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "The Agent Toolkit exposes create_refund/get_refund tools and dispute tools (list_disputes, get_dispute, accept_dispute_claim) so refunds on agent-placed orders can be initiated and tracked programmatically via MCP/LangChain/etc., backed by the underlying PayPal REST orders/disputes API and webhooks for status updates. However, the docs don't specifically address refund flows tied to the new agentic-commerce cart/checkout (ACP/UCP) orders, and there's no independent hands-on confirmation of refund success for agent-originated transactions. missing for 10: explicit documentation linking refund/dispute tools to agent-placed (ACP/UCP/Store Sync) orders specifically, and independent/hands-on verification of the refund tracking flow.", "evidenceIds": [ "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-agent-toolkit", "paypal-ac-supp-webhooks", "paypal-ac-probe-rt-2", "paypal-ac-supp-rest-overview" ] }, { "productId": "paypal-agent-commerce", "storyId": "scoped-payment-tokens", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's ACP/UCP flows use Braintree single-use payment tokens/nonces that are explicitly described as 'bound to your merchant ID and includes amount and time restrictions that you can configure' — a genuine scoped, limited-use credential rather than a raw card number, and Google's UCP path similarly returns a tokenized, single-use credential. However this is merchant-side infrastructure (tokens generated by the merchant's Braintree integration for a specific checkout), not a consumer/end-user-controlled credential that an AI-native user personally hands to their own agent with self-set amount/expiry/merchant limits; there's no evidence of a user-facing wallet-style scoped credential issuance flow. missing for 10: end-user-facing UI/API for a consumer to mint their own scoped credential (set their own amount cap, expiry, merchant allowlist) independent of a specific merchant checkout session, and independent/hands-on confirmation of these restriction configs working in practice.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-cart-reverse-api" ] }, { "productId": "paypal-agent-commerce", "storyId": "settlement-payout-clarity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Agent-originated orders flow into the merchant's existing order management, payment, refund/dispute, and webhook systems (create_order, refund/dispute tools, webhooks with signature verification, existing Orders v2/Braintree rails), and docs explicitly state Store Sync orders arrive 'just as it would from any other channel,' suggesting standard reconciliation. However, there is no dedicated agentic-channel reporting/settlement documentation, no separate transaction tagging or reconciliation report distinguishing agent-originated payments, and fee schedules show no distinct line item for agent transactions, making channel-level reconciliation an inference rather than a documented flow. missing for 10: dedicated agent-channel reporting/settlement statements, explicit reconciliation tooling or transaction tags identifying agent-originated payments, independent merchant confirmation of clean reconciliation in production.", "evidenceIds": [ "paypal-ac-supp-store-sync", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-webhooks", "paypal-ac-supp-fees", "paypal-ac-supp-rest-overview", "paypal-ac-supp-cart-reverse-api" ] }, { "productId": "paypal-agent-commerce", "storyId": "spend-caps-revocation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows per-transaction delegated tokens with configurable amount/time restrictions bound to a merchant (paypal-ac-supp-acp-chatgpt), but nothing about a user or merchant setting persistent per-agent spend caps/usage limits across multiple transactions, or an instant revoke-authority mechanism for a given agent's payment access. No dashboard, API, or docs reference for agent-level authorization management or revocation is present.", "evidenceIds": [ "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-cart-reverse-api" ] }, { "productId": "paypal-agent-commerce", "storyId": "stablecoin-settlement", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack details PayPal's agentic commerce rails extensively (ACP/UCP via Braintree tokens, agent toolkit, cart APIs, webhooks, fees) but none of it mentions stablecoins, PYUSD, crypto, or blockchain-based settlement rails for agent-initiated payments — all documented settlement is via traditional card/Braintree processing and standard PayPal fee schedules.", "evidenceIds": [ "paypal-ac-supp-agent-ready", "paypal-ac-supp-acp-chatgpt", "paypal-ac-supp-ucp-googlepay", "paypal-ac-supp-fees" ] }, { "productId": "paypal-agent-commerce", "storyId": "structured-offer-data", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's Store Sync catalog feed spec and agent-toolkit's list_product/show_product_details tools do define machine-readable offer fields (id, title, price, availability, description, image_link, link — with each row representing a product variant) and cart-read endpoints expose price/checkout totals, so the core data model the story asks for exists. But this is a gated, merchant-onboarding pathway (form approval required, US-only physical goods, Braintree/PayPal-account prerequisite) rather than an open read surface for 'any listed product,' and there's no evidence of a simple public GET-offer endpoint or checkout-link retrieval independent of the full agentic-commerce integration. Missing for 10: an open/self-serve read API (vs form-gated onboarding), broader product/geography scope, explicit example of returning a checkout link, independent/hands-on corroboration of reading catalog data.", "evidenceIds": [ "paypal-ac-supp-create-catalog", "paypal-ac-supp-store-sync", "paypal-ac-supp-refund-dispute-tools", "paypal-ac-supp-getcart", "paypal-ac-supp-acs-gate" ] }, { "productId": "shopify-ucp", "storyId": "agent-cart-create", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Cart MCP and Checkout MCP are documented UCP protocol calls (create_cart, update_cart, create_checkout, complete_checkout) with JSON-RPC schemas, and a runtime probe confirms a real cart was created keylessly against a live Shopify store via the CLI/protocol. missing for 10: no independent (non-Shopify) hands-on corroboration of a full end-to-end checkout completion.", "evidenceIds": [ "shopify-ucp-supp-cart-mcp", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-probe-rt-3", "shopify-ucp-docs-23", "shopify-ucp-docs-24" ] }, { "productId": "shopify-ucp", "storyId": "agent-catalog-search", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Shopify's Global Catalog MCP server explicitly supports keyless, self-service cross-merchant product search ('search and discover products across the entire Shopify ecosystem... from multiple merchants'), requiring only a self-hosted UCP agent profile URL rather than a private partnership — confirmed by a live runtime probe showing a full keyless JSON-RPC handshake and catalog search against catalog.shopify.com/api/ucp/mcp, and another probe showing the profile-gate behaves as documented (self-service profile, not vendor approval). Storefront-level search is similarly self-service per-merchant. Missing for 10: independent (non-Shopify) developer corroboration of onboarding friction, and confirmation that profile creation itself has no gatekeeping/approval step.", "evidenceIds": [ "shopify-ucp-supp-global-catalog", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-4", "shopify-ucp-supp-agent-profiles", "shopify-ucp-supp-storefront-catalog" ] }, { "productId": "shopify-ucp", "storyId": "agent-checkout-complete", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs describe a full documented path — create_checkout, payment_handlers (e.g. com.google.pay) negotiation, complete_checkout requiring a collected payment credential, and order confirmation via get_order/order webhooks — and even name complete_checkout as Token-tier gated 'when the token is granted permission to complete purchases.' However, the default flow explicitly hands off to the buyer's browser for payment ('Build carts, convert them to checkouts, and hand off to the merchant for payment') and the only hands-on runtime probe reached cart creation only, explicitly stopping 'no checkout, no payment.' Missing for 10: an independent/hands-on trace of an actual complete_checkout call with a delegated payment credential and a resulting confirmed order, and clarity on how broadly (vs. only select trusted agents) autonomous payment completion is actually granted.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-buyer-handoff", "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-order-mcp", "shopify-ucp-supp-order-webhooks", "shopify-ucp-probe-rt-3" ] }, { "productId": "shopify-ucp", "storyId": "agent-fraud-liability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents UCP's protocol mechanics (catalog, cart, checkout, order webhooks, trust tiers, profile negotiation) but nowhere specifies fraud liability, chargeback responsibility, or dispute-resolution rules for agent-initiated purchases. The only tangential mention is UCP's general 'Merchant of Record' framing on ucp.dev, which addresses customer-relationship ownership, not who bears fraud/chargeback risk in an agent transaction — no Shopify-specific policy, contract terms, or dispute process is documented.", "evidenceIds": [ "shopify-ucp-supp-ucp-governance" ] }, { "productId": "shopify-ucp", "storyId": "agent-identity-tiers", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Shopify's UCP documents a concrete three-tier trust model (Token, Signed, Anonymous) tied to agent identity, with Signed-tier requiring RFC 9421 ECDSA P-256 signature verification against a published public key in the agent's UCP profile, and access/rate-limits scaling with identification strength; a live probe confirms the trust gate actually enforces this (invalid_profile_url error when no hosted profile is presented). This gives merchants a verifiable way to distinguish anonymous vs. cryptographically-signed vs. token-authenticated agent traffic. missing for 10: no independent/third-party audit of the signature verification in production merchant traffic, and no merchant-facing dashboard/reporting evidence showing how tier data is surfaced to merchants themselves.", "evidenceIds": [ "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-agent-profiles", "shopify-ucp-probe-rt-4", "shopify-ucp-docs-9", "shopify-ucp-docs-27" ] }, { "productId": "shopify-ucp", "storyId": "agent-order-attribution", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Cart/checkout objects carry explicit agent-attribution metadata (referring_domain, click_id_tag, activity_id, utm_* fields) and orders are tied to a specific agent's UCP profile via checkout creation, giving Shopify the raw data needed to attribute orders to an agent. However, there is no evidence of a merchant-facing report, analytics dashboard, or order-list filter that lets a merchant actually query or segment transactions by originating agent — only developer-facing MCP/webhook data plumbing is documented. Missing for 10: merchant admin UI or reporting API to filter/segment orders by agent, aggregate agent-performance analytics, independent confirmation that attribution data surfaces in Shopify's order admin.", "evidenceIds": [ "shopify-ucp-supp-cart-mcp", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-order-webhooks", "shopify-ucp-supp-order-mcp", "shopify-ucp-supp-agent-profiles" ] }, { "productId": "shopify-ucp", "storyId": "agent-order-tracking", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Order MCP's get_order explicitly returns current order state (line items, fulfillment events, post-purchase adjustments) for orders placed via the agent, complemented by push order webhooks for tracking updates, and this is documented with concrete access/scope details (Token-tier, read_global_api_orders scope). The quickstart even walks through discovery-to-order-tracking as a first-party flow. Missing for 10: independent/third-party hands-on confirmation of get_order in production (only first-party docs/probes), and no evidence of consumer-facing tracking UI beyond the API/webhook mechanism.", "evidenceIds": [ "shopify-ucp-docs-7", "shopify-ucp-supp-order-mcp", "shopify-ucp-supp-order-webhooks", "shopify-ucp-docs-19", "shopify-ucp-docs-30" ] }, { "productId": "shopify-ucp", "storyId": "agent-traffic-controls", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Shopify's UCP documents a platform-wide trust-tier system (Token/Signed/Anonymous) where 'rate limits scale with identification' and certain tools (like complete_checkout or Order MCP) are gated to higher trust tiers, which provides some rate-limiting infrastructure. However, this is a Shopify-controlled protocol mechanism based on identification strength, not a merchant-facing dashboard/setting to specifically allow, deny, or rate-limit named agents or agent platforms (e.g. blocking 'Agent X' or 'Platform Y' by name). Missing for 10: merchant-configurable allow/deny lists for specific agents/platforms, merchant UI or API to set custom rate limits per agent, and any evidence of per-merchant policy enforcement beyond the global trust-tier scheme.", "evidenceIds": [ "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-agent-profiles", "shopify-ucp-supp-order-mcp" ] }, { "productId": "shopify-ucp", "storyId": "agent-wallet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Shopify's UCP evidence covers checkout, payment-handler negotiation (e.g., com.google.pay), and AP2 payment mandates/verifiable credentials tied to cart state, but there is no documentation of a user-funded, agent-held wallet construct with balance visibility — payment credentials are collected per-checkout, not provisioned as a standing wallet.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-docs-31", "shopify-ucp-supp-trust-tiers" ] }, { "productId": "shopify-ucp", "storyId": "agentic-agent-docs", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "Shopify does not host its own llms.txt (shopify.dev/llms.txt returns 404), but it provides extensive agent-oriented documentation reachable via .md suffixed URLs (e.g. shopify.dev/docs/agents.md returns 200 with structured content) covering catalog, cart, checkout, orders, and profiles — exactly the kind of agent-consumable docs the story asks for. The related UCP spec (ucp.dev/llms.txt) does serve a proper llms.txt index, showing the ecosystem partially satisfies this pattern even though Shopify's own domain doesn't. Missing for 10: a working llms.txt directly at shopify.dev, and independent (non-Shopify) confirmation that agents reliably parse these .md docs as intended.", "evidenceIds": [ "shopify-ucp-probe-1", "shopify-ucp-probe-2", "shopify-ucp-probe-rt-5", "shopify-ucp-docs-2", "shopify-ucp-docs-19" ] }, { "productId": "shopify-ucp", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "The evidence pack for Shopify Agentic Commerce (UCP) is entirely about enabling third-party AI agents to search, cart, checkout, and track orders on behalf of buyers — a transactional commerce protocol, not a feature for surfacing AI-generated insights or suggestions from a user's own data. This story is a category error for this product's scope.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "UCP's trust-tier model lets Token-tier agents call complete_checkout autonomously once granted permission, and order webhooks push background state updates to a registered endpoint without polling — both hint at unattended, background-capable agent operation. But there is no documented feature for an AI-native user to configure a scheduled or trigger-based automation (e.g., recurring reorders, price-watch, monitor-and-act loops) that runs unsupervised over time; the evidence only covers per-session agent tool calls (search/cart/checkout/order) and merchant-side webhook delivery, not user-configurable autonomous background jobs. Missing for 10: explicit scheduling/trigger mechanism, evidence of a persistent background agent process, and independent confirmation of real autonomous (no-human-in-loop) purchase completion.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-order-webhooks", "shopify-ucp-supp-buyer-handoff" ] }, { "productId": "shopify-ucp", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes Shopify's Universal Commerce Protocol (UCP) and MCP servers as the *backend* that external AI agents (ChatGPT, Claude, etc.) connect to in order to search, cart, and checkout on behalf of buyers — Shopify is the server/merchant side, not a built-in assistant that a user delegates tasks to within the product itself. Nothing in the pack describes an embedded assistant (e.g., a Shopify-hosted chat agent for store owners or shoppers) that a user interacts with directly and delegates tasks to inside Shopify's own UI. Missing for 10: any first-party built-in assistant UI/feature, evidence of a user directly delegating a task to an in-product assistant, and independent confirmation of such an assistant's existence.", "evidenceIds": [ "shopify-ucp-docs-1", "shopify-ucp-docs-11", "shopify-ucp-supp-ucp-journey" ] }, { "productId": "shopify-ucp", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The UCP CLI is explicitly designed as a scriptable, headless tool with structured commands (search, cart, checkout, order tracking) usable via npm install and local profile init, and probes confirm real keyless CLI runs against live endpoints (catalog search, cart creation) succeeding non-interactively — consistent with CI/automation use. missing for 10: no explicit CI pipeline example (e.g., GitHub Actions), no documented exit codes/machine-readable output format guarantees, and no independent third-party report of running it in a CI environment.", "evidenceIds": [ "shopify-ucp-docs-2", "shopify-ucp-docs-19", "shopify-ucp-docs-20", "shopify-ucp-supp-ucp-journey", "shopify-ucp-probe-rt-3", "shopify-ucp-probe-rt-4", "shopify-ucp-probe-5" ] }, { "productId": "shopify-ucp", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Shopify Agentic Commerce's entire evidence pack describes it as an MCP *server* provider (Catalog, Cart, Checkout, Order MCP servers) that AI agents connect to and consume — it is the tool-provider side of the UCP protocol, not a host/client product into which a user would plug third-party MCP servers. This story's axis (acting as an MCP client that ingests external servers' tools) is a category mismatch for a commerce backend whose role is to be the target integration, not the integrator.", "evidenceIds": [ "shopify-ucp-docs-1", "shopify-ucp-supp-ucp-journey", "shopify-ucp-supp-global-catalog", "shopify-ucp-supp-cart-mcp" ] }, { "productId": "shopify-ucp", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Shopify ships multiple official UCP-compliant MCP servers (Global Catalog, Storefront Catalog, Cart, Checkout, Order) plus a Storefront MCP, all documented and independently probe-verified with live handshakes (catalog.shopify.com/api/ucp/mcp, per-merchant endpoints) and real cart creation via the CLI. Agent identification/authentication via hosted profiles and tiered trust is also verified in runtime probes. Missing for 10: independent third-party (non-Shopify) developer accounts of connecting an arbitrary agent end-to-end beyond Shopify's own probes.", "evidenceIds": [ "shopify-ucp-supp-ucp-journey", "shopify-ucp-supp-global-catalog", "shopify-ucp-supp-storefront-catalog", "shopify-ucp-supp-cart-mcp", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-order-mcp", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-2", "shopify-ucp-probe-rt-3", "shopify-ucp-probe-rt-4", "shopify-ucp-docs-11" ] }, { "productId": "shopify-ucp", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Shopify's UCP stack is explicitly designed so a natural-language request to an AI assistant ('find me crewneck sweaters under $50') is mapped by a skill/plugin to the right structured UCP CLI/MCP command, and runtime probes confirm the underlying MCP catalog/cart tools actually work end-to-end (search, cart creation) via the CLI with a local profile. Missing for 10: independent third-party evidence of a user issuing free-form natural-language commands (only one first-party doc line makes this claim) and no evidence of NL support beyond the catalog-search example (checkout/order flows are shown as structured CLI/MCP calls, not demonstrated NL-driven).", "evidenceIds": [ "shopify-ucp-docs-13", "shopify-ucp-docs-1", "shopify-ucp-supp-ucp-journey", "shopify-ucp-probe-rt-3", "shopify-ucp-probe-rt-1" ] }, { "productId": "shopify-ucp", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Shopify documents and ships an official UCP CLI (`@shopify/ucp-cli`) with structured commands for catalog search, cart building, checkout, and order tracking, backed by a quickstart guide and runtime probes confirming live functionality (cart creation, catalog search) against real endpoints. missing for 10: independent third-party (non-Shopify) hands-on reviews of the CLI itself and broader adoption evidence beyond Shopify's own docs/probes.", "evidenceIds": [ "shopify-ucp-supp-ucp-journey", "shopify-ucp-docs-2", "shopify-ucp-docs-19", "shopify-ucp-docs-20", "shopify-ucp-probe-5", "shopify-ucp-probe-rt-3", "shopify-ucp-supp-buyer-handoff" ] }, { "productId": "shopify-ucp", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Shopify documents and exposes a full public, documented agent-facing API surface (UCP CLI + MCP servers for Catalog, Cart, Checkout, Order) with schemas, auth tiers, negotiation, webhooks, and runtime probes confirming live handshakes, keyless catalog search, and real cart creation — clearly enabling an AI-native user to drive the product programmatically. Missing for 10: no publicly documented OpenAPI/REST spec found (404s on openapi.json/llms.txt) and no independent third-party developer report beyond Shopify's own docs/probes.", "evidenceIds": [ "shopify-ucp-docs-1", "shopify-ucp-supp-ucp-journey", "shopify-ucp-supp-global-catalog", "shopify-ucp-supp-cart-mcp", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-order-mcp", "shopify-ucp-supp-order-webhooks", "shopify-ucp-supp-agent-profiles", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-3", "shopify-ucp-probe-rt-4" ] }, { "productId": "shopify-ucp", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Shopify's UCP documents concrete least-privilege mechanics: three trust tiers (Anonymous/Signed/Token) that gate which tools and rate limits an agent gets, a specific scope (read_global_api_orders) required for Order MCP, short-lived (60-minute TTL) JWTs minted from Dev Dashboard client credentials, and checkout completion gated on the token being 'granted permission to complete purchases.' A runtime probe confirms the profile/identity gate rejects unauthenticated calls (invalid_profile_url), corroborating the scoped-access model works as documented. Missing for 10: a full catalog of all available scopes/permissions beyond the few named, self-service credential/scope management UI, explicit revocation workflow, and independent third-party verification of least-privilege enforcement in production.", "evidenceIds": [ "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-order-mcp", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-probe-rt-4" ] }, { "productId": "shopify-ucp", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Shopify provides official developer tooling for agentic commerce — the `@shopify/ucp-cli`, UCP-compliant MCP servers (Catalog, Cart, Checkout, Order), profile/negotiation docs, and an AI Toolkit that validates GraphQL/Liquid/Extensions — all documented with schemas and confirmed live via runtime probes. However, this is CLI/MCP/JSON-RPC tooling rather than a conventional language-specific SDK (e.g., a Python or JS client library) that an AI-native developer could import directly. Missing for 10: dedicated SDK packages/libraries beyond the CLI and MCP JSON-RPC interface, and independent third-party corroboration of SDK usability.", "evidenceIds": [ "shopify-ucp-supp-ucp-journey", "shopify-ucp-docs-10", "shopify-ucp-supp-global-catalog", "shopify-ucp-supp-cart-mcp", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-probe-rt-3", "shopify-ucp-docs-2" ] }, { "productId": "shopify-ucp", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 5, "confidence": "high", "rationale": "Shopify does deliver order webhooks — UCP-shaped payloads pushed to a registered endpoint on committed order changes, HMAC-signed and retried — but the subscription mechanism itself is not agent-native: 'There's no self-serve subscription API today... contact your Shopify partner manager,' and although the UCP profile spec allows agents to declare a webhook_url, 'Shopify doesn't honor that field today.' This means an AI-native user cannot programmatically subscribe/register for webhook events themselves — it requires a manual, human, out-of-band process, undercutting the 'agentic' self-serve subscription story. missing for 10: self-serve/programmatic webhook subscription API, honoring the agent-declared webhook_url in the UCP profile, and any evidence of agent-driven (not partner-manager-mediated) event subscription.", "evidenceIds": [ "shopify-ucp-docs-8", "shopify-ucp-supp-order-webhooks", "shopify-ucp-docs-26" ] }, { "productId": "shopify-ucp", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Shopify's UCP docs provide a step-by-step quickstart with real, copy-pasteable CLI commands that run the full discovery→cart→checkout→order flow, and MCP tools are self-describing (agents can fetch live input schemas via `--input-schema`), which gives AI-native users a way to explore and run real examples against live endpoints (confirmed by runtime probes actually executing search/cart calls). However, there is no dedicated interactive API-reference surface — probes explicitly found no OpenAPI/Swagger spec and no llms.txt at shopify.dev (404s), so there's no Postman/Swagger-style 'try it' reference page, only linear docs plus CLI/MCP introspection. Missing for 10: a dedicated interactive API-reference UI (OpenAPI/Swagger explorer or embedded try-it-now widgets), and independent hands-on confirmation that non-CLI docs pages let users run examples inline.", "evidenceIds": [ "shopify-ucp-docs-19", "shopify-ucp-supp-storefront-catalog", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-3", "shopify-ucp-probe-1", "shopify-ucp-probe-3" ] }, { "productId": "shopify-ucp", "storyId": "api-machine-spec", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "There's no downloadable OpenAPI/Swagger file — a direct probe found openapi.json, swagger.json, and similar candidate paths all 404 — but the underlying protocol is machine-readable in other ways: MCP servers expose live input schemas agents can introspect at runtime (--input-schema) and the UCP protocol itself has a published, versioned technical specification with reference implementations in a public GitHub repo (ucp.dev/llms.txt). missing for 10: an actual OpenAPI/JSON-Schema-equivalent document downloadable in one shot, and confirmation that the GitHub spec repo is machine-readable in OpenAPI-equivalent form rather than prose/markdown protocol docs.", "evidenceIds": [ "shopify-ucp-probe-3", "shopify-ucp-supp-storefront-catalog", "shopify-ucp-supp-ucp-governance", "shopify-ucp-probe-rt-5" ] }, { "productId": "shopify-ucp", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item describes a dedicated sandbox/test environment for UCP agent development; the only relevant runtime probe shows testing being done directly against a live production Shopify store ('a REAL cart was created keylessly on Shopify's own hardware store'), not a sandbox. No test-mode flag, dev store, or mock UCP endpoint is documented anywhere in the pack.", "evidenceIds": [ "shopify-ucp-probe-rt-3", "shopify-ucp-probe-rt-2" ] }, { "productId": "shopify-ucp", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Evidence shows real API versioning (protocol version headers like x-shopify-ucp-mcp-api-version: 2026-08-25, dated UCP spec releases on ucp.dev, and profile negotiation based on 'the protocol version and capabilities the platform supports'), which supports the 'versioned APIs' half of the story. However, no evidence anywhere describes a documented deprecation policy, sunset timelines, or backward-compatibility guarantees for older versions. Missing for 10: explicit deprecation/sunset policy documentation, version-support lifecycle commitments, migration guidance between dated versions.", "evidenceIds": [ "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-5", "shopify-ucp-supp-agent-profiles" ] }, { "productId": "shopify-ucp", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes single-item/cart-at-a-time flows (search, build a cart, checkout, track one order) and catalog pagination for browsing, but nothing documents a bulk operation primitive — e.g., adding many items to a cart in one call, batch checkout, or bulk order management — for an AI agent to act on many items at once.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Shopify's UCP order webhooks push event notifications (fulfillment, refunds, cancellations) to a registered endpoint whenever a committed change occurs, giving a basic event-trigger backbone, but there is no evidence of an actual rules/automation engine where an AI-native user declares conditional logic (\"if X then do Y\") that Shopify executes on their behalf. Missing for 10: a rule-definition interface or automation engine, support for triggers beyond order state changes, and any evidence of user-authored conditional actions rather than raw webhook delivery.", "evidenceIds": [ "shopify-ucp-supp-order-webhooks", "shopify-ucp-docs-8", "shopify-ucp-docs-26" ] }, { "productId": "shopify-ucp", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Shopify Agentic Commerce is a commerce/MCP protocol for catalog search, cart, checkout, and order tracking by AI agents — not a workflow/job orchestration or scheduling platform. Recurring job/workflow scheduling is a different product category (task schedulers, automation platforms) and no evidence pack material addresses scheduling recurring commerce actions or workflows.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "This story concerns versioning, review, and rollback of user-authored automations (e.g., workflow definitions), which is a wrong axis for Shopify's agentic commerce/UCP protocol tooling — the evidence pack is entirely about product discovery, cart/checkout, order state, and trust/negotiation protocols, none of which involve automation authoring, versioning, or rollback capabilities.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "catalog-feed-publish", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Shopify's Storefront Catalog MCP server exposes each merchant's product catalog at a documented, live endpoint ({shop}.myshopify.com/api/ucp/mcp), confirmed by both docs and a runtime probe (hardware.shopify.com handshake), and merchants are also discoverable via the cross-merchant Global Catalog MCP server, with a documented UCP profile mechanism for agent identification/negotiation. missing for 10: no separate static feed/file-based import format (e.g., XML/JSON feed upload) is documented beyond the live MCP query interface, and no independent third-party merchant case study confirms adoption.", "evidenceIds": [ "shopify-ucp-supp-storefront-catalog", "shopify-ucp-supp-global-catalog", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-2", "shopify-ucp-supp-agent-profiles", "shopify-ucp-docs-4" ] }, { "productId": "shopify-ucp", "storyId": "chat-surface-checkout", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Shopify ships a real, live UCP checkout stack — Catalog, Cart, and Checkout MCP servers with a documented complete_checkout tool that can 'submit payment and place the order' for Token-tier trusted agents, backed by a runtime-verified cart creation and marketing claiming buyers 'check out right in the chat' — and UCP itself is co-developed with Google, Microsoft, OpenAI-adjacent ecosystem players. However, the docs make buyer handoff/escalation a first-class, common path ('hand off to the buyer via continue_url', 'Build for escalations regardless of how you authenticate'), meaning many purchases route the buyer out to the merchant's own checkout page rather than completing fully inside the chat UI, and named surfaces beyond Claude (only a Claude plugin is documented) — ChatGPT, Gemini, Copilot — have no confirmed live integration in the evidence. Missing for 10: confirmed named integrations with ChatGPT/Gemini/Copilot, evidence that in-chat completion (not handoff) is the norm rather than the exception, and independent buyer-side confirmation of an end-to-end in-chat purchase.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-buyer-handoff", "shopify-ucp-supp-trust-tiers", "shopify-ucp-docs-14", "shopify-ucp-probe-rt-3", "shopify-ucp-supp-ucp-governance" ] }, { "productId": "shopify-ucp", "storyId": "checkout-spec-versioned", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "UCP is documented as a versioned protocol (dated releases like 2026-08-25, 2026-04-08) with a publicly hosted spec and reference implementations on GitHub, and Shopify's MCP servers enforce schema/profile validation at runtime (e.g. `--input-schema` to fetch a merchant's live input schema, and a probed `invalid_profile_url` error when an agent lacks a valid hosted profile), plus an AI Toolkit that validates GraphQL/Liquid/Extensions against Shopify schemas. Missing for 10: an explicit standalone conformance test suite or certification program for third-party UCP implementations, and independent (non-Shopify) corroboration of schema stability across versions.", "evidenceIds": [ "shopify-ucp-supp-agent-profiles", "shopify-ucp-supp-storefront-catalog", "shopify-ucp-probe-rt-4", "shopify-ucp-supp-ucp-governance", "shopify-ucp-probe-rt-5", "shopify-ucp-docs-10" ] }, { "productId": "shopify-ucp", "storyId": "dispute-handling-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers catalog, cart, checkout, order state, and order webhooks (which surface refunds/returns/cancellations), but nowhere mentions a dispute or chargeback API, evidence submission, dispute status tracking, or dispute outcome handling for agent transactions.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "fees-transparency-agent-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack thoroughly documents UCP's technical architecture (catalog, cart, checkout, orders, trust tiers) but contains no mention of transaction fees, take rates, commission percentages, or pricing terms for agent-originated sales — nothing addresses what a merchant would pay for agentic-channel transactions.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "http-402-machine-payments", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Shopify Agentic Commerce/UCP is a retail commerce protocol for AI agents to search catalogs, build carts, and complete merchant checkouts — it is not an API/service monetization mechanism using HTTP 402 per-call machine payments. Nothing in the evidence describes HTTP 402 status-code payment flows, API paywalls, or per-call agent billing; all payment/checkout flows described are tied to merchant cart/checkout sessions for buying goods, a different axis than developer API monetization.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "human-approval-gate", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Shopify's UCP checkout flow documents explicit pre-purchase gates: complete_checkout must only be called once 'Checkout status is ready_for_complete', the 'Buyer has reviewed and confirmed the order', and the 'Payment credential has been collected', and unresolved cases force a hand-off to the buyer via continue_url (requires_escalation/requires_buyer_review). AP2 integration adds 'cryptographically signed payment authorizations that are mathematically tied to the specific state of the cart', which maps to a signed-mandate model, and trust tiers restrict complete_checkout to Token-tier agents with explicit purchase permission. However, the docs also note 'Trusted agents can complete checkouts directly,' implying some agents can skip buyer-facing confirmation, and enforcement of the 'buyer reviewed' precondition appears to rely on agent self-attestation rather than a Shopify-verified user signature captured at time of purchase. Missing for 10: independent/third-party confirmation that buyer consent is cryptographically captured (not just agent-declared) and clarity on exactly which agents qualify as 'trusted' to bypass buyer review.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-buyer-handoff", "shopify-ucp-supp-trust-tiers", "shopify-ucp-docs-31", "shopify-ucp-supp-ucp-governance" ] }, { "productId": "shopify-ucp", "storyId": "merchant-agent-onboarding", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show every UCP-enabled storefront automatically exposes a /api/ucp/mcp endpoint and a merchant publishes a UCP profile at {shop}.myshopify.com/.well-known/ucp for capability negotiation — that's a documented, quasi-self-serve publishing path, and probes confirm live merchant endpoints exist. But the pack explicitly contradicts full self-serve: order webhook subscription is 'not self-serve... contact your Shopify partner manager,' and there is no merchant-facing admin setting or signed agreement flow described (all guidance is developer/CLI-facing, not merchant-console-facing). missing for 10: a merchant-admin toggle/setting in Shopify admin UI, an explicit merchant agreement/terms step, and self-serve webhook registration (currently manual via partner manager).", "evidenceIds": [ "shopify-ucp-supp-agent-profiles", "shopify-ucp-supp-order-webhooks", "shopify-ucp-probe-rt-2", "shopify-ucp-docs-27" ] }, { "productId": "shopify-ucp", "storyId": "multi-implementer-adoption", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "UCP is documented as an industry-governed open standard rather than a Shopify-only integration: ucp.dev's co-developer wall names Google, Etsy, Wayfair, Target, Walmart, Amazon, Microsoft, Meta, Salesforce and Stripe as builders of the spec, with 'The complete technical specification, documentation, and reference implementations are hosted in our public GitHub repository' and versioned releases confirmed live via ucp.dev/llms.txt. Shopify itself ships a conformant implementation (catalog/cart/checkout/order MCP servers, verified live via runtime probes), demonstrating at least one non-founding-spec-author adopting the protocol. Missing for 10: independent, hands-on evidence that another named co-developer (e.g., Etsy, Walmart) has a live production UCP endpoint analogous to Shopify's, rather than just being listed as a spec co-author.", "evidenceIds": [ "shopify-ucp-supp-ucp-governance", "shopify-ucp-probe-rt-5", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-2" ] }, { "productId": "shopify-ucp", "storyId": "open-spec-published", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "UCP is documented as an open, industry-governed standard with versioned releases and a public GitHub repository hosting the full spec and reference implementations, and ucp.dev/llms.txt confirms a dated, versioned spec index with no signup gate. Shopify's own docs and runtime probes show keyless, unauthenticated access to core UCP endpoints (catalog search, cart creation) without any signature required to read or implement the protocol. missing for 10: no direct evidence of the actual spec text/license terms confirming implementation rights, and no independent third-party (non-Shopify, non-ucp.dev) confirmation of the openness claim.", "evidenceIds": [ "shopify-ucp-supp-ucp-governance", "shopify-ucp-probe-rt-5", "shopify-ucp-docs-18", "shopify-ucp-probe-rt-4" ] }, { "productId": "shopify-ucp", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Shopify's UCP/MCP surface documents broad API parity for the core buyer journey — catalog search, cart building, checkout creation/completion, and order tracking/webhooks all mirror what a human can do in a Shopify storefront UI, with runtime probes confirming live handshakes and a real cart creation. However, the spec explicitly carves out cases where the API cannot fully replace the UI: checkouts can enter a `requires_escalation` state where 'Checkout requires buyer input or review not available via API,' forcing a handoff via `continue_url` to the merchant's own UI, and full autonomous `complete_checkout` is gated to Token-tier trusted agents only. Missing for 10: evidence of parity for non-purchase storefront actions (account management, returns UI, arbitrary merchant customizations) and confirmation that escalation-required flows are rare rather than common.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-buyer-handoff", "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-cart-mcp", "shopify-ucp-probe-rt-3", "shopify-ucp-supp-order-mcp", "shopify-ucp-supp-order-webhooks" ] }, { "productId": "shopify-ucp", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "None of the evidence addresses data export, portability, or the ability for a user/agent to extract their commerce data in an open format and leave the platform — the pack only covers catalog search, cart/checkout MCP tools, order webhooks, and profile negotiation. Since data portability is a plausible axis for any commerce platform, absence of evidence means 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows the UCP protocol specification and reference implementations are published openly on GitHub, but this is the industry-wide protocol spec (ucp.dev), not Shopify's own Agentic Commerce product source code, servers, or CLI implementation. No citation shows Shopify's actual MCP server/checkout implementation, storefront code, or platform source is released under an open license.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Shopify Agentic Commerce is a hosted SaaS/e-commerce platform with proprietary MCP servers and merchant infrastructure, not open-source software a user could self-host; the underlying UCP protocol spec is open but that is distinct from self-hosting Shopify's actual product. This is a category error — self-hosting is not a fair question for a hosted commerce platform.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "order-event-webhooks", "verdict": "partial", "quality": 5, "confidence": "high", "rationale": "Shopify does push full, HMAC-signed UCP-shaped order webhooks (created/updated/fulfilled/canceled/refunded etc.) with retry logic, so lifecycle events are indeed pushed programmatically once configured. However the same documentation states subscription itself is not self-serve — 'There's no self-serve subscription API today: your delivery URL and topic scoping are registered server-side... contact your Shopify partner manager' — and the UCP profile's webhook_url field, meant to let agents declare their endpoint programmatically, 'Shopify doesn't honor that field today.' This is a first-party documented limitation (not an external dispute) directly undercutting the 'programmatically subscribe' part of the story. missing for 10: a self-serve/programmatic subscription or registration API, honoring of the webhook_url profile field, and independent/hands-on confirmation of webhook delivery in production.", "evidenceIds": [ "shopify-ucp-docs-8", "shopify-ucp-supp-order-webhooks", "shopify-ucp-docs-26" ] }, { "productId": "shopify-ucp", "storyId": "payable-service-directory", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Shopify publishes UCP-compliant Global Catalog and Storefront Catalog MCP servers that agents can discover payable services/products through, with documented endpoints, tool schemas, and profile-based discovery negotiation, corroborated by live runtime probes showing real handshakes and search/cart flows against catalog.shopify.com and a merchant storefront. The broader UCP spec is also openly published (ucp.dev) as an industry discovery standard. Missing for 10: a single canonical top-level directory/index listing all payable services across merchants (discovery is per-server/per-merchant plus a global catalog, not one unified public index), and independent (non-Shopify) confirmation of third-party agent adoption discovering via this index.", "evidenceIds": [ "shopify-ucp-docs-3", "shopify-ucp-docs-4", "shopify-ucp-supp-global-catalog", "shopify-ucp-supp-storefront-catalog", "shopify-ucp-supp-agent-profiles", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-2", "shopify-ucp-probe-rt-4", "shopify-ucp-supp-ucp-governance", "shopify-ucp-probe-rt-5" ] }, { "productId": "shopify-ucp", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "This story concerns data residency/region choice for storing an AI-native user's own data, which is a cloud/SaaS infrastructure axis. Shopify Agentic Commerce is a commerce protocol/MCP toolset for agent-driven shopping, not a data-hosting platform where a user selects storage regions — the evidence pack contains nothing about data residency and the axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Shopify Agentic Commerce is a commerce protocol/MCP platform for enabling AI agents to shop, not an AI model or assistant product; there is no concept here of user data being used to train an AI model, so an AI-training opt-out control is a category error for this product type.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers UCP agent profiles, catalog/cart/checkout/order MCP servers, webhooks, and trust tiers, but nowhere describes any mechanism for an AI-native user to control retention or deletion of their data (e.g., profile data, cart history, order records) — no privacy/data-deletion API, retention policy, or opt-out control is documented.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers UCP CLI, MCP servers, cart/checkout/order flows, trust tiers, and profile negotiation, but nowhere mentions telemetry collection, usage analytics, or any opt-out mechanism for the CLI or MCP servers. Since CLI/SDK tools commonly report usage telemetry, this axis is a fair question, but no evidence supports or denies it.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "refund-via-api", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Refunds are only surfaced as read/notification events — order webhooks fire on committed changes including refunds, and get_order can be polled to see post-purchase adjustments — but there is no documented API/tool for a developer to programmatically initiate a refund on an agent-placed order; webhook subscription itself is not self-serve ('contact your Shopify partner manager'). missing for 10: an actual refund-initiation endpoint/tool (create_refund or equivalent), self-serve webhook subscription for refund events, and any tracking dashboard/status API dedicated to refund lifecycle beyond generic order state.", "evidenceIds": [ "shopify-ucp-supp-order-webhooks", "shopify-ucp-supp-order-mcp", "shopify-ucp-docs-26", "shopify-ucp-docs-7" ] }, { "productId": "shopify-ucp", "storyId": "scoped-payment-tokens", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "UCP references AP2 payment mandates as \"cryptographically signed payment authorizations that are mathematically tied to the specific state of the cart\" and verifiable credentials, plus short-lived (60-minute) JWT checkout tokens and Token-tier gating for complete_checkout — gesturing at scoped, non-raw-card credentials, but this describes protocol/session tokens for API access, not a user-issued payment instrument with explicit amount limits, expiry, and merchant restrictions handed to the agent. Missing for 10: concrete documentation of a user-facing scoped payment credential (spending caps, expiry dates, merchant allow-lists) rather than just agent-identity/session auth tokens, and no independent/hands-on evidence of this credential-issuance flow in practice.", "evidenceIds": [ "shopify-ucp-docs-31", "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-trust-tiers", "shopify-ucp-supp-ucp-governance" ] }, { "productId": "shopify-ucp", "storyId": "settlement-payout-clarity", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence documents order creation, checkout/payment completion, order-state webhooks, and get_order reconciliation of order state, but nothing addresses payout, settlement, or financial reporting flows that let a merchant reconcile agent-originated revenue against other channels (no mention of payout reports, settlement schedules, or accounting/export integration). Since payout/reporting reconciliation is a normal, fair expectation for any commerce channel with real payments, this axis applies but is unaddressed in the pack.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "spend-caps-revocation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes trust tiers, rate limiting, token TTLs, and JWT scopes, but nowhere documents per-agent spend caps, usage limits, or an instant revoke-payment-authority mechanism — tokens simply expire after 60 minutes rather than being explicitly revocable on demand, and no dollar-limit or usage-cap controls are mentioned anywhere in the pack.", "evidenceIds": [] }, { "productId": "shopify-ucp", "storyId": "stablecoin-settlement", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence documents payment_handlers like com.google.pay, credit-card style checkout, and AP2/payment mandate concepts, but nowhere mentions stablecoins, crypto rails, or any stablecoin settlement path for agent-initiated payments. This is a documented gap, not a category mismatch, since UCP explicitly discusses payment handler negotiation and could plausibly include stablecoin rails.", "evidenceIds": [ "shopify-ucp-supp-checkout-mcp", "shopify-ucp-supp-ucp-governance", "shopify-ucp-docs-31" ] }, { "productId": "shopify-ucp", "storyId": "structured-offer-data", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Shopify's Catalog MCP servers (global and storefront) expose structured, machine-readable product data — price (minor units), availability, variants, media, checkout links (continue_url) — verified live via runtime probes (get_product, search_catalog, cart continue_url), and Cart/Checkout MCP further surface checkout links and negotiated payment handlers. Missing for 10: no independent third-party benchmark of data completeness/accuracy across many merchants beyond Shopify's own demo store.", "evidenceIds": [ "shopify-ucp-supp-global-catalog", "shopify-ucp-supp-storefront-catalog", "shopify-ucp-supp-cart-mcp", "shopify-ucp-probe-rt-1", "shopify-ucp-probe-rt-2", "shopify-ucp-probe-rt-3" ] }, { "productId": "skyfire", "storyId": "agent-cart-create", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Skyfire's documented protocol (tokens, kya/pay/kya-pay, MCP tools like find-sellers/create-*-token) covers identity verification and payment authorization/settlement, but there is no documented call for creating or updating a cart or order draft — order/cart state is left to the seller's own system, not exposed via Skyfire's API or MCP server.", "evidenceIds": [ "skyfire-docs-6", "skyfire-docs-7", "skyfire-supp-9", "skyfire-supp-1" ] }, { "productId": "skyfire", "storyId": "agent-catalog-search", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Skyfire's MCP server exposes a 'find-sellers' tool for programmatic discovery, but access requires a self-service API key scoped to a registered agent (not fully keyless) and seller listings are approval-gated by Skyfire rather than an open, permissionless catalog; runtime probe confirms endpoints are key-gated. missing for 10: evidence of true keyless/anonymous discovery, breadth/independence of merchant catalog, and independent corroboration of discovery quality beyond Skyfire's own docs.", "evidenceIds": [ "skyfire-docs-6", "skyfire-supp-9", "skyfire-docs-1", "skyfire-supp-8", "skyfire-probe-rt-1" ] }, { "productId": "skyfire", "storyId": "agent-checkout-complete", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Skyfire documents the full agent-checkout loop: MCP tools let an agent discover sellers, create kya/pay/kya-pay tokens (delegated payment+identity credential), and sellers charge the token post-delivery with funds moved between wallets, completing a confirmed order/settlement. missing for 10: independent/hands-on end-to-end transaction proof (evidence is vendor docs plus a narrow auth-only runtime probe, not a full live purchase trace) and no example of an explicit 'confirmed order' object/receipt returned to the buyer.", "evidenceIds": [ "skyfire-docs-4", "skyfire-docs-6", "skyfire-docs-9", "skyfire-supp-1", "skyfire-supp-4", "skyfire-supp-5", "skyfire-supp-9", "skyfire-probe-rt-1" ] }, { "productId": "skyfire", "storyId": "agent-fraud-liability", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Skyfire's docs explicitly allocate payment risk: sellers are guaranteed payment up to a token's committed amount and 'do not carry buyer non-payment risk' (skyfire-supp-4), overcharges are rejected, and even after account deactivation in-flight tokens are still honored so sellers get paid (skyfire-supp-6). Card-based flows also state the agent can never exceed cardholder-approved amounts and purchases are never anonymous to the merchant (skyfire-supp-7). However, there is no dedicated chargeback/dispute-resolution policy, no explicit statement of who bears fraud losses when credentials are stolen or a buyer disputes via their bank, and no formal merchant-facing liability/ToS document. Missing for 10: explicit chargeback/dispute process, stolen-credential fraud liability terms, formal merchant liability agreement or ToS reference.", "evidenceIds": [ "skyfire-supp-4", "skyfire-supp-6", "skyfire-supp-7", "skyfire-supp-5" ] }, { "productId": "skyfire", "storyId": "agent-identity-tiers", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Skyfire's KYA/KYA-Pay tokens give merchants a verifiable, signed identity credential (JWT) per agent, with optional real-world identity attachment and hard gating ('token creation fails and the transaction does not proceed' if verification level is insufficient), plus per-agent scoped API keys and a documented merchant/bot-manager flow to identify and admit agent traffic instead of blocking it. This directly addresses distinguishing trusted, verified agent traffic from anonymous bots via a signature-based, tiered identity system. Missing for 10: independent/third-party corroboration of real-world merchant adoption or trust-tier enforcement outside Skyfire's own docs, and no public API schema (openapi probes 404) to verify signature/verification details externally.", "evidenceIds": [ "skyfire-docs-8", "skyfire-supp-2", "skyfire-supp-3", "skyfire-supp-7", "skyfire-docs-10", "skyfire-docs-1" ] }, { "productId": "skyfire", "storyId": "agent-order-attribution", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Skyfire ties every transaction to a specific Buyer Agent via KYA identity tokens and per-agent API keys, so orders are technically attributable to the originating agent (skyfire-docs-1, skyfire-supp-2, skyfire-supp-7), and introspect/charge-token APIs let a seller programmatically check token/agent status (skyfire-docs-4, skyfire-docs-5). However, there is no evidence of a merchant-facing report or dashboard view that lets a merchant filter/aggregate transactions by agent — only a general 'Agent Dashboard' for key management is mentioned. Missing for 10: documented merchant reporting/analytics UI or API for filtering transactions by agent, evidence of aggregate order-to-agent attribution reporting.", "evidenceIds": [ "skyfire-docs-1", "skyfire-supp-2", "skyfire-supp-7", "skyfire-docs-4", "skyfire-docs-5" ] }, { "productId": "skyfire", "storyId": "agent-order-tracking", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is strictly an identity-and-payments rail (token issuance, KYA verification, charging, settlement) between buyer and seller agents; it has no order-management or fulfillment-tracking role. Order status/tracking after purchase is the seller's own system, not something Skyfire's token introspection (which only checks token validity/balance) addresses — this axis is a category error for a payments/identity infrastructure product.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "agent-traffic-controls", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Skyfire lets sellers set per-service identity requirements (KYA verification levels) that gate token creation and thus checkout access, and its payment-card flow lets a merchant's bot manager identify and allow known agents rather than block them — giving coarse allow/deny-by-identity control. However there is no documented rate-limiting feature, no explicit deny-list or per-agent/platform blocking mechanism, and no console for merchants to enumerate specific agents/platforms to throttle or reject. Missing for 10: rate-limiting controls, explicit allow/deny list management UI/API, granular per-agent-platform policy enforcement beyond identity-level gating.", "evidenceIds": [ "skyfire-supp-2", "skyfire-docs-10", "skyfire-supp-8" ] }, { "productId": "skyfire", "storyId": "agent-wallet-provisioning", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs describe a Buyer Agent wallet auto-created and pre-funded on signup, scoped per-agent via API keys that the user controls, with committed-amount enforcement against the wallet balance and an introspect-token API to check remaining balance. This covers user-provisioned/funded/controlled wallet plus balance visibility, but missing for 10: dashboard UI screenshots showing balance, explicit mechanism for manually topping up/funding beyond initial pre-fund, and independent/hands-on corroboration.", "evidenceIds": [ "skyfire-docs-11", "skyfire-supp-8", "skyfire-docs-5", "skyfire-supp-4", "skyfire-docs-1" ] }, { "productId": "skyfire", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Skyfire's docs site serves a working llms.txt (HTTP 200, agent-oriented summary) confirmed by both a probe and a runtime check, and its full docs are structured as agent-consumable markdown (.md endpoints throughout). This directly satisfies pointing an agent at llms.txt/agent-oriented docs. Missing for 10: no independent third-party report of an agent successfully consuming llms.txt end-to-end, and no OpenAPI spec (all candidate paths 404) which would further strengthen machine-readability.", "evidenceIds": [ "skyfire-probe-1", "skyfire-probe-rt-1", "skyfire-probe-2" ] }, { "productId": "skyfire", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments infrastructure layer for AI agents (tokens, KYA, MCP commerce), not a data product with dashboards or analytics — 'AI-generated insights and suggestions from my data' is a category mismatch, not a missing feature.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Skyfire's MCP server lets an agent autonomously discover sellers, mint kya/pay tokens, and execute commerce transactions without human-in-the-loop approval up to committed token limits (skyfire-docs-6, skyfire-supp-9, skyfire-supp-4), which supports autonomous background operation for agent commerce specifically. But Skyfire is a payment/identity layer, not a general automation/orchestration platform — there's no documented scheduler, trigger system, or persistent background-job mechanism for setting up broader autonomous workflows beyond commerce transactions. missing for 10: evidence of a scheduling/trigger system, persistent background job execution beyond per-call MCP invocations, and support for non-commerce automation tasks.", "evidenceIds": [ "skyfire-docs-6", "skyfire-supp-9", "skyfire-supp-4", "skyfire-supp-1" ] }, { "productId": "skyfire", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments infrastructure layer (APIs, tokens, MCP server) for AI agents to transact — it is not itself an AI assistant product with a built-in assistant persona for users to delegate tasks to. This axis is a category error for an infrastructure/API product.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Skyfire is API-first: agents authenticate via scoped API keys (no interactive login) and all core operations (token creation, introspection, charging) are REST endpoints, confirmed live and key-gated by a runtime probe, plus an MCP server for programmatic agent workflows. However, there's no explicit CI/CD example, headless setup guide, or CLI/SDK documentation showing automation-pipeline usage. missing for 10: explicit CI/headless usage guide, CLI or SDK tooling, and independent confirmation of non-interactive automation beyond API-key auth.", "evidenceIds": [ "skyfire-docs-1", "skyfire-docs-4", "skyfire-docs-5", "skyfire-docs-6", "skyfire-probe-rt-1", "skyfire-supp-8", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments layer for agents that itself exposes an MCP server (find-sellers, create-token tools) for other agents to consume — it is not an agent runtime or orchestrator that would plug in and consume arbitrary external MCP servers' tools. The client-role axis is a category error for this kind of infrastructure/protocol product.", "evidenceIds": [ "skyfire-docs-6", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Skyfire documents an official hosted MCP server (https://mcp.skyfire.xyz/mcp, plus sandbox) with documented tools (find-sellers, create-kya-token, create-pay-token, create-kya-payment-token) and auth via API key header, letting agents connect and execute commerce workflows. missing for 10: independent/third-party corroboration of the MCP server working in practice, and no public OpenAPI/schema for deeper verification.", "evidenceIds": [ "skyfire-docs-6", "skyfire-docs-7", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Skyfire ships an MCP server exposing tools (find-sellers, create-kya-token, create-pay-token, create-kya-payment-token) that let an LLM-driven agent translate natural-language requests into commerce actions like discovering sellers and issuing/charging tokens, which is the standard mechanism for natural-language operation in agentic products. Missing for 10: no evidence of a first-party conversational interface, no examples of actual natural-language prompts mapped to tool calls, and no independent/hands-on confirmation of NL-driven usage beyond the docs.", "evidenceIds": [ "skyfire-docs-6", "skyfire-docs-7", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Skyfire's docs describe REST APIs, MCP server integration, and a dashboard/Playground, but no evidence pack item mentions an official CLI tool for developers or agents. Missing for 10: any documented CLI binary, npm/pip package, or command-line reference.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Skyfire ships a documented public REST API (tokens, introspect, charge-token) gated by per-agent API keys, confirmed live via runtime probe returning a structured auth error rather than a 404, plus llms.txt-served docs. Missing for 10: a published OpenAPI/swagger spec (probe found all candidate spec URLs 404) and independent third-party corroboration beyond vendor docs/probes.", "evidenceIds": [ "skyfire-docs-1", "skyfire-docs-4", "skyfire-docs-5", "skyfire-probe-1", "skyfire-probe-2", "skyfire-probe-rt-1", "skyfire-supp-5" ] }, { "productId": "skyfire", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Skyfire API keys are scoped per-agent (Buyer/Seller) and pay tokens carry committed amounts with hard balance ceilings, and KYA-gated tokens enforce identity requirements, which together give agent-level least-privilege credentials. However, this is scoped to payment/identity tokens rather than granular API permission scopes (e.g., no fine-grained action/resource-level scoping or role-based permission sets), and there is no documented per-token revocation API. missing for 10: fine-grained permission/action scoping beyond agent+amount+identity, documented revocation controls, independent/hands-on verification of scoping enforcement.", "evidenceIds": [ "skyfire-docs-1", "skyfire-supp-4", "skyfire-supp-2", "skyfire-supp-6", "skyfire-supp-8" ] }, { "productId": "skyfire", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Skyfire has REST API reference docs, a Playground, and an MCP server for agent integration, but nowhere does it mention or link to an official language SDK (e.g., Python/JS client library). The openapi.json probe even returned 404, undermining any inference of auto-generated SDK tooling.", "evidenceIds": [ "skyfire-docs-6", "skyfire-probe-2", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers token issuance, charging, MCP tools, and identity verification, but nowhere mentions webhooks or any event subscription/callback mechanism for developers to receive notifications. Missing for 10: any webhook endpoint registration, event types, or push-notification documentation.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows Skyfire has structured reference docs (charge-token, introspect-token, etc.) but the openapi probe found no machine-readable spec (404s on all candidate paths), and there is no mention of an interactive console, 'try it' feature, or runnable code examples anywhere in the pack — only static markdown-style API reference pages.", "evidenceIds": [ "skyfire-probe-2", "skyfire-docs-4", "skyfire-docs-5" ] }, { "productId": "skyfire", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The docs contain structured API reference pages (e.g., charge-token, introspect-token) suggesting an underlying spec, but a direct probe for machine-readable OpenAPI/Swagger files at all standard locations returned 404 for every candidate path, and no evidence shows a downloadable spec file or link.", "evidenceIds": [ "skyfire-probe-2", "skyfire-docs-4", "skyfire-docs-5" ] }, { "productId": "skyfire", "storyId": "api-sandbox", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "The MCP server docs explicitly reference a separate sandbox endpoint (mcp-sandbox.skyfire.xyz) distinct from the production mcp.skyfire.xyz, showing a dedicated test environment exists. However, there's no broader documentation of a sandbox for the core token/payment APIs, wallets, or KYA flows outside the MCP context, and no detail on how sandbox data is isolated from production. Missing for 10: dedicated sandbox docs for REST/token APIs beyond MCP, explicit guidance on test credentials/test wallets, independent confirmation the sandbox fully mirrors production without touching real funds.", "evidenceIds": [ "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While the API path shows a v1 prefix (skyfire-probe-rt-1) and an OpenAPI spec probe returned 404s (skyfire-probe-2), there is no documentation of a versioning scheme, deprecation timeline, or migration policy anywhere in the evidence pack. Missing for 10: any deprecation policy page, versioning changelog, or migration guide.", "evidenceIds": [ "skyfire-probe-2", "skyfire-probe-rt-1" ] }, { "productId": "skyfire", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Skyfire's documented API is single-item/token-centric (create one token, charge one token, introspect one token) with no documented batch or bulk endpoints for processing many items in one call. No evidence of any bulk-operation capability across tokens, sellers, or charges.", "evidenceIds": [ "skyfire-docs-4", "skyfire-docs-5", "skyfire-supp-5" ] }, { "productId": "skyfire", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments layer for agent commerce (tokens, KYA verification, charge/settlement APIs, MCP server for discovering sellers and creating tokens) — it does not offer a rules/trigger engine for automating actions on events. This is a category mismatch, not a missing feature of the product's domain.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments layer for agent-to-agent commerce (tokens, KYA verification, charging, settlement), not a workflow orchestration or job-scheduling product. Scheduling recurring jobs/workflows is outside its category — this is a category mismatch, not a missing feature.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments layer for AI agent commerce, not an automation-building or workflow tool; there is no concept of authoring, versioning, reviewing, or rolling back 'automations' in this evidence. This axis is a category error for an identity/payments API product.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "catalog-feed-publish", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Skyfire lets a seller register services via 'Create Service' (name, type, pricing, identity requirements) and then makes them discoverable to agents through the MCP server's 'find-sellers' tool, which is a real agent-discovery surface. But this is a one-at-a-time, approval-gated dashboard/API flow rather than a documented bulk catalog feed or import API for a full product/service catalog. missing for 10: a bulk catalog feed/import API (e.g., CSV/JSON catalog upload), documentation on how multiple SKUs or listings map to discovery, and evidence of independent merchant usage confirming catalog visibility in agent surfaces.", "evidenceIds": [ "skyfire-docs-3", "skyfire-supp-8", "skyfire-docs-6", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "chat-surface-checkout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Skyfire's evidence documents a generic agent-to-agent payment/identity protocol (tokens, MCP server for 'find-sellers' and token creation) but nowhere mentions ChatGPT, Claude, Gemini, Copilot or any named chat/assistant surface, nor any commerce-in-chat integration or app-store listing. The MCP server is a generic protocol endpoint, not documented evidence of embedding within these specific consumer assistant surfaces.", "evidenceIds": [ "skyfire-docs-6", "skyfire-supp-9", "skyfire-docs-7" ] }, { "productId": "skyfire", "storyId": "checkout-spec-versioned", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Skyfire points to an external 'open' KYAPay protocol (KYAPay.org) with JWT-based tokens that all Skyfire tokens conform to, giving a nominal published spec, but the evidence pack shows no OpenAPI/schema file for Skyfire's own API (all standard OpenAPI paths 404) and no conformance/validation tooling (test suites, schema validators, certification) is documented anywhere. Missing for 10: a published machine-readable schema for the Skyfire API itself, explicit protocol versioning, and any conformance/validation tooling a developer could run against.", "evidenceIds": [ "skyfire-supp-3", "skyfire-probe-2", "skyfire-docs-7" ] }, { "productId": "skyfire", "storyId": "dispute-handling-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents token creation, charging, introspection, settlement timing, and revocation limits, but nowhere describes a dispute or chargeback mechanism — no evidence-submission endpoint, dispute status API, or outcome reporting is mentioned. Payment guarantees are described as ceiling-bound token commitments rather than a dispute-resolution workflow, so this applicable axis has no supporting evidence.", "evidenceIds": [ "skyfire-supp-4", "skyfire-supp-5", "skyfire-supp-6" ] }, { "productId": "skyfire", "storyId": "fees-transparency-agent-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows sellers set their own service pricing when configuring a service, but there is no published fee schedule for Skyfire's own transaction/take-rate fees on agent-originated payments — nothing lets a merchant price agentic channels without contacting sales.", "evidenceIds": [ "skyfire-docs-3", "skyfire-supp-8" ] }, { "productId": "skyfire", "storyId": "http-402-machine-payments", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Skyfire lets sellers register a service, gate access with kya/pay tokens, and charge per call via the Charge Token API after delivery — with no checkout UI, matching most of the story's intent, and the docs explicitly note overcharges are rejected with an HTTP 402 PAYMENT_ERROR. However, the evidence shows Skyfire's core mechanism is its own token/JWT (KYAPay) issuance-and-charge flow rather than a standard HTTP 402 challenge-response loop as the primary payment protocol. Missing for 10: explicit documentation that HTTP 402 is used as the initial payment-required response/handshake (not just an overcharge error code), and independent confirmation of the 402-based flow in production use.", "evidenceIds": [ "skyfire-docs-3", "skyfire-docs-4", "skyfire-supp-1", "skyfire-supp-5", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "human-approval-gate", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Skyfire's pay/kya-pay tokens are signed JWT 'mandates' that commit a specific spending ceiling at creation time, and that ceiling is a hard cap enforced by the buyer's wallet balance and cardholder consent ('agent can never spend more than the cardholder approved'), giving a documented, auditable authorization trail per token. However, the evidence shows token creation is an agent/API-driven action, not a human-facing confirmation prompt or explicit per-purchase human sign-off — there's no documented UI step where a person approves each individual transaction before it fires, only the pre-set balance/identity gating. Missing for 10: an explicit human-in-the-loop confirmation/approval UI or workflow per purchase, and documentation of configurable spend policies beyond wallet pre-funding and KYA identity requirements.", "evidenceIds": [ "skyfire-supp-3", "skyfire-supp-4", "skyfire-supp-7", "skyfire-supp-2", "skyfire-docs-11" ] }, { "productId": "skyfire", "storyId": "merchant-agent-onboarding", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Skyfire documents a concrete merchant-facing path: create a Seller Agent, generate a scoped API key, click 'Create Service' with pricing/identity requirements, and use the Charge Token API to collect payment — all via the Agent Dashboard (skyfire-docs-3, skyfire-supp-8, skyfire-docs-4). However, service creation is explicitly 'Submit for approval,' meaning it's gated rather than a pure self-serve flip-a-switch flow. Missing for 10: confirmation of approval turnaround/criteria, an explicit merchant agreement/ToS signing step, and independent verification that the approval process is lightweight rather than a manual sales gate.", "evidenceIds": [ "skyfire-docs-3", "skyfire-supp-8", "skyfire-docs-4", "skyfire-docs-1" ] }, { "productId": "skyfire", "storyId": "multi-implementer-adoption", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Skyfire claims tokens conform to an 'open KYAPay protocol' hosted at KYAPay.org, but every operational piece — charging, wallets, settlement, MCP server, verification — runs exclusively through Skyfire's own APIs and infrastructure per the evidence pack. There is no mention of any independent vendor, competitor, or third party implementing the protocol or running their own compatible service/settlement layer.", "evidenceIds": [ "skyfire-supp-3", "skyfire-supp-5", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "open-spec-published", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Skyfire claims tokens conform to \"the open KYAPay protocol, an industry specification for identity-linked payment credentials\" (referencing KYAPay.org), suggesting a published spec exists, but the evidence pack itself notes that charging, wallets, and settlement all run through Skyfire's own gated APIs, and every other capability (creating tokens, MCP server, seller services) requires an API key and account signup — no evidence of a version number, a standalone spec document, or an implementation path that doesn't require signing up with Skyfire. missing for 10: a link to a versioned KYAPay spec document, confirmation it can be implemented independently of Skyfire's account/API-key system, and independent corroboration of the spec's openness.", "evidenceIds": [ "skyfire-supp-3", "skyfire-probe-2", "skyfire-probe-rt-1", "skyfire-supp-8" ] }, { "productId": "skyfire", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Core operations (token creation/charge/introspect, service creation, KYA verification) are all documented as REST API endpoints, and an MCP server exposes agentic workflows, showing strong API-first parity with the UI dashboard/playground. However, no OpenAPI/swagger spec was found (404s on all candidate paths), and some UI-only flows like account approval, dashboard-based key management, and paid KYA subscription setup aren't confirmed as fully API-driven. missing for 10: published OpenAPI/swagger spec, confirmation that account/service approval and subscription management can be done purely via API without dashboard interaction, independent third-party confirmation of full API/UI parity.", "evidenceIds": [ "skyfire-docs-3", "skyfire-docs-4", "skyfire-docs-5", "skyfire-docs-6", "skyfire-docs-8", "skyfire-probe-2", "skyfire-supp-8", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers token issuance, KYA identity verification, MCP commerce workflows, and payment settlement, but nothing describes a data export feature or open-format data portability for a user's account, transaction history, or identity data. missing for 10: any documented export/download capability, open-format (CSV/JSON) data dump, or account-closure data portability guarantee.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows Skyfire is a closed, key-gated commercial API/platform (identity+payments infrastructure) with only a published token spec (KYAPay) being open, not the product's own source code; no repo, license, or open-source claim appears anywhere in the pack.", "evidenceIds": [ "skyfire-probe-rt-1", "skyfire-supp-3" ] }, { "productId": "skyfire", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is a hosted identity/payments network — wallets, token settlement, and charging all run through Skyfire's own centrally-operated APIs (skyfire-supp-3, skyfire-supp-4), which is inherent to a trust/settlement layer rather than self-hostable software; no self-host option is offered or plausible for this product category.", "evidenceIds": [ "skyfire-supp-3", "skyfire-supp-4", "skyfire-supp-8" ] }, { "productId": "skyfire", "storyId": "order-event-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Skyfire's docs cover token creation, charging, and introspection (pull-based checks), but there is no evidence of any webhook, event subscription, or push notification mechanism for order lifecycle events (created/updated/fulfilled/canceled). Developers must poll introspect-token rather than subscribe to pushed events.", "evidenceIds": [ "skyfire-docs-5", "skyfire-supp-5", "skyfire-supp-4" ] }, { "productId": "skyfire", "storyId": "payable-service-directory", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Skyfire's MCP server exposes a 'find-sellers' tool that lets an agent query for payable services/sellers programmatically, and sellers register services through an approval-gated catalog, giving agents a discovery mechanism (skyfire-docs-6, skyfire-supp-9, skyfire-docs-3). However, there's no evidence of a publicly browsable directory/index outside the MCP tool call, nor documentation of how the directory is structured, filtered, or how comprehensive/curated it is. Missing for 10: a documented public directory/catalog UI or API endpoint separate from the MCP tool, details on search/filter capabilities, and independent confirmation of discovery breadth.", "evidenceIds": [ "skyfire-docs-6", "skyfire-supp-9", "skyfire-docs-3", "skyfire-docs-7" ] }, { "productId": "skyfire", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments layer for agent commerce, not a data storage or hosting platform, so data residency/region choice is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity/payments layer for AI agent commerce, not a data/training or AI-model-usage product; controlling whether user data is used for AI model training is entirely outside its category and evidence set.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Skyfire's docs describe identity verification (KYA), token issuance/expiry, and payment settlement, but nothing in the evidence pack addresses user-controlled data retention policies or deletion of stored identity/verification/payment data. Given Skyfire handles real-world identity data via KYA, this is a fair privacy axis to expect, but no retention or deletion controls are documented.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Skyfire is an identity-and-payments infrastructure layer for AI agent commerce, not a telemetry-collecting analytics/consumer product; the evidence pack contains no mention of telemetry collection or opt-out mechanisms, and this axis is not a natural fit for its product category.", "evidenceIds": [] }, { "productId": "skyfire", "storyId": "refund-via-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers token creation, charging, settlement, and revocation bounds in detail, but nowhere documents a refund API, refund initiation flow, or refund status/tracking endpoint. Since Skyfire is a payments platform, refunds are a plausible feature, but no evidence of programmatic refund support exists — missing for 10: any refund/dispute API reference, refund status tracking, or documented refund workflow.", "evidenceIds": [ "skyfire-supp-5", "skyfire-supp-6", "skyfire-supp-4" ] }, { "productId": "skyfire", "storyId": "scoped-payment-tokens", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Skyfire issues scoped pay/kya-pay tokens with committed amount ceilings, expiry windows (10s-24h plus grace period), and merchant/identity-requirement gating rather than raw card numbers, all documented via API and MCP server tooling. Missing for 10: independent third-party/hands-on corroboration beyond vendor docs, and explicit merchant-restriction scoping details (evidence shows identity/amount/time limits clearly but merchant-lock-in specifics are thinner).", "evidenceIds": [ "skyfire-supp-4", "skyfire-supp-5", "skyfire-supp-6", "skyfire-supp-2", "skyfire-docs-11", "skyfire-supp-9" ] }, { "productId": "skyfire", "storyId": "settlement-payout-clarity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Skyfire documents the settlement mechanics merchants need — charge-token API, committed/ceiling amounts, multi-charge until balance exhausted, defined settlement windows (up to 51 hours), and overcharge rejection (402) — which supports reconciliation of individual transactions. However, there is no documented merchant-facing payout flow (e.g., withdrawal to bank/external accounts), no statement/reporting/export API, and no mention of standard accounting artifacts (invoices, ledgers, CSV/webhook reporting) that would let a merchant reconcile against other channels. missing for 10: documented payout/withdrawal mechanism to real-world funds, merchant reporting/statement or export API, reconciliation tooling or ledger export, independent confirmation of reporting flows.", "evidenceIds": [ "skyfire-supp-4", "skyfire-supp-5", "skyfire-supp-6", "skyfire-docs-4", "skyfire-supp-1" ] }, { "productId": "skyfire", "storyId": "spend-caps-revocation", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Skyfire supports per-agent scoping and spend caps: keys are scoped to a single agent, and pay tokens carry a committed amount ceiling that bounds spend and rejects overcharges. However, the docs explicitly state there is no per-token revocation API and that deactivating an account does not void already-issued tokens — in-flight tokens remain chargeable until expiry plus a 24-hour grace window — directly contradicting 'instant' revocation of payment authority. missing for 10: a documented instant per-agent/per-token revocation mechanism, independent or hands-on confirmation of revocation behavior, and granular usage-limit controls beyond token amount/expiry.", "evidenceIds": [ "skyfire-supp-4", "skyfire-supp-5", "skyfire-supp-6", "skyfire-docs-1" ] }, { "productId": "skyfire", "storyId": "stablecoin-settlement", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Skyfire documents thorough payment settlement rails — wallets, pay/kya-pay tokens, committed amounts, charge-token API, settlement timing windows, and open KYAPay token spec — but none of the evidence explicitly states that settlement occurs in stablecoins or names any specific blockchain/stablecoin rail. Missing for 10: explicit stablecoin currency mention, underlying blockchain/rail specification, and confirmation that wallet balances/settlement are denominated in a stablecoin rather than fiat/credit abstraction.", "evidenceIds": [ "skyfire-supp-1", "skyfire-supp-4", "skyfire-supp-5", "skyfire-docs-11", "skyfire-supp-3" ] }, { "productId": "skyfire", "storyId": "structured-offer-data", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Skyfire's MCP server exposes a 'find-sellers' tool for service discovery, and seller service creation includes a 'pricing' field (skyfire-docs-3, skyfire-docs-6, skyfire-supp-9), suggesting some machine-readable service metadata exists. However, there is no documented schema showing availability, variants, or checkout links returned to a developer/agent, and no OpenAPI spec was found (skyfire-probe-2) to confirm structured offer data beyond pricing and identity requirements. Missing for 10: documented availability/variant fields, explicit checkout-link data, and a public API schema showing full offer payloads.", "evidenceIds": [ "skyfire-docs-3", "skyfire-docs-6", "skyfire-supp-9", "skyfire-probe-2" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-cart-create", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-acp-custom-checkout", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-spt-limits", "stripe-ac-supp-chat-commerce" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-catalog-search", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Stripe does expose some keyless/self-service discovery paths — the Link CLI lets an agent 'Search products and complete payments with UCP' using a customer-controlled wallet with self-service credentials (no merchant partnership needed on the buyer side), and Stripe Directory helps agents find external providers. But the flagship agentic-commerce discovery/checkout path (ACS/OCA) explicitly requires a private, seller-initiated relationship — 'Only a seller can initiate an OCA request' and 'An OCA is a required connection between your agent and a seller that enables agentic commerce flows' — and is gated as 'private preview' in limited geographies, meaning broad cross-merchant search without any partnership is not generally available. missing for 10: universal, partnership-free product search across arbitrary merchants (most flows require seller-approved OCA or private-preview access), independent/hands-on confirmation that Link CLI's UCP search actually returns cross-merchant results without any seller-side integration.", "evidenceIds": [ "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-docs-13", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-chat-commerce" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-checkout-complete", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-acp-custom-checkout", "stripe-ac-supp-spt-limits", "stripe-ac-supp-order-attribution", "stripe-ac-supp-embedded-checkout-oca", "stripe-agentic-commerce-docs-4", "stripe-ac-probe-rt-1", "stripe-ac-probe-rt-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-fraud-liability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-identity-tiers", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-order-attribution", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-spt-limits", "stripe-agentic-commerce-docs-7" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-order-attribution", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-order-attribution" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-order-tracking", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-order-attribution", "stripe-ac-supp-embedded-checkout-oca" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-traffic-controls", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-order-attribution" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agent-wallet-provisioning", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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).", "evidenceIds": [ "stripe-agentic-commerce-docs-11", "stripe-agentic-commerce-docs-12", "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-gh-1", "stripe-agentic-commerce-gh-2", "stripe-agentic-commerce-docs-28", "stripe-ac-probe-rt-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-probe-1", "stripe-agentic-commerce-probe-2", "stripe-ac-probe-rt-3", "stripe-agentic-commerce-docs-6", "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-probe-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-25", "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-docs-17", "stripe-agentic-commerce-docs-27" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-machine-payments", "stripe-ac-supp-mpp-agent-build", "stripe-ac-supp-spt-limits", "stripe-ac-supp-mcp-approval", "stripe-ac-supp-link-wallet" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is payments/commerce infrastructure (APIs, MCP server, Link CLI, ACP/MPP protocols) that external AI agents (e.g., ChatGPT) plug into to transact on Stripe's behalf — it is not itself a consumer-facing product with a built-in AI assistant that a user delegates tasks to inside the product. The 'delegate to a built-in assistant' axis is a category mismatch for an agent-facing commerce infrastructure/API platform.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-24", "stripe-ac-supp-mpp-agent-build", "stripe-ac-supp-mcp-approval", "stripe-ac-supp-link-wallet" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is a payments/commerce platform that exposes its own MCP server and tools for other agents to consume (server role), not an agent runtime or assistant that itself plugs in and consumes external MCP servers' tools (client role). No evidence shows Stripe Agentic Commerce acting as an MCP client hosting third-party MCP servers, so this axis is a category mismatch for this product type.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-5", "stripe-agentic-commerce-docs-21", "stripe-ac-supp-mcp-approval", "stripe-ac-probe-rt-1", "stripe-agentic-commerce-probe-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-25", "stripe-agentic-commerce-docs-26", "stripe-agentic-commerce-docs-27", "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-docs-5", "stripe-agentic-commerce-docs-6", "stripe-ac-probe-rt-1", "stripe-ac-probe-rt-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-11", "stripe-agentic-commerce-gh-1", "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-probe-5", "stripe-ac-probe-rt-4", "stripe-agentic-commerce-docs-24", "stripe-ac-supp-mpp-agent-build" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-5", "stripe-ac-probe-rt-1", "stripe-ac-probe-rt-2", "stripe-ac-probe-rt-3", "stripe-ac-probe-rt-4", "stripe-ac-supp-acp-custom-checkout", "stripe-ac-supp-spt-limits", "stripe-ac-supp-machine-payments", "stripe-agentic-commerce-probe-3" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-7", "stripe-agentic-commerce-docs-23", "stripe-ac-supp-spt-limits", "stripe-ac-supp-mcp-approval", "stripe-agentic-commerce-docs-24" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-sdks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-5", "stripe-agentic-commerce-docs-6", "stripe-agentic-commerce-docs-7", "stripe-agentic-commerce-docs-11", "stripe-agentic-commerce-gh-1", "stripe-ac-probe-rt-1", "stripe-ac-probe-rt-2", "stripe-ac-probe-rt-3", "stripe-ac-probe-rt-4", "stripe-ac-supp-mpp-agent-build", "stripe-ac-supp-mcp-approval" ] }, { "productId": "stripe-agentic-commerce", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-order-attribution", "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-spt-limits" ] }, { "productId": "stripe-agentic-commerce", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-24", "stripe-agentic-commerce-docs-21", "stripe-ac-probe-rt-1", "stripe-ac-probe-rt-3", "stripe-agentic-commerce-probe-3", "stripe-agentic-commerce-probe-2" ] }, { "productId": "stripe-agentic-commerce", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-probe-3" ] }, { "productId": "stripe-agentic-commerce", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-24" ] }, { "productId": "stripe-agentic-commerce", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-chat-commerce", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-acp-custom-checkout" ] }, { "productId": "stripe-agentic-commerce", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-order-attribution" ] }, { "productId": "stripe-agentic-commerce", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-order-attribution", "stripe-ac-supp-spt-limits", "stripe-ac-supp-mcp-approval" ] }, { "productId": "stripe-agentic-commerce", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is a payments/commerce infrastructure product (checkout, tokens, machine payments, MCP tools) — it has no concept of scheduling recurring jobs/workflows for an AI agent; that capability belongs to orchestration/automation tools, not a payments API layer. This is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is a payments/commerce infrastructure product (checkout, shared payment tokens, machine payments, MCP server for API actions) — it has no concept of user-built 'automations' that could be versioned, reviewed, or rolled back like a workflow-automation platform. This axis targets automation-builder products, not a commerce/payments rails product.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "catalog-feed-publish", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe documents a concrete, detailed catalog-publishing mechanism for merchants: a CSV feed format uploaded via the v2 Product Catalog Import API to a presigned URL, with defined cadence (daily product data, 15-min inventory/pricing), explicit replace-mode deletion semantics, import-result webhooks with per-row error reporting, and required restricted-key permissions — all under the self-serve ACS onboarding flow described in the for-sellers docs. This directly matches the story of publishing a catalog into agent surfaces via a documented feed/import API, going well beyond a vague claim into an operational spec merchants can implement against. missing for 10: independent/hands-on merchant confirmation of the import pipeline working end-to-end, and the feature is still gated to private preview / limited geographies (US, Canada, select European countries) rather than universally GA.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-agentic-commerce-docs-1", "stripe-agentic-commerce-docs-14", "stripe-ac-supp-chat-commerce" ] }, { "productId": "stripe-agentic-commerce", "storyId": "chat-surface-checkout", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-chat-commerce", "stripe-ac-supp-acp-openness", "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-spt-limits", "stripe-ac-supp-order-attribution" ] }, { "productId": "stripe-agentic-commerce", "storyId": "checkout-spec-versioned", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-acp-openness", "stripe-ac-supp-mpp-agent-build", "stripe-ac-probe-rt-2", "stripe-agentic-commerce-probe-3" ] }, { "productId": "stripe-agentic-commerce", "storyId": "dispute-handling-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "fees-transparency-agent-payments", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-pricing", "stripe-agentic-commerce-comm-2" ] }, { "productId": "stripe-agentic-commerce", "storyId": "http-402-machine-payments", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-8", "stripe-agentic-commerce-docs-9", "stripe-ac-supp-machine-payments", "stripe-ac-supp-mpp-agent-build", "stripe-ac-probe-rt-2" ] }, { "productId": "stripe-agentic-commerce", "storyId": "human-approval-gate", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-mcp-approval", "stripe-ac-supp-link-wallet", "stripe-ac-supp-spt-limits", "stripe-ac-probe-rt-1", "stripe-ac-probe-rt-4", "stripe-agentic-commerce-docs-28" ] }, { "productId": "stripe-agentic-commerce", "storyId": "merchant-agent-onboarding", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-order-attribution", "stripe-ac-supp-acp-custom-checkout", "stripe-ac-supp-chat-commerce" ] }, { "productId": "stripe-agentic-commerce", "storyId": "multi-implementer-adoption", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-acp-openness", "stripe-ac-supp-mpp-agent-build", "stripe-ac-probe-rt-2", "stripe-ac-supp-acp-custom-checkout" ] }, { "productId": "stripe-agentic-commerce", "storyId": "open-spec-published", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-acp-openness", "stripe-ac-probe-rt-2", "stripe-ac-supp-mpp-agent-build", "stripe-agentic-commerce-docs-9" ] }, { "productId": "stripe-agentic-commerce", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe's docs show an extensive API surface for agentic commerce (Product Catalog Import API, Checkout Sessions, Shared Payment Tokens, MCP server exposing Stripe API tools, restricted API keys, CLI/sandbox tooling) letting agents perform most seller/agent/consumer actions programmatically, with the MCP server explicitly wrapping the API. However evidence also documents real UI/human dependencies: seller onboarding is described as 'Dashboard self-serve', and Stripe's own MCP server 'requires human confirmation' via a Dashboard approval URL before certain writes (refunds, outbound payments), meaning not all actions can be completed purely via API without a human UI step. Missing for 10: evidence that seller onboarding and gated write actions (refunds, payouts) can be fully completed via API without a Dashboard/human approval step, and independent confirmation of full UI/API feature parity.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-mcp-approval", "stripe-agentic-commerce-docs-5", "stripe-agentic-commerce-docs-7", "stripe-ac-supp-order-attribution" ] }, { "productId": "stripe-agentic-commerce", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers agentic checkout, payment tokens, MCP tools, machine payments, and wallet CLIs, but contains no mention of a data export feature, open-format data portability, or account/data offboarding process for merchants or AI agents using the platform.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "openness-open-license", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-acp-openness", "stripe-agentic-commerce-gh-1", "stripe-ac-probe-rt-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is a hosted payments/commerce SaaS platform, not infrastructure a user could run on their own servers; self-hosting the core product is a category error for this kind of managed financial service.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "order-event-webhooks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-order-attribution", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-spt-limits", "stripe-ac-supp-seller-catalog-feed" ] }, { "productId": "stripe-agentic-commerce", "storyId": "payable-service-directory", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-agentic-commerce-docs-13", "stripe-ac-probe-rt-3", "stripe-ac-probe-rt-2", "stripe-agentic-commerce-docs-9", "stripe-agentic-commerce-docs-18" ] }, { "productId": "stripe-agentic-commerce", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Data residency/region selection is a data-infrastructure/privacy-compliance axis (like a database or SaaS storage layer), not applicable to a payments/commerce protocol layer like Stripe Agentic Commerce, which routes transactions and tokens rather than letting users choose where data is stored.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is a payments/checkout infrastructure product, not an AI model provider or training-data platform; there is no axis for 'preventing data from being used to train AI models' since it does not train models on user data as part of its offering.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Agentic Commerce is a payments/commerce infrastructure product, not a data-collecting AI assistant/tool with telemetry settings; the evidence pack contains no mention of telemetry, analytics opt-out, or usage-tracking controls, and this axis is a category mismatch for a payments API/protocol suite.", "evidenceIds": [] }, { "productId": "stripe-agentic-commerce", "storyId": "refund-via-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-machine-payments", "stripe-ac-supp-mcp-approval", "stripe-ac-supp-order-attribution" ] }, { "productId": "stripe-agentic-commerce", "storyId": "scoped-payment-tokens", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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).", "evidenceIds": [ "stripe-ac-supp-spt-limits", "stripe-agentic-commerce-gh-1", "stripe-ac-supp-link-wallet", "stripe-agentic-commerce-docs-11", "stripe-ac-probe-rt-4", "stripe-ac-supp-mcp-approval" ] }, { "productId": "stripe-agentic-commerce", "storyId": "settlement-payout-clarity", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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", "evidenceIds": [ "stripe-ac-supp-order-attribution", "stripe-ac-supp-machine-payments", "stripe-ac-supp-pricing", "stripe-ac-supp-seller-catalog-feed" ] }, { "productId": "stripe-agentic-commerce", "storyId": "spend-caps-revocation", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.\n\nmissing 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.", "evidenceIds": [ "stripe-ac-supp-spt-limits", "stripe-agentic-commerce-docs-7", "stripe-ac-supp-mcp-approval", "stripe-agentic-commerce-docs-4" ] }, { "productId": "stripe-agentic-commerce", "storyId": "stablecoin-settlement", "verdict": "partial", "quality": 6, "confidence": "high", "rationale": "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.", "evidenceIds": [ "stripe-ac-supp-machine-payments", "stripe-agentic-commerce-docs-9", "stripe-ac-probe-rt-2", "stripe-agentic-commerce-docs-10" ] }, { "productId": "stripe-agentic-commerce", "storyId": "structured-offer-data", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe documents a seller-side catalog feed (CSV) containing product/variant rows with price and availability fields, plus checkout completion via shared payment tokens and delegated checkout webhooks, and agent-builder docs describe 'product feed ingestion' so agents can present offers and checkout. However, the mechanism is a seller-pushed feed into Stripe's index rather than a documented universal read/query API that any developer/agent can call to fetch offer data for an arbitrary listed product, and it's gated behind private preview, onboarding agreements (OCA), and US/Canada/EU-only availability. Missing for 10: a documented public read/query endpoint or protocol response schema for agents to pull offer data on demand, and independent/hands-on confirmation of catalog read access working end-to-end.", "evidenceIds": [ "stripe-ac-supp-seller-catalog-feed", "stripe-ac-supp-embedded-checkout-oca", "stripe-ac-supp-acp-custom-checkout", "stripe-ac-supp-chat-commerce" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-cart-create", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-5", "visa-intelligent-commerce-docs-3" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-catalog-search", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payment authorization/tokenization/mandate layer for agent-initiated checkout (enrollment, passkey step-up, purchase-intent mandates, credential retrieval), not a product-catalog or merchant-search API; nothing in the evidence describes agents querying product/service listings across merchants. Product discovery is a different axis than payment rails, so this story does not apply to this product's category.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-checkout-complete", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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'.", "evidenceIds": [ "visa-ic-supp-1", "visa-ic-supp-2", "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-intelligent-commerce-docs-5", "visa-intelligent-commerce-docs-7" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-fraud-liability", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-8", "visa-ic-supp-2", "visa-ic-supp-6" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-identity-tiers", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-gh-1", "visa-intelligent-commerce-gh-2", "visa-intelligent-commerce-docs-11", "visa-ic-supp-6", "visa-ic-supp-7", "visa-ic-supp-9", "visa-ic-probe-rt-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-order-attribution", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-6", "visa-ic-supp-9", "visa-ic-supp-8", "visa-ic-supp-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-order-tracking", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-5", "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-traffic-controls", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-gh-1", "visa-intelligent-commerce-gh-2", "visa-ic-supp-6", "visa-ic-supp-9" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agent-wallet-provisioning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-1", "visa-ic-supp-2", "visa-ic-supp-3", "visa-ic-supp-4", "visa-intelligent-commerce-docs-3" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-probe-1", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2", "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-docs-10" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-2", "visa-intelligent-commerce-docs-3", "visa-ic-supp-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a developer/payments infrastructure platform that enables third-party AI agents to transact on a user's behalf — it is not itself a product with a built-in AI assistant that an end user interacts with and delegates tasks to. The evidence describes APIs, tokens, mandates, and protocols for external agents, not a native assistant UI, so this axis is a category mismatch for this product type.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2", "visa-ic-supp-10" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "medium", "rationale": "Visa Intelligent Commerce is a payments infrastructure/API product, not an agent runtime or orchestrator that consumes external tools; the evidence only shows Visa exposing its own capabilities via an MCP server (docs-8, docs-9, docs-10, probe-2) for others to connect to, which is the opposite direction of 'plugging MCP servers into this product.' Acting as an MCP client that ingests arbitrary third-party tool servers is not a fair capability to expect of a payment-rails platform, so this axis does not apply.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-docs-9", "visa-intelligent-commerce-docs-10", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-9", "visa-intelligent-commerce-docs-10", "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-docs-10", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2", "visa-ic-supp-10" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-1", "visa-ic-supp-2", "visa-ic-supp-3", "visa-ic-supp-5", "visa-intelligent-commerce-comm-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-docs-10", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2", "visa-ic-supp-3", "visa-ic-supp-5", "visa-ic-supp-9" ] }, { "productId": "visa-intelligent-commerce", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-ic-supp-10", "visa-intelligent-commerce-probe-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "api-machine-spec", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-intelligent-commerce-probe-1", "visa-intelligent-commerce-docs-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-10", "visa-ic-supp-8", "visa-ic-supp-4" ] }, { "productId": "visa-intelligent-commerce", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5" ] }, { "productId": "visa-intelligent-commerce", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-10", "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5" ] }, { "productId": "visa-intelligent-commerce", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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", "evidenceIds": [ "visa-intelligent-commerce-docs-5", "visa-ic-supp-2", "visa-ic-supp-3" ] }, { "productId": "visa-intelligent-commerce", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payment authorization/tokenization and trust protocol for agent-initiated transactions, not a workflow/job orchestration or automation-scheduling platform; the evidence describes mandates, credentials, and passkey step-up flows but nothing resembling recurring job/workflow scheduling. This axis is a category error for a payments infrastructure product.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Visa Intelligent Commerce lets users set mandate parameters (spend caps, expiry) and cancel a purchase intent, which is a rudimentary form of rollback, but there is no evidence of version history, change review, or restoring prior automation states. missing for 10: versioning/history of mandate changes, review/audit UI for past automation edits, rollback beyond simple cancellation.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "catalog-feed-publish", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payments/authentication and trusted-agent-verification layer (tokenization, mandates, passkeys, Trusted Agent Protocol signatures) — none of the evidence concerns publishing a merchant's product/service catalog into agent-discovery surfaces via a feed or import API. Catalog/discovery feeds are a different product category (commerce catalog/search infrastructure) than agentic payment authorization, so this axis is a category error for this product.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "chat-surface-checkout", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-docs-9", "visa-ic-supp-1", "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-ic-probe-rt-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "checkout-spec-versioned", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-ic-supp-6", "visa-ic-supp-9", "visa-ic-supp-10", "visa-intelligent-commerce-docs-11" ] }, { "productId": "visa-intelligent-commerce", "storyId": "dispute-handling-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "fees-transparency-agent-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "http-402-machine-payments", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-7", "visa-ic-supp-6", "visa-ic-supp-9", "visa-intelligent-commerce-gh-3" ] }, { "productId": "visa-intelligent-commerce", "storyId": "human-approval-gate", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-2", "visa-ic-supp-3", "visa-ic-supp-4", "visa-ic-supp-5", "visa-ic-supp-6", "visa-intelligent-commerce-docs-7", "visa-ic-supp-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "merchant-agent-onboarding", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-10", "visa-ic-supp-9", "visa-intelligent-commerce-gh-1", "visa-intelligent-commerce-gh-2", "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "multi-implementer-adoption", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-comm-1", "visa-intelligent-commerce-comm-2", "visa-ic-supp-9", "visa-ic-probe-rt-1" ] }, { "productId": "visa-intelligent-commerce", "storyId": "open-spec-published", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-probe-rt-1", "visa-ic-supp-9", "visa-ic-supp-6", "visa-ic-supp-10", "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "openness-api-parity", "verdict": "na", "quality": 0, "confidence": "medium", "rationale": "Visa Intelligent Commerce is an API/infrastructure platform for agent-initiated payments (tokenization, mandates, credentials, TAP signatures) consumed by merchants and agent developers; there is no separate first-party end-user UI product whose feature set the API must match. The evidence pack shows only developer docs, sandbox onboarding, and an MCP/agent-toolkit for API consumption—no Visa-run consumer or merchant UI is described as a parity benchmark, so the 'UI vs API parity' axis is a category mismatch here.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "openness-full-export", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payments/agent-authorization infrastructure product, not a data-holding service with a personal data corpus for a user to export; 'export all my data in open formats and leave' is a data-portability axis that doesn't fit this product's category.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "openness-open-license", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-probe-rt-1", "visa-ic-supp-9", "visa-intelligent-commerce-gh-1", "visa-intelligent-commerce-docs-10" ] }, { "productId": "visa-intelligent-commerce", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a hosted payment-network service (tokenization, mandates, authorization) that inherently depends on Visa's proprietary payment rails and cannot be self-hosted by a third party; this is a category error, not a missing feature. The open-sourced Trusted Agent Protocol reference implementation is a companion trust/signature spec, not the core commerce/payments product itself.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "order-event-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-5", "visa-ic-supp-3", "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "payable-service-directory", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-8", "visa-intelligent-commerce-probe-1", "visa-intelligent-commerce-probe-2", "visa-ic-probe-rt-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers tokenization, consent, mandates, and the Trusted Agent Protocol but contains no mention of data residency, regional storage options, or geographic controls over where consumer/agent data is held. This is a plausible axis for a payments platform (as compliance/residency is common in enterprise payment products), but nothing in the docs, GitHub, or probes addresses it.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payments/agentic-commerce infrastructure product, not an AI model provider or platform that trains models on user data; the evidence pack covers tokenization, consent, mandates, and agent authentication, with no mention of AI model training on user data at all. This axis is a category error for a payments network product.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-intelligent-commerce-docs-3", "visa-ic-supp-2" ] }, { "productId": "visa-intelligent-commerce", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payments/agent-authorization infrastructure product, not a telemetry-collecting AI tool or SDK where a user opts out of usage tracking; the evidence pack covers consent, mandates, and payment authorization, not telemetry collection preferences. This axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "visa-intelligent-commerce", "storyId": "refund-via-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-8", "visa-ic-supp-5" ] }, { "productId": "visa-intelligent-commerce", "storyId": "scoped-payment-tokens", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-1", "visa-ic-supp-2", "visa-ic-supp-3", "visa-ic-supp-5", "visa-ic-supp-4" ] }, { "productId": "visa-intelligent-commerce", "storyId": "settlement-payout-clarity", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-5", "visa-ic-supp-7", "visa-ic-supp-8" ] }, { "productId": "visa-intelligent-commerce", "storyId": "spend-caps-revocation", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "visa-ic-supp-3", "visa-ic-supp-2", "visa-ic-supp-1", "visa-ic-supp-5", "visa-intelligent-commerce-docs-3" ] }, { "productId": "visa-intelligent-commerce", "storyId": "stablecoin-settlement", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [ "visa-intelligent-commerce-docs-4", "visa-ic-supp-1", "visa-ic-supp-3", "visa-ic-supp-4" ] }, { "productId": "visa-intelligent-commerce", "storyId": "structured-offer-data", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Visa Intelligent Commerce is a payment-and-trust rail (tokenization, consent/mandates, agent authentication, credential retrieval) for agent-initiated checkout — it is not a product catalog or discovery service and has no evidence of exposing price/availability/variant data for arbitrary listed products; that is a merchant/catalog concern, not a payments-network concern.", "evidenceIds": [] } ]