Stripe Agentic Commerce vs Skyfire

Cart

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Checkout

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

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

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

   proof ↗⚑ flag

Embedded surfaces

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Protocol conformance

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialprobed4/10

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

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

   proof ↗⚑ flag

Agent search

1. ai-native userMy agent can programmatically search products or services across merchants — keylessly or with self-service credentials, no private partnership required

   weight 3 · round to Skyfire
   Stripe Agentic Commerce~partialclaimed4/10

   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.

   • [claimed-docs] “"Link CLI gives your agent access to a wallet that your customer controls. Your agent can retrieve one-time-use payment credentials to compl…”
   • [claimed-docs] “Stripe Directory helps developers and AI agents find the best external providers for a task and follow the best supported path to provision …”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”

   proof ↗⚑ flag

   Skyfire~partialprobed5/10

   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.

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

   proof ↗⚑ flag

Machine readable offers

1. developerRead machine-readable offer data — price, availability, variants, checkout links — for any listed product or service

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

   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.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “For agent builders, the embedded mode manages "the full checkout lifecycle through Stripe, including product feed ingestion, cart management…”
   • [claimed-docs] “The ACP-style custom integration has sellers "implement a reverse API that defines the requests Stripe sends to your commerce backend and th…”
   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”

   proof ↗⚑ flag

   Skyfire~partialprobed3/10

   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.

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

   proof ↗⚑ flag

Merchant feeds

1. merchantPublish my product or service catalog into agent surfaces through a documented feed or import API so AI agents can discover what I sell

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

   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.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration.”
   • [claimed-docs] “It lets you share product, price, and availability information with agents while minimizing changes to your existing commerce systems.”
   • [claimed-docs] “Stripe's agentic-commerce hub is explicitly chat-native: "Buyers can browse products, get personalized recommendations, and complete purchas…”

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

   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.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Service discovery

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

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

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

   proof ↗⚑ flag

Agent access

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

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

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

   ⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

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

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

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

   ⚑ flag

Agentic features

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

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

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

   proof ↗⚑ flag

Api quality

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Fees transparency

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Payouts

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

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

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

   proof ↗⚑ flag

Attribution analytics

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

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

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

   proof ↗⚑ flag

Onboarding to agents

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed7/10

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

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

   proof ↗⚑ flag

Traffic controls

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed4/10

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

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

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

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

   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.

   • [claimed-docs] “Merchant onboarding is Dashboard self-serve — "Use Agentic Commerce Suite (ACS) to start selling through agents with a single integration", …”
   • [claimed-docs] “Dashboard-side agent actions carry a documented human approval gate: "To prevent agents from making mistakes, Stripe requires human confirma…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API”
   • [claimed-docs] “RAKs are the recommended type of key for API keys you give to AI agents.”
   • [claimed-docs] “Agent orders flow through standard Stripe rails with per-agent attribution: "Stripe sends `checkout.session.completed` after the agent compl…”

   proof ↗⚑ flag

   Skyfire~partialprobed6/10

   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.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agent…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

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

   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.

   ⚑ flag

   Skyfire—none0/10

   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.

   ⚑ flag

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Order events

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Delegated credentials

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Machine payments

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed7/10

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

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

   proof ↗⚑ flag

Settlement rails

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed3/10

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

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

   proof ↗⚑ flag

Wallets

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullclaimed7/10

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

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

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

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

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

   ⚑ flag

   Skyfire—none0/10

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

   ⚑ flag

Ecosystem adoption

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Spec publication

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialprobed4/10

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

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

   proof ↗⚑ flag

Disputes

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

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

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

   ⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Refunds

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

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

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

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

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Agent identity

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

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

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

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

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Human oversight

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

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

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

   proof ↗⚑ flag

Liability

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

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

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

   ⚑ flag

   Skyfire~partialclaimed6/10

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

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

   proof ↗⚑ flag

Spend controls

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

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

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

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

   proof ↗⚑ flag

   Skyfire~partialclaimed4/10

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

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

   proof ↗⚑ flag