PayPal 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 PayPal Agentic Commerce
   PayPal Agentic Commerce✓fullclaimed8/10

   PayPal documents a concrete, callable cart protocol: POST /merchant-cart createcart to create a cart from a PayPalCart object and getcart to retrieve/update cart status, validation issues, and totals, explicitly invoked by AI agents/PayPal Shopping Cart during checkout; the agent toolkit also exposes create_order and related order-management tools callable by AI agents via MCP/LangChain/etc. Missing for 10: no independent hands-on developer report confirming a live end-to-end agent-driven cart creation/update flow beyond PayPal's own docs, and cart update (vs. only create/get) isn't explicitly documented as a separate call.

   • [claimed-docs] “Creates a new cart with the provided PayPalCart object. This is called by PayPal Shopping Cart when an AI agent or customer initiates a chec…”
   • [claimed-docs] “Retrieves the current state of a cart. Used by PayPal Shopping Cart to check cart status, validation issues, and current totals.”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “The companion read endpoint keeps agent-side cart state fresh: get cart "Retrieves the current state of a cart. Used by PayPal Shopping Cart…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”

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

   Docs describe a real end-to-end path: agent-initiated checkout session (ACP requestCheckout / UCP checkout-session), a delegated one-time-use payment credential (Braintree nonce / Google Pay token), and order confirmation flowing into the merchant's existing order system, backed by a cart API and agent toolkit tools (create_order, pay_order). However this is gated behind Braintree accounts, PayPal's form-based approval, Google's separate merchant enablement, and Store Sync's narrow scope (US, physical goods only) — all from first-party docs with no independent or hands-on confirmation of a completed purchase. Missing for 10: independent/hands-on evidence of an actual completed agent purchase, broader (non-gated) merchant eligibility, and real-world confirmation beyond sandbox/spec descriptions.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”

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

   PayPal offers real infrastructure for in-chat checkout: ACP for ChatGPT (via Braintree delegated tokens), UCP for Google AI Mode/Gemini (via Google Pay tokens), and Store Sync for broader catalog/agent discovery, plus an MCP server and agent toolkit. However, coverage is fragmented and gated — Store Sync is US-only, physical-goods-only, and access is form-gated with manual onboarding; ACP/UCP require an existing Braintree relationship or separate Google merchant registration; no evidence of Claude or Copilot checkout support is present. Missing for 10: broader platform coverage beyond ChatGPT/Google (Claude, Copilot), self-serve enablement without form gating, and independent/hands-on confirmation of live buyer transactions completing in-chat.

   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”
   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”

   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 drawn
   PayPal Agentic Commerce~partialclaimed4/10

   PayPal does version its agentic-commerce cart API (v1 createcart/getcart) and provides catalog-feed validation tooling for Store Sync ('a validated product catalog file' against Google/OpenAI ACP feed specs), and it interoperates with external versioned protocols (ACP, UCP). But there's no evidence of a published, standalone schema (e.g., OpenAPI/JSON Schema) for PayPal's own agentic-commerce protocol nor a formal conformance/test suite for developers to validate protocol implementations beyond feed-file field checks. Missing for 10: published protocol schema/spec document, dedicated conformance or validation test suite for the cart/checkout API (not just catalog feed format), and independent evidence of developers using such tooling.

   • [claimed-docs] “Creates a new cart with the provided PayPalCart object. This is called by PayPal Shopping Cart when an AI agent or customer initiates a chec…”
   • [claimed-docs] “Retrieves the current state of a cart. Used by PayPal Shopping Cart to check cart status, validation issues, and current totals.”
   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “The companion read endpoint keeps agent-side cart state fresh: get cart "Retrieves the current state of a cart. Used by PayPal Shopping Cart…”

   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
   PayPal Agentic Commerce!disputedcontradicted3/10

   PayPal frames agentic commerce as 'connect once to reach many platforms', but access to Store Sync/agentic commerce services is explicitly form-gated ('merchants must complete a form... to request access... PayPal AI team will follow up to guide onboarding'), Agent Ready requires an existing Braintree merchant relationship, and UCP requires separate Google merchant registration — none of this is keyless or self-service, and runtime probing confirms the live MCP server itself demands OAuth Bearer authentication (401 + www-authenticate) rather than allowing keyless discovery calls. This contradicts the story's requirement of keyless or self-service, no-partnership product search across merchants. Missing for 10: keyless/anonymous cross-merchant product search, a genuinely self-serve onboarding path without a sales/approval form, and evidence of catalog search working without a pre-existing Braintree/PayPal merchant relationship.

   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce~partialclaimed5/10

   PayPal's Store Sync catalog feed spec and agent-toolkit's list_product/show_product_details tools do define machine-readable offer fields (id, title, price, availability, description, image_link, link — with each row representing a product variant) and cart-read endpoints expose price/checkout totals, so the core data model the story asks for exists. But this is a gated, merchant-onboarding pathway (form approval required, US-only physical goods, Braintree/PayPal-account prerequisite) rather than an open read surface for 'any listed product,' and there's no evidence of a simple public GET-offer endpoint or checkout-link retrieval independent of the full agentic-commerce integration. Missing for 10: an open/self-serve read API (vs form-gated onboarding), broader product/geography scope, explicit example of returning a checkout link, independent/hands-on corroboration of reading catalog data.

   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “The companion read endpoint keeps agent-side cart state fresh: get cart "Retrieves the current state of a cart. Used by PayPal Shopping Cart…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce~partialclaimed6/10

   PayPal documents a real catalog-publishing path (Store Sync with feed specs like Google Product Feed/OpenAI ACP Product Feed, CSV/TSV/PSV, field requirements) that explicitly targets AI-agent discovery, plus partner-based catalog connections (Wix, Cymbio, BigCommerce/Feedonomics, Shopware). However, access is form-gated (not self-serve), scope is narrow (US-only, physical goods, USD only), and eligibility requires an existing PayPal/Braintree merchant account with compatible setup. missing for 10: self-serve onboarding without a sales-gated form, broader product-type/geography coverage, independent merchant confirmation the feed import actually surfaces products in live agent surfaces (ChatGPT/Gemini) rather than only demo/spec documentation.

   • [claimed-docs] “Easy setup: Connect your product listings to PayPal's partners like Wix, Cymbio, Commerce (BigCommerce & Feedonomics), and Shopware to make …”
   • [claimed-docs] “It connects your product catalog and commerce API with PayPal's agentic commerce services, enabling AI agents to discover your products, cre…”
   • [claimed-docs] “By the end of this page, you will have a validated product catalog file that is ready to connect to Store Sync.”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”

   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 Skyfire
   PayPal Agentic Commerce~partialprobed5/10

   PayPal provides discovery mechanisms — Store Sync product-catalog feeds (Google Product Feed / OpenAI ACP Product Feed) that let AI agents 'discover your products' and a live MCP server discoverable via RFC 9728 well-known metadata — but there is no published cross-merchant directory or marketplace index of payable services/APIs; discovery is scoped to a single merchant's catalog after form-gated onboarding, and Store Sync itself is limited to US physical goods only. missing for 10: a cross-merchant/public discovery index of payable services or APIs, evidence of self-serve (non form-gated) discoverability, and support beyond US physical goods.

   • [claimed-docs] “It connects your product catalog and commerce API with PayPal's agentic commerce services, enabling AI agents to discover your products, cre…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [probe] “official MCP server documented at https://developer.paypal.com/ai-tools/mcp-server”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce✓fullprobed9/10

   There's a confirmed live llms.txt at developer.paypal.com/llms.txt (HTTP 200) plus per-page .md agent-readable docs (e.g. agent-ready/overview.md), and the docs are explicitly agent-oriented (MCP server, agent toolkit, ACP/UCP guides) that an AI agent could consume directly. Missing for 10: no independent third-party report of an agent actually consuming llms.txt successfully in the wild, just first-party probes.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.paypal.com/llms.txt # PayPal Developer Documentation > PayPal's developer documentation for i…”
   • [probe] “PROBE docs-md: HTTP 200 at https://developer.paypal.com/agent-ready/overview.md # Agent Ready overview (/agent-ready/overview) Agent Read…”
   • [probe] “official MCP server documented at https://developer.paypal.com/ai-tools/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   PayPal's agent toolkit (npm/PyPI packages) and REST APIs, plus the sandbox environment, can be scripted headlessly and invoked from CI pipelines via SDKs (LangChain, CrewAI, OpenAI Agents SDK, MCP) without a UI; webhooks and sandbox credentials support automated testing. However the remote MCP server requires interactive OAuth/PKCE authorization flow (dynamic client registration, bearer auth), which complicates pure headless/CI use, and there's no explicit CI/automation guide or example pipeline in the evidence. missing for 10: documented headless auth flow for CI (service-account/client-credentials for MCP), explicit CI/automation examples, and independent confirmation of unattended operation.

   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [claimed-docs] “The PayPal sandbox "is a self-contained, virtual testing environment that simulates the live PayPal production environment" — "a shielded sp…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”

   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 drawn
   PayPal Agentic Commerce✓fullprobed8/10

   PayPal documents and runtime-probes an official MCP server (developer.paypal.com/ai-tools/mcp-server) plus a published agent-toolkit npm/PyPI package explicitly listing MCP as a supported integration, and a live probe confirms the remote MCP endpoint (mcp.paypal.com/mcp) responds with proper OAuth-protected-resource metadata. missing for 10: independent/community hands-on confirmation of a successful end-to-end MCP client connection (beyond PayPal's own docs and the auth-handshake probe), and clearer documentation of the full tool list exposed over MCP.

   • [claimed-docs] “PayPal built an MCP server that lets merchants use natural language with their favorite MCP clients. This helps users complete business task…”
   • [probe] “official MCP server documented at https://developer.paypal.com/ai-tools/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

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

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   The evidence pack documents PayPal's Agent Toolkit, MCP server, REST APIs, and SDKs, but nowhere mentions an official command-line interface (CLI) tool for developers or AI-native users to interact with PayPal's agentic commerce services. Since PayPal is a developer-facing platform with APIs and SDKs, a CLI would be a plausible product offering, but none is evidenced here.

   ⚑ 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 PayPal Agentic Commerce
   PayPal Agentic Commerce✓fullprobed9/10

   PayPal publishes extensive, concrete developer documentation (REST API reference, Agent Toolkit, MCP server, agentic-commerce cart API, Store Sync, ACP/UCP guides) with runtime confirmation of a live MCP endpoint and published npm/PyPI SDK packages, giving AI-native developers a genuinely documented public API surface to build against. Missing for 10: some flows are form-gated/partner-gated (Braintree, Store Sync approval) rather than fully self-serve, slightly limiting pure API-driven access.

   • [claimed-docs] “PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using Amazon Bedrock, CrewAI, LangChain, Model Contex…”
   • [claimed-docs] “PayPal built an MCP server that lets merchants use natural language with their favorite MCP clients. This helps users complete business task…”
   • [claimed-docs] “Creates a new cart with the provided PayPalCart object. This is called by PayPal Shopping Cart when an AI agent or customer initiates a chec…”
   • [claimed-docs] “Retrieves the current state of a cart. Used by PayPal Shopping Cart to check cart status, validation issues, and current totals.”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “The PayPal sandbox "is a self-contained, virtual testing environment that simulates the live PayPal production environment" — "a shielded sp…”

   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 Skyfire
   PayPal Agentic Commerce~partialprobed4/10

   There's no explicit 'issue a scoped API key/token for an agent' feature for the general Agent Toolkit or REST API surface, but agent-specific payment tokens are documented as scoped/least-privilege by design — the ACP delegated token is 'bound to your merchant ID and includes amount and time restrictions that you can configure,' and the MCP server enforces OAuth with PKCE and dynamic client registration rather than static keys. This shows some least-privilege credentialing pattern for agent checkout flows but not a general-purpose scoped-credential system for arbitrary agent API access. Missing for 10: documented scope/permission tiers (e.g., read-only vs write) for the Agent Toolkit or REST OAuth tokens, and any self-serve UI/API to mint restricted credentials per agent.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce✓fullprobed8/10

   PayPal publishes an official Agent Toolkit SDK (npm/PyPI, versioned and actively published) integrating with MCP, OpenAI Agents SDK, LangChain, CrewAI, Vercel AI SDK, and Bedrock, plus documented pre-built functions for orders, invoices, subscriptions, refunds, disputes, and catalog management, backed by REST API docs, sandbox testing, and webhooks. This is corroborated by runtime probes confirming the toolkit is live on public registries and the MCP server is reachable. Missing for 10: independent third-party developer reviews/case studies of building against these SDKs beyond PayPal's own docs and registry probes.

   • [claimed-docs] “PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using Amazon Bedrock, CrewAI, LangChain, Model Contex…”
   • [claimed-docs] “PayPal built an MCP server that lets merchants use natural language with their favorite MCP clients. This helps users complete business task…”
   • [claimed-docs] “Integrate with PayPal APIs to access orders, invoices, subscriptions, shipment tracking, transaction details, and dispute management through…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [claimed-docs] “The PayPal sandbox "is a self-contained, virtual testing environment that simulates the live PayPal production environment" — "a shielded sp…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [github] “create_order: Create an order in PayPal system based on provided details”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce✓fullclaimed7/10

   PayPal's webhook API is explicitly documented: merchants can subscribe up to 10 webhook URLs per app, scoped to specific event types, with durable retry (25 attempts over 3 days) and signature verification guidance — enabling event-driven, agentic integrations. Missing for 10: explicit agentic-commerce-specific event types (e.g., cart/order events tied to AI checkout flows) and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”

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

   PayPal provides the building blocks for background automation — an agent toolkit with pre-built functions (orders, refunds, disputes, subscriptions) usable in LangChain/CrewAI/Bedrock workflows, an MCP server for natural-language triggered actions, and webhooks that fire asynchronously with retry logic — enabling autonomous background agent workflows. However, PayPal's own docs explicitly recommend keeping 'human oversight in areas where personal judgment matters most,' and much of the deeper commerce automation (Store Sync, agentic commerce services) is gated behind manual application forms rather than self-serve autonomous setup. Missing for 10: evidence of a fully autonomous, unattended scheduling/orchestration layer, independent confirmation of agents running unattended in production, and self-serve (non-form-gated) enablement.

   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”

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

   PayPal supports natural-language operation via its MCP server and agent toolkit (LangChain, OpenAI Agents SDK, CrewAI, etc.), letting AI agents issue commands for orders, refunds, disputes, and shopping carts in conversational form, and a runtime probe confirms the MCP endpoint is live. However, the 'user' operating this isn't typically an end consumer speaking to PayPal directly — most flows are merchant-hosted or gated behind Braintree/Google/form approval, and the natural-language surface is mediated through third-party chat assistants (ChatGPT, Gemini) or developer-built agents rather than a native PayPal NL interface. missing for 10: independent/hands-on evidence of an end user directly issuing free-form natural-language commands to PayPal itself (not via a third-party chat assistant or developer-built agent), and confirmation the MCP server/agent toolkit works smoothly without heavy setup/gating.

   • [claimed-docs] “PayPal built an MCP server that lets merchants use natural language with their favorite MCP clients. This helps users complete business task…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

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

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

   proof ↗⚑ flag

Api quality

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

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

   Evidence shows static API reference pages (createcart, getcart) and REST API docs, plus a sandbox environment for testing, but nothing describing an interactive reference with embedded runnable/try-it-out examples (e.g., live code execution in docs, Swagger-style console). Missing for 10: any mention of an interactive API console, embedded runnable code snippets, or in-docs request execution.

   • [claimed-docs] “Creates a new cart with the provided PayPalCart object. This is called by PayPal Shopping Cart when an AI agent or customer initiates a chec…”
   • [claimed-docs] “Retrieves the current state of a cart. Used by PayPal Shopping Cart to check cart status, validation issues, and current totals.”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “The PayPal sandbox "is a self-contained, virtual testing environment that simulates the live PayPal production environment" — "a shielded sp…”

   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
   PayPal Agentic Commerce—none0/10

   The evidence pack documents REST API references, SDKs, webhooks, and endpoint descriptions (e.g., createcart/getcart docs), but nowhere mentions a downloadable OpenAPI/Swagger file or other machine-readable spec artifact for the agentic-commerce or general PayPal APIs. This axis is clearly applicable to an API-based commerce product, but no evidence shows PayPal exposing such a spec for download.

   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “The companion read endpoint keeps agent-side cart state fresh: get cart "Retrieves the current state of a cart. Used by PayPal Shopping Cart…”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce✓fullclaimed8/10

   PayPal documents a dedicated sandbox that mirrors production, allowing developers/agents to test agent-toolkit tools, cart API, and checkout flows without touching live accounts, and confirms the same REST rails (Orders, cart API) run against sandbox credentials. Missing for 10: no independent/hands-on verification of sandbox parity for agentic-commerce-specific flows (cart API, ACP/UCP checkout) and no explicit documentation of sandbox mode for the MCP server or agent toolkit specifically.

   • [claimed-docs] “The PayPal sandbox "is a self-contained, virtual testing environment that simulates the live PayPal production environment" — "a shielded sp…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”

   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
   PayPal Agentic Commerce—none0/10

   The evidence pack documents PayPal's agentic-commerce APIs (createcart, getcart, agent toolkit, REST APIs) including a versioned path like /v1/createcart, but nowhere is there any documented deprecation policy, versioning strategy, or backward-compatibility commitment for AI agents to rely on. The axis is clearly applicable (PayPal is an API-first commerce platform) but no supporting evidence exists.

   • [claimed-docs] “Creates a new cart with the provided PayPalCart object. This is called by PayPal Shopping Cart when an AI agent or customer initiates a chec…”
   • [claimed-docs] “Retrieves the current state of a cart. Used by PayPal Shopping Cart to check cart status, validation issues, and current totals.”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

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

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

   The evidence shows only single-item agent tools (create_order, create_refund, get_dispute, etc.) and a one-time bulk catalog feed upload for merchant setup, but no documented bulk/batch operation capability (e.g., batch refunds, batch order processing, multi-item transaction endpoints) that an AI agent could invoke across many items at once.

   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce~partialclaimed5/10

   Evidence shows agent-originated transactions run through existing Braintree/PayPal Checkout rails and thus inherit the standard published US commercial fee schedule (2.99–4.99% + fixed fee), so merchants aren't quoted a hidden or sales-negotiated rate for the payment processing itself. However, the same evidence explicitly states 'No separate agentic/AI-channel fee schedule is published,' and access to Agent Ready/Store Sync/ACS is gated behind a sales-contact form, leaving open whether any additional platform or enablement fee applies to the agentic channel — so a merchant cannot fully price the agentic channel without engaging sales for onboarding. Missing for 10: an explicit agentic-channel fee page or fee line item, and self-serve (non-form-gated) enrollment that would let a merchant confirm total costs without sales contact.

   • [claimed-docs] “The published US commercial rates that agent-initiated orders inherit: "PayPal Checkout" and "PayPal Guest Checkout" at "3.49% +" fixed fee,…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”

   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 PayPal Agentic Commerce
   PayPal Agentic Commerce~partialclaimed6/10

   Agent-originated orders flow into the merchant's existing order management, payment, refund/dispute, and webhook systems (create_order, refund/dispute tools, webhooks with signature verification, existing Orders v2/Braintree rails), and docs explicitly state Store Sync orders arrive 'just as it would from any other channel,' suggesting standard reconciliation. However, there is no dedicated agentic-channel reporting/settlement documentation, no separate transaction tagging or reconciliation report distinguishing agent-originated payments, and fee schedules show no distinct line item for agent transactions, making channel-level reconciliation an inference rather than a documented flow. missing for 10: dedicated agent-channel reporting/settlement statements, explicit reconciliation tooling or transaction tags identifying agent-originated payments, independent merchant confirmation of clean reconciliation in production.

   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”
   • [claimed-docs] “The published US commercial rates that agent-initiated orders inherit: "PayPal Checkout" and "PayPal Guest Checkout" at "3.49% +" fixed fee,…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

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

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

   proof ↗⚑ flag

Attribution analytics

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

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

   Evidence covers agent-initiated checkout flows (ACP/UCP/Store Sync/cart API/agent toolkit) but nowhere describes orders being tagged with an originating-agent identifier, nor any merchant dashboard/report/filter capability by agent; in fact Store Sync docs state orders arrive 'just as it would from any other channel,' suggesting no special agent attribution.

   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “The companion read endpoint keeps agent-side cart state fresh: get cart "Retrieves the current state of a cart. Used by PayPal Shopping Cart…”

   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 to Skyfire
   PayPal Agentic Commerce~partialclaimed5/10

   There is documented onboarding material (Agent Ready guides, Store Sync docs, catalog feed specs), but the path is explicitly gated rather than self-serve: PayPal's own docs state that agentic commerce services access is 'form-gated, not self-serve' requiring a form submission and manual follow-up from PayPal's AI team, Store Sync eligibility requires an existing Braintree/Orders v2 account plus the same approval gate, and the UCP/Google Pay path requires separate 'merchant registration with Google. Contact Google for enablement.' Agent Ready itself assumes an existing Braintree merchant relationship rather than a simple toggle or self-issued agreement. Missing for 10: a true no-approval self-serve enablement (setting flip, standard clickthrough agreement, or endpoint publish without a contact-form/manual review step), and confirmation of approval turnaround time.

   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Catalog publishing is feed-file based: "PayPal supports 3 feed specifications", including the Google Product Feed ("you can reuse it to powe…”

   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 Skyfire
   PayPal Agentic Commerce—none0/10

   Evidence shows PayPal gates agentic-commerce access at the platform/onboarding level (Braintree account, Google UCP registration, PayPal AI-team approval form) and gives merchants brand/communication control, but nothing describes merchant-configurable rate limits or per-agent/per-platform allow/deny controls over catalog or checkout access.

   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”

   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
   PayPal Agentic Commerce~partialclaimed6/10

   PayPal's agent toolkit and REST APIs expose a broad set of merchant operations (orders, invoices, subscriptions, refunds, disputes, shipment tracking, catalog management) that mirror much of what's doable in the PayPal/Braintree dashboards, and there's a documented MCP server, SDKs, and sandbox for building against these. However, the flagship agentic-commerce paths are heavily gated rather than self-serve: Agent Ready requires a Braintree account, Store Sync and Agentic Commerce Services require a manual form-based approval process, UCP requires separate Google merchant registration, and Store Sync itself is scoped only to US physical goods in USD — none of which are pure API-driven equivalents of UI actions. Missing for 10: explicit UI-vs-API feature-parity mapping, self-serve (non-gated) access to the agentic commerce APIs, and confirmation that all dashboard-level configuration/reporting is API-accessible without approval gates.

   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “The PayPal sandbox "is a self-contained, virtual testing environment that simulates the live PayPal production environment" — "a shielded sp…”

   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 userRead the product's source under an open license

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

   PayPal's agentic commerce services (Store Sync, ACP/UCP integrations, agent toolkit) are proprietary hosted APIs and closed-source integrations; the agent-toolkit SDK is published on npm/PyPI but no evidence indicates an open-source license for its source, and core commerce services (Store Sync, cart API, MCP server backend) are entirely closed, gated behind forms and merchant accounts. No evidence pack item shows an open-license repository for the product's source.

   ⚑ 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 PayPal Agentic Commerce
   PayPal Agentic Commerce~partialclaimed5/10

   PayPal's generic webhooks system (developer.paypal.com/api/webhooks/overview) lets a merchant subscribe up to 10 URLs to specific event types, with durable retry (up to 25 attempts/3 days) and signature verification — and the agent-toolkit/cart API run on the same REST/order rails, so this infrastructure would carry order events. However, no evidence pack item explicitly names order-lifecycle event types (ORDER.CREATED/UPDATED/CANCELLED/fulfilled) tied to the agentic-commerce cart or Store Sync flows — those docs describe merchant-hosted reverse endpoints (createcart/getcart) rather than push-based lifecycle events for agents. Missing for 10: explicit order-lifecycle event-type list for agentic commerce, confirmation that Store Sync/cart orders emit standard webhook events, and any hands-on/independent proof of an agent successfully subscribing to these events.

   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “The companion read endpoint keeps agent-side cart state fresh: get cart "Retrieves the current state of a cart. Used by PayPal Shopping Cart…”

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Delegated credentials

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

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

   PayPal's ACP/UCP flows use Braintree single-use payment tokens/nonces that are explicitly described as 'bound to your merchant ID and includes amount and time restrictions that you can configure' — a genuine scoped, limited-use credential rather than a raw card number, and Google's UCP path similarly returns a tokenized, single-use credential. However this is merchant-side infrastructure (tokens generated by the merchant's Braintree integration for a specific checkout), not a consumer/end-user-controlled credential that an AI-native user personally hands to their own agent with self-set amount/expiry/merchant limits; there's no evidence of a user-facing wallet-style scoped credential issuance flow. missing for 10: end-user-facing UI/API for a consumer to mint their own scoped credential (set their own amount cap, expiry, merchant allowlist) independent of a specific merchant checkout session, and independent/hands-on confirmation of these restriction configs working in practice.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Machine payments

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

   weight 3 · round to Skyfire
   PayPal Agentic Commerce—none0/10

   All evidence describes PayPal's agentic commerce as checkout-flow based (carts, ACP/UCP delegated tokens, Store Sync, agent toolkit for orders/refunds/disputes) — none of it describes HTTP 402 status-code machine payments or per-call API monetization without a checkout UI, which is a distinct technical pattern. Since PayPal is a payments platform, this axis could plausibly apply, but there is no evidence it ships or supports the 402 pay-per-call mechanism described in the story.

   ⚑ flag

   Skyfire~partialclaimed7/10

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

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

   proof ↗⚑ flag

Settlement rails

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

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

   The evidence pack details PayPal's agentic commerce rails extensively (ACP/UCP via Braintree tokens, agent toolkit, cart APIs, webhooks, fees) but none of it mentions stablecoins, PYUSD, crypto, or blockchain-based settlement rails for agent-initiated payments — all documented settlement is via traditional card/Braintree processing and standard PayPal fee schedules.

   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”
   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “The published US commercial rates that agent-initiated orders inherit: "PayPal Checkout" and "PayPal Guest Checkout" at "3.49% +" fixed fee,…”

   proof ↗⚑ flag

   Skyfire~partialclaimed3/10

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

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

   proof ↗⚑ flag

Wallets

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

   weight 3 · round to Skyfire
   PayPal Agentic Commerce—none0/10

   All evidence describes merchant-side infrastructure (Agent Ready, Store Sync, agent toolkit, cart APIs) that lets AI agents check out with merchants or lets merchants build agents for order/refund/dispute management — none of it describes a consumer-provisioned wallet that a user funds, an agent holds/spends from, with balance visibility. The delegated tokens in ACP/UCP are single-use, merchant-bound checkout credentials, not a persistent user wallet.

   ⚑ 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
   PayPal Agentic Commerce—none0/10

   The evidence pack covers agentic commerce protocols, cart APIs, webhooks, fees, and toolkit integrations, but contains no mention of data retention policies, deletion controls, or privacy settings that an AI-native user could invoke to manage stored data. This axis plausibly applies to a payments platform handling AI agent transaction data, but no supporting evidence exists.

   ⚑ flag

   Skyfire—none0/10

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

   ⚑ flag

Ecosystem adoption

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

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

   The evidence shows PayPal/Braintree acting as an implementer of protocols defined by other parties (OpenAI's ACP, Google's UCP, and the Anthropic-originated MCP), but nothing shows independent third parties implementing PayPal's own agentic-commerce platform (Cart API, Store Sync, agent toolkit) as an open ecosystem. Merchants and partners (Wix, Shopware, BigCommerce) are consumers/integrators of PayPal's platform, not independent implementers of its protocol.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Store Sync is the full-catalog path, "enabling AI agents to discover your products, create and manage shopping carts, and complete purchases…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”

   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 Skyfire
   PayPal Agentic Commerce—none0/10

   The evidence pack shows PayPal implements OpenAI's ACP and Google's UCP protocols and tells developers to 'follow the ACP agentic checkout specification,' but never provides or links a version number, license, or spec document for ACP/UCP that a developer could read independently of PayPal. Instead, everything documented is gated: Braintree merchant account required, PayPal AI team form-approval required for agentic commerce services, and separate Google merchant registration required for UCP enablement — none of this evidences an open, versioned, sign-nothing spec.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Access to PayPal's agentic commerce services is form-gated, not self-serve: merchants must complete a form "to contact the AI team at PayPal…”
   • [claimed-docs] “"Agent Ready helps Braintree merchants accept payments from AI shopping assistants across major platforms, including ChatGPT, Google AI Mode…”

   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 to PayPal Agentic Commerce
   PayPal Agentic Commerce~partialclaimed6/10

   The agent toolkit exposes dispute tools — list_disputes, get_dispute, and accept_dispute_claim — plus the general REST API surface explicitly lists 'disputes' alongside orders/payments, giving developers programmatic access to dispute status and resolution outcomes. However, no evidence-submission endpoint (e.g., uploading documents/evidence for a dispute) is documented anywhere in the pack, so the 'evidence submission' part of the story is unsupported. missing for 10: documented evidence-submission API/tool for disputes, and any hands-on/independent confirmation that these dispute tools work end-to-end in production.

   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “Integrate with PayPal APIs to access orders, invoices, subscriptions, shipment tracking, transaction details, and dispute management through…”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”

   proof ↗⚑ flag

   Skyfire—none0/10

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

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

   proof ↗⚑ flag

Refunds

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

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

   The Agent Toolkit exposes create_refund/get_refund tools and dispute tools (list_disputes, get_dispute, accept_dispute_claim) so refunds on agent-placed orders can be initiated and tracked programmatically via MCP/LangChain/etc., backed by the underlying PayPal REST orders/disputes API and webhooks for status updates. However, the docs don't specifically address refund flows tied to the new agentic-commerce cart/checkout (ACP/UCP) orders, and there's no independent hands-on confirmation of refund success for agent-originated transactions. missing for 10: explicit documentation linking refund/dispute tools to agent-placed (ACP/UCP/Store Sync) orders specifically, and independent/hands-on verification of the refund tracking flow.

   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the PayPal Agent Toolkit resolves on the public npm registry (npm view @paypal/agent-toolkit → 1.11.0, …”
   • [claimed-docs] “The developer portal's REST API getting-started page anchors the agent surface: "REST APIs, including orders, payments, subscriptions, invoi…”

   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
   PayPal Agentic Commerce—none0/10

   PayPal's docs describe payment-token authentication (Braintree single-use tokens bound to merchant ID), PayPal-issued JWTs for verifying that requests come from PayPal's own Shopping Cart service, and webhook signature verification — but none of this constitutes a verifiable agent identity system (no registered agent profiles, agent-level signatures, or trust tiers that would let a merchant distinguish which specific AI agent or bot is originating traffic). The authentication documented is merchant-to-PayPal or PayPal-to-merchant channel security, not agent-to-merchant identity/trust signaling.

   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”
   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”
   • [probe] “PROBE runtime (recorded 2026-09-14): PayPal's remote MCP server is live — a keyless JSON-RPC initialize POST to https://mcp.paypal.com/mcp a…”

   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 drawn
   PayPal Agentic Commerce~partialclaimed5/10

   PayPal's ACP/UCP flows use single-use, time- and amount-bound delegated tokens tied to a specific merchant and transaction, and the toolkit docs explicitly recommend 'human oversight' for judgment-sensitive actions — both suggest transaction-level guardrails rather than fully autonomous spending. However, the evidence never documents an explicit user-facing confirmation screen, signed mandate artifact, or per-purchase consent UI shown to the end user before the token is used to move money; the checkout flow (requestCheckout/Instant Checkout) is described only at a technical/token level, not from the consent-UX perspective. Missing for 10: an explicit documented consent/confirmation step or mandate artifact shown to the payer, and any independent/hands-on confirmation that this consent step actually blocks unauthorized charges.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “"PayPal's agent toolkit supports the integration of PayPal APIs into AI agent workflows using" Amazon Bedrock, CrewAI, LangChain, MCP, OpenA…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”

   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
   PayPal Agentic Commerce—none0/10

   Evidence shows general dispute-management and refund tools (list_disputes, accept_dispute_claim, create_refund) and standard PayPal fee/webhook docs, but nothing documents fraud, liability, or chargeback allocation specifically for agent-initiated transactions (e.g., who bears risk when a delegated token or AI agent purchase is disputed). The delegated-token docs mention tokens are 'bound to your merchant ID' but stop short of stating liability shift or chargeback rules for agent-driven checkouts.

   • [claimed-docs] “Post-purchase operations are first-class agent tools: refunds via create_refund / get_refund (a "refund for a captured payment", where "If n…”
   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The published US commercial rates that agent-initiated orders inherit: "PayPal Checkout" and "PayPal Guest Checkout" at "3.49% +" fixed fee,…”
   • [claimed-docs] “"Webhooks are HTTPS posts from PayPal to an endpoint on your server whenever the corresponding event type occurs" — "Up to 10 webhook URLs m…”

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

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

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

   proof ↗⚑ flag

Spend controls

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

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

   Evidence shows per-transaction delegated tokens with configurable amount/time restrictions bound to a merchant (paypal-ac-supp-acp-chatgpt), but nothing about a user or merchant setting persistent per-agent spend caps/usage limits across multiple transactions, or an instant revoke-authority mechanism for a given agent's payment access. No dashboard, API, or docs reference for agent-level authorization management or revocation is present.

   • [claimed-docs] “The ACP path is an in-ChatGPT checkout build: "Implement an MCP server with the `complete_checkout` tool to receive tokens", "Call `requestC…”
   • [claimed-docs] “The UCP path targets Google surfaces: "This enables AI-powered checkout experiences through Google AI Mode (Gemini), where Google Pay return…”
   • [claimed-docs] “Cart execution is a reverse API the merchant hosts: POST /merchant-cart "Creates a new cart with the provided PayPalCart object. This is cal…”

   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