[ { "productId": "adyen", "storyId": "accept-card-payment-online", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Adyen's docs describe a fast technical integration (single /sessions call, test-then-go-live flow, no setup fees) that could suggest same-day acceptance, but independent community reports concretely contradict a founder's ability to just sign up and start accepting payments quickly: Adyen reportedly refuses small clients ('under the million'), requires large reserves for subscription businesses, and one user describes a multi-hundred-hour integration effort before abandoning it. These are hands-on, specific counter-examples, not generic skepticism, so the 'within a day' claim is disputed rather than simply partial. Missing for 10: any evidence of Adyen actually onboarding a small/new founder-level merchant same-day, or a rebuttal to the reserve/minimum-volume gating reports.", "evidenceIds": [ "adyen-docs-1", "adyen-docs-6", "adyen-docs-23", "adyen-comm-1", "adyen-comm-6", "adyen-comm-9", "adyen-comm-11" ] }, { "productId": "adyen", "storyId": "agent-handles-dispute-end-to-end", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of a Disputes API, chargeback evidence submission, or any agent/MCP workflow for handling disputes end-to-end—only risk/fraud detection (Protect), refusal reasons, and unrelated agentic-commerce checkout flows are documented. The MCP server's tool list (sessions, payment links, modifications, management API) explicitly does not include dispute retrieval or evidence submission.", "evidenceIds": [ "adyen-supp-mcp-tools", "adyen-docs-8", "adyen-docs-48", "adyen-docs-7" ] }, { "productId": "adyen", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen provides the raw building blocks an agent could use—webhooks for status changes (adyen-docs-3/17/45), refusal-reason detail on failed payments (adyen-docs-7), idempotent retries (adyen-docs-4/25), and an MCP server exposing webhook list/get/test and payment tools (adyen-supp-mcp-tools)—but there is no documented dunning/subscription-retry feature, automated outreach mechanism, or agent workflow specifically for failed-payment recovery. Missing for 10: native dunning/retry orchestration, recurring-billing failed-payment workflow, and evidence of an agent actually driving retries/outreach rather than just monitoring raw webhook/API data.", "evidenceIds": [ "adyen-docs-3", "adyen-docs-7", "adyen-docs-17", "adyen-docs-25", "adyen-docs-45", "adyen-supp-mcp-tools" ] }, { "productId": "adyen", "storyId": "agent-provisions-payment-link", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Adyen's API and MCP server cover payments, payment links, checkout sessions, and payouts, but there is no evidence of any 'product' or 'price' resource concept (billing/catalog objects like Stripe's Products/Prices) that an agent could provision alongside a payment link — Adyen is a payments processor, not a billing/invoicing product catalog system. The only 'product' references are to inventory feeds for agentic commerce (syncing existing catalog to AI platforms), not creating new products/prices via API. missing for 10: evidence of a Products/Prices API or equivalent billing object model, evidence of a single-session workflow that creates a product+price+payment link together, any documentation of provisioning billing entities (not just payment links) via API or MCP.", "evidenceIds": [ "adyen-supp-mcp-tools", "adyen-docs-24", "adyen-supp-agentic-feed" ] }, { "productId": "adyen", "storyId": "agent-reconciles-payouts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes payouts, payout frequency, currencies, and a dashboard 'visual representation' of balances/payouts (adyen-docs-9,10,12,30,43), but nowhere documents an API for pulling balance/transaction-level data or a reconciliation workflow that an agent could invoke — the MCP tool list (adyen-supp-mcp-tools) covers checkout, payment links, and management API objects (merchants, terminals, webhooks, credentials) with no balance-transaction or reconciliation tools. Missing for 10: documented Balance/Transaction API endpoints, evidence of agent/MCP access to payout reconciliation data, and any reconciliation workflow example.", "evidenceIds": [ "adyen-docs-9", "adyen-docs-10", "adyen-docs-12", "adyen-docs-30", "adyen-docs-43", "adyen-supp-mcp-tools" ] }, { "productId": "adyen", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 10, "confidence": "high", "rationale": "Adyen has a live, probed llms.txt (HTTP 200) plus markdown-renderable docs pages (append .md), a documented full-docs ZIP mirror explicitly for feeding AI agents/code assistants, and an OpenAPI spec repo positioned as LLM context — this is direct, independently-probed confirmation of agent-oriented docs.", "evidenceIds": [ "adyen-probe-1", "adyen-probe-2", "adyen-supp-docs-tools", "adyen-supp-openapi-source-of-truth" ] }, { "productId": "adyen", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen Uplift is documented as an AI layer that analyzes payment data and 'gives you recommendations that are tailored for your business' to optimize conversion, risk, and cost, and risk management includes ML-powered fraud detection using global transaction data. This matches the spirit of AI-generated insights/suggestions from account data, but it's narrowly scoped to payment-funnel optimization and fraud, not a general-purpose 'insights' feature across reporting/dashboards, and there's no independent/hands-on corroboration of how these suggestions surface in the UI. Missing for 10: broader AI-generated insights across reporting/analytics (not just Uplift/fraud), and third-party or hands-on evidence of the insights UX.", "evidenceIds": [ "adyen-supp-uplift-ai", "adyen-docs-29", "adyen-docs-20", "adyen-docs-28", "adyen-docs-10" ] }, { "productId": "adyen", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen supports several background/event-driven automations — webhooks that eliminate manual polling for async status changes, Uplift's AI-driven payment-funnel optimization experiments that can be started/evaluated/stopped autonomously, and risk-management rules/ML fraud detection that run continuously — but these are fixed platform features rather than a general-purpose mechanism for an AI-native user to author custom autonomous background automations. Missing for 10: a user-configurable automation/workflow builder or scheduler that an AI-native user can set up to run arbitrary agentic tasks unattended, and independent evidence of such automations running reliably in production.", "evidenceIds": [ "adyen-docs-3", "adyen-docs-17", "adyen-supp-uplift-ai", "adyen-docs-20", "adyen-docs-28" ] }, { "productId": "adyen", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Adyen documents an MCP server (for external LLM clients to call Adyen's APIs) and 'Uplift' (automated AI-driven payment optimization), but no evidence of a built-in AI assistant/copilot inside the Adyen product itself that a user can converse with or delegate tasks to interactively.", "evidenceIds": [ "adyen-docs-5", "adyen-supp-mcp-tools", "adyen-supp-uplift-ai" ] }, { "productId": "adyen", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen's core integration is a server-to-server REST API (docs-1, docs-2) that can be called entirely headlessly with no UI dependency, supports idempotency keys for safe automated retries (adyen-docs-4, adyen-docs-25), and provides a dedicated test environment with test credentials explicitly meant for pre-production integration testing (adyen-docs-6, adyen-docs-18). Scoped, multiple API credentials support automated/service-account style access (adyen-docs-26, adyen-supp-api-credential-scoping). However, there is no explicit CI/CD pipeline documentation, no CLI/SDK testing harness, and the MCP server is documented as running locally via npx rather than as a CI-oriented headless service. Missing for 10: explicit CI/CD integration guides, automated test-suite/SDK tooling, and confirmation of non-interactive credential provisioning for pipelines.", "evidenceIds": [ "adyen-docs-1", "adyen-docs-2", "adyen-docs-4", "adyen-docs-25", "adyen-docs-6", "adyen-docs-18", "adyen-docs-26", "adyen-supp-api-credential-scoping" ] }, { "productId": "adyen", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen is a payments platform/API, not an AI agent or assistant host; it ships an MCP *server* exposing its own payment tools (adyen-docs-5, adyen-supp-mcp-tools) but nothing suggests Adyen itself acts as an MCP client/host that plugs in and consumes external MCP servers' tools. This 'plug servers into it' client-role story is a category error for a payments API product.", "evidenceIds": [ "adyen-docs-5", "adyen-supp-mcp-tools" ] }, { "productId": "adyen", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen documents and ships an official MCP server (github.com/Adyen/adyen-mcp) that lets LLM clients call Checkout, payment links, modifications, and Management API tools via natural language, with clear setup (npx install), scoped API-key auth, and role-based permissions. Missing for 10: independent/hands-on third-party verification of the MCP server working in practice (only vendor docs and a live-probe confirming the doc page exists, no community usage reports) and clarity on production-readiness given its 'Alpha' status.", "evidenceIds": [ "adyen-docs-5", "adyen-docs-27", "adyen-probe-4", "adyen-supp-mcp-tools", "adyen-supp-mcp-credential-roles" ] }, { "productId": "adyen", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "Adyen ships an official MCP server (adyen-mcp) that explicitly lets users 'use natural language with your chosen LLM client' to interact with Adyen APIs (create sessions, payment links, refunds, management API), with documented scoped-credential setup — a genuine natural-language operation surface for AI-native users. However, the MCP server is explicitly marked 'Alpha', runs only locally via npx, and only exposes a documented subset of tools rather than full product coverage. Missing for 10: production-grade/GA status, independent hands-on validation of the NL interface actually working reliably, and broader coverage beyond the documented tool subset.", "evidenceIds": [ "adyen-docs-5", "adyen-docs-27", "adyen-supp-mcp-tools", "adyen-supp-mcp-credential-roles", "adyen-probe-4" ] }, { "productId": "adyen", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers an MCP server, OpenAPI specs, docs tooling, and agentic-commerce protocols, but there is no mention of an official Adyen CLI for AI-native workflows anywhere in the pack.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Adyen ships extensive documented public REST APIs (Checkout, Management, Platforms, Payouts, Agentic Commerce, etc.), an OpenAPI spec repo as 'single source of truth' for client generation, idempotency keys, scoped API credentials, webhooks, and machine-readable docs (llms.txt, .md pages, full docs mirror) explicitly aimed at AI tooling. Probes independently confirm llms.txt and .md doc endpoints return 200. Missing for 10: a live discoverable OpenAPI/swagger endpoint directly under docs.adyen.com (probe found 404s on standard paths) and independent third-party corroboration of API usability beyond vendor docs.", "evidenceIds": [ "adyen-supp-openapi-source-of-truth", "adyen-supp-docs-tools", "adyen-docs-25", "adyen-supp-api-credential-scoping", "adyen-docs-3", "adyen-probe-1", "adyen-probe-2", "adyen-probe-3" ] }, { "productId": "adyen", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen documents scoped, role-based API credentials (roles define exactly what a credential can do, e.g. limiting to initiating vs capturing payments, per-merchant-account scoping) and explicitly recommends creating multiple credentials for finer-grained access control — and the MCP server docs instruct assigning a dedicated API credential with only the specific roles needed for agent use, plus a --tools flag to limit which MCP tools are exposed. This directly supports least-privilege credential issuance for an AI agent. missing for 10: no independent/hands-on verification of least-privilege enforcement in practice, and no explicit per-agent short-lived/ephemeral credential mechanism beyond static role-scoped API keys.", "evidenceIds": [ "adyen-supp-api-credential-scoping", "adyen-supp-mcp-credential-roles", "adyen-supp-mcp-tools", "adyen-docs-26" ] }, { "productId": "adyen", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen documents official SDKs for web/iOS/Android/React Native/Flutter and a public OpenAPI spec repo as the 'single source of truth' usable to generate client libraries, which supports SDK-based building; however, the OpenAPI/spec endpoint probes returned 404s and there's no independent/hands-on corroboration of SDK quality or completeness for AI-native workflows specifically. missing for 10: independent verification of official SDK repos/quality, working OpenAPI spec endpoint (probe returned 404s), hands-on developer confirmation of SDK-based agentic integration.", "evidenceIds": [ "adyen-docs-14", "adyen-supp-openapi-source-of-truth", "adyen-probe-3" ] }, { "productId": "adyen", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen provides first-party webhook subscriptions to avoid polling, with event logs visible in the Customer Area, and MCP tools to list/get/test webhooks, plus agentic-commerce flows that explicitly send webhook payment outcomes to merchant servers — showing webhooks are usable both directly and via AI-native/agent tooling. missing for 10: no independent/hands-on developer confirmation of webhook subscription setup via API or MCP, and no detail on webhook event types/payload schema management through natural-language/agentic tooling.", "evidenceIds": [ "adyen-docs-3", "adyen-docs-17", "adyen-docs-45", "adyen-supp-mcp-tools", "adyen-supp-google-ucp" ] }, { "productId": "adyen", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes OpenAPI specs (usable to generate Postman collections or client libraries), markdown-rendered docs, and an MCP server for natural-language API access, but there is no evidence of an actual interactive API reference/console embedded in Adyen's docs where a user can run live example requests. A probe for a standard OpenAPI/Swagger endpoint also returned 404s, and no 'try it' console or embedded runnable code examples are documented.", "evidenceIds": [ "adyen-supp-openapi-source-of-truth", "adyen-probe-3", "adyen-supp-docs-tools" ] }, { "productId": "adyen", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen documents a dedicated OpenAPI specification repository (github.com/Adyen/adyen-openapi) covering 'every public API Adyen offers' as the 'single source of truth,' explicitly positioned for machine consumption (client-library generation, Postman collections, and LLM/agent context). This is reinforced by llms.txt, markdown-renderable docs, and a full docs mirror ZIP for AI tooling. missing for 10: independent/hands-on confirmation that the OpenAPI repo is current and complete, and a direct in-docs discoverable openapi.json endpoint (probe found only 404s for openapi.json-style paths on the docs domain itself).", "evidenceIds": [ "adyen-supp-openapi-source-of-truth", "adyen-supp-docs-tools", "adyen-probe-1", "adyen-probe-3" ] }, { "productId": "adyen", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen documents a dedicated test environment for the full integration (client- and server-side) using test credentials before going live, and this test environment is explicitly wired into AI-native workflows via the Adyen MCP server which runs with `--env=TEST` (or LIVE with a live prefix), letting an AI agent exercise Checkout, payment links, and modification tools against sandbox data. Missing for 10: no independent/hands-on confirmation that sandbox test data is fully isolated from production, and no detail on seeding/resetting sandbox state for repeatable AI-driven test runs.", "evidenceIds": [ "adyen-docs-6", "adyen-docs-18", "adyen-supp-mcp-tools", "adyen-docs-5" ] }, { "productId": "adyen", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers API idempotency, webhooks, credentials, OpenAPI specs, and agentic commerce integrations, but contains no documentation of API versioning scheme or a deprecation policy for older API versions. Versioning/deprecation policy is a standard and fair axis for a payments API platform, so absence of evidence yields 'none'.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "automatic-tax-calculation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Adyen's evidence pack is entirely about payment processing, payouts, platforms, risk management, and agentic-commerce integrations — nothing addresses tax calculation, VAT/GST determination, tax collection, or tax compliance/remittance features. This axis applies since a payments platform could plausibly integrate tax calculation, but no evidence shows Adyen offers this.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen documents concrete bulk operations in its agentic Product Feed API — batch ingest of up to 200 items per call and batch delete of up to 200 products per call — which is genuine 'many items at once' functionality for AI-platform inventory sync. However, evidence of bulk operations elsewhere in the platform (e.g., bulk payouts, bulk refunds/modifications, bulk reporting exports, or MCP tools operating on many resources at once) is absent; the MCP tool list is single-item oriented (create one session, one payment link, one refund). Missing for 10: bulk support evidenced across other core domains (payments, payouts, platforms/onboarding) and bulk-capable MCP tools, not just the product feed.", "evidenceIds": [ "adyen-docs-38", "adyen-supp-agentic-feed", "adyen-supp-mcp-tools" ] }, { "productId": "adyen", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen documents a genuine rules mechanism — the risk management rule builder lets you 'create, backtest, and label custom rules' that automatically trigger block/allow/review actions on each transaction event (adyen-docs-20, adyen-docs-28, adyen-docs-48), and webhooks notify on async status-change events (adyen-docs-3/17). This satisfies the core 'rule triggers action on event' pattern, but only within the fraud/risk-decisioning domain, not as a general-purpose automation/workflow engine, and there's no evidence of AI-native rule authoring (e.g., via the MCP server or natural language) for these rules. Missing for 10: general cross-domain event-action automation beyond fraud rules, AI/LLM-driven rule creation or triggering, and independent evidence of real-world use of the rule builder.", "evidenceIds": [ "adyen-docs-20", "adyen-docs-28", "adyen-docs-48", "adyen-docs-8", "adyen-docs-3", "adyen-docs-17" ] }, { "productId": "adyen", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen is a payments platform; scheduling recurring jobs/workflows (general automation orchestration) is not a capability category it addresses—its 'recurring' features are limited to payout frequency, not general job/workflow scheduling, which is outside its product category.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen is a payments platform, not an automation/workflow-builder product; there is no concept of 'automations' with version history, review, or rollback in its evidence pack — this axis is a category error for a payments API/platform.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "dunning-failed-payment-recovery", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers payments, payouts, webhooks, idempotency, risk management, platforms/marketplace payouts, and agentic commerce, but contains no mention of subscription billing, dunning management, automatic retry logic for failed recurring payments, or recovery emails. This is a plausible axis for a payments platform, but nothing in the docs or community evidence shows Adyen offering smart dunning/recovery workflows.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen's Web/mobile Drop-in and Components let developers embed sessions-based payment UI directly in their own site/app (web, iOS, Android, React Native, Flutter) with customizable styling and localization, rather than redirecting to a hosted page. This is a core, well-documented capability with sample flows (create session, mount Components) and cross-platform SDK support. Missing for 10: independent hands-on confirmation of embedding ease (community feedback is mixed/critical on integration complexity), and no detailed code-level customization examples in the pack.", "evidenceIds": [ "adyen-docs-1", "adyen-docs-14", "adyen-docs-15", "adyen-docs-19", "adyen-docs-44", "adyen-comm-10" ] }, { "productId": "adyen", "storyId": "fraud-screening-rules", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen's Protect risk management system explicitly provides ML-based fraud scoring plus a rule builder to create, backtest, and label custom rules, with risk evaluations resulting in block/allow/review actions — directly matching the story. Missing for 10: independent/hands-on validation of the rule builder UX and finance-ops-specific workflow evidence beyond first-party docs.", "evidenceIds": [ "adyen-docs-8", "adyen-docs-20", "adyen-docs-28", "adyen-docs-48", "adyen-supp-uplift-ai" ] }, { "productId": "adyen", "storyId": "hosted-checkout-page", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen explicitly offers hosted 'payment links' that developers can generate and redirect customers to without building payment UI (adyen-docs-24), and the MCP tool surface confirms this as a first-class API capability (create/get/expire payment links) (adyen-supp-mcp-tools). However, Adyen's primary integration path emphasized in the docs is the Sessions/Components client-side flow which requires building or embedding UI (adyen-docs-1), and there is no detailed documentation on conversion-optimization specifics of the hosted page itself. Missing for 10: dedicated documentation describing the hosted checkout page's design/conversion features, independent evidence of its effectiveness, and clarity on it being the recommended 'no-code UI' path rather than a secondary option.", "evidenceIds": [ "adyen-docs-24", "adyen-supp-mcp-tools", "adyen-docs-1" ] }, { "productId": "adyen", "storyId": "idempotent-api-retries", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen explicitly documents idempotency-key headers for retrying API requests without duplicate side-effects (adyen-docs-4, adyen-docs-25), directly matching the story. Missing for 10: independent/hands-on developer confirmation of idempotency behavior in production and detail on key expiration/edge cases.", "evidenceIds": [ "adyen-docs-4", "adyen-docs-25" ] }, { "productId": "adyen", "storyId": "integrate-from-docs-in-a-day", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Adyen's docs describe a clear-looking integration path (single /sessions call or paymentMethods/payments/payments/details flow, testing, webhooks) and multi-platform SDK support (web, iOS, Android, React Native, Flutter), but no evidence pack item actually shows copy-paste code samples per language, and independent hands-on reports directly contradict the 'under a day' claim: one integrator says 'after hundreds of hours invested, we ditched Adyen' and another states 'Stripe beats Adyen on ease of integration... hands down,' while a third calls it 'much more bare metal' than turnkey competitors. A counter-report says the integration 'was not as terrible as many here make it seem,' so the picture is mixed rather than uniformly negative. missing for 10: actual copy-paste language-specific code samples in the evidence, a documented time-to-first-payment benchmark, and independent confirmation that integration is fast rather than the reported multi-hundred-hour effort.", "evidenceIds": [ "adyen-docs-1", "adyen-docs-2", "adyen-docs-6", "adyen-docs-14", "adyen-comm-9", "adyen-comm-10", "adyen-comm-5", "adyen-comm-11" ] }, { "productId": "adyen", "storyId": "marketplace-split-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen for Platforms is explicitly documented to onboard sellers/contractors with verification (adyen-docs-11, adyen-docs-31, adyen-docs-36), split payments between parties and hold funds until payout (adyen-docs-21, adyen-docs-37), and configure flexible payout frequency/currency/local vs cross-border payouts (adyen-docs-12, adyen-docs-13, adyen-docs-22, adyen-docs-43, adyen-docs-50). Reporting/dashboards and risk management further round out the marketplace platform story (adyen-docs-10, adyen-docs-8). missing for 10: independent/hands-on developer account of building a full marketplace integration end-to-end, and more granular API-level detail (e.g., specific split-payment API request/response schemas) beyond docs summaries.", "evidenceIds": [ "adyen-docs-11", "adyen-docs-21", "adyen-docs-31", "adyen-docs-36", "adyen-docs-37", "adyen-docs-12", "adyen-docs-13", "adyen-docs-22", "adyen-docs-43", "adyen-docs-49", "adyen-docs-50", "adyen-docs-10" ] }, { "productId": "adyen", "storyId": "multi-currency-charge-settle", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Adyen documents accepting local payment methods/currencies, configuring multiple payout currencies per merchant account, and both local (no SWIFT fee) and cross-border (SWIFT) settlement options, plus flexible payout timing/currency choice — directly supporting charge-local/settle-in-own-currency workflows. However, there's no explicit documentation of FX rate transparency (e.g., disclosed markup, real-time rate reporting) beyond the currency/payout mechanics themselves. Missing for 10: explicit FX rate/markup transparency documentation, independent confirmation of settlement FX handling in practice.", "evidenceIds": [ "adyen-docs-13", "adyen-docs-22", "adyen-docs-30", "adyen-docs-43", "adyen-docs-12", "adyen-docs-50" ] }, { "productId": "adyen", "storyId": "no-code-payment-links", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Adyen's docs confirm a payment-links feature exists (\"Offer payment links\" - adyen-docs-24) and a Customer Area dashboard for managing transactions (adyen-docs-16), but there is no evidence of a self-serve, no-code flow a founder can use to instantly start selling. Community reports concretely contradict the 'start immediately' premise for founders: Adyen is described as refusing small clients ('Adyen refuses small clients, under the million' - adyen-comm-1) and requiring underwriting/minimum volumes that keep early-stage startups away ('integration complexity and minimum processing volumes usually keep early-stage startups on Stripe' - adyen-comm-11), unlike a turnkey signup-and-sell experience. missing for 10: documented self-serve onboarding flow for small merchants, step-by-step dashboard payment-link creation, evidence that a founder can go live without a sales/underwriting process.", "evidenceIds": [ "adyen-docs-24", "adyen-docs-16", "adyen-comm-1", "adyen-comm-11" ] }, { "productId": "adyen", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen exposes extensive Management/Checkout/Platforms APIs covering payments, onboarding, payouts, webhooks, credentials, terminals, and even an MCP server wrapping many of these APIs, suggesting broad API/UI parity for core payment operations. However, some UI-only surfaces (Customer Area account/transaction overview, visual reporting dashboards) are described only as UI features with no explicit statement that every dashboard/report/action is also API-accessible, and no full OpenAPI spec was reachable at standard docs endpoints (404s), only a separate GitHub repo. Missing for 10: explicit parity claim or evidence that all Customer Area/reporting/dashboard actions have API equivalents, and a verified complete OpenAPI coverage confirmation.", "evidenceIds": [ "adyen-docs-10", "adyen-docs-16", "adyen-docs-26", "adyen-supp-mcp-tools", "adyen-supp-api-credential-scoping", "adyen-probe-3", "adyen-supp-openapi-source-of-truth" ] }, { "productId": "adyen", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows reporting dashboards and general documentation transparency (llms.txt, markdown docs, OpenAPI specs) but nothing about a merchant being able to export their own transactional/account data in open formats or close their account and leave without lock-in. Reporting is described as visual dashboards (adyen-docs-10), not bulk open-format export, and no data-portability/account-closure mechanism is documented.", "evidenceIds": [ "adyen-docs-10", "adyen-comm-9" ] }, { "productId": "adyen", "storyId": "openness-open-license", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Adyen's core payment-processing platform is closed, proprietary SaaS with no evidence of the underlying service source being published under any license. However, evidence shows genuinely open-source ancillary components: the Adyen MCP server (github.com/Adyen/adyen-mcp) and the OpenAPI specification repo (github.com/Adyen/adyen-openapi) described as 'the single source of truth for our APIs,' both publicly viewable on GitHub. Missing for 10: any open license on the actual platform/service code, no stated license type for the repos, no independent confirmation of license terms, and no indication the core product itself is inspectable beyond API specs and a thin MCP client tool.", "evidenceIds": [ "adyen-supp-mcp-tools", "adyen-supp-openapi-source-of-truth", "adyen-supp-docs-tools" ] }, { "productId": "adyen", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen is a regulated payments processing service (licensed financial institution acting as PSP/acquirer), not software that can be self-hosted by customers; self-hosting a core payment-processing/licensed-institution service is a category error for this product type.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs clearly support configuring payout frequency, currency, and timing per merchant account (adyen-docs-12, adyen-docs-30, adyen-docs-50, adyen-docs-22) and note local vs cross-border payout mechanics (adyen-docs-13, adyen-docs-43). Reporting is mentioned as giving a 'visual representation of balances, sales, and payouts' (adyen-docs-10) and the Customer Area gives an overview of payment channels (adyen-docs-16), but there is no explicit evidence of a line-item payout reconciliation report breaking down which specific charges, fees, and refunds compose each payout. Missing for 10: detailed payout reconciliation report/API showing per-payout transaction breakdown, fee itemization, and refund matching.", "evidenceIds": [ "adyen-docs-12", "adyen-docs-30", "adyen-docs-50", "adyen-docs-22", "adyen-docs-10", "adyen-docs-16", "adyen-docs-13", "adyen-docs-43" ] }, { "productId": "adyen", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen's Checkout API/sessions flow shows card data handled client-side and passed via Adyen's hosted fields/client key rather than touching the merchant's server (adyen-docs-1, adyen-docs-44), which implies the tokenization pattern developers rely on for reduced PCI scope. However, none of the evidence explicitly discusses PCI DSS, SAQ levels, or scope-reduction guidance, so the compliance benefit is only inferable from the technical integration pattern, not documented directly. missing for 10: explicit PCI DSS scope-reduction documentation, SAQ-A eligibility guidance, independent compliance certification evidence.", "evidenceIds": [ "adyen-docs-1", "adyen-docs-44", "adyen-docs-14" ] }, { "productId": "adyen", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of data residency, regional data storage options, or any control over where Adyen stores payment/customer data. While this is a fair question for a payments platform (compliance/data-residency is a common enterprise requirement), nothing in the docs, community posts, or agentic-commerce material addresses it.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen is a payment processing platform, not an AI model provider or chat product that trains models on user data; there's no evidence of any AI-training data usage to opt out of. This axis targets consumer-facing AI/chat tools, which is a category error for a payments infrastructure API.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Adyen's evidence pack covers payments, payouts, risk management, and agentic commerce integrations, but there is no documentation on data retention policies, data deletion requests, or user/API-level controls to manage how long payment or transaction data is stored or how to purge it. This is a fair axis for a payments platform handling PII/PCI data, but no evidence addresses it.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Adyen ships AI-native tooling (an MCP server, docs-for-LLMs surface, agentic commerce APIs) so a privacy-posture question about telemetry/usage-tracking opt-out is a fair axis to ask, but no evidence in the pack describes any telemetry collection by these tools or any opt-out mechanism for it.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "recurring-subscription-billing", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Adyen's evidence pack covers payments, payouts, platforms, risk, reporting, and agentic commerce, but there is no mention of subscription/recurring billing constructs like plans, trial periods, upgrades/downgrades, or proration—these are the domain of a billing/subscription-management layer (e.g. Adyen has separate tooling or partners for this) not documented here.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "refunds-full-partial", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Evidence confirms API-level refund capability (Adyen's Management/Checkout 'modifications' API allows refunding a captured payment, and the MCP tool set explicitly includes 'refund a captured payment') and dashboard access to transaction management via the Customer Area, but no citation explicitly confirms partial-refund amount support or a documented dashboard refund button/workflow. missing for 10: explicit documentation of partial refund support (specifying an amount less than the captured total), explicit dashboard refund action screenshot/flow, and any independent/hands-on confirmation that refunds work as described.", "evidenceIds": [ "adyen-supp-mcp-tools", "adyen-docs-7", "adyen-docs-16", "adyen-docs-45" ] }, { "productId": "adyen", "storyId": "respond-to-disputes-evidence", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Adyen's risk/fraud tooling (Protect, rule builder, ML fraud detection) but contains no documentation of a chargeback/dispute management API, structured evidence submission, or dispute lifecycle tracking/status workflow. A vague community comment says Stripe beats Adyen on chargebacks 'hands down' but gives no concrete detail to substantiate a documented-capability failure, so it doesn't rise to a disputed claim — it simply reinforces the absence of positive evidence.", "evidenceIds": [] }, { "productId": "adyen", "storyId": "sandbox-test-mode-fidelity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen documents a dedicated test environment with test credentials for exercising different transaction types (adyen-docs-18), recommends testing the full client+server integration before going live (adyen-docs-6), and documents refusal reasons/result codes for simulating declines (adyen-docs-7). However, the pack lacks explicit documentation of test cards for disputes/chargebacks specifically, or a catalog of scenario-specific test cards, and community evidence notes real-world integration friction (adyen-comm-9) though not specifically about sandbox fidelity. Missing for 10: explicit dispute/chargeback simulation test cards, a documented full test-card matrix, and independent hands-on confirmation that sandbox mirrors production behavior.", "evidenceIds": [ "adyen-docs-6", "adyen-docs-18", "adyen-docs-7", "adyen-docs-45", "adyen-comm-9" ] }, { "productId": "adyen", "storyId": "send-hosted-invoices", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Adyen's evidence covers payment links, checkout, platforms, payouts, and agentic commerce, but there is no mention of a hosted invoicing product, invoice generation, or automatic payment reminders anywhere in the pack — only generic 'payment links' (adyen-docs-24) which is a different capability.", "evidenceIds": [ "adyen-docs-24" ] }, { "productId": "adyen", "storyId": "settlement-reconciliation-reports", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Adyen's reporting docs mention a dashboard 'visual representation of your balances, sales, and payouts' and configurable payout frequency/currency, implying some settlement reporting exists, but nothing in the evidence describes itemized reconciliation reports that break out fees, refunds, and chargebacks against bank deposits. Missing for 10: documented settlement/reconciliation report format, explicit fee/refund/chargeback itemization, and any bank-deposit matching workflow or independent confirmation it works as needed.", "evidenceIds": [ "adyen-docs-10", "adyen-docs-12", "adyen-docs-16", "adyen-docs-22", "adyen-docs-30", "adyen-docs-43" ] }, { "productId": "adyen", "storyId": "wallets-local-payment-methods", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen docs explicitly promise 'one integration' covering all preferred payment methods (wallets, local methods, BNPL) via a single Checkout API/sessions flow, with community corroboration that it supports native local methods like iDEAL and Sofort. Missing for 10: an explicit itemized list of Apple Pay/Google Pay/BNPL support and independent hands-on confirmation of wallet/BNPL specifically (only general local-method corroboration exists), plus some community friction reports on integration complexity.", "evidenceIds": [ "adyen-docs-35", "adyen-docs-41", "adyen-docs-14", "adyen-docs-1", "adyen-docs-2", "adyen-comm-10" ] }, { "productId": "adyen", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Adyen documents webhook event logs in the Customer Area (adyen-docs-45) and general webhook mechanics to avoid polling (adyen-docs-3/17), plus an MCP tool to 'test' webhooks (adyen-supp-mcp-tools) that hints at replay tooling. However, the evidence pack never explicitly documents HMAC/signature verification for webhook payloads, an automatic retry policy for failed webhook deliveries, or a dedicated replay mechanism. Missing for 10: explicit signed-webhook (HMAC) verification docs, documented automatic retry/backoff schedule for webhook delivery, and a concrete replay/redeliver feature beyond the vague MCP 'test' tool.", "evidenceIds": [ "adyen-docs-45", "adyen-docs-3", "adyen-docs-17", "adyen-supp-mcp-tools", "adyen-docs-4", "adyen-docs-25" ] }, { "productId": "airwallex", "storyId": "accept-card-payment-online", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex offers fast-to-integrate options for accepting online card payments quickly (Payment Links requiring no storefront, Hosted Payment Page, Drop-in Element, sandbox quickstart), which are consistent with a founder going live within a day. However, the evidence does not document the actual account-opening/KYC onboarding timeline or approval SLA for a brand-new founder signing up, which is the critical gatekeeper before any live payment can be accepted. Missing for 10: documented onboarding/KYB approval turnaround time, explicit same-day go-live confirmation, and independent/hands-on evidence of a founder completing signup-to-first-payment within 24 hours.", "evidenceIds": [ "airwallex-docs-9", "airwallex-docs-7", "airwallex-docs-8", "airwallex-docs-18" ] }, { "productId": "airwallex", "storyId": "agent-handles-dispute-end-to-end", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Airwallex documents a general disputes process page (docs-26) but no API endpoints for retrieving disputes, assembling evidence, or submitting responses, and the AgentOS/CLI 'skills' list (contract-to-billing, beneficiary creation, card provisioning, cashflow management) never mentions disputes as a supported agent workflow. Missing for 10: dispute-retrieval API, evidence-assembly workflow, dispute-response submission API, and any AgentOS/CLI skill or MCP tool covering disputes end-to-end.", "evidenceIds": [ "airwallex-docs-26", "awx-supp-agentos" ] }, { "productId": "airwallex", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Airwallex provides the raw building blocks an agent could use for this story: webhooks with retry-safe event IDs and delivery inspection/re-delivery, an AgentOS MCP/CLI toolkit that can read balances and act on the production account, and API access to payments/billing data. However, there is no documented failed-payment monitoring workflow, no dunning/retry-specific Skill, and 'no money-out actions by default' in AgentOS suggests retry/charge actions would be restricted, requiring custom agent logic rather than a built-in capability. missing for 10: a documented failed-payment retry or dunning skill/workflow, evidence of automated retry logic tied to webhook failed-payment events, and confirmation that money-out/retry actions are actually permitted for agents rather than blocked by default guardrails.", "evidenceIds": [ "awx-supp-webhooks", "awx-supp-agentos-mcp", "awx-supp-agentos", "awx-supp-cli", "airwallex-docs-15", "airwallex-docs-13" ] }, { "productId": "airwallex", "storyId": "agent-provisions-payment-link", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex has real billing/invoicing/payment-link APIs and an agent-facing toolkit (AgentOS/CLI/MCP) that can create beneficiaries, cards, and run multi-step workflows, and docs explicitly cover products, subscriptions, invoicing, and payment links, but no evidence shows a documented single-session flow where an agent creates a product, sets a price, and generates a payment link end-to-end via one skill/workflow. missing for 10: an explicit worked example or skill covering product+price+payment-link creation in one agent session, and independent/hands-on confirmation this multi-step billing workflow works in practice.", "evidenceIds": [ "airwallex-docs-9", "airwallex-docs-13", "airwallex-docs-14", "awx-supp-agentos", "awx-supp-cli", "awx-supp-agentos-mcp", "awx-supp-billing-suite" ] }, { "productId": "airwallex", "storyId": "agent-reconciles-payouts", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex documents agent-facing tooling (AgentOS, CLI, MCP server) that lets an agent read balances, build cashflow reports, and pull payout/transfer data programmatically, and the CLI/MCP explicitly support scripting/read access to production resources. However, there is no specific mention of a 'balance transaction' API endpoint or a documented reconciliation workflow matching bank deposits to underlying charges — the closest is generic 'cashflow reports' and 'Skills' bundles. Missing for 10: explicit balance-transactions API/reconciliation endpoint docs, a worked example of matching payouts to charges, and independent/hands-on evidence of this reconciliation working end-to-end.", "evidenceIds": [ "airwallex-docs-3", "airwallex-docs-12", "awx-supp-cli", "awx-supp-agentos-mcp", "awx-supp-agentos" ] }, { "productId": "airwallex", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex publishes a live llms.txt (confirmed HTTP 200 probe) plus explicit agent-oriented docs (developer-connector.md, agentos.md, ai-agent-instructions.md) designed for machine/agent consumption, including instructions written specifically for AI agents and dedicated MCP endpoints. This directly matches pointing an agent at llms.txt/agent-oriented docs. Missing for 10: independent third-party confirmation that agents successfully consume these docs in practice (only vendor docs and a probe, no hands-on community report).", "evidenceIds": [ "airwallex-probe-1", "airwallex-docs-2", "awx-supp-ai-instructions", "awx-supp-developer-mcp", "airwallex-probe-3" ] }, { "productId": "airwallex", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "AgentOS documents pre-built agent workflows including 'building cashflow reports' and 'cashflow management' skills, which implies some data-driven insight generation via AI agents, but this is framed as an external agent toolkit for action-taking (transfers, beneficiaries, cards) rather than a native in-product analytics/insights feature surfaced to users. Missing for 10: evidence of a built-in AI insights/suggestions panel or dashboard inside the Airwallex web app itself, and independent/hands-on confirmation that agent-generated 'reports' actually surface proactive suggestions rather than just executing user-directed tasks.", "evidenceIds": [ "awx-supp-agentos", "airwallex-docs-3", "airwallex-docs-19" ] }, { "productId": "airwallex", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "AgentOS bundles a hosted MCP server, CLI, and pre-built 'Skills' explicitly designed for agents to run multi-step financial workflows 'on your behalf', and webhooks provide event-driven triggers with retry/dedup semantics for automated systems (awx-supp-agentos, awx-supp-agentos-mcp, awx-supp-cli, awx-supp-webhooks). However, these are agent-invoked or event-triggered rather than a documented persistent scheduler/orchestrator, and AgentOS enforces 'no money-out actions by default', limiting true autonomous background operation. Missing for 10: evidence of a native scheduling/cron mechanism or always-on background execution engine, and independent confirmation that automations run unattended without per-invocation agent triggering.", "evidenceIds": [ "awx-supp-agentos", "awx-supp-agentos-mcp", "awx-supp-cli", "awx-supp-webhooks", "airwallex-docs-3" ] }, { "productId": "airwallex", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Airwallex doesn't ship a native in-product chat assistant, but its AgentOS toolkit (CLI + hosted MCP server + pre-built 'skills') lets an AI agent read balances, create beneficiaries, issue cards, and run multi-step workflows on the user's behalf, effectively delegating account tasks — though the actual assistant runs in an external client (Claude Code, Cursor, Claude Cowork) rather than being embedded in Airwallex's own UI. Missing for 10: a first-party assistant surfaced directly inside the Airwallex web app/dashboard, and independent hands-on evidence of end-users delegating tasks this way.", "evidenceIds": [ "awx-supp-agentos", "awx-supp-agentos-mcp", "awx-supp-cli", "airwallex-docs-3" ] }, { "productId": "airwallex", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Airwallex ships a documented CLI explicitly designed for scripting and CI (\"script repeatable tasks, and wire Airwallex into automated systems\"), plus API/webhook infrastructure enabling headless automation, corroborated by a probe confirming the CLI docs exist. Missing for 10: independent third-party evidence of actual CI pipeline usage and explicit CI/CD examples (e.g., GitHub Actions integration) beyond vendor docs.", "evidenceIds": [ "awx-supp-cli", "airwallex-probe-4", "awx-supp-webhooks", "airwallex-docs-15" ] }, { "productId": "airwallex", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Airwallex is a financial platform, not an agentic orchestrator; the evidence shows it publishes MCP *servers* (AgentOS MCP, Developer MCP) for other agents like Claude Code/Cursor to consume its tools — the opposite direction from this story, which asks whether the product itself can plug in and consume external MCP servers' tools. There is no agent runtime within Airwallex that ingests third-party MCP servers, so this axis is a category mismatch for this product type.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex documents an official hosted remote MCP server (AgentOS MCP at https://mcp.airwallex.com/mcp) with OAuth authentication, safety guardrails, and explicit connection instructions for MCP clients like Claude Code, plus a separate Developer MCP for docs/sandbox integration work — both first-party and independently probed as live docs. Missing for 10: independent hands-on third-party verification of the MCP server actually working end-to-end beyond vendor docs and a probe confirming the doc page exists.", "evidenceIds": [ "awx-supp-agentos-mcp", "awx-supp-agentos", "awx-supp-developer-mcp", "airwallex-probe-3" ] }, { "productId": "airwallex", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Airwallex ships AgentOS with an MCP server and CLI explicitly designed so AI agents (Claude Code, Cursor, Codex) can read balances, create beneficiaries, issue cards, and run multi-step financial workflows via natural-language instructions, plus dedicated 'AI agent instructions' docs to guide correct NL-driven API use. Missing for 10: independent/hands-on validation of real-world NL command reliability and no third-party review beyond first-party docs.", "evidenceIds": [ "awx-supp-agentos", "awx-supp-agentos-mcp", "awx-supp-cli", "awx-supp-ai-instructions", "airwallex-probe-3", "airwallex-probe-4" ] }, { "productId": "airwallex", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex documents an official CLI (installable via a public install script) that exposes API resources as terminal commands, supports sandbox/production modes, scripting, and is explicitly positioned as the foundation for AI coding agents to operate accounts, corroborated by a probe confirming the docs page exists. Missing for 10: independent/hands-on third-party review of the CLI beyond vendor docs and probes.", "evidenceIds": [ "airwallex-docs-5", "awx-supp-cli", "airwallex-docs-20", "airwallex-probe-4" ] }, { "productId": "airwallex", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex publishes extensive first-party API documentation, scoped API keys, a sandbox environment, CLI, webhooks with retry semantics, and even dedicated 'Instructions for AI agents' pages plus AgentOS/MCP tooling explicitly built for agentic/programmatic use, confirmed live via probes (llms.txt 200, CLI and AgentOS docs pages resolving). Missing for 10: independent third-party developer corroboration (e.g. community reviews of the public API itself) beyond vendor docs and probes.", "evidenceIds": [ "airwallex-docs-1", "airwallex-docs-4", "airwallex-docs-5", "airwallex-docs-6", "airwallex-docs-15", "awx-supp-cli", "awx-supp-sandbox", "awx-supp-webhooks", "awx-supp-ai-instructions", "airwallex-probe-1", "airwallex-probe-4" ] }, { "productId": "airwallex", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Airwallex documents scoped API keys with granular Read/Write permissions per resource (not full account access), and explicitly ties this to agent use cases via AgentOS/MCP with additional layered safety defaults (no money-out actions by default, OAuth-scoped roles, role-gated CLI authorization). This directly matches the story of issuing least-privilege credentials for an agent. Missing for 10: independent/hands-on verification of scope enforcement and no documented UI/API walkthrough of creating a scoped key specifically for an agent identity.", "evidenceIds": [ "airwallex-docs-4", "awx-supp-agentos-mcp", "awx-supp-cli", "awx-supp-developer-mcp" ] }, { "productId": "airwallex", "storyId": "agentic-sdks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex documents a full official SDK/API surface for AI-native building: REST API, official CLI, hosted MCP servers (AgentOS MCP and Developer MCP), dedicated AI-agent instructions pages, sandbox environment, webhooks, and plugin installs for Claude Code/Cursor. This is well beyond a typical SDK — it includes machine-readable docs, scoped API keys, and agent-specific tooling with safety guardrails, confirmed by both docs and independent probes. Missing for 10: independent third-party developer reviews/hands-on validation of SDK ergonomics beyond vendor docs.", "evidenceIds": [ "airwallex-docs-2", "airwallex-docs-3", "awx-supp-agentos", "awx-supp-agentos-mcp", "awx-supp-developer-mcp", "awx-supp-cli", "awx-supp-ai-instructions", "awx-supp-sandbox", "airwallex-probe-3", "airwallex-probe-4" ] }, { "productId": "airwallex", "storyId": "agentic-webhooks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex documents a full webhooks system with real-time push notifications, stable event IDs for safe retry handling, delivery status inspection, and re-delivery for debugging — clearly enabling event subscription for automated/AI-native workflows. Missing for 10: no independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "airwallex-docs-15", "awx-supp-webhooks" ] }, { "productId": "airwallex", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Airwallex docs claim you can 'explore the API interactively — discover endpoints, preview requests, and inspect schemas before you commit to a full integration' via the CLI, and a sandbox environment lets you run real requests without live money, which together approximate an interactive, runnable API exploration experience. However, there's no evidence of a traditional in-browser interactive API reference (e.g., Swagger/Redoc-style docs with embedded runnable code snippets) — the interactivity is CLI-driven rather than a reference page. Missing for 10: a dedicated interactive web API reference UI, embedded runnable code samples in docs, and independent confirmation of this workflow.", "evidenceIds": [ "airwallex-docs-20", "airwallex-docs-6", "airwallex-docs-18", "awx-supp-cli" ] }, { "productId": "airwallex", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Airwallex documents extensive API tooling (CLI, MCP servers, sandbox, interactive schema explorer), none of the evidence explicitly confirms a downloadable OpenAPI (or equivalent) spec file. The 'inspect schemas' feature (airwallex-docs-20) hints at schema-driven tooling but doesn't confirm exportable machine-readable spec access.", "evidenceIds": [ "airwallex-docs-20", "airwallex-probe-4" ] }, { "productId": "airwallex", "storyId": "api-sandbox", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex documents a dedicated sandbox environment fully separate from production, covering nearly all products/APIs, with self-serve signup and simulation guides, and even AI-specific sandbox MCP/connector tooling (mcp.sandbox.airwallex.com/developer) explicitly for agents to 'create test resources, simulate events, and call sandbox endpoints' without touching production. The CLI also defaults to sandbox unless --prod is passed, reinforcing safe-by-default testing. Missing for 10: independent/hands-on confirmation of sandbox parity beyond docs.", "evidenceIds": [ "airwallex-docs-6", "awx-supp-sandbox", "awx-supp-developer-mcp", "awx-supp-cli", "airwallex-docs-18" ] }, { "productId": "airwallex", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers API keys, sandbox, CLI, MCP/AgentOS, webhooks, and AI-agent instructions, but nowhere documents API versioning conventions or a formal deprecation policy/timeline for endpoints. The only related hint is steering away from a 'legacy' SDK library, which is not evidence of a documented API versioning/deprecation policy.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "automatic-tax-calculation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex's Merchant of Record add-on explicitly automates sales tax, VAT, and GST calculation and collection per sale, letting sellers avoid registering for tax in each market. However, it is documented as a beta feature limited to digital products only (physical goods unsupported), has restricted eligibility, and leaves refunds/disputes to the merchant — so it doesn't cover all transaction types a finance-ops user might need automated tax handling for. Missing for 10: general availability (non-beta) status, physical goods/product coverage, and independent/hands-on verification of tax accuracy across jurisdictions.", "evidenceIds": [ "airwallex-docs-10", "awx-supp-mor" ] }, { "productId": "airwallex", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The Airwallex CLI and AgentOS toolkit let AI agents 'script repeatable tasks' and 'wire Airwallex into automated systems' or run 'multi-step financial workflows,' which implies looping over many items via API/CLI calls, but there is no documented native batch/bulk endpoint (e.g., bulk beneficiary creation, batch payouts, bulk invoice generation) for processing many items in a single call. Missing for 10: explicit bulk/batch API or CLI subcommands, evidence of batch-processing limits or throughput, and independent confirmation of bulk usage in practice.", "evidenceIds": [ "awx-supp-cli", "awx-supp-agentos", "airwallex-docs-12" ] }, { "productId": "airwallex", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Airwallex supports event-driven automation via webhooks (real-time push notifications with retry/dedupe semantics) and AgentOS/CLI/MCP tooling that lets agents run multi-step workflows, but there is no documented user-facing 'rules engine' where an AI-native user declaratively defines trigger-condition-action rules — automation still requires building a webhook consumer or scripting agent workflows rather than configuring rules in-product. missing for 10: a native rules/automation builder (event + condition + action) exposed via API or UI, and independent evidence of such rule-based automation actually firing in production.", "evidenceIds": [ "awx-supp-webhooks", "airwallex-docs-15", "awx-supp-agentos", "awx-supp-agentos-mcp", "awx-supp-cli" ] }, { "productId": "airwallex", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Airwallex's Billing product supports recurring invoices and multi-frequency subscription billing, and AgentOS advertises 'multi-step financial workflows' and pre-built 'Skills,' but there is no documented scheduler/cron capability letting an AI agent set up or trigger recurring automated jobs itself — recurring billing is a finance feature, not an agent-orchestrated recurring workflow mechanism. missing for 10: an explicit job/workflow scheduler API or cron-like trigger for AgentOS/CLI/MCP, evidence of agents autonomously re-running workflows on a schedule, independent confirmation of recurring automation in practice.", "evidenceIds": [ "airwallex-docs-13", "airwallex-docs-24", "airwallex-docs-25", "awx-supp-agentos", "airwallex-docs-19" ] }, { "productId": "airwallex", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Airwallex documents AI agent tooling (AgentOS, MCP, CLI, skills/plugins) for executing financial workflows, but there is no evidence of version control, review workflows, or rollback capability for automations themselves — e.g. no changelog/versioning of skills, no diff/review UI, no rollback mechanism for executed multi-step workflows beyond webhook event replay (which is for delivery, not automation state).", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "dunning-failed-payment-recovery", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Airwallex Billing docs cover subscriptions, invoicing, and payment collection but there is no mention of automatic retry logic for failed subscription payments, smart dunning rules, or automated recovery email sequences.", "evidenceIds": [ "airwallex-docs-13", "airwallex-docs-14", "airwallex-docs-24", "airwallex-docs-25", "awx-supp-billing-suite" ] }, { "productId": "airwallex", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Airwallex offers a Drop-in Element and embeddable checkout components (createElement with customizable appearance/layout, field auto-adjustment) as an alternative to the Hosted Payment Page, plus embedded checkout in Billing, directly enabling in-page/in-app embedded payments rather than redirects. Missing for 10: independent/hands-on developer corroboration of the embedded element's real-world customization depth and no evidence of broader UI kit flexibility beyond docs.", "evidenceIds": [ "airwallex-docs-8", "airwallex-docs-21", "airwallex-docs-18", "awx-supp-billing-suite", "airwallex-docs-22" ] }, { "productId": "airwallex", "storyId": "fraud-screening-rules", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers payments, billing, transfers, AI/developer tooling, webhooks, and dispute facilitation, but contains no mention of ML-based fraud scoring or a rules engine for custom block/review/allow rules; only generic dispute-management language and a sandbox mention of 'risk' simulations without detail. This is a fair capability to expect from a payments platform, so absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [ "airwallex-docs-26", "awx-supp-sandbox" ] }, { "productId": "airwallex", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Airwallex documents a Hosted Payment Page — a secure, pre-built, Airwallex-hosted checkout supporting multiple payment methods with custom styling, plus a quickstart showing end-to-end integration without building custom payment UI, and payment links for no-code acceptance. missing for 10: independent/hands-on conversion-optimization benchmarks beyond vendor docs.", "evidenceIds": [ "airwallex-docs-7", "airwallex-docs-22", "airwallex-docs-18", "airwallex-docs-9" ] }, { "productId": "airwallex", "storyId": "idempotent-api-retries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes webhook delivery reliability (stable event IDs for webhook retries) but contains no documentation of idempotency keys for outbound API requests (e.g., payment creation) to prevent duplicate charges on retry. This is a distinct, applicable axis for a payments API but is unevidenced here.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "integrate-from-docs-in-a-day", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "There is a clear quickstart doc ('Complete a minimal end-to-end online payment in the sandbox environment using Airwallex.js and Airwallex-hosted payment page') plus a self-serve sandbox and multiple integration options (Hosted Payment Page, Drop-in Element) with styling/config snippets, suggesting a fast path to a working payment flow. However, the evidence pack never shows actual copy-paste code samples in specific languages (e.g., Node, Python, PHP) or confirms multi-language SDK coverage, nor any independent developer report confirming a sub-day integration time. Missing for 10: concrete multi-language code snippets, language/SDK coverage, and independent hands-on confirmation of integration speed.", "evidenceIds": [ "airwallex-docs-18", "airwallex-docs-7", "airwallex-docs-8", "awx-supp-sandbox", "airwallex-docs-21" ] }, { "productId": "airwallex", "storyId": "marketplace-split-payments", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Airwallex explicitly documents programmatic creation of connected accounts for businesses/individuals with financial capabilities (marketplace onboarding), plus Transfers/payouts to move funds to suppliers/contractors, and multi-currency wallet settlement — the core building blocks for onboarding sellers and paying them out. Payment splitting isn't explicitly named as a feature but is a natural extension of connected accounts + transfers, and sandbox/webhooks support building and testing such flows end-to-end. Missing for 10: explicit documentation of a 'split payment' or marketplace-specific API/feature, and independent case studies of marketplaces built on Airwallex.", "evidenceIds": [ "airwallex-docs-1", "airwallex-docs-12", "airwallex-docs-11", "airwallex-docs-15", "awx-supp-sandbox" ] }, { "productId": "airwallex", "storyId": "multi-currency-charge-settle", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Airwallex directly supports charging customers via 160+ local payment methods and multi-currency pricing (accepting in local currencies), and its multi-currency Wallet enables like-for-like settlement without forced FX conversion, explicitly marketed as eliminating FX fees versus traditional gateways that force home-currency settlement. Transfers/payouts and invoicing further round out the collect-and-settle flow, backed by first-party docs. Missing for 10: independent/hands-on verification of actual FX rates charged and real-world transparency (e.g., third-party review of fee disclosure) beyond vendor documentation.", "evidenceIds": [ "airwallex-docs-11", "airwallex-docs-16", "airwallex-docs-14", "airwallex-docs-12", "airwallex-docs-23" ] }, { "productId": "airwallex", "storyId": "no-code-payment-links", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Payment Links are documented as 'the easiest way to accept payments online without a digital storefront,' supporting no-code shareable link creation, and other docs (invoicing, quickstart) reinforce a self-serve dashboard flow. However, there's no direct evidence of the dashboard UI/UX for founders (e.g., screenshots, step count, signup-to-first-sale time) or independent/hands-on confirmation of ease of setup. missing for 10: dashboard UI walkthrough or screenshots, independent/hands-on confirmation of no-code simplicity, evidence of account approval/KYC turnaround time before selling.", "evidenceIds": [ "airwallex-docs-9", "airwallex-docs-14", "airwallex-docs-18" ] }, { "productId": "airwallex", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Airwallex documents an extensive API surface plus a CLI that 'exposes a broad slice of the Airwallex API as terminal commands' and an AgentOS/MCP toolkit letting agents read balances, create beneficiaries, issue cards, and run workflows — strong evidence that most UI actions have programmatic equivalents. However, AgentOS explicitly ships with 'no money-out actions by default' as a safety guardrail, and Connected Account APIs are excluded from sandbox, indicating some UI-capable actions are deliberately restricted or gated via role/OAuth permissions rather than fully mirrored in the API/agent tooling. Missing for 10: confirmation that all money-movement and account-management UI actions are reachable via API without special unlocking, and independent/hands-on verification that the CLI/MCP truly cover 100% of UI functionality.", "evidenceIds": [ "awx-supp-cli", "awx-supp-agentos", "awx-supp-agentos-mcp", "awx-supp-sandbox", "airwallex-docs-4" ] }, { "productId": "airwallex", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Airwallex is a financial platform (payments, treasury, billing) with an API/CLI/MCP for account operations, but there is no evidence of a bulk data export feature or open-format data portability that would let a user export all their account data and leave the platform. The APIs allow reading individual resources but no documented full-account export/migration tool is mentioned.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Airwallex is a closed financial SaaS platform, not open-source software; source code availability under an open license is not a fair axis for this kind of product.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Airwallex is a regulated financial-services SaaS platform (payments, treasury, billing); self-hosting the core product is a category error for this kind of product, as it fundamentally requires Airwallex to operate the licensed financial infrastructure and hold funds — no on-prem or self-hosted deployment mode is conceivable or evidenced.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "payout-schedule-control", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Airwallex's transfers, billing, invoicing, and webhook capabilities but contains no mention of configurable payout schedules or itemized payout reports that break down constituent charges, fees, and refunds — a distinct reconciliation feature payment platforms typically document separately.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Airwallex offers a Hosted Payment Page and Drop-in Elements that are pre-built, Airwallex-hosted card collection UIs implying card data doesn't touch the merchant's servers, which is the typical mechanism for reducing PCI scope. However, no evidence explicitly discusses PCI DSS compliance, SAQ scope reduction, or tokenization-for-compliance framing. missing for 10: explicit PCI DSS scope statements, tokenization/vaulting documentation, SAQ-A or compliance certification details, independent confirmation that card data never touches merchant servers.", "evidenceIds": [ "airwallex-docs-7", "airwallex-docs-8", "airwallex-docs-18" ] }, { "productId": "airwallex", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No documentation describes a data residency/region-selection feature letting users choose where their data is stored; the community item raises concerns about China/HK data access but does not confirm or deny any residency-choice capability.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Airwallex is a financial/payments platform, not an AI model provider or data-processing tool whose customer data is used for AI training; the evidence pack contains no AI-training data-usage policy, and this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Airwallex's evidence pack covers API scoping, sandbox environments, MCP/CLI tooling, and payment features, but nowhere addresses data retention policies or user-initiated data deletion controls (e.g., GDPR/CCPA-style deletion requests, retention period configuration). This is a fair axis for a fintech handling AI-agent data, but no capability is documented.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Airwallex is a financial platform/API provider, not an AI agent or dev tool with client-side telemetry settings a user would opt out of; no evidence pack item discusses telemetry/usage-tracking opt-out, and this axis is a category mismatch for a fintech API/CLI/MCP ecosystem.", "evidenceIds": [] }, { "productId": "airwallex", "storyId": "recurring-subscription-billing", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Airwallex Billing documents subscription management with multi-item and multi-frequency billing plus recurring invoicing, indicating core plan-based recurring billing capability. However, the evidence pack never mentions trial periods, plan upgrades/downgrades, or proration logic explicitly. Missing for 10: documented trial period support, upgrade/downgrade workflows, and proration calculation mechanics.", "evidenceIds": [ "airwallex-docs-13", "airwallex-docs-24", "airwallex-docs-25", "awx-supp-billing-suite" ] }, { "productId": "airwallex", "storyId": "refunds-full-partial", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm refunds are a documented capability ('When a shopper returns goods or services, you can issue a refund to return their funds') and the CLI/API expose broad read/write access to Airwallex resources including presumably refunds, but no evidence explicitly confirms a dashboard refund UI or distinguishes full vs partial refund support at the API/dashboard level. Missing for 10: explicit documentation of partial refund amounts, dashboard UI screenshots/flow for issuing refunds, and independent/hands-on confirmation of both channels working.", "evidenceIds": [ "airwallex-docs-17" ] }, { "productId": "airwallex", "storyId": "respond-to-disputes-evidence", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Airwallex docs confirm a dispute-management feature exists ('Airwallex will facilitate your dispute management step-by-step, but generally does not have influence over the outcome'), implying some workflow for chargebacks, but there is no evidence of structured evidence submission templates, evidence checklists, or dispute lifecycle status tracking in the UI/API. Missing for 10: documentation of evidence upload/structuring, dispute status/lifecycle tracking (open/under review/won/lost), API or webhook events specifically for dispute state changes, and any independent confirmation of the workflow.", "evidenceIds": [ "airwallex-docs-26" ] }, { "productId": "airwallex", "storyId": "sandbox-test-mode-fidelity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex documents a full sandbox environment mirroring production (all products except Connected Account APIs), simulation docs for payments/payouts/deposits/issuing/risk, and a quickstart for an end-to-end sandbox payment flow, plus dispute-handling docs. However, there is no explicit mention of a documented set of test card numbers covering specific decline reason codes or dispute-triggering scenarios. missing for 10: documented test card numbers/scenarios for specific decline codes, explicit dispute-simulation test cards, independent developer confirmation of sandbox fidelity to production.", "evidenceIds": [ "awx-supp-sandbox", "airwallex-docs-18", "airwallex-docs-26", "awx-supp-developer-mcp" ] }, { "productId": "airwallex", "storyId": "send-hosted-invoices", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex Billing supports one-time and recurring invoicing with online payment via 160+ local payment methods (docs-14, docs-25), but the evidence pack does not explicitly confirm automatic payment reminders for unpaid invoices. missing for 10: explicit documentation of automated reminder scheduling/notifications for overdue invoices, independent/hands-on confirmation of the reminder feature working in practice.", "evidenceIds": [ "airwallex-docs-14", "airwallex-docs-25", "awx-supp-billing-suite", "airwallex-docs-13" ] }, { "productId": "airwallex", "storyId": "settlement-reconciliation-reports", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers payments, payouts/transfers, refunds, disputes, webhooks, billing/invoicing, and treasury, but there is no mention of a settlement-to-bank-deposit reconciliation report, itemized fee/refund/chargeback breakdowns tied to deposits, or any reconciliation-specific reporting feature for finance-ops. Refunds and disputes are documented in isolation but not connected to a reconciliation/report workflow.", "evidenceIds": [ "airwallex-docs-17", "airwallex-docs-26", "airwallex-docs-12", "airwallex-docs-11" ] }, { "productId": "airwallex", "storyId": "wallets-local-payment-methods", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm a single integration (Hosted Payment Page / Drop-in Element / Payment Links) that adapts fields per payment method/country and mentions 160+ local payment methods via invoicing, plus multi-currency pricing to unlock local methods, but no explicit evidence naming Apple Pay, Google Pay, bank redirects, or BNPL support. Missing for 10: explicit listing/documentation of specific wallets (Apple Pay/Google Pay) and BNPL providers, and independent confirmation these render correctly in a single checkout integration.", "evidenceIds": [ "airwallex-docs-7", "airwallex-docs-8", "airwallex-docs-14", "airwallex-docs-16", "airwallex-docs-9" ] }, { "productId": "airwallex", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Airwallex's webhook docs describe reliability primitives that map to most of this story: a required 200 response for delivery confirmation, a stable event id explicitly for safe retry handling/deduplication, and a web app view to inspect delivery status and re-deliver events after downtime or debugging (covers automatic retries, event logs, and replay). However, none of the evidence explicitly documents cryptographic signature verification for webhook payloads. Missing for 10: explicit signed-webhook/signature-verification documentation, and independent/hands-on confirmation of retry behavior in practice.", "evidenceIds": [ "awx-supp-webhooks", "airwallex-docs-15" ] }, { "productId": "autumn", "storyId": "accept-card-payment-online", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Autumn is a billing/metering layer built on top of Stripe, with an `attach` API that handles new subscriptions/upgrades/downgrades and a CLI that syncs pricing plans in a single command, suggesting reasonably fast setup. However, there's no direct evidence of a turnkey checkout page or explicit same-day payment acceptance flow, and the product only works atop Stripe (comm-4), meaning a founder still needs a separate Stripe account/setup for actual card processing. Missing for 10: an end-to-end checkout UI or hosted payment page, explicit time-to-first-payment claims, and independent confirmation of same-day integration speed.", "evidenceIds": [ "autumn-docs-13", "autumn-docs-5", "autumn-comm-4" ] }, { "productId": "autumn", "storyId": "agent-handles-dispute-end-to-end", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/metering/entitlements infrastructure product (pricing plans, feature gating, usage tracking, credits) — it has no concept of disputes, chargebacks, or fraud evidence handling. Dispute-resolution workflows are entirely outside its category, making this a wrong-axis question.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "agent-monitors-dunning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Autumn webhooks fire only on plan changes (new subscriptions, upgrades, downgrades) and covers usage/credit tracking, but there is no mention of failed-payment events, retry logic, or dunning outreach workflows anywhere in the docs, changelog, or community threads. This is a fair axis for a billing product (Stripe-based dunning is a common billing capability) but no evidence supports Autumn delivering it.", "evidenceIds": [ "autumn-docs-8", "autumn-docs-13", "autumn-docs-9" ] }, { "productId": "autumn", "storyId": "agent-provisions-payment-link", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Autumn's API/CLI supports creating products/plans (attach, config.ts, atmn CLI) and MCP server exposes billing/plan/customer tools to AI assistants, suggesting an agent could provision products and prices programmatically, but there is no direct evidence of generating a 'payment link' via API or of a documented single-session workflow combining product+price+payment link creation. missing for 10: explicit payment-link creation endpoint/API, end-to-end example of an agent provisioning product+price+payment link in one session, independent verification of this workflow.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-13", "autumn-docs-7", "autumn-probe-3", "autumn-probe-4" ] }, { "productId": "autumn", "storyId": "agent-reconciles-payouts", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a pricing/billing and feature-gating layer built on top of Stripe (plans, usage tracking, entitlements) — it has no concept of payouts, balance transactions, or bank deposit reconciliation, which is a Stripe Connect/platform-payments concern, not part of Autumn's product surface.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A probe confirms llms.txt is live at docs.useautumn.com/llms.txt returning HTTP 200 with structured doc links, directly satisfying the ability to point an agent at agent-oriented docs; this is reinforced by an official MCP server for AI assistants. Missing for 10: no independent/community confirmation of an agent successfully consuming llms.txt in practice, and no openapi.json fallback.", "evidenceIds": [ "autumn-probe-1", "autumn-docs-7", "autumn-probe-3" ] }, { "productId": "autumn", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/metering/entitlements infrastructure product for developers, not an end-user data product; it has no concept of surfacing AI-generated insights or suggestions from user data. This story targets analytics/insights features, which is a wrong axis for a billing control layer.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements/metering control layer for SaaS and AI products, not an automation or workflow-orchestration platform; there is no concept of user-defined autonomous background automations in its evidence. This axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/pricing/entitlements infrastructure product for developers; it has no built-in AI assistant for end users to delegate tasks to. Its MCP server (autumn-docs-7) lets external AI assistants call Autumn's APIs, which is the opposite role (Autumn as a tool provider, not an agent host) — this does not constitute a built-in assistant inside the product.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Autumn ships an `atmn` CLI that syncs pricing configs (`autumn.config.ts`) with a single command and supports non-interactive actions like `preview` and `pull`, which are scriptable and could run in CI, plus SDK calls (`check`, `track`) that are inherently headless. However, there's no explicit documentation or example of running Autumn in a CI/CD pipeline, no mention of non-interactive auth/token flags for automated environments, and no community confirmation of headless CI usage. Missing for 10: explicit CI/CD pipeline examples, non-interactive authentication guidance, and independent confirmation of automated/headless runs.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-6", "autumn-docs-11", "autumn-docs-1", "autumn-docs-2", "autumn-probe-4" ] }, { "productId": "autumn", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements SaaS platform, not an AI agent — the story asks whether the product can consume/plug in external MCP servers to use their tools, which only applies to agentic products. Evidence shows the opposite direction: Autumn ships an MCP *server* so other AI assistants can call Autumn's own billing tools (autumn-docs-7, autumn-probe-3), which does not make this client-side axis applicable.", "evidenceIds": [ "autumn-docs-7", "autumn-probe-3" ] }, { "productId": "autumn", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Autumn is a billing/entitlements SaaS platform (not itself an agent), and it documents an official MCP server that connects AI assistants to its billing, customer, plan, balance, and log tools, confirmed by both docs and probe. Missing for 10: independent hands-on confirmation of the MCP server working and more detail on its tool coverage/setup.", "evidenceIds": [ "autumn-docs-7", "autumn-probe-3" ] }, { "productId": "autumn", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Autumn ships an official MCP server that 'connects AI assistants to Autumn's billing, customer, plan, balance, and log tools,' enabling AI-native/natural-language operation indirectly through an MCP-connected assistant rather than a built-in chat interface. There's no first-party or community evidence of actual natural-language command usage in practice, and the product is fundamentally a CLI/API/dashboard tool otherwise. Missing for 10: direct natural-language command interface (not just MCP passthrough), hands-on demonstration of NL commands working, independent user corroboration.", "evidenceIds": [ "autumn-docs-7", "autumn-probe-3" ] }, { "productId": "autumn", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Autumn ships an official `atmn` CLI documented in first-party docs, supporting config-as-code (autumn.config.ts), pushing/syncing plans, previewing changes (bunx atmn preview), and pulling existing dashboard products (atmn pull) — clearly enabling AI-native, code-first workflows. Missing for 10: independent/hands-on community verification of the CLI itself (community evidence covers billing/security topics, not CLI usage) and no evidence of scripting/automation-specific features beyond basic commands.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-6", "autumn-docs-11", "autumn-probe-4" ] }, { "productId": "autumn", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Autumn ships a documented public API with clear reference pages (check, track, attach) and code examples, webhooks, and an API-reference section, letting an AI-native user drive billing/entitlements programmatically. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe found only 404s at expected paths), and independent hands-on confirmation of API robustness beyond docs.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-2", "autumn-docs-12", "autumn-docs-13", "autumn-docs-8", "autumn-probe-2" ] }, { "productId": "autumn", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's docs describe customerId-based check/track/attach calls and an MCP server for billing tools, but there is no evidence of an API-key or credential system that lets an AI-native user mint scoped, least-privilege credentials for an agent. Community reports even describe unauthenticated server actions and customer_id spoofing (IDOR), the opposite of least-privilege access control.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-2", "autumn-docs-7", "autumn-comm-6", "autumn-comm-7" ] }, { "productId": "autumn", "storyId": "agentic-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs consistently show official SDK code (autumn.check, autumn.track, autumn.attach) across many endpoints, plus a companion CLI (atmn) for config sync, indicating a first-party SDK for building AI-native billing integrations. Missing for 10: explicit multi-language SDK coverage/package registry links and independent developer corroboration of SDK usage beyond docs.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-2", "autumn-docs-5", "autumn-docs-13", "autumn-probe-4" ] }, { "productId": "autumn", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Autumn documents webhooks fired on plan/subscription changes (autumn-docs-8), giving basic event subscription capability, but evidence doesn't cover a broad event catalog (e.g. usage/track events), payload schemas, signing/verification, or subscription management API — missing for 10: full webhook event catalog, payload/signature docs, subscription management endpoints, independent hands-on confirmation.", "evidenceIds": [ "autumn-docs-8" ] }, { "productId": "autumn", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's docs include static code snippets for API endpoints (e.g. check, attach) but there is no evidence of an interactive, runnable API console—probes for openapi/swagger specs all 404'd, indicating no interactive reference tooling exists.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-13", "autumn-probe-2" ] }, { "productId": "autumn", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "There's an api-reference section implying documented endpoints, but a direct probe for OpenAPI/Swagger specs at standard paths returned 404s with no alternate machine-readable spec found or linked anywhere in the docs.", "evidenceIds": [ "autumn-probe-2" ] }, { "productId": "autumn", "storyId": "api-sandbox", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn is a billing/entitlements layer where sandbox/test-mode testing is a reasonable ask (similar to Stripe test mode), but the evidence pack has no mention of a dedicated sandbox/test environment separate from production—only 'atmn preview' for previewing pricing plan changes before pushing config, which is not the same as isolating test transactions/customers from production data.", "evidenceIds": [ "autumn-docs-6" ] }, { "productId": "autumn", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of API versioning scheme or documented deprecation policy; changelog entries show ongoing changes but no version numbers or deprecation guarantees, and OpenAPI/spec probes 404. missing for 10: versioned API endpoints/headers, explicit deprecation policy documentation, migration guides for breaking changes.", "evidenceIds": [ "autumn-probe-2", "autumn-docs-9", "autumn-docs-10" ] }, { "productId": "autumn", "storyId": "automatic-tax-calculation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/metering/entitlements layer for SaaS pricing built on Stripe; the evidence pack shows no tax/VAT/GST calculation or collection capability, and this is not the axis this product addresses—it relies on Stripe or other systems for tax handling, which is outside its documented scope.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's docs show only single-item operations (check, track, attach for one customer/feature at a time) and CLI commands (pull/preview/push) that sync a single config, but no batch/bulk API for operating across many customers, features, or items at once. missing for 10: bulk/batch API endpoints, documentation of batch customer or feature updates, evidence of any multi-item transaction support.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-2", "autumn-docs-13", "autumn-docs-5" ] }, { "productId": "autumn", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Autumn supports event-driven mechanisms like webhooks fired on plan changes and usage alerts with configurable thresholds (basis field), which act as simple automated triggers tied to billing state. However, there is no evidence of a general-purpose rule engine where users can define custom trigger→action logic across arbitrary events; the automation is scoped narrowly to billing/entitlement events. Missing for 10: a documented rules/automation DSL or workflow builder, support for arbitrary custom triggers/actions beyond billing events, and evidence of chaining multiple actions per rule.", "evidenceIds": [ "autumn-docs-8", "autumn-docs-9", "autumn-docs-2", "autumn-docs-12" ] }, { "productId": "autumn", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/metering/entitlements control layer for SaaS and AI products, not a workflow/job scheduling or automation orchestration tool; scheduling recurring jobs or workflows is outside its product category.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements infrastructure product (plans, metering, checks, webhooks) rather than a workflow/automation builder with 'automations' that a user could version, review, and roll back; its config-as-code CLI (push/pull/preview) applies to pricing plans, not automations. This story is a category mismatch for the product type.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "dunning-failed-payment-recovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's evidence covers metering, entitlements, plan attachment, and Stripe catalog sync, but there is no mention of dunning, retry logic for failed payments, or recovery emails anywhere in the docs, changelog, or community discussion.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "embedded-checkout-components", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's evidence describes a billing/metering/entitlements API, CLI, and MCP integration built on top of Stripe, but nothing in the pack mentions embeddable payment/checkout UI components as an alternative to hosted checkout pages—attach/billing calls appear to route through Stripe's own flows.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "fraud-screening-rules", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/pricing/entitlements control layer for SaaS and AI products, not a fraud-detection or transaction-screening system; ML fraud scoring and block/review/allow rule authoring for disputes-fraud workflows are entirely outside its product category.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "hosted-checkout-page", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Autumn's metering, entitlements, CLI, MCP, and plan-attach APIs, but nowhere describes a vendor-hosted, conversion-optimized checkout page that a developer can redirect customers to; 'attach' only documents subscription state changes, not a hosted checkout flow.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "idempotent-api-retries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item mentions idempotency keys or request-retry safety mechanisms anywhere in Autumn's docs, changelog, or community discussion; the API examples shown (check, track, attach) don't reference idempotency handling.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "integrate-from-docs-in-a-day", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs provide multiple copy-paste TypeScript/JS snippets (check, track, attach, gating) and a CLI/config flow that suggest a fast path to a working payment flow, and community comments (comm-2, comm-5) reflect developers finding it appealing to integrate quickly. However all examples are JS/TS only (no other languages), there's no explicit hands-on confirmation of a 'under a day' integration timeline, and separate security reports (comm-6/7) show at least one integration built from the docs' approach ended up with an IDOR vulnerability, suggesting the docs alone may not guarantee a fully working/secure flow without extra care. Missing for 10: multi-language code samples, an independent hands-on report confirming rapid end-to-end integration, and evidence the documented flow is secure by default.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-2", "autumn-docs-5", "autumn-docs-6", "autumn-docs-11", "autumn-docs-13", "autumn-comm-2", "autumn-comm-5", "autumn-comm-7" ] }, { "productId": "autumn", "storyId": "marketplace-split-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Autumn's evidence focuses entirely on single-party SaaS billing—metering, plans, entitlements, customer subscriptions via Stripe—with no mention of multi-party marketplace features like seller onboarding, payment splitting, or payouts (e.g., Stripe Connect-style functionality). No evidence pack item addresses marketplace/platform payment distribution.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "multi-currency-charge-settle", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses multi-currency charging, FX conversion, or settlement to a founder's home currency; documentation covers pricing models, metering, and Stripe catalog sync only. Community threads even highlight Autumn's dependency on Stripe alone with no other payment processors, but nothing on currency/FX handling either way.", "evidenceIds": [ "autumn-docs-10", "autumn-comm-4" ] }, { "productId": "autumn", "storyId": "no-code-payment-links", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn is a code-first billing/entitlements layer requiring SDK calls, an autumn.config.ts file, or CLI (atmn) to define and attach plans—there is no evidence of a no-code, dashboard-generated shareable payment link feature for founders to start selling immediately.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-11", "autumn-docs-13", "autumn-docs-4" ] }, { "productId": "autumn", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Autumn exposes a broad API (check, track, attach, credit systems, usage-based pricing) plus a CLI (`atmn push/pull/preview`) that can define and sync pricing config as code, and an MCP server for AI-native access to billing/customer/plan tools — strong evidence of API-driven control. However, the docs also show a 'pull' workflow for dashboard-created products, implying some setup still originates in the dashboard UI, and there's no explicit statement or independent test confirming full 1:1 parity between every UI action and API/CLI capability. Missing for 10: explicit parity documentation or proof that all dashboard-only actions (e.g., initial product/catalog creation, Stripe processor linking) are fully replicable via API/CLI without ever touching the UI, and independent verification of this parity.", "evidenceIds": [ "autumn-docs-1", "autumn-docs-2", "autumn-docs-3", "autumn-docs-5", "autumn-docs-6", "autumn-docs-7", "autumn-docs-11", "autumn-probe-3", "autumn-probe-4" ] }, { "productId": "autumn", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's docs show CLI sync/pull for pricing config (autumn.config.ts) and webhooks for event data, but there is no documented feature for exporting all customer/usage/billing data in an open format to allow a user or team to leave the platform. missing for 10: a documented full data-export or account-portability feature, open-format bulk export of customer/usage records, evidence of data portability upon offboarding.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-11", "autumn-docs-8" ] }, { "productId": "autumn", "storyId": "openness-open-license", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The only evidence is a fragment from Autumn's llms.txt describing it as 'Drop-in, open-source control layer for AI and Sa[aS]', suggesting an open-source posture, but there is no link to an actual repository, license file, or license type (e.g., MIT/Apache) in the evidence pack, and no independent confirmation of a public code repo. Missing for 10: a direct GitHub/source repo link, an explicit license name/file, and corroboration that the full source (not just docs) is publicly readable.", "evidenceIds": [ "autumn-probe-1" ] }, { "productId": "autumn", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn's docs describe it as an 'open-source control layer' (autumn-probe-1), which would make self-hosting a fair question, but the evidence pack contains no self-hosting guide, Docker/deployment instructions, or infrastructure requirements — all documentation and CLI references (atmn, MCP, API) point to using Autumn as a hosted SaaS. missing for 10: self-host deployment docs, infrastructure/Docker setup instructions, confirmation of a self-hostable server component.", "evidenceIds": [ "autumn-probe-1" ] }, { "productId": "autumn", "storyId": "payout-schedule-control", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements control layer built on top of Stripe (pricing, metering, feature gating), not a payments/payout processor; payout scheduling and payout-level reconciliation of charges/fees/refunds is a Stripe Connect/platform payouts concern, outside Autumn's product category.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "pci-scope-reduction", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements/metering layer built on Stripe, not a payment processor handling card data directly; PCI scope reduction via tokenization is a payment-gateway concern (e.g., Stripe's), not something Autumn's product category addresses. This is a category error for this product type.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements layer for AI and SaaS products; there is no mention anywhere in the evidence pack of data residency, region selection, or data storage location controls. This is an applicable axis for a data-handling SaaS product, but no evidence supports it.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/metering/entitlements control layer for SaaS/AI products, not an AI model or data platform; the story about preventing user data from being used for AI model training is a category error for this product type.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements/metering control layer, not an AI system that stores/retains user data or conversation history; data retention and deletion controls are not a fair axis for this product category. The evidence pack contains nothing about data retention policies since it's off-topic for a billing/metering tool.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements infrastructure product, and its own telemetry/tracking APIs (track, check) are core product features for customer usage billing, not analytics on the developer's own usage of Autumn itself—so the axis of opting out of Autumn's own telemetry collection about its users is applicable but no evidence addresses it. No docs, changelog, or community evidence mention any telemetry opt-out, privacy settings, or data collection disclosure for Autumn's own tooling (CLI, SDK, MCP). missing for 10: any privacy policy or opt-out mechanism documentation, any mention of what usage data Autumn collects from its own users, any CLI/SDK flag to disable telemetry.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "recurring-subscription-billing", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Autumn's docs explicitly cover defining plans (autumn.config.ts + atmn CLI), attaching plans to customers with automatic handling of new subscriptions, upgrades, and downgrades, usage-based/pay-per-use pricing with proration-like billing period logic, and webhooks firing on plan changes (new subscriptions, upgrades, downgrades). Community feedback corroborates real-world use for billing/entitlements and notes Autumn's team handling of annual/monthly billing transitions and race conditions. Missing for 10: explicit first-party documentation of free trials and detailed proration mechanics, plus independent hands-on verification of trial/upgrade billing flows.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-13", "autumn-docs-8", "autumn-docs-4", "autumn-docs-10", "autumn-comm-1", "autumn-comm-5" ] }, { "productId": "autumn", "storyId": "refunds-full-partial", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack items mention refunds at all—no dashboard refund UI, no refund API endpoint, or partial-refund logic; docs cover checks, tracking, attach/subscriptions, credit systems, and CLI/MCP but never refunds.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "respond-to-disputes-evidence", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements/metering control layer built on Stripe; it has no chargeback/dispute management functionality (evidence covers metering, plans, CLI, MCP, webhooks—none touch chargebacks or dispute lifecycle). Chargeback handling is a payment-processor/fraud-ops axis, not something this product category ships.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "sandbox-test-mode-fidelity", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions a sandbox/test mode, test cards, or simulated decline/dispute scenarios; Autumn's docs cover CLI, config, gating, webhooks, and MCP but nothing about a testing environment mirroring production payment flows. Since Autumn sits atop Stripe, this is a fair and applicable axis for a billing product, but it's simply undocumented here.", "evidenceIds": [ "autumn-docs-5", "autumn-docs-6", "autumn-docs-11", "autumn-docs-13" ] }, { "productId": "autumn", "storyId": "send-hosted-invoices", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements control layer built on top of Stripe for pricing, metering, and feature-gating — not a hosted-invoicing/AP tool. There is no evidence of hosted invoice pages, invoice-specific payment links, or automated reminder emails; the product's focus is subscription/usage billing logic, so this invoicing-specific axis is a category mismatch.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "settlement-reconciliation-reports", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Autumn is a billing/entitlements/metering control layer for SaaS/AI products, not a payments settlement or banking reconciliation tool; there is no concept of bank deposit reconciliation in its evidence pack. This story targets a payments-processor/finance-ops reconciliation product, which is a different category from Autumn's feature-gating and subscription billing focus.", "evidenceIds": [] }, { "productId": "autumn", "storyId": "wallets-local-payment-methods", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Autumn is a billing/entitlement/metering layer built on top of Stripe (confirmed by autumn-comm-4, which notes it lacks support for other payment providers like Paystack), but the evidence pack contains no mention of Autumn configuring or exposing digital wallets, local payment methods, bank redirects, or BNPL options in checkout. Missing for 10: any documentation of wallet/BNPL/local payment method support, checkout configuration options, or evidence Autumn surfaces Stripe's payment-method capabilities to founders.", "evidenceIds": [ "autumn-comm-4" ] }, { "productId": "autumn", "storyId": "webhook-delivery-reliability", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docs mention webhooks are fired for plan changes, but there is no evidence of signed payloads, automatic retries, event logs, or replay functionality for webhook deliveries; the evidence pack shows only a single event type description with no delivery guarantees.", "evidenceIds": [ "autumn-docs-8" ] }, { "productId": "checkout-com", "storyId": "accept-card-payment-online", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com explicitly markets a Hosted Payment Page you can get 'fully branded... in less than a day' and offers self-serve test accounts, payment links, and low-code Flow for fast integration, suggesting a founder could technically wire up a checkout quickly. However, the pricing model is explicitly sales-led with 'no self-serve rate card' and merchants must 'get in touch with our team' to create a plan, implying an onboarding/underwriting step before going live with real payments that isn't addressed in the evidence. Missing for 10: evidence of self-serve signup-to-live-payment flow without sales contact, KYC/merchant approval timelines, and confirmation that a brand-new account can process a live card charge within 24 hours.", "evidenceIds": [ "checkout-com-docs-39", "cko-supp-testing", "cko-supp-pricing", "checkout-com-docs-19", "checkout-com-docs-38" ] }, { "productId": "checkout-com", "storyId": "agent-handles-dispute-end-to-end", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Checkout.com's docs cover general dispute management topics (manage-disputes, disputes testing, preventing fraudulent disputes) but there's no evidence of an API endpoint for retrieving disputes or submitting evidence, and the documented MCP server's capabilities explicitly list only payment status queries, refunds, voids, and payment links — dispute handling is not among them. No evidence shows an agent can retrieve a dispute, assemble evidence, and submit a response end-to-end via API or MCP.", "evidenceIds": [ "checkout-com-docs-30", "checkout-com-docs-14", "cko-supp-mcp-server" ] }, { "productId": "checkout-com", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Checkout.com provides the raw building blocks an agent could use — webhooks for payment lifecycle events (including failures), idempotent retry-safe API endpoints, and an MCP server that can query payment statuses and manage payment operations from an AI agent — but there is no documented dunning/retry-campaign feature or subscription-billing failed-payment workflow (no mention of automatic retry scheduling, dunning emails, or a 'monitor failed payments and drive outreach' capability). missing for 10: dedicated dunning/retry-campaign automation, evidence of subscription/recurring billing failure handling, and any documented agent workflow specifically for failed-payment monitoring/outreach.", "evidenceIds": [ "cko-supp-webhooks", "cko-supp-idempotency", "cko-supp-mcp-server", "cko-supp-mcp-endpoints", "checkout-com-docs-11", "checkout-com-docs-12" ] }, { "productId": "checkout-com", "storyId": "agent-provisions-payment-link", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Checkout.com documents API-driven Payment Link creation (docs-19/56) and an MCP server that can be used from an AI-assisted IDE to 'create and manage payment links' (cko-supp-mcp-server), so an agent could plausibly create a payment link in one session via API/MCP. However, there is no evidence of a discrete 'product' or 'price' catalog object/API (unlike a full product-catalog model) — Checkout.com's docs only reference amount/currency fields on payment links, not reusable Product/Price entities. missing for 10: a documented Products API and Prices API (or catalog object model) that an agent could provision alongside a payment link, and any hands-on/independent confirmation of an agent completing product+price+link creation end-to-end in one session.", "evidenceIds": [ "checkout-com-docs-19", "checkout-com-docs-56", "cko-supp-mcp-server", "cko-supp-mcp-endpoints" ] }, { "productId": "checkout-com", "storyId": "agent-reconciles-payouts", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Checkout.com documents a report suite explicitly designed for reconciling payouts to underlying financial actions (Balance Breakdown, Balance, Financial Actions by Date Range/Payout ID, Payouts, Settlement Breakdown, Settlement Statement reports), and these are exposed via API alongside a documented MCP server and OAuth2/API-key auth suitable for agent-driven automation. Missing for 10: no explicit end-to-end example showing an agent script pulling payout+balance-transaction endpoints and matching them to charges, and no independent/hands-on confirmation of this reconciliation workflow being done via an agent.", "evidenceIds": [ "cko-supp-reconciliation", "checkout-com-docs-26", "checkout-com-docs-27", "cko-supp-api-keys", "cko-supp-mcp-server", "cko-supp-mcp-endpoints" ] }, { "productId": "checkout-com", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Checkout.com hosts a live llms.txt at both www.checkout.com/llms.txt and docs.checkout.com/llms.txt, confirmed via probe returning HTTP 200 with structured content, plus multiple docs entries derived from that file listing agent-readable summaries of products/APIs. This directly satisfies pointing an agent at llms.txt. missing for 10: independent third-party confirmation of an agent successfully consuming the file end-to-end, and a docs.md/markdown mirror (docs.md returned 404).", "evidenceIds": [ "checkout-com-probe-1", "checkout-com-docs-2", "checkout-com-docs-18", "checkout-com-docs-52", "checkout-com-probe-2" ] }, { "productId": "checkout-com", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Checkout.com references a general 'AI-driven solution' to optimize payment acceptance rates and mentions 'advanced analytics' on transaction-level data, which gestures at AI working on the merchant's own data, but there is no documented dashboard AI-insights/copilot feature that surfaces suggestions or narrative insights to the user. Missing for 10: a named in-product AI insights/analytics feature, evidence of generated recommendations shown to users, and any hands-on/independent corroboration beyond marketing copy.", "evidenceIds": [ "checkout-com-docs-36", "checkout-com-docs-32" ] }, { "productId": "checkout-com", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Checkout.com offers building blocks that support background automation — webhooks trigger server-side actions on payment lifecycle events, and the MCP server lets an AI agent query statuses, issue refunds, and manage payment links — plus agentic commerce protocols (ChatGPT, Google AI) letting an AI complete transactions on a user's behalf. However, none of this constitutes a dedicated 'set up an automation that runs autonomously in the background' capability (e.g., scheduled jobs, persistent agent workflows); the MCP server is described as an IDE-session tool, not an unattended background process. Missing for 10: a documented scheduler/background-job or persistent autonomous-agent workflow feature, and independent evidence of such automations running unattended.", "evidenceIds": [ "cko-supp-webhooks", "cko-supp-mcp-server", "cko-supp-agentic-commerce", "cko-supp-mcp-endpoints" ] }, { "productId": "checkout-com", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Checkout.com offers an MCP server so external AI agents/IDEs can query its API, and supports agentic-commerce protocols so third-party AI agents (ChatGPT, Google AI) can transact with merchants — but there is no evidence of a built-in AI assistant embedded inside the Checkout.com product/dashboard itself that a user can delegate tasks to. The MCP 'Guide tool' and AI-driven acceptance optimization are external-agent or backend features, not an in-product assistant.", "evidenceIds": [ "checkout-com-docs-15", "cko-supp-mcp-server", "cko-supp-agentic-commerce", "checkout-com-docs-36" ] }, { "productId": "checkout-com", "storyId": "agentic-headless", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Checkout.com is API-first with SDKs (e.g. Node.js), OAuth2 client-credentials auth, idempotent retries, webhooks, and a full sandbox/test-account environment with test cards — all of which support scripted, headless use in CI/test pipelines. However there is no dedicated CLI or explicit CI/CD pipeline documentation/tutorials for automation. Missing for 10: dedicated CLI tool, explicit CI/CD integration guide or example pipeline.", "evidenceIds": [ "cko-supp-idempotency", "cko-supp-api-keys", "cko-supp-testing", "checkout-com-gh-1", "checkout-com-docs-13" ] }, { "productId": "checkout-com", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments infrastructure platform, not an AI agent/assistant that itself hosts a tool-use loop into which a user would plug external MCP servers. The evidence shows the reverse relationship — Checkout.com publishes its own MCP server so that external AI agents/IDEs can call Checkout's tools — which is a different axis (being an MCP server, not an MCP client). There is no evidence of Checkout.com acting as an agent that consumes other MCP servers, and this story does not fit the product's category.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Checkout.com documents an official, hosted MCP server (sandbox and production endpoints, OAuth via Dashboard account) with concrete setup instructions (e.g., adding it to Claude Code) and documented capabilities like querying payments, issuing refunds, managing payment links, and knowledge-base search — directly fulfilling the story. Missing for 10: independent/third-party corroboration of real-world usage beyond vendor docs, and it's explicitly marked Beta.", "evidenceIds": [ "cko-supp-mcp-server", "cko-supp-mcp-endpoints", "checkout-com-docs-15", "checkout-com-probe-4" ] }, { "productId": "checkout-com", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Checkout.com ships an official MCP Server that lets users query payment statuses, issue refunds, void payments, and manage payment links via natural-language requests to an AI agent, plus guided onboarding through a 'Guide tool' — directly matching the story. This is corroborated by concrete endpoint/setup details (OAuth, sandbox/production URLs, `claude mcp add` command) rather than just marketing copy. Missing for 10: independent/hands-on user reports of the NL commands working (server is labeled Beta) and no evidence beyond vendor docs of reliability at scale.", "evidenceIds": [ "cko-supp-mcp-server", "cko-supp-mcp-endpoints", "checkout-com-docs-15", "checkout-com-probe-4" ] }, { "productId": "checkout-com", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows SDKs (Node.js), a Dashboard, an MCP server, and agentic-commerce protocol integrations, but no mention of an official CLI tool for developers. Payment platforms commonly ship CLIs (e.g., for testing webhooks, managing keys), so the axis applies, but no such capability is documented anywhere in this evidence pack.", "evidenceIds": [ "checkout-com-gh-1", "cko-supp-mcp-server", "checkout-com-probe-2", "checkout-com-probe-3" ] }, { "productId": "checkout-com", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Checkout.com documents a comprehensive public REST/Unified Payments API with OAuth2/API-key auth, idempotency, rate limits, webhooks, SDKs (Node.js), and a full testing sandbox, plus explicit agentic-commerce integrations (ChatGPT, Google AI) and an official MCP server for AI-agent operation — strongly supporting AI-native programmatic control. Missing for 10: a discoverable OpenAPI/swagger spec (probe found 404s) and independent third-party corroboration beyond vendor docs.", "evidenceIds": [ "checkout-com-docs-2", "cko-supp-idempotency", "cko-supp-api-keys", "cko-supp-webhooks", "cko-supp-testing", "cko-supp-mcp-server", "cko-supp-mcp-endpoints", "cko-supp-agentic-commerce", "checkout-com-gh-1", "checkout-com-probe-3" ] }, { "productId": "checkout-com", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Checkout.com documents OAuth 2.0 client-credentials flow and 'access keys' alongside secret keys, letting integrations obtain scoped, non-static credentials per processing channel — a real least-privilege mechanism. However, the MCP server (the actual agent-facing surface) authenticates via a full Dashboard account login rather than a dedicated scoped/agent-specific credential, so there's no documented way to mint a narrowly-scoped key specifically for an autonomous agent. Missing for 10: explicit agent-scoped OAuth scopes/roles for the MCP server, granular permission docs tied to agent use cases, and independent confirmation that access-key scopes can be limited to agent-safe operations only.", "evidenceIds": [ "cko-supp-api-keys", "cko-supp-mcp-endpoints", "cko-supp-mcp-server" ] }, { "productId": "checkout-com", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com documents an official Node.js SDK on GitHub, a native Mobile SDK for iOS/Android, plugins for ecommerce platforms, and machine-readable docs (llms.txt) plus an MCP server that let AI agents build against its API. However, evidence only names one language SDK explicitly and no broader SDK catalog (e.g., Python, PHP, Java, .NET) or independent hands-on validation is shown. Missing for 10: multi-language official SDK coverage, independent/community corroboration of SDK quality, and a public OpenAPI spec (probes show openapi.json 404).", "evidenceIds": [ "checkout-com-gh-1", "checkout-com-docs-3", "checkout-com-docs-6", "checkout-com-docs-2", "checkout-com-probe-1", "checkout-com-docs-15", "cko-supp-mcp-server" ] }, { "productId": "checkout-com", "storyId": "agentic-webhooks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Checkout.com has robust, well-documented webhooks: event notifications with HMAC signature verification, configuration via Dashboard or API, resending webhooks, and integration with Amazon EventBridge for event streaming — directly enabling programmatic/agentic subscription to payment lifecycle events. Missing for 10: independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "cko-supp-webhooks", "checkout-com-docs-11", "checkout-com-docs-12", "checkout-com-docs-51" ] }, { "productId": "checkout-com", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows extensive documentation pages, an llms.txt feed, and an MCP server for AI agents, but no evidence of an interactive API reference with runnable/live code examples (e.g., a 'try it' console or embedded sandbox). The OpenAPI probe explicitly found all candidate spec paths returning 404, suggesting no machine-readable spec is exposed for such tooling.", "evidenceIds": [ "checkout-com-probe-3", "checkout-com-probe-2", "checkout-com-docs-18" ] }, { "productId": "checkout-com", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows an llms.txt (LLM-friendly documentation index) but explicit probes for OpenAPI/Swagger specs at common paths (openapi.json, swagger.json, .well-known/openapi.json) all returned 404, and no other citation references a downloadable OpenAPI or equivalent machine-readable API spec.", "evidenceIds": [ "checkout-com-probe-3", "checkout-com-probe-1", "checkout-com-probe-2" ] }, { "productId": "checkout-com", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Checkout.com documents a dedicated sandbox/test-account environment (test cards, disputes testing, fraud/payouts testing, and a public 'get test account' signup) separate from production, and the MCP server itself is explicitly split into a sandbox endpoint (checkout.mcp.sbox.cko.tech) versus production (mcp.checkout.com), letting AI-native integrations test agentic operations without touching live data. Missing for 10: independent/hands-on confirmation that the sandbox fully mirrors production behavior and more detail on data isolation guarantees.", "evidenceIds": [ "cko-supp-testing", "checkout-com-docs-13", "checkout-com-docs-14", "cko-supp-mcp-endpoints", "cko-supp-mcp-server" ] }, { "productId": "checkout-com", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers idempotency, rate limits, auth, webhooks, and testing, but contains no mention of API version headers, a changelog, or a documented deprecation/sunset policy; probes for an OpenAPI spec even returned 404s, suggesting no discoverable versioning artifact.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "automatic-tax-calculation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments processing platform, not a tax/VAT/GST calculation engine; no evidence pack item addresses tax determination, tax rate lookup, or tax remittance, and this capability is a different axis (tax compliance software) rather than a payments gateway function.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers single-resource operations (payments, refunds, payment links, webhooks) and idempotent retries for individual requests, but there is no documentation of a batch/bulk API, bulk refund/payout endpoints, or MCP tooling that operates across many items at once. Reconciliation and reporting are read-only aggregate views, not bulk write operations.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Checkout.com supports webhooks that notify external systems on payment lifecycle events, and documented 'risk rules and lists' that automatically trigger fraud-prevention actions based on transaction conditions — both are forms of event-triggered automation. However, there is no evidence of a general-purpose, user-defined rules/automation engine (e.g., 'if X event then Y action' workflow builder) spanning arbitrary events beyond fraud, so it only partially satisfies the story. Missing for 10: a native no-code/low-code rules engine for arbitrary event-triggered actions, documented conditional logic builder, and evidence of automation beyond fraud rules and webhook delivery.", "evidenceIds": [ "checkout-com-docs-28", "cko-supp-webhooks", "checkout-com-docs-11", "checkout-com-docs-29" ] }, { "productId": "checkout-com", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents payment processing, webhooks, MCP-driven operations, and reconciliation reports, but nowhere describes recurring/scheduled job or workflow automation (e.g., subscription billing, cron-like scheduling, recurring payment automation) that an AI-native user could set up. No mention of scheduling, recurring billing, or workflow orchestration exists in the pack.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments platform; the evidence covers webhooks, idempotency, MCP server, and flows/plugins, but nothing documents versioning, review workflows, or rollback of 'automations' (e.g. Flow configs, webhook rules, risk rules) as artifacts with history/diff/rollback capability.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "dunning-failed-payment-recovery", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack shows Checkout.com as a payments/acquiring platform with API idempotency (for network retries, not subscription dunning), webhooks, refunds, and platforms/marketplace features, but there is no documented subscription billing product, dunning logic, automatic retry scheduling for failed recurring payments, or recovery email capability. This axis is plausible for a payments platform, but no evidence supports it being delivered.", "evidenceIds": [ "cko-supp-idempotency", "cko-supp-webhooks", "checkout-com-docs-22" ] }, { "productId": "checkout-com", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Checkout.com's Flow product is explicitly documented as embeddable, customizable payment components in a single integration rather than a redirect ('Accept payments using customizable components – all through one simple integration'), alongside Mobile SDKs for native embedded checkout. missing for 10: hands-on/independent verification of the embedded component customization (theming depth, framework support), and a code sample showing actual component embedding rather than marketing copy.", "evidenceIds": [ "checkout-com-docs-38", "checkout-com-docs-1", "checkout-com-docs-40", "checkout-com-docs-3" ] }, { "productId": "checkout-com", "storyId": "fraud-screening-rules", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com's docs explicitly cover 'Create risk rules and lists' and 'Retrieve fraud reports' under Prevent Fraud, giving finance-ops the ability to write custom block/review/allow-style rules, and it separately touts an 'AI-driven solution' for optimizing acceptance. However, the evidence never names a machine-learning fraud score, a scoring model, or how scores feed into rule conditions, nor a review-queue UI. Missing for 10: explicit ML fraud-score documentation, rule-to-score integration details, and hands-on/independent confirmation of the scoring engine's accuracy or usability.", "evidenceIds": [ "checkout-com-docs-28", "checkout-com-docs-29", "checkout-com-docs-30", "checkout-com-docs-36" ] }, { "productId": "checkout-com", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Checkout.com documents a dedicated Hosted Payments Page product ('Get a fully branded checkout page in less than a day... one integration') with low-code deployment and customization docs, plus a related Payment Links option for no-code hosted checkout flows. This directly matches the story of redirecting to a vendor-hosted, conversion-optimized checkout page without building custom payment UI. Missing for 10: independent/third-party conversion benchmarks or hands-on merchant testimonials validating the 'conversion-optimized' claim beyond vendor copy.", "evidenceIds": [ "checkout-com-docs-39", "checkout-com-docs-20", "checkout-com-docs-4", "checkout-com-docs-19", "checkout-com-docs-41", "checkout-com-docs-38" ] }, { "productId": "checkout-com", "storyId": "idempotent-api-retries", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Checkout.com's docs explicitly document idempotency support via the Cko-Idempotency-Key header across payments, authorizations, captures, refunds, cancellations, voids, and transfers endpoints, caching results of 2xx responses to safely retry without duplicate charges, with a configurable idempotency window. Missing for 10: independent/hands-on developer corroboration of real-world retry behavior beyond vendor docs.", "evidenceIds": [ "cko-supp-idempotency", "checkout-com-docs-7", "checkout-com-docs-49" ] }, { "productId": "checkout-com", "storyId": "integrate-from-docs-in-a-day", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Checkout.com's docs support several low-code paths (Hosted Payment Page explicitly marketed as 'less than a day', Flow, Payment Links, plugins) and there's a Unified Payments API plus a public Node.js SDK on GitHub, suggesting a developer could get a basic flow running quickly. However, the pack shows only one language SDK (Node.js) with no evidence of multi-language copy-paste snippets in the docs themselves, and openapi/reference-doc probes returned 404s, weakening confidence that a full in-docs multi-language integration experience exists. missing for 10: multi-language code samples embedded in docs, other official SDKs (Python/Java/PHP/Ruby), independent hands-on confirmation of 'under a day' integration.", "evidenceIds": [ "checkout-com-docs-39", "checkout-com-docs-38", "checkout-com-docs-43", "checkout-com-gh-1", "checkout-com-probe-3", "checkout-com-docs-20" ] }, { "productId": "checkout-com", "storyId": "marketplace-split-payments", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Checkout.com has a dedicated 'Platforms' product explicitly for marketplaces/payfacs that documents onboarding sub-entities, splitting funds between platform and sub-entities, and paying out sub-entities in their local currency/preferred method, backed by reconciliation and settlement reporting to track those splits and payouts. missing for 10: independent/hands-on validation of the onboarding flow, detailed KYC/sub-entity API reference specifics, and public case studies of marketplaces running this in production.", "evidenceIds": [ "cko-supp-platforms", "checkout-com-docs-22", "checkout-com-docs-23", "checkout-com-docs-24", "cko-supp-reconciliation", "checkout-com-docs-27" ] }, { "productId": "checkout-com", "storyId": "multi-currency-charge-settle", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com clearly supports charging in local currencies (150+ currencies, local acquiring, FX rates API for acquiring/payouts) and provides settlement reporting and a documented FX rate fee for reconciliation, which supports the founder's need to settle in their own currency. However, evidence does not show a clear, transparent published FX markup/rate table or a self-serve explanation of exactly how conversion and settlement currency selection works — pricing and FX fees are sales-led/unpublished, undercutting the 'transparent' claim. Missing for 10: a documented transparent FX rate/markup disclosure mechanism, self-serve settlement currency selection docs, and independent verification of actual FX transparency in practice.", "evidenceIds": [ "checkout-com-docs-10", "checkout-com-docs-33", "checkout-com-docs-44", "cko-supp-reconciliation", "checkout-com-docs-53", "cko-supp-pricing", "checkout-com-docs-27" ] }, { "productId": "checkout-com", "storyId": "no-code-payment-links", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com explicitly documents no-code Payment Links that can be sent via email/SMS/social to accept payments without coding (checkout-com-docs-5, -19, -41, -56), which directly matches the story. However, the account/pricing evidence indicates a sales-led, KYC-gated onboarding model rather than instant self-serve signup ('get in touch with our team' — cko-supp-pricing), undercutting the 'start selling immediately' claim for a new founder. Missing for 10: evidence of an instant self-serve dashboard signup (no sales call) and independent/hands-on confirmation that a first-time user can generate a link within minutes.", "evidenceIds": [ "checkout-com-docs-5", "checkout-com-docs-19", "checkout-com-docs-41", "checkout-com-docs-56", "cko-supp-pricing" ] }, { "productId": "checkout-com", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com's core payment lifecycle (payments, refunds, voids, payment links, webhooks, reconciliation, platforms/sub-entities, FX) is fully API-driven per docs, and the API is treated as the primary integration surface rather than the UI. However, some Dashboard-only or UI-centric functions (e.g., some fraud rule configuration, risk list management, business account setup, certain reporting views) are only shown via Dashboard screenshots/flows without confirmed API parity, and no OpenAPI spec was discoverable (404s on probes) to verify full API surface coverage. missing for 10: confirmed API parity for all Dashboard-configurable settings (risk rules, fraud lists, business account management), a public/complete OpenAPI spec, and independent evidence confirming no UI-only features exist.", "evidenceIds": [ "checkout-com-docs-2", "cko-supp-idempotency", "cko-supp-api-keys", "cko-supp-webhooks", "cko-supp-reconciliation", "cko-supp-platforms", "checkout-com-docs-28", "checkout-com-docs-29", "checkout-com-probe-3", "checkout-com-docs-21", "checkout-com-docs-55" ] }, { "productId": "checkout-com", "storyId": "openness-full-export", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Checkout.com documents various financial reports (Settlement Breakdown, Balance, Payouts, Reconciliation) accessible via Dashboard/API, which implies some data export capability, but there is no explicit documentation of a comprehensive 'export all your data in open formats and leave' capability, no data portability policy, and no mention of open-format guarantees or full account data export upon departure. missing for 10: explicit full-data export tooling, open-format (CSV/JSON) export guarantees, documented data portability/account closure export process, and independent confirmation of completeness.", "evidenceIds": [ "checkout-com-docs-26", "checkout-com-docs-27", "cko-supp-reconciliation" ] }, { "productId": "checkout-com", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a closed-source commercial payments platform, not an open-source project; source-code availability under an open license is not a relevant axis for this kind of product (its own SDKs are OSS but the core platform/API is proprietary).", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a hosted payments-processing SaaS platform (regulated financial infrastructure), not open-source software; self-hosting the core product is a category error for this type of product, since payment processing requires the vendor's regulated infrastructure, licensing, and acquiring relationships.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com documents a strong reconciliation report suite mapping payouts to their underlying financial actions — the 'Financial Actions by Payout ID Report', 'Payouts Report', 'Settlement Breakdown Report', and 'Balance' reports explicitly let finance-ops trace charges, fees, and refunds composing a payout, plus FX fee visibility. However, there is no evidence of the 'control the payout schedule' half of the story (e.g., configuring payout frequency/cadence or triggering ad hoc payouts) anywhere in the pack. Missing for 10: documentation of payout schedule/frequency configuration, self-serve payout timing controls.", "evidenceIds": [ "cko-supp-reconciliation", "checkout-com-docs-27", "checkout-com-docs-53", "checkout-com-docs-26" ] }, { "productId": "checkout-com", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com offers hosted payment pages, Flow, mobile SDKs, and payment links that are explicitly marketed as reducing compliance burden ('no confusing compliance'), and also supports tokens/network tokens/payment instruments as an alternative to raw card data, all of which are standard mechanisms for keeping card data off merchant servers and reducing PCI scope. However, no evidence explicitly names PCI DSS, SAQ levels, or describes tokenization architecture/vaulting in detail, and the API also documents accepting 'full card details' directly, meaning scope reduction depends on which integration path a developer chooses. Missing for 10: explicit PCI DSS compliance/SAQ-A scope-reduction documentation, dedicated tokenization/vaulting API docs, and independent confirmation of scope-reduction claims.", "evidenceIds": [ "checkout-com-docs-18", "checkout-com-docs-38", "checkout-com-docs-39", "checkout-com-docs-40", "checkout-com-docs-41", "checkout-com-docs-20" ] }, { "productId": "checkout-com", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions data residency, regional data storage options, or user/customer control over where data is stored; while the product processes payments across many currencies/countries, this does not address data residency choice. This axis is applicable to a payments platform handling sensitive data but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments infrastructure provider, not an AI model or platform that trains models on user data; the evidence pack contains nothing about AI-training data usage policies or opt-outs, and this axis is a category error for a payments product.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments API/platform, not a data-handling AI tool whose users would control retention/deletion of AI conversation or model data; this story's axis (AI-native data retention/deletion controls) doesn't map onto a payments gateway's product surface. No evidence pack items address user-controllable data retention/deletion policies for AI usage, so the axis is a category mismatch rather than a gap.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments platform, not an AI agent or data-collecting client tool; the evidence pack contains no telemetry/usage-tracking opt-out mechanism, and this axis is not a natural fit for a payments API/SDK product.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "recurring-subscription-billing", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments/acquiring platform (payment processing, links, hosted pages, platforms/marketplaces, issuing) but the evidence pack contains no mention of subscription/recurring billing objects such as plans, trial periods, proration, or plan upgrades/downgrades — these are billing-engine concepts (like Stripe Billing/Chargebee) not documented here.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "refunds-full-partial", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs explicitly cover refunding a payment via API with or without a reference (checkout-com-docs-21, checkout-com-docs-55), implying support for full/partial refunds through the payments/{id}/refunds endpoint (also listed as idempotent, cko-supp-idempotency). Dashboard-based refund management is implied by broader webhook/dashboard management patterns but not explicitly documented with a dedicated dashboard refund walkthrough. Missing for 10: explicit dashboard UI screenshot/walkthrough for issuing refunds, and independent/hands-on confirmation of partial refund amounts being configurable.", "evidenceIds": [ "checkout-com-docs-21", "checkout-com-docs-55", "cko-supp-idempotency" ] }, { "productId": "checkout-com", "storyId": "respond-to-disputes-evidence", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Checkout.com documents a disputes management area (\"Preventing fraudulent disputes\"), dedicated disputes testing scenarios, and webhook events that report \"progress on disputes,\" showing the platform supports dispute lifecycle tracking. However, there is no evidence of the actual structured-evidence submission workflow (e.g., uploading proof documents, dispute reason codes, response deadlines) or a documented end-to-end resolution tracking UI/API. Missing for 10: documentation of evidence submission fields/API, dispute status states and resolution outcomes, and any dashboard/API walkthrough of responding to a chargeback.", "evidenceIds": [ "checkout-com-docs-30", "checkout-com-docs-14", "checkout-com-docs-28", "checkout-com-docs-29", "cko-supp-webhooks" ] }, { "productId": "checkout-com", "storyId": "sandbox-test-mode-fidelity", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Checkout.com documents a dedicated test-account environment with a public 'Get test account' signup, plus per-scenario testing docs covering payments testing, test cards, disputes testing, fraud-detection testing, and bank payouts testing — directly matching the story's requirement for a sandbox mirroring production with test cards for declines and disputes. Missing for 10: independent/hands-on developer corroboration that the sandbox truly mirrors production behavior end-to-end, and more detail on how comprehensive the decline-scenario coverage is beyond the docs listing.", "evidenceIds": [ "cko-supp-testing", "checkout-com-docs-13", "checkout-com-docs-14" ] }, { "productId": "checkout-com", "storyId": "send-hosted-invoices", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Checkout.com is a payments infrastructure/API platform (payment links, hosted payment pages, Platforms, funds management), not a billing/invoicing product with hosted invoices and automated dunning reminders. This story targets invoicing SaaS billing tools, which is a different product category — a category error rather than a missing feature.", "evidenceIds": [] }, { "productId": "checkout-com", "storyId": "settlement-reconciliation-reports", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Checkout.com documents a dedicated reconciliation report suite (Balance Breakdown, Balance Report, Financial Actions by Date Range/Payout ID, Payouts Report, Settlement Breakdown Report, Settlement Statement) explicitly mapping settlements to underlying financial actions including fee categories, and separate refund/dispute docs cover those transaction types. Missing for 10: independent/third-party corroboration (e.g. finance-ops user reviews) that reconciliation reports itemize chargebacks specifically and match to bank deposits in practice, and no sample report output shown.", "evidenceIds": [ "cko-supp-reconciliation", "checkout-com-docs-26", "checkout-com-docs-27", "cko-supp-webhooks", "checkout-com-docs-21", "checkout-com-docs-55", "checkout-com-docs-30", "checkout-com-docs-53" ] }, { "productId": "checkout-com", "storyId": "wallets-local-payment-methods", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Checkout.com documents a unified payments API and Flow/Hosted Payment Page integrations that give access to digital wallets, local payment methods, and global card schemes via a single integration (checkout-com-docs-45, checkout-com-docs-2, checkout-com-docs-38, checkout-com-docs-43), explicitly covering local currencies and regional payment strategies. Missing for 10: no explicit line-item confirmation of BNPL providers or bank redirect method names, and no independent/hands-on corroboration of wallet coverage breadth.", "evidenceIds": [ "checkout-com-docs-45", "checkout-com-docs-2", "checkout-com-docs-38", "checkout-com-docs-43", "checkout-com-docs-44", "checkout-com-docs-33" ] }, { "productId": "checkout-com", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Checkout.com documents HMAC-signed webhooks, dashboard/API-based webhook configuration, and a dedicated 'Resend webhooks' capability for replay, satisfying the signing and replay parts of the story. However, evidence does not confirm automatic system-driven retries of failed webhook deliveries (only manual resend) or a dedicated event log/audit trail view for webhook history. Missing for 10: documented automatic retry policy for undelivered webhooks, explicit event log/audit UI, independent confirmation of retry behavior.", "evidenceIds": [ "cko-supp-webhooks", "checkout-com-docs-11", "checkout-com-docs-12", "checkout-com-docs-51" ] }, { "productId": "mollie", "storyId": "accept-card-payment-online", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie offers multiple fast paths to accept a card payment—hosted checkout, plug-and-play e-commerce plugins (Shopify/WooCommerce/Magento), and no-code Payment Links shareable via email/chat—all of which could plausibly go live quickly after signup. However, there is no explicit evidence about account verification/KYC turnaround time or a documented 'go live same day' onboarding flow, which is the crux of the founder's story. Missing for 10: explicit onboarding/KYC approval timeline evidence, first-party or independent confirmation that a new merchant can complete verification and accept a live payment within 24 hours.", "evidenceIds": [ "mollie-docs-1", "mollie-supp-hosted-checkout", "mollie-docs-5", "mollie-docs-21", "mollie-docs-23" ] }, { "productId": "mollie", "storyId": "agent-handles-dispute-end-to-end", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Mollie's Chargebacks API only supports retrieving chargeback details (mollie-docs-9); there is no documented capability for assembling evidence or submitting a dispute response via the API, and the MCP server's supported API list does not even include Chargebacks (mollie-supp-mcp-server). No evidence supports the 'submitting the response' half of this story.", "evidenceIds": [ "mollie-docs-9", "mollie-supp-mcp-server" ] }, { "productId": "mollie", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Mollie exposes webhooks with real-time payment status updates (including failures) and a Subscriptions/Payments API that an agent could poll or subscribe to via the MCP server, giving raw building blocks for monitoring failed payments programmatically. However, there is no documented dunning/retry-management feature, automated retry scheduling, or outreach tooling — an agent would have to build all retry/dunning logic itself on top of raw webhook events and API calls. Missing for 10: native dunning/retry automation, documented failed-payment recovery workflow, and evidence of an agent orchestrating retries end-to-end.", "evidenceIds": [ "mollie-docs-16", "mollie-supp-webhooks-nextgen", "mollie-docs-25", "mollie-supp-mcp-server", "mollie-docs-31" ] }, { "productId": "mollie", "storyId": "agent-provisions-payment-link", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Mollie's MCP server (mollie-supp-mcp-server) lets an agent create resources including Payment Links via natural language in one session, and the Payment Links API supports generating a shareable payment link directly from an amount/description (mollie-docs-5, mollie-docs-23). However, Mollie has no documented 'Product' or 'Price' catalog objects (unlike Stripe-style billing) — the MCP tool coverage list (Balances, Captures, Customers, Invoices, Mandates, Methods, Payments, Payment Links, Settlements, Subscriptions, Terminals, Webhooks) never mentions Products or Prices APIs, so the exact three-step workflow described isn't evidenced. Missing for 10: a Products/Prices API or equivalent catalog resource, an end-to-end documented/independent example of an agent chaining product+price+link creation in one session.", "evidenceIds": [ "mollie-supp-mcp-server", "mollie-docs-5", "mollie-docs-23", "mollie-docs-22" ] }, { "productId": "mollie", "storyId": "agent-reconciles-payouts", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie documents a Balances API for real-time/historical balance data and a Settlement Report that breaks down transactions, fees, and deductions per payout for reconciliation, both accessible via API and exposed through the Mollie MCP server (Balances, Settlements listed as covered APIs). However, evidence doesn't show a documented API endpoint for retrieving the underlying settlement/payout line items programmatically beyond the Settlements API listing itself, nor concrete agent-driven examples of matching balance transactions to charges. missing for 10: explicit documented Settlements API line-item/transactions endpoint schema, worked example of an agent reconciling deposits to charges end-to-end, and independent/hands-on confirmation of this reconciliation workflow via API or MCP.", "evidenceIds": [ "mollie-docs-10", "mollie-docs-11", "mollie-docs-27", "mollie-docs-28", "mollie-supp-mcp-server" ] }, { "productId": "mollie", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mollie publishes a live llms.txt index (verified by probe returning HTTP 200) and documents the markdown-mirror convention (append .md to any doc page) so agents can systematically discover and fetch docs; this is corroborated by an independent probe hit, not just vendor claims. missing for 10: no independent third-party (non-Mollie) report of an agent actually using llms.txt successfully in practice.", "evidenceIds": [ "mollie-supp-llms-md", "mollie-probe-1" ] }, { "productId": "mollie", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Mollie's AI-related evidence covers an MCP server that lets external AI tools create/manage payment resources via natural language, but there is no evidence of the product itself generating insights, analytics, or suggestions from a merchant's data within Mollie's own interface or reports.", "evidenceIds": [ "mollie-docs-19", "mollie-supp-mcp-server" ] }, { "productId": "mollie", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie ships genuine background automation primitives — Subscriptions/Recurring Payments run autonomously after initial setup ('happen in the background', 'we automatically create recurring payments for you at the interval you specified') and webhooks push real-time async updates — and its MCP server lets AI tools like Claude Desktop/Cursor create these resources via natural language. However, the automation scope is narrow (payment-related resources only) and the MCP server is documented for one-off resource creation/queries, not for orchestrating persistent autonomous agent workflows. Missing for 10: evidence of AI agents scheduling/monitoring ongoing automations themselves (vs. one-time setup), and any broader workflow/automation-builder beyond payments primitives.", "evidenceIds": [ "mollie-docs-24", "mollie-docs-25", "mollie-docs-7", "mollie-docs-16", "mollie-docs-19", "mollie-supp-mcp-server", "mollie-supp-webhooks-nextgen" ] }, { "productId": "mollie", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Mollie's evidence describes an MCP server that lets external AI tools (Claude Desktop, Cursor, VS Code) call Mollie's APIs via natural language — this is Mollie acting as a tool/backend for other assistants, not a built-in AI assistant inside Mollie's own product that users delegate tasks to. No dashboard chatbot, in-app assistant, or similar built-in AI feature is documented.", "evidenceIds": [ "mollie-docs-19", "mollie-supp-mcp-server", "mollie-probe-3" ] }, { "productId": "mollie", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Mollie is a REST API-based payment platform designed for headless/server-side integration: API keys, idempotency keys, webhooks, and test mode all support fully automated, non-interactive/CI-driven operation without a UI. Missing for 10: no explicit CI/CD pipeline examples, SDK/CLI tooling for automated test suites, or independent hands-on reports of running Mollie flows inside a CI pipeline.", "evidenceIds": [ "mollie-supp-testing", "mollie-supp-idempotency", "mollie-supp-auth-scopes", "mollie-docs-22", "mollie-docs-16" ] }, { "productId": "mollie", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments platform/API, not an agent or assistant that consumes tools — the evidence only shows Mollie *exposes* an MCP server for other AI tools (Claude Desktop, Cursor) to call, which is the opposite (server) role, not Mollie plugging in external MCP servers to use their tools itself.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mollie documents an official hosted MCP server at https://mcp.mollie.com/mcp acting as a proxy for its public API, with documented API coverage (Payments, Balances, Subscriptions, Webhooks, etc.), scoped access tokens, and setup instructions for Claude Desktop, Cursor, and VS Code. Missing for 10: independent/hands-on third-party corroboration beyond vendor docs and probe confirmation.", "evidenceIds": [ "mollie-docs-19", "mollie-supp-mcp-server", "mollie-probe-3" ] }, { "productId": "mollie", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Mollie ships an official MCP server (hosted at mcp.mollie.com/mcp) explicitly documented as enabling merchants to use natural language via AI tools like Claude Desktop and Cursor AI to create resources in their Mollie account, with scoped OAuth access and documented client configs. Missing for 10: independent/hands-on user reports confirming reliability, and broader coverage details (only a subset of APIs are exposed via MCP, e.g. no Payments creation confirmation beyond listed APIs).", "evidenceIds": [ "mollie-docs-19", "mollie-supp-mcp-server", "mollie-probe-3" ] }, { "productId": "mollie", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments API/platform; while it offers an MCP server, llms.txt index, and REST API/SDKs, no evidence pack item describes an official CLI tool for managing Mollie resources or workflows. Absence of evidence for this applicable capability yields 'none'.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mollie exposes a comprehensive, well-documented public REST API (Payments, Subscriptions, Balances, Webhooks, etc.), plus auth schemes, idempotency headers, test mode, and an llms.txt documentation index explicitly designed for AI agent discovery, alongside an official MCP server proxying the public API for AI tools like Claude/Cursor. Missing for 10: no discoverable OpenAPI/Swagger spec (probe returned 404s) and no independent hands-on corroboration beyond vendor docs.", "evidenceIds": [ "mollie-docs-22", "mollie-supp-idempotency", "mollie-supp-testing", "mollie-supp-auth-scopes", "mollie-supp-llms-md", "mollie-supp-mcp-server", "mollie-probe-1", "mollie-probe-2", "mollie-probe-3" ] }, { "productId": "mollie", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie documents scoped credential mechanisms applicable to agent use: Advanced access tokens can be scoped to a specific mode or profile, API keys are scoped per payment profile with granular permissions grouped by business area/API, and the MCP server explicitly requires profile.read plus optional per-API scopes to enable individual tools. This shows a real least-privilege model usable when provisioning an agent, but there's no dedicated 'agent credential' concept, no fine-grained per-action/per-amount limits, and no independent evidence of this being used in practice for agent scoping. Missing for 10: agent-specific credential issuance workflow, granular per-action/spend-limit scoping beyond API/profile level, independent/hands-on confirmation of least-privilege enforcement in an agentic context.", "evidenceIds": [ "mollie-supp-auth-scopes", "mollie-supp-mcp-server", "mollie-docs-19" ] }, { "productId": "mollie", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack documents Mollie's REST API references, webhooks, testing mode, and an MCP server for AI agents, but never mentions official client SDKs/libraries (e.g., PHP, Node, Python, Java clients) that developers or AI agents could build against. Since SDK availability is a standard axis for a payments API platform, its absence here is a gap rather than a category mismatch.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mollie's next-gen Webhooks API explicitly supports permanent subscriptions to specific event types (replacing one-off payment webhooks), backed by a Webhook Events API for auditing past events and documented HMAC signature verification for security. This directly satisfies event-driven subscription via webhooks for programmatic/agentic consumption. Missing for 10: independent/hands-on verification of webhook delivery reliability and broader real-world event-type coverage beyond docs.", "evidenceIds": [ "mollie-supp-webhooks-nextgen", "mollie-docs-16", "mollie-docs-17", "mollie-docs-32", "mollie-docs-33" ] }, { "productId": "mollie", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers static markdown documentation, an llms.txt index, and reference pages, but there is no mention of an interactive API console, 'try it' runnable examples, or Postman/OpenAPI-based playground; a probe for OpenAPI/swagger specs returned 404s, suggesting no such interactive reference exists.", "evidenceIds": [ "mollie-probe-2", "mollie-supp-llms-md", "mollie-probe-1" ] }, { "productId": "mollie", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Probes for standard OpenAPI/Swagger spec locations on Mollie's docs site all returned 404, and no evidence pack item shows a published, downloadable OpenAPI/Swagger spec; the llms.txt index and markdown mirrors are documentation aids, not a machine-readable API spec.", "evidenceIds": [ "mollie-probe-2", "mollie-supp-llms-md", "mollie-probe-1" ] }, { "productId": "mollie", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mollie documents a first-class test mode that isolates test resources from live data, supports test API keys or a testmode parameter, replaces hosted checkout with a simulated flow, and even allows simulating refunds/chargebacks via changePaymentState — directly matching the sandbox-without-production-data story. missing for 10: no independent/hands-on third-party confirmation of sandbox behavior beyond vendor docs, and no explicit mention of sandbox support specifically for the MCP/AI-agent workflow (only general API test mode is documented).", "evidenceIds": [ "mollie-docs-18", "mollie-supp-testing" ] }, { "productId": "mollie", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows Mollie has a v2 API (mollie-docs-12) but nothing documents a versioning scheme, deprecation policy, changelog, or sunset timeline for older API versions/endpoints. Missing for 10: explicit API versioning documentation, deprecation/sunset policy, changelog or migration guide evidence.", "evidenceIds": [ "mollie-docs-12" ] }, { "productId": "mollie", "storyId": "automatic-tax-calculation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Mollie is a payment processing platform (checkout, payments, subscriptions, payouts, connect/marketplace splits) with no evidence of tax/VAT/GST calculation, rate lookup, or automated tax collection features anywhere in the evidence pack.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Mollie's documented APIs (Payments, Refunds, Subscriptions, Balances, MCP server, etc.) are all single-resource endpoints; there is no evidence of a batch/bulk API, bulk payment creation, or bulk refund/webhook management across many items at once. The MCP server description explicitly frames it as creating individual resources via natural language, not bulk operations.", "evidenceIds": [ "mollie-docs-19", "mollie-supp-mcp-server", "mollie-docs-22", "mollie-docs-26" ] }, { "productId": "mollie", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Mollie provides event-driven building blocks — webhooks that fire on payment status changes, subscriptions that auto-create recurring payments, and application fees that auto-collect on every payment — but these are fixed, pre-built automations, not a general rules engine where a user defines arbitrary 'if event X then action Y' logic. Actual custom rule logic must be built externally by consuming webhooks in the merchant's own system. Missing for 10: a native rules/automation builder, conditional trigger-action configuration UI or API, and evidence of user-defined (vs. Mollie-predefined) automated actions.", "evidenceIds": [ "mollie-docs-16", "mollie-supp-webhooks-nextgen", "mollie-docs-25", "mollie-docs-30", "mollie-supp-idempotency" ] }, { "productId": "mollie", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie's Subscriptions API automatically creates recurring payments at specified intervals without further manual action, which is a genuine recurring-job capability, but it is scoped strictly to payment charges rather than general workflow/job scheduling. Missing for 10: any general-purpose task/workflow scheduler, cron-like triggers beyond billing, or orchestration hooks usable outside payments.", "evidenceIds": [ "mollie-docs-7", "mollie-docs-25", "mollie-docs-6", "mollie-docs-24" ] }, { "productId": "mollie", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments API/platform, not an automation/workflow builder; there is no concept of 'automations' with versioning, review, or rollback in its product surface. This story applies to workflow-automation tools, not a payments infrastructure provider.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "dunning-failed-payment-recovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Mollie's docs cover Subscriptions API, recurring payments, webhooks, and idempotency, but none of the evidence describes automatic retry logic for failed subscription payments, dunning schedules, or recovery emails to customers — this is a distinct capability not documented anywhere in the pack.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mollie Components (Mollie JS) let developers embed PCI-DSS-compliant card fields directly in their own checkout UI rather than redirecting to a hosted page, and docs explicitly outline build-your-own-checkout via the Payments API as an alternative to hosted checkout. This covers the core story of embeddable, customizable payment components. Missing for 10: independent/hands-on developer corroboration of styling customization depth and broader component coverage beyond card fields.", "evidenceIds": [ "mollie-docs-2", "mollie-docs-4", "mollie-supp-hosted-checkout" ] }, { "productId": "mollie", "storyId": "fraud-screening-rules", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers chargebacks retrieval, webhooks, idempotency, and testing, but there is no mention of ML-based fraud scoring or a rules engine for block/review/allow decisions on transactions.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mollie's hosted checkout is explicitly documented as a Mollie-hosted, device-optimized payment page that lets developers redirect customers without building their own UI, with e-commerce platform plugins and Payments API integration for redirect flows. missing for 10: independent/hands-on conversion-optimization evidence beyond vendor docs.", "evidenceIds": [ "mollie-docs-21", "mollie-docs-3", "mollie-supp-hosted-checkout", "mollie-docs-1", "mollie-docs-22" ] }, { "productId": "mollie", "storyId": "idempotent-api-retries", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mollie documents the Idempotency-Key header explicitly for safe retries and even calls out the exact danger scenarios (double charges on recurring payments/subscriptions, duplicate partial refunds) that it prevents. missing for 10: independent/hands-on developer confirmation of idempotency behavior in production beyond vendor docs.", "evidenceIds": [ "mollie-docs-20", "mollie-supp-idempotency", "mollie-docs-40" ] }, { "productId": "mollie", "storyId": "integrate-from-docs-in-a-day", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mollie's docs give a clear, well-structured path (hosted checkout, Payments API, webhooks, test mode, idempotency) that a developer could follow to build a working payment flow, and llms.txt/markdown mirrors make the docs easily consumable. However, the evidence pack never shows actual copy-paste code snippets in a specific programming language (e.g. PHP/Node/Python SDK examples) or confirms a 'under a day' end-to-end tutorial — only conceptual/API-reference descriptions are present. missing for 10: language-specific copy-paste code samples/SDK quickstarts, an explicit fast end-to-end tutorial timeline, independent developer corroboration of setup speed", "evidenceIds": [ "mollie-docs-2", "mollie-docs-21", "mollie-docs-22", "mollie-supp-hosted-checkout", "mollie-supp-testing", "mollie-supp-idempotency", "mollie-supp-llms-md" ] }, { "productId": "mollie", "storyId": "marketplace-split-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mollie Connect explicitly supports onboarding connected merchants, escrow-like holding of funds, split payments to multiple sellers, and application fees/commission retention for the platform, backed by documented onboarding, reporting, and payout mechanisms (settlement reports, balances API). missing for 10: independent/hands-on developer case studies building a full marketplace end-to-end, and more detail on seller onboarding KYC flow specifics beyond doc mentions.", "evidenceIds": [ "mollie-docs-13", "mollie-docs-14", "mollie-docs-15", "mollie-supp-connect-splits", "mollie-docs-27", "mollie-docs-28", "mollie-docs-30" ] }, { "productId": "mollie", "storyId": "multi-currency-charge-settle", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mollie documents accepting payments in currencies beyond EUR via its v2 APIs [mollie-docs-12], and provides Settlement Reports and Balances API for reconciling payouts [mollie-docs-10, mollie-docs-27, mollie-docs-11, mollie-docs-28], which supports part of the founder's need. However, there is no evidence detailing FX conversion rates, markup/fee transparency, or explicit confirmation that funds settle to the merchant's bank account in their own currency after conversion. Missing for 10: explicit FX rate/markup disclosure, settlement-currency selection/conversion mechanics, and independent confirmation of how multi-currency payments reconcile to a single bank currency.", "evidenceIds": [ "mollie-docs-12", "mollie-docs-10", "mollie-docs-27", "mollie-docs-11", "mollie-docs-28" ] }, { "productId": "mollie", "storyId": "no-code-payment-links", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie's docs confirm a no-code Payment Links capability that lets founders generate a shareable link (email/chat) without building a full checkout, and it's explicitly called out as a 'no-code' option alongside hosted/API checkouts [mollie-docs-5, mollie-docs-23, mollie-supp-hosted-checkout]. However, the evidence never explicitly shows the dashboard UI flow for creating a payment link (it frames it as an API), so it's unclear if a founder can do this purely by clicking in the dashboard with zero technical setup. Missing for 10: explicit dashboard UI screenshots/steps for generating a payment link with no code, and confirmation that no account/API key setup is needed before selling.", "evidenceIds": [ "mollie-docs-5", "mollie-docs-23", "mollie-supp-hosted-checkout" ] }, { "productId": "mollie", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Mollie's API surface is extensive and mirrors most Dashboard functionality: payments, refunds (explicitly noted as available both via API and manually in the 'Mollie Web app'), subscriptions, balances, settlement reports, chargebacks, webhooks, and Connect split-payments/application-fees are all API-accessible. However, no evidence explicitly asserts full 1:1 API/UI parity across every dashboard feature (e.g., account settings, onboarding flows, reporting UI extras), and the MCP server itself only proxies a subset of APIs (missing Refunds, Chargebacks, Orders), leaving some UI-only gaps unconfirmed either way. Missing for 10: explicit parity statement, independent confirmation that every dashboard action has an API equivalent, and coverage of admin/config UI features not mentioned in docs.", "evidenceIds": [ "mollie-docs-8", "mollie-docs-26", "mollie-docs-11", "mollie-docs-28", "mollie-docs-10", "mollie-docs-27", "mollie-docs-9", "mollie-supp-connect-splits", "mollie-supp-testing", "mollie-supp-auth-scopes" ] }, { "productId": "mollie", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Mollie's docs show only piecemeal transaction-reporting APIs (Settlement Report, Balances API) for reconciliation, not a comprehensive account data export or account-closure/portability feature; there's no evidence of a full data export in open formats or a documented way to close an account and take all data with you.", "evidenceIds": [ "mollie-docs-10", "mollie-docs-11", "mollie-docs-27", "mollie-docs-28" ] }, { "productId": "mollie", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a closed-source payments API/SaaS platform, not an open-source project; there is no evidence of any open-licensed source code repository. Reading 'source under an open license' is a category error for this kind of product—its API docs and MCP server are proprietary services, not open-source software.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a hosted payments SaaS/API platform, not infrastructure a user runs themselves; self-hosting the core payment processing engine is a category error for a regulated financial service, not an applicable openness axis.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie's Settlement Report gives a full breakdown of transactions, fees, and deductions per payout, and the Balances API exposes real-time/historical balance data useful for reconciliation, directly supporting the 'see what makes up each payout' half of the story. However, there is no evidence of finance-ops controls to set or change the payout schedule (e.g., daily/weekly/custom payout frequency settings) — the docs only describe reporting/retrieval APIs, not schedule configuration. missing for 10: documented payout schedule/frequency controls, UI or API to set payout timing, confirmation that fees/refunds/chargebacks are itemized per payout beyond settlement report summary.", "evidenceIds": [ "mollie-docs-10", "mollie-docs-27", "mollie-docs-11", "mollie-docs-28" ] }, { "productId": "mollie", "storyId": "pci-scope-reduction", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mollie offers hosted checkout, Payment Links, and Mollie Components explicitly documented as 'fully PCI-DSS SAQ-A compliant', keeping card data off the merchant's own servers via tokenized/embedded fields or redirect, which minimizes PCI scope. missing for 10: no independent third-party audit or compliance certificate evidence, and no explicit statement of merchant SAQ-A eligibility requirements/limitations.", "evidenceIds": [ "mollie-docs-4", "mollie-supp-hosted-checkout", "mollie-docs-3", "mollie-docs-21" ] }, { "productId": "mollie", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments API/platform; data residency/region choice for stored data is not a documented axis in this evidence, and the product category (payment processing) doesn't naturally offer region-selection controls to end users. This is a category mismatch rather than an unmet applicable capability.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments API/platform, not an AI model provider or consumer-facing platform that trains AI models on user data; the evidence pack contains no mention of AI-training opt-outs or data-use policies for model training, and this axis is a category error for a payments infrastructure product.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments API/platform; no evidence in the pack addresses data retention policies, data deletion controls, or export/erasure mechanisms for AI-native users. The evidence covers payments, checkout, webhooks, Connect, and MCP server capabilities but nothing about privacy/data lifecycle controls.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mollie is a payments API/platform, not an AI agent or telemetry-collecting AI tool; there's no evidence of any telemetry/usage-tracking collection mechanism aimed at AI-native users that would require an opt-out. This axis is a category error for a payments platform's evidence pack shown here.", "evidenceIds": [] }, { "productId": "mollie", "storyId": "recurring-subscription-billing", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Mollie's Subscriptions API automates recurring payments at set intervals, which covers basic recurring billing, but the evidence shows no concept of 'plans' as reusable templates, no trial period support, no subscription upgrade/downgrade mechanism, and no proration logic — these are core parts of the story. missing for 10: plan/catalog abstraction, trial period support, upgrade/downgrade workflows, proration calculation, and any documented example of managing subscription lifecycle changes.", "evidenceIds": [ "mollie-docs-7", "mollie-docs-25", "mollie-docs-24", "mollie-docs-6" ] }, { "productId": "mollie", "storyId": "refunds-full-partial", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs confirm refunds can be created via the API endpoint and manually via the Mollie Web app (dashboard), and the idempotency docs explicitly reference 'partial refunds' as a supported operation, confirming both full and partial refund support across both surfaces. Missing for 10: no dedicated Refunds API reference doc explicitly listing full vs partial refund parameters, and no independent/hands-on confirmation beyond first-party docs.", "evidenceIds": [ "mollie-docs-8", "mollie-docs-26", "mollie-supp-idempotency" ] }, { "productId": "mollie", "storyId": "respond-to-disputes-evidence", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Mollie's Chargebacks API only lets merchants retrieve details of chargebacks that occurred on their account (mollie-docs-9); there is no documented capability to submit structured evidence in response to a dispute or to track a dispute lifecycle through stages to resolution. Settlement reports and balances APIs (mollie-docs-10, mollie-docs-11) help reconcile chargeback deductions financially, but this is reconciliation, not dispute-response workflow. missing for 10: evidence-submission/response mechanism for chargebacks, dispute status/lifecycle states, resolution outcome tracking, any UI or API for contesting a chargeback.", "evidenceIds": [ "mollie-docs-9", "mollie-docs-10", "mollie-docs-11" ] }, { "productId": "mollie", "storyId": "sandbox-test-mode-fidelity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mollie documents a genuine test mode that isolates test data from production, replaces hosted checkout with a walkthrough screen, and exposes a changePaymentState URL to simulate refunds and chargebacks (mollie-supp-testing, mollie-docs-18). However, the evidence never mentions specific test card numbers or a documented list of decline/failure scenarios by card, which the story explicitly calls for. Missing for 10: documented test card numbers per scenario (success, decline, insufficient funds, etc.), and independent/hands-on confirmation that test mode fully mirrors all production payment method behaviors.", "evidenceIds": [ "mollie-supp-testing", "mollie-docs-18" ] }, { "productId": "mollie", "storyId": "send-hosted-invoices", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Mollie's Payment Links can be attached to an unpaid invoice and shared via email/chat, giving a hosted payment option for invoices, and an 'Invoices API' is listed among MCP-server-exposed APIs, but there is no documentation of generating/sending actual hosted invoice documents or of automatic payment reminders. missing for 10: dedicated hosted-invoice creation/send flow, automatic reminder scheduling, and any invoice-status/reminder API details.", "evidenceIds": [ "mollie-docs-5", "mollie-docs-23", "mollie-supp-mcp-server" ] }, { "productId": "mollie", "storyId": "settlement-reconciliation-reports", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Mollie's Settlement Report explicitly gives a breakdown of a payout showing 'all transactions, fees and deductions,' and the Balances API supports bookkeeping reconciliation, while separate Chargebacks and Refunds APIs let finance-ops retrieve those items — together covering the core of the story. However, no evidence shows a single itemized report combining fees, refunds, and chargebacks in one reconciliation view, nor any bank-deposit matching feature or independent/hands-on validation of the reconciliation workflow. Missing for 10: unified itemized settlement report explicitly breaking out refunds/chargebacks line-by-line, bank-deposit matching capability, and independent user corroboration.", "evidenceIds": [ "mollie-docs-10", "mollie-docs-27", "mollie-docs-11", "mollie-docs-28", "mollie-docs-9", "mollie-docs-8" ] }, { "productId": "mollie", "storyId": "wallets-local-payment-methods", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mollie's hosted checkout is documented as a single integration where 'customer can select their payment method of choice' (mollie-docs-21), and Apple Pay is explicitly called out as a checkout button option (mollie-docs-35), supporting the core 'one integration, many methods' claim. However, the evidence pack never explicitly names Google Pay, bank redirects (iDEAL/SEPA/Bancontact), or BNPL options (Klarna/Riverty) as available methods within this single integration. Missing for 10: explicit documentation of Google Pay support, bank redirect methods, and BNPL options within the same checkout integration.", "evidenceIds": [ "mollie-docs-21", "mollie-docs-35", "mollie-supp-hosted-checkout", "mollie-docs-3" ] }, { "productId": "mollie", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mollie documents signed webhooks via HMAC verification (X-Mollie-Signature) and a next-gen Webhook Events API that lets developers 'retroactively inspect past events' and retrieve detailed info per triggered event, giving an audit/event-log capability. However, there is no documented automatic retry mechanism for webhook delivery, and no explicit 'replay' feature to resend a webhook event to reprocess it — idempotency keys only cover client-side API request retries, not Mollie's own webhook delivery retries. missing for 10: documented automatic webhook delivery retry policy, explicit replay/resend capability for webhook events, independent/hands-on confirmation of retry behavior.", "evidenceIds": [ "mollie-docs-17", "mollie-docs-33", "mollie-supp-webhooks-nextgen", "mollie-docs-32", "mollie-supp-idempotency" ] }, { "productId": "paddle", "storyId": "accept-card-payment-online", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle's docs show clear fast paths to a live checkout: overlay checkout requiring 'minimal frontend coding,' Paddle.js embeds, a sandbox for testing without real payments, and ready-made Next.js/Supabase starter kits that bundle checkout + billing in a day-scale setup. However, nothing in the evidence pack addresses the merchant-of-record account verification/KYC timeline that typically gates going live with real card payments, so the 'within a day' claim is not directly substantiated. Missing for 10: explicit onboarding/verification turnaround time, first-party or independent confirmation of same-day live acceptance.", "evidenceIds": [ "paddle-docs-14", "paddle-docs-13", "paddle-supp-sandbox", "paddle-docs-51", "paddle-docs-60", "paddle-docs-23" ] }, { "productId": "paddle", "storyId": "agent-handles-dispute-end-to-end", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of a Disputes/Chargebacks API endpoint, no ability to retrieve dispute details, assemble evidence, or submit a response programmatically. The only related mentions are generic references to 'chargeback defense' as part of Paddle's merchant-of-record fee and 'investigate failed payments' in the MCP server description, neither of which constitutes dispute-evidence submission via API.", "evidenceIds": [ "paddle-supp-mor-tax", "paddle-supp-mcp-server", "paddle-supp-payout-reconciliation" ] }, { "productId": "paddle", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle documents webhooks for real-time payment-failure notifications, an API/MCP server that lets agents 'Investigate failed payments and resolve billing issues,' and built-in dunning (Tactical Retries, notification config) — covering the monitoring and resolution loop an AI agent could drive via API/MCP. However, the dunning/retry mechanism itself is a built-in automated system (configured, not actively 'driven' step-by-step by an agent), and there's no explicit example of an agent initiating a retry or outreach action end-to-end. Missing for 10: a concrete agent-driven retry/outreach workflow example, and clarity on whether MCP actions can actually trigger/override the automatic retry schedule rather than just configure it.", "evidenceIds": [ "paddle-docs-11", "paddle-docs-18", "paddle-supp-dunning", "paddle-supp-mcp-server", "paddle-supp-mcp-codemode", "paddle-docs-12" ] }, { "productId": "paddle", "storyId": "agent-provisions-payment-link", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Paddle's hosted MCP server gives agents a codemode interface (search + execute) that can chain arbitrary Paddle API calls — including creating products, prices, and payment/checkout links — all within one authenticated session, backed by API key/OAuth auth and full OpenAPI coverage (paddle-supp-mcp-server, paddle-supp-mcp-codemode, paddle-docs-15, paddle-docs-46). This directly supports an agent provisioning product+price+payment link end-to-end via API in one session. missing for 10: no independent/hands-on report of an agent actually completing this exact three-step flow (product→price→link) in one session, and no explicit example transcript showing payment-link creation specifically via the MCP execute tool.", "evidenceIds": [ "paddle-supp-mcp-server", "paddle-supp-mcp-codemode", "paddle-docs-15", "paddle-docs-46", "paddle-docs-8", "paddle-supp-sandbox" ] }, { "productId": "paddle", "storyId": "agent-reconciles-payouts", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Paddle publishes dedicated payout reconciliation reports that explicitly reconcile payouts to transactions/adjustments, itemized by gross, tax, fees and currency, generated via API for feeding into accounting/BI systems, and the hosted Paddle MCP server exposes this data to agents (report generation, revenue/refund/transaction analysis) alongside Bearer-token API access with granular permissions. This directly matches the ai-native reconciliation workflow described in the story. missing for 10: independent/hands-on evidence of an agent actually executing an end-to-end payout-to-charge reconciliation via the API/MCP, and explicit documentation of a 'balance transaction' endpoint terminology matching the story's phrasing", "evidenceIds": [ "paddle-supp-payout-reconciliation", "paddle-docs-19", "paddle-docs-37", "paddle-docs-70", "paddle-supp-mcp-server", "paddle-supp-auth-permissions", "paddle-docs-8" ] }, { "productId": "paddle", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Paddle publishes a dedicated llms.txt (confirmed live via HTTP 200 probe) plus a full suite of agent-oriented docs including agent-skills, MCP servers, and an LLM integration benchmark explicitly instructing agents to load skills first. missing for 10: independent third-party (non-Paddle) confirmation that an agent successfully consumed llms.txt end-to-end in the wild.", "evidenceIds": [ "paddle-docs-29", "paddle-probe-1", "paddle-supp-agent-skills", "paddle-supp-llm-benchmark", "paddle-docs-30" ] }, { "productId": "paddle", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Paddle's MCP server explicitly supports 'analyze revenue, refunds, and transaction patterns' and 'investigate failed payments' via natural-language queries from a connected AI agent (Claude, Cursor, etc.), which can surface insights from account data. However, this requires an external agent/tool to connect via MCP rather than an in-product, always-on AI insights/suggestions feature (e.g., no evidence of a native dashboard widget proactively surfacing AI-generated recommendations). Missing for 10: evidence of built-in, in-app AI-generated insights/suggestions surfaced automatically to users without requiring a separate agent connection, and independent/hands-on corroboration of the MCP-driven analysis actually producing useful insights in practice.", "evidenceIds": [ "paddle-supp-mcp-server", "paddle-docs-65", "paddle-docs-57", "paddle-docs-55" ] }, { "productId": "paddle", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Paddle's evidence covers webhooks, MCP servers, and agent skills for integration purposes, but none of this describes autonomous background automations (e.g., scheduled/triggered workflows that run without user invocation) — the product is a payments/billing platform with agent-assisted integration tooling, not an automation/workflow engine that runs tasks autonomously in the background. missing for 10: any evidence of scheduled jobs, autonomous triggers, or background automation execution initiated by the user rather than by an explicit API/webhook call.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 6, "confidence": "high", "rationale": "Paddle doesn't ship a native, in-dashboard AI assistant chat UI; instead it exposes a hosted MCP server and agent-skills that let external AI agents (Claude, Cursor, etc.) connect to Paddle and perform pricing, billing, and integration tasks in natural language, plus a codemode search/execute interface for chaining API calls. This delivers the 'delegate tasks to AI' outcome but only via a third-party agent client rather than an assistant embedded inside Paddle's own product surface. Missing for 10: a first-party in-product chat/assistant UI (not just an MCP endpoint for external agents), and independent hands-on evidence of the delegation experience.", "evidenceIds": [ "paddle-supp-mcp-server", "paddle-docs-31", "paddle-supp-mcp-codemode", "paddle-supp-agent-skills", "paddle-docs-57" ] }, { "productId": "paddle", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle exposes a full REST API with Bearer-token auth, OpenAPI spec, Postman collection, and server-side SDKs (Node/Python/Go/PHP) that can all be scripted headlessly in CI, plus a documented Sandbox environment for automated testing and webhooks for event-driven automation. However, this evidence is all API/SDK automation rather than a CLI or headless mode for the product's own dashboard/UI workflows, and there's no explicit CI pipeline example, GitHub Actions integration, or independent hands-on confirmation of running Paddle in CI. missing for 10: dedicated CLI tool, documented CI/CD pipeline examples (e.g., GitHub Actions), independent/community verification of headless CI usage.", "evidenceIds": [ "paddle-docs-25", "paddle-docs-8", "paddle-supp-sandbox", "paddle-docs-29", "paddle-docs-24", "paddle-docs-11", "paddle-probe-1" ] }, { "productId": "paddle", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Paddle is a payments/billing SaaS platform, not an AI agent or assistant with its own tool-use runtime; the evidence entirely concerns Paddle publishing MCP servers (paddle-mcp, docs-mcp) for external agents like Claude/Cursor to consume, i.e. Paddle as an MCP server, not as an MCP client plugging in others' servers to gain tool use. This client-side capability is a category error for a billing platform of this kind.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Paddle documents an official, hosted, remote MCP server (sandbox and live endpoints, OAuth/API-key auth) that lets agents like Claude and Cursor perform real account actions—pricing, billing, refunds, subscription changes—plus a separate docs MCP server and agent skills, all corroborated by an independent probe confirming the docs URL. This is a first-party, production MCP integration well beyond a generic API wrapper. Missing for 10: independent hands-on user report of connecting an agent to the live MCP server (only vendor docs and a URL probe, no third-party usage account).", "evidenceIds": [ "paddle-supp-mcp-server", "paddle-supp-mcp-codemode", "paddle-supp-docs-mcp", "paddle-supp-agent-skills", "paddle-docs-4", "paddle-docs-31", "paddle-probe-3" ] }, { "productId": "paddle", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 9, "confidence": "medium", "rationale": "Paddle documents an extensive MCP-based natural-language interface: the hosted Paddle MCP server lets agents 'ask an agent in natural language to handle pricing, billing, support, and integration workflows,' covering pricing changes, refunds, subscription upgrades/downgrades/cancellations, webhook config, and report generation, backed by a codemode search/execute interface, agent skills, and a published LLM benchmark showing measured task success. This is rich, detailed first-party documentation directly on-topic for natural-language operation. Missing for 10: independent/hands-on third-party corroboration that the natural-language commands work reliably in practice (community evidence available is unrelated to AI/MCP usage).", "evidenceIds": [ "paddle-docs-4", "paddle-docs-30", "paddle-docs-31", "paddle-supp-mcp-server", "paddle-supp-mcp-codemode", "paddle-supp-agent-skills", "paddle-supp-llm-benchmark", "paddle-docs-62" ] }, { "productId": "paddle", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Paddle's evidence covers SDKs, MCP servers, agent skills, OpenAPI/Postman specs, and webhooks, but nowhere documents an official Paddle CLI tool; the mentions of 'Claude Code, Codex, and Gemini CLI' refer to third-party AI coding CLIs that Paddle plugins integrate with, not a Paddle-branded CLI.", "evidenceIds": [ "paddle-supp-agent-skills", "paddle-docs-29", "paddle-probe-2" ] }, { "productId": "paddle", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Paddle exposes a full public REST API with Bearer auth, granular permissions, key rotation, an OpenAPI 3.1 spec, Postman collection, and official SDKs (Node, Python, Go, PHP) — plus a purpose-built MCP server with codemode search/execute tools, agent skills, and a docs MCP, explicitly designed for AI agents to drive the product end-to-end. Missing for 10: independent third-party corroboration of the MCP/API working reliably at scale (evidence is entirely vendor docs), and the probe found the OpenAPI spec not resolvable at common guessed paths.", "evidenceIds": [ "paddle-supp-mcp-server", "paddle-supp-mcp-codemode", "paddle-supp-openapi-postman", "paddle-docs-8", "paddle-docs-9", "paddle-docs-25", "paddle-supp-auth-permissions", "paddle-supp-agent-skills", "paddle-probe-3" ] }, { "productId": "paddle", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle supports API keys with documented granular permissions/scopes (paddle-docs-9, paddle-supp-auth-permissions) and sandbox-only keys (paddle-supp-sandbox) that can be issued for agent use via the MCP server, and Live OAuth MCP connections default to read-only access initially (paddle-supp-mcp-server). However, the MCP server itself explicitly does not gate destructive operations and relies on the user manually creating least-privilege keys rather than the product enforcing scoped credential issuance for agents (paddle-supp-mcp-codemode). missing for 10: no dedicated agent-specific credential/token issuance flow (e.g. per-agent scoped key generation UI or API), no evidence of fine-grained action-level restriction enforced automatically for MCP/agent use, no independent confirmation that permission scoping actually restricts agent behavior in practice.", "evidenceIds": [ "paddle-docs-9", "paddle-supp-auth-permissions", "paddle-supp-sandbox", "paddle-supp-mcp-server", "paddle-supp-mcp-codemode" ] }, { "productId": "paddle", "storyId": "agentic-sdks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Paddle publishes official server-side SDKs (Node.js, Python, Go, PHP) with TypeScript definitions, pagination helpers, and webhook signature verification, alongside a maintained OpenAPI 3.1 spec (GitHub repo) and Postman collection for generating clients — all documented as first-party, developer-facing tooling suited to AI-native/agentic building workflows. Missing for 10: independent hands-on developer corroboration of SDK quality/DX beyond Paddle's own docs, and the direct openapi.json endpoint probe 404'd (spec is hosted elsewhere per docs, a minor discrepancy).", "evidenceIds": [ "paddle-docs-29", "paddle-docs-23", "paddle-docs-49", "paddle-docs-50", "paddle-supp-openapi-postman", "paddle-docs-25", "paddle-docs-33", "paddle-probe-2" ] }, { "productId": "paddle", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Paddle has robust first-party webhook documentation: real-time push notifications for account events, signature verification via Paddle-Signature header, IP allowlisting guidance, and SDK helpers (Node.js, Python) for verifying webhook signatures. MCP tooling also explicitly supports 'configure webhooks, and simulate events for testing,' making this agent-accessible. Missing for 10: independent/hands-on confirmation of webhook reliability or agent-driven webhook subscription workflows beyond vendor docs.", "evidenceIds": [ "paddle-docs-11", "paddle-docs-12", "paddle-docs-28", "paddle-docs-45", "paddle-docs-49", "paddle-docs-50", "paddle-docs-5", "paddle-supp-mcp-server" ] }, { "productId": "paddle", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle documents an OpenAPI 3.1 spec and an importable Postman collection explicitly framed for interactive exploration/testing ('try the API interactively before writing code', 'explore and test the Paddle Billing API interactively'), which supports runnable-example exploration for AI-native/developer users. However, a probe for a directly hosted interactive reference page (Swagger/Redoc-style) on the docs site returned 404s at common paths, suggesting the 'interactive reference' is delegated to external tools (Postman, Scalar, Redocly) rather than a first-party built-in interactive console. Missing for 10: confirmed first-party hosted interactive API console with live runnable examples, and independent hands-on corroboration of the interactive experience.", "evidenceIds": [ "paddle-docs-24", "paddle-docs-25", "paddle-docs-33", "paddle-supp-openapi-postman", "paddle-probe-2" ] }, { "productId": "paddle", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Paddle publishes an OpenAPI 3.1 spec maintained in a public GitHub repo (github.com/PaddleHQ/paddle-openapi) documented for generating client libraries and editor tooling, plus a Postman collection, giving AI-native users a downloadable machine-readable spec. However, a live probe found the spec not hosted at common guessable URLs on developer.paddle.com itself, so discoverability outside docs pages is imperfect. missing for 10: direct probe confirmation of a working download URL, independent third-party corroboration of the spec's completeness/currency.", "evidenceIds": [ "paddle-docs-25", "paddle-docs-32", "paddle-supp-openapi-postman", "paddle-probe-2" ] }, { "productId": "paddle", "storyId": "api-sandbox", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Paddle documents a dedicated Sandbox environment with fully separate datasets, credentials, dashboards and even a distinct sandbox MCP endpoint/API key prefix, explicitly for building and testing integrations without touching real data or payments — directly serving an AI agent's need to safely test flows. Agent skills and MCP server docs also explicitly reference sandbox testing workflows. Missing for 10: independent/hands-on confirmation that AI agents actually operate correctly against sandbox-mcp.paddle.com in practice (only vendor docs, no third-party corroboration).", "evidenceIds": [ "paddle-docs-26", "paddle-supp-sandbox", "paddle-supp-mcp-server", "paddle-supp-agent-skills" ] }, { "productId": "paddle", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers OpenAPI specs, SDKs, authentication, and a changelog, but nowhere documents an explicit API versioning scheme or a deprecation policy for breaking changes. Missing for 10: documented API version headers/scheme, explicit deprecation/sunset policy, and migration timelines for breaking changes.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "automatic-tax-calculation", "verdict": "disputed", "quality": 6, "confidence": "medium", "rationale": "Paddle's merchant-of-record model is core to its tax story: docs explicitly state Paddle 'calculates, collects, and remits taxes for you' across 200+ countries with no extra engineering, and reconciliation reports break out tax rates/tax mode per transaction for compliance proof. However, a hands-on community report describes phenomenon-level VAT invoice errors (wrong post-Brexit VAT number, then wrong currency amounts) contradicting the 'just works' claim, while another user praises the same EU VAT handling as a key differentiator vs Stripe/Chargebee — a genuine mixed/contradictory record rather than mere skepticism. Missing for 10: independent audits or documented tax-accuracy testing across specific jurisdictions, and resolution/rebuttal of the VAT invoice complaint.", "evidenceIds": [ "paddle-docs-48", "paddle-supp-mor-tax", "paddle-docs-2", "paddle-supp-payout-reconciliation", "paddle-comm-1", "paddle-comm-2" ] }, { "productId": "paddle", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "The MCP 'execute' tool lets an agent chain multiple Paddle API calls in a single invocation, and SDKs offer iterator-based pagination for reading many records, which supports scripted bulk-style workflows for AI agents. However, there is no documented bulk/batch API endpoint (e.g., bulk update prices, bulk refunds) or evidence of handling large-scale operations reliably. Missing for 10: explicit bulk/batch endpoints, evidence of rate-limit handling for large batch jobs, and hands-on proof of bulk operations succeeding at scale.", "evidenceIds": [ "paddle-supp-mcp-codemode", "paddle-docs-49", "paddle-docs-50", "paddle-docs-9" ] }, { "productId": "paddle", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Paddle exposes event-driven webhooks that fire on billing events (paddle-docs-11, paddle-docs-45) and lets users configure some built-in automated behaviors like payment recovery/dunning rules and tactical retries (paddle-supp-dunning, paddle-docs-18), which count as rudimentary 'if event X happens, do Y' automation. However, this is limited to a handful of pre-built scenarios (dunning, webhook delivery) rather than a general-purpose rules engine where an AI-native user can define arbitrary custom triggers/actions; actually triggering an action still requires the developer to write server-side code to consume the webhook. Missing for 10: a native no-code/rules-builder UI for arbitrary event-to-action automation, evidence of user-defined conditional logic beyond dunning settings, and any AI-agent-specific example of autonomously creating such rules.", "evidenceIds": [ "paddle-docs-11", "paddle-docs-45", "paddle-supp-dunning", "paddle-docs-18" ] }, { "productId": "paddle", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Paddle's AI/MCP tooling (paddle-mcp, docs-mcp, agent-skills) lets agents execute one-off actions like billing, refunds, and integration tasks in real time, and its subscriptions themselves are recurring billing cycles, but there is no evidence of a scheduler or cron-like mechanism letting an AI agent set up or manage recurring automated jobs/workflows (e.g., scheduled reports, recurring agent-triggered tasks) beyond subscription billing itself.", "evidenceIds": [ "paddle-supp-mcp-server", "paddle-supp-mcp-codemode", "paddle-docs-16", "paddle-docs-35" ] }, { "productId": "paddle", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Paddle is a billing/payments infrastructure platform with AI-agent integrations (MCP, skills) for executing billing actions, not a workflow/automation-builder product with a concept of versioned 'automations' that can be reviewed or rolled back — this axis is a category mismatch for Paddle's product type.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "dunning-failed-payment-recovery", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Paddle's docs explicitly describe built-in dunning: failed payments are automatically retried up to seven times over 30 days, and Paddle Retain's Payment Recovery adds configurable Tactical Retries, optimized recovery email notifications, and in-app retry forms, plus control over past-due subscription outcomes. missing for 10: independent/hands-on evidence of recovery-email effectiveness or customer testimonials, and the pack notes Retain can't be tested in sandbox, limiting pre-production verification.", "evidenceIds": [ "paddle-docs-18", "paddle-supp-dunning" ] }, { "productId": "paddle", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Paddle documents both Inline checkout (embed checkout and totals fully within your own UI/interface) and Overlay checkout, explicitly positioned as alternatives to a hosted redirect page, backed by Paddle.js and localized pricing components. missing for 10: independent/hands-on developer corroboration of embedding customization depth, and no visual/styling API detail beyond docs claims.", "evidenceIds": [ "paddle-docs-13", "paddle-docs-14", "paddle-docs-1", "paddle-docs-2" ] }, { "productId": "paddle", "storyId": "fraud-screening-rules", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence only mentions Paddle's merchant-of-record fee covering generic 'fraud protection' and 'chargeback defense' as a bundled service, with no documentation of ML-generated fraud scores or of any UI/API for finance-ops to write custom block/review/allow rules. This axis is fair for a payments platform, but no capability is evidenced.", "evidenceIds": [ "paddle-supp-mor-tax" ] }, { "productId": "paddle", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Paddle explicitly documents overlay checkout ('present customers with an overlay that handles all parts of the checkout process — minimal frontend coding required') and Paddle.js checkout integration, which is vendor-hosted and conversion-optimized without building a custom payment UI. This is corroborated by supporting docs on inline vs overlay checkout options and sandbox testing. Missing for 10: independent hands-on developer reports validating conversion optimization or checkout UX quality beyond vendor docs.", "evidenceIds": [ "paddle-docs-1", "paddle-docs-14", "paddle-docs-13", "paddle-docs-26" ] }, { "productId": "paddle", "storyId": "idempotent-api-retries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions idempotency keys or any mechanism for safely retrying API requests without duplicate charges; the API auth/rate-limit docs cover bearer tokens, permissions, and key rotation but nothing about idempotency handling.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "integrate-from-docs-in-a-day", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Paddle's docs include multiple checkout integration paths (inline/overlay), official SDKs for Node.js, Python, Go and PHP with copy-paste style code and TypeScript support, a sandbox for testing without real payments, and a production-ready Next.js SaaS starter kit that yields 'a working three-tier subscription app' with Paddle checkout and webhooks — directly matching the 'working payment flow in under a day' story across languages. missing for 10: independent/hands-on third-party confirmation of the 'under a day' timeframe and broader language coverage beyond the four official SDKs.", "evidenceIds": [ "paddle-docs-13", "paddle-docs-14", "paddle-docs-23", "paddle-docs-29", "paddle-docs-49", "paddle-docs-50", "paddle-docs-51", "paddle-docs-60", "paddle-docs-26" ] }, { "productId": "paddle", "storyId": "marketplace-split-payments", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack describes Paddle purely as a merchant-of-record billing/subscription platform for a single seller (checkout, subscriptions, invoices, payouts to the seller's own account, tax compliance) — there is no mention of onboarding multiple third-party sellers, split payments between parties, or marketplace payout distribution akin to Stripe Connect. Nothing in the docs, MCP tooling, or SDKs addresses multi-party marketplace flows.", "evidenceIds": [ "paddle-docs-20", "paddle-docs-38", "paddle-docs-48", "paddle-supp-mor-tax", "paddle-supp-payout-reconciliation" ] }, { "productId": "paddle", "storyId": "multi-currency-charge-settle", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Paddle explicitly documents built-in multi-currency support for both payments and payouts ('customers purchase in their local currency and letting you get paid in yours'), plus localized pricing pages, 200+ country/currency support, and payout reconciliation reports that break down amounts in both transaction and balance currencies for transparency. As merchant of record, Paddle also handles tax compliance alongside FX, directly matching the story. Missing for 10: no explicit documentation of FX conversion rates/margins used, and no independent/hands-on corroboration of settlement transparency beyond vendor docs.", "evidenceIds": [ "paddle-docs-20", "paddle-docs-21", "paddle-docs-2", "paddle-supp-payout-reconciliation", "paddle-supp-mor-tax", "paddle-docs-59" ] }, { "productId": "paddle", "storyId": "no-code-payment-links", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Paddle's evidence centers on developer-integrated checkout (Paddle.js overlay/inline checkout embedded in a website or app) and dashboard-created transactions for internal use, but there is no evidence of a standalone, no-code 'shareable payment link' a founder could generate and immediately distribute (e.g., via email or social media) without any integration work. The closest hints — overlay checkout needing 'minimal frontend coding' and dashboard-created transactions — still imply some setup/integration rather than a pure link-generation flow.", "evidenceIds": [ "paddle-docs-13", "paddle-docs-14", "paddle-docs-15", "paddle-docs-46" ] }, { "productId": "paddle", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle's docs show broad API coverage for most UI-surfaced flows — checkout, transactions, subscriptions (pause/upgrade), invoices, webhooks, reports, customer portal — plus MCP/agent-skill tooling that lets agents perform catalog, billing, and integration tasks end-to-end (paddle-docs-3, paddle-docs-15-19, paddle-supp-mcp-server, paddle-supp-agent-skills). However, the pack also documents explicit exceptions, e.g. Paddle Retain's dunning/payment-recovery features 'work with live data... you can't integrate or test with sandbox accounts' (paddle-supp-dunning), showing at least one dashboard-configurable feature not fully API/sandbox-equivalent, and there's no blanket claim or independent audit confirming total UI/API parity. missing for 10: an explicit vendor or third-party statement of full UI-API feature parity, and confirmation that Retain-style dashboard-only configurations have API equivalents.", "evidenceIds": [ "paddle-docs-15", "paddle-docs-3", "paddle-docs-17", "paddle-docs-19", "paddle-supp-mcp-server", "paddle-supp-agent-skills", "paddle-supp-dunning" ] }, { "productId": "paddle", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Paddle documents reports/reconciliation exports and an OpenAPI spec for building integrations, but there is no evidence of a customer-facing 'export all my account/business data in an open format to leave' capability — no GDPR-style data export, no full account data dump, nothing enabling migration away from Paddle with your data intact. Community comments even raise concerns about Paddle's control over customer data rather than showing an exit/export path.", "evidenceIds": [ "paddle-docs-19", "paddle-supp-payout-reconciliation", "paddle-comm-3", "paddle-comm-4" ] }, { "productId": "paddle", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Paddle is a payments/billing SaaS product, not open-source software; the axis of reading source code under an open license is a category error for this kind of product (the OpenAPI spec repo is API documentation, not the product's own source).", "evidenceIds": [] }, { "productId": "paddle", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Paddle is a hosted merchant-of-record payments/billing SaaS (handling tax remittance, compliance, and payment processing as the seller of record); self-hosting the core product is a category error since it inherently requires Paddle to act as the regulated merchant of record — no evidence pack for a SaaS-of-this-kind would offer this.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle provides detailed payout reconciliation reports that itemize gross, taxes, Paddle fees, chargebacks, and retained fees per payout, in both transaction and balance currencies, split by invoice entity — directly matching the 'see exactly which charges/fees/refunds' half of the story. However, no evidence describes finance-ops controlling or configuring the payout schedule itself (frequency, timing, thresholds). Missing for 10: documentation of payout schedule/frequency configuration, independent/hands-on confirmation of reconciliation report accuracy.", "evidenceIds": [ "paddle-supp-payout-reconciliation", "paddle-docs-19", "paddle-docs-37", "paddle-docs-70" ] }, { "productId": "paddle", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle's checkout products (overlay and inline via Paddle.js) handle card capture directly, and as merchant of record Paddle also handles tax/compliance — this strongly implies card data never touches the developer's servers, which is the basis for reduced PCI scope. However, the evidence pack never explicitly states PCI DSS compliance or scope reduction, or names a SAQ level, so the compliance-specific claim is inferred rather than documented.\n\nmissing for 10: explicit PCI DSS compliance/certification statement, explicit scope-reduction language, and independent/third-party confirmation of PCI posture.", "evidenceIds": [ "paddle-docs-13", "paddle-docs-14", "paddle-docs-1", "paddle-supp-mor-tax", "paddle-docs-27" ] }, { "productId": "paddle", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence addresses data residency or region-specific storage choices for Paddle accounts/customers; the pack covers billing, checkout, tax compliance, and AI/MCP tooling but never data residency or regional storage options. Missing for 10: any mention of data center regions, data residency guarantees, or ability to select storage location.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of Paddle's data-usage policies for AI model training, opt-out controls, or any privacy commitments specific to AI training — it covers only checkout, billing, webhooks, MCP/agent tooling, and API auth. Since a billing/SaaS platform handling customer data could plausibly publish such a policy, the axis applies, but there is no evidence Paddle addresses it.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains extensive docs on billing, checkout, webhooks, API auth, and AI/MCP integrations, but nothing about data retention policies, customer data deletion/export controls, or GDPR-style right-to-be-forgotten mechanisms. Community comments even raise unresolved privacy concerns about Paddle's access to customer data (paddle-comm-3, paddle-comm-4) without any documented deletion/retention controls to address them.", "evidenceIds": [ "paddle-comm-3", "paddle-comm-4" ] }, { "productId": "paddle", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of telemetry or usage-tracking collection by Paddle's SDKs, MCP servers, or dashboard, nor any opt-out mechanism. Community items about customer data/spam concerns (paddle-comm-3, paddle-comm-4) relate to end-customer marketing data, not AI-agent telemetry, so they don't establish or contradict this capability.", "evidenceIds": [] }, { "productId": "paddle", "storyId": "recurring-subscription-billing", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Paddle's docs comprehensively cover setting up subscription checkouts, plans/prices, pausing subscriptions, and upgrading/downgrading (including changing base plan and billing frequency) via replacing products/prices, plus sales-assisted invoicing and dunning for failed payments — a solid recurring-billing foundation. missing for 10: explicit documentation of free-trial period setup and how proration is calculated/applied on plan changes (evidence only implies plan-change mechanics without naming proration).", "evidenceIds": [ "paddle-docs-1", "paddle-docs-3", "paddle-docs-16", "paddle-docs-35", "paddle-docs-47", "paddle-docs-52", "paddle-docs-18", "paddle-docs-17" ] }, { "productId": "paddle", "storyId": "refunds-full-partial", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Refunds are mentioned only indirectly, e.g. AI/MCP docs say agents can 'process customer refunds' and MCP can 'analyze revenue, refunds, and transaction patterns,' implying refund capability exists in the underlying API, but no dedicated dashboard or API documentation on issuing full/partial refunds is present in the evidence pack. missing for 10: explicit API endpoint or dashboard walkthrough for issuing refunds, confirmation of partial-refund support, and independent/hands-on evidence of refund flow working.", "evidenceIds": [ "paddle-docs-30", "paddle-docs-57", "paddle-supp-mcp-server", "paddle-docs-65" ] }, { "productId": "paddle", "storyId": "respond-to-disputes-evidence", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows chargebacks appearing as a fee line-item in payout reconciliation reports and a passing mention that Paddle's merchant-of-record fee includes 'chargeback defense,' but there is no documentation of a finance-ops workflow for submitting structured dispute evidence or tracking a chargeback's lifecycle to resolution.", "evidenceIds": [ "paddle-supp-mor-tax", "paddle-supp-payout-reconciliation" ] }, { "productId": "paddle", "storyId": "sandbox-test-mode-fidelity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle documents a full Sandbox environment that mirrors production (\"same features and APIs but completely separate datasets, credentials, and dashboards\") with sandbox-specific API keys, and the MCP tooling explicitly supports simulating webhook events for testing. However, the evidence pack contains no documentation of specific test card numbers for scenario coverage (e.g., decline codes, dispute/chargeback simulation), and notes that Paddle Retain's dunning/payment-recovery features explicitly cannot be tested in sandbox ('you can't integrate or test with sandbox accounts'), which undercuts full parity for testing the entire payment flow. missing for 10: documented test-card list for various decline/failure scenarios, explicit dispute/chargeback simulation support, and confirmation that all payment-flow features (including Retain) are testable in sandbox.", "evidenceIds": [ "paddle-docs-26", "paddle-supp-sandbox", "paddle-docs-5", "paddle-supp-dunning" ] }, { "productId": "paddle", "storyId": "send-hosted-invoices", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle documents sales-assisted invoicing where a team can 'draft and send invoices for subscriptions, collecting payment manually rather than by charging a card on file' (paddle-docs-17/36), and Paddle automatically creates a subscription once an invoice is issued (paddle-docs-69), implying an online payment path. However, the 'automatic reminders' portion of the story is not clearly evidenced for invoices specifically — the documented dunning/Payment Recovery and Tactical Retries feature (paddle-docs-18, paddle-supp-dunning) applies to failed automatic subscription charges, not to reminders for outstanding hosted invoices. Missing for 10: explicit documentation of automated invoice reminder emails/schedules, and independent/hands-on confirmation that invoice payment links and reminders work as described.", "evidenceIds": [ "paddle-docs-17", "paddle-docs-36", "paddle-docs-69", "paddle-docs-18", "paddle-supp-dunning" ] }, { "productId": "paddle", "storyId": "settlement-reconciliation-reports", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Paddle publishes dedicated payout reconciliation documentation describing itemized breakdowns of gross, taxes, fees, chargebacks and retained fees split by transaction/balance currency, invoice entity, and even US state/ZIP, explicitly framed as reconciling payouts to remittance advice/bank deposits, plus an API to feed accounting/BI systems for monthly reconciliation. missing for 10: independent/hands-on customer confirmation that the reports actually match bank deposits in practice, and no detail on report formats/exports beyond API generation.", "evidenceIds": [ "paddle-supp-payout-reconciliation", "paddle-docs-19", "paddle-docs-37", "paddle-docs-70", "paddle-docs-20" ] }, { "productId": "paddle", "storyId": "wallets-local-payment-methods", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence confirms Paddle's broad multi-currency and 200+-country reach, and a specific local payment method (Pix recurring mandate for Brazil) was added, showing the platform does add local payment methods over time. However, there is no explicit documentation of Apple Pay, Google Pay, bank redirects, or BNPL options being available through the same checkout integration. missing for 10: explicit mention/docs of Apple Pay, Google Pay, bank redirect methods, and BNPL support in checkout.", "evidenceIds": [ "paddle-docs-54", "paddle-docs-20", "paddle-docs-21", "paddle-docs-38" ] }, { "productId": "paddle", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Paddle documents signed webhooks (Paddle-Signature header + secret-key verification), IP allowlisting guidance, and automatic retries for failed payments/dunning (up to 7 retries over 30 days, Tactical Retries via Retain), plus SDK helpers for signature verification. However, there is no documented event log/dashboard for webhook delivery history, no explicit replay/resend mechanism for missed webhook events, and no mention of delivery guarantees or dead-letter handling. missing for 10: webhook event log/delivery history UI, explicit event replay/resend capability, delivery guarantee/idempotency documentation, independent hands-on confirmation of retry behavior.", "evidenceIds": [ "paddle-docs-11", "paddle-docs-12", "paddle-docs-28", "paddle-docs-45", "paddle-supp-dunning", "paddle-docs-49", "paddle-docs-50" ] }, { "productId": "paypal", "storyId": "accept-card-payment-online", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PayPal explicitly markets no-code, fast paths to accept card payments — Payment Links ('swiftly create... no coding skills required'), PayPal Checkout buttons, and card field support — alongside sandbox testing and REST APIs for those wanting custom integration, all consistent with a founder starting to accept card payments quickly after signup. No independent hands-on report confirms the exact 'within a day' timeline, and community threads flag post-signup fund holds/verification friction that could affect real-world speed, though none concretely refute the initial-setup speed claim. Missing for 10: independent/hands-on confirmation of same-day account approval and first live transaction, and documentation of KYC/verification turnaround times.", "evidenceIds": [ "paypal-docs-31", "paypal-docs-29", "paypal-docs-37", "paypal-docs-11", "paypal-docs-30", "paypal-comm-8" ] }, { "productId": "paypal", "storyId": "agent-handles-dispute-end-to-end", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's Disputes API and agent-toolkit both document dispute-related tools (list_disputes, get_dispute, accept_dispute_claim) accessible via API/agent frameworks, enabling an agent to retrieve and act on disputes programmatically. However, evidence shows only 'accept_dispute_claim' (resolving in favor of the buyer) as a documented action tool — there's no evidence of a tool for assembling/submitting counter-evidence or contesting a dispute (e.g., uploading evidence documents, filing a merchant-side response) end-to-end via the agent toolkit or MCP. missing for 10: a documented tool/endpoint for submitting evidence or contesting a dispute (not just accepting it), end-to-end automated evidence-assembly workflow, and independent/hands-on confirmation that an agent can fully close the loop on a contested dispute.", "evidenceIds": [ "paypal-docs-7", "paypal-docs-26", "paypal-supp-agent-tools-inventory", "paypal-gh-2", "paypal-docs-64" ] }, { "productId": "paypal", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's subscriptions API documents 'Automate payment recovery for failed payments' (dunning) and webhooks can notify apps of billing failures, and the agent-toolkit/MCP tools expose subscription and invoice management functions an agent could call. However, there's no documented dedicated 'failed payment' webhook-driven retry workflow guide, no specific dunning/outreach tooling in the agent-tools inventory (only generic subscription create/update/cancel), and no evidence of an agent specifically monitoring failed payments end-to-end. missing for 10: explicit failed-payment webhook event documentation, a dedicated retry/dunning API or agent tool, and a concrete example of an agent autonomously handling failed payment recovery.", "evidenceIds": [ "paypal-docs-40", "paypal-docs-57", "paypal-docs-9", "paypal-docs-28", "paypal-supp-agent-tools-inventory", "paypal-gh-1" ] }, { "productId": "paypal", "storyId": "agent-provisions-payment-link", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal's agent-toolkit/MCP tool inventory explicitly includes create_product, and subscription/plan creation tools (create plan, create_order/pay_order) plus payment-link style checkout order creation, all callable via API/function-calling in one agent session with sandbox testing supported. missing for 10: no single documented end-to-end walkthrough showing product+price+payment-link created in one session, and no independent/hands-on report confirming this exact multi-step flow works in practice.", "evidenceIds": [ "paypal-supp-agent-tools-inventory", "paypal-docs-45", "paypal-docs-59", "paypal-supp-toolkit-frameworks", "paypal-docs-20", "paypal-docs-31", "paypal-gh-2" ] }, { "productId": "paypal", "storyId": "agent-reconciles-payouts", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's REST API and agent-toolkit expose transaction/reporting data (list_transaction, get_merchant_insights) and payouts (Payouts API), and the agent-toolkit explicitly advertises access to 'transaction details' for AI agents via function calling, which supports an agent pulling data programmatically. However, there is no evidence of a dedicated payout-item/balance-transaction endpoint or tool that maps bank deposits to underlying charges (no reconciliation-specific tool, no balance-transaction-to-deposit linkage documented). missing for 10: explicit Payouts/Balance-transaction reconciliation API or MCP tool, documented deposit-to-charge matching logic, and independent/hands-on evidence of an agent performing this reconciliation successfully.", "evidenceIds": [ "paypal-docs-5", "paypal-docs-24", "paypal-supp-agent-tools-inventory", "paypal-supp-insights-tool", "paypal-docs-64", "paypal-gh-2" ] }, { "productId": "paypal", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Direct probe confirms a live llms.txt at developer.paypal.com/llms.txt (HTTP 200) plus .md-suffixed docs pages (e.g., api/rest.md) that agents can fetch directly, exactly matching the agent-oriented docs pattern. This is corroborated by extensive first-party agent tooling (MCP server, agent toolkit) showing PayPal actively supports agent-native consumption of its docs/APIs. Missing for 10: no independent/community verification of an agent actually using llms.txt in practice.", "evidenceIds": [ "paypal-probe-1", "paypal-probe-2", "paypal-docs-10" ] }, { "productId": "paypal", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "PayPal's agent toolkit exposes a `get_merchant_insights` tool that retrieves 'business intelligence metrics and analytics for a merchant' filtered by date/type/interval, which could power AI-generated insights — but this is a data-retrieval function for external AI agents to call via the toolkit/MCP, not a native in-product AI feature that surfaces insights or suggestions directly inside PayPal's own dashboard to end users. Missing for 10: evidence of a first-party AI assistant embedded in PayPal's UI/dashboard that proactively generates insights or suggestions, and independent/hands-on confirmation of such a feature in use.", "evidenceIds": [ "paypal-supp-insights-tool", "paypal-supp-agent-tools-inventory", "paypal-docs-64" ] }, { "productId": "paypal", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "PayPal ships several building blocks for background automation: webhooks that fire automatically on events, subscriptions with autonomous recurring billing and automated failed-payment recovery, batch payouts, an automatable Disputes API, and an Agent Toolkit/MCP server that lets developers build AI agents to execute payment workflows (create orders, invoices, subscriptions, refunds) via function calling. However, these are separate mechanisms rather than a unified 'set up an automation that runs autonomously in the background' feature, and there's no evidence of PayPal hosting persistent scheduled/cron-style agent tasks — the agent toolkit requires the user's own agent runtime to invoke tools. Missing for 10: a dedicated scheduling/trigger-based automation builder, evidence of PayPal-hosted persistent agent execution, and independent/hands-on confirmation that autonomous background workflows actually run unattended.", "evidenceIds": [ "paypal-docs-9", "paypal-docs-28", "paypal-docs-40", "paypal-docs-24", "paypal-docs-26", "paypal-gh-1", "paypal-gh-2", "paypal-docs-43", "paypal-docs-44", "paypal-supp-agent-tools-inventory", "paypal-supp-toolkit-frameworks", "paypal-supp-remote-mcp" ] }, { "productId": "paypal", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The story asks for a built-in AI assistant inside the PayPal product itself that an end-user can delegate tasks to (e.g., 'pay this invoice', 'check my balance' via a native PayPal chat assistant). All AI-related evidence describes the reverse: PayPal exposing an MCP server/agent toolkit so *external* AI agents (Claude, ChatGPT, LangChain, etc.) can call PayPal's APIs, or enabling other platforms' shopping assistants (ChatGPT, Gemini) to check out via PayPal/Braintree. There is no evidence of a native, built-in assistant surfaced inside the PayPal app/website that a user converses with to delegate PayPal tasks. Missing for 10: any documented in-product PayPal assistant/chatbot for end-users, evidence of natural-language task delegation within the PayPal UI itself, and confirmation this isn't just developer-facing agent tooling.", "evidenceIds": [ "paypal-docs-10", "paypal-docs-43", "paypal-docs-44", "paypal-supp-remote-mcp", "paypal-supp-agentic-commerce-services" ] }, { "productId": "paypal", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PayPal's core developer experience is API-first: OAuth client-credentials tokens authenticate calls without a UI, REST APIs cover orders/payments/subscriptions/invoicing/payouts, webhooks provide event-driven automation, and a sandbox environment exists for automated testing — all of which support headless/CI usage. missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions integration), and independent hands-on confirmation of running PayPal API calls in a CI environment.", "evidenceIds": [ "paypal-docs-1", "paypal-docs-18", "paypal-docs-54", "paypal-docs-9", "paypal-docs-28", "paypal-docs-11", "paypal-gh-1" ] }, { "productId": "paypal", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal's AI evidence is entirely about PayPal exposing itself AS an MCP server/tool-provider (paypal-docs-10, paypal-supp-remote-mcp, paypal-gh-1/2) and building agent-toolkit integrations so other agents can call PayPal's APIs — not about PayPal itself acting as an MCP client that plugs in and consumes external MCP servers' tools. PayPal is a payments platform, not an AI-native agent/client product, so the 'plug MCP servers into this product' client-role story is a category mismatch for it.", "evidenceIds": [ "paypal-docs-10", "paypal-supp-remote-mcp", "paypal-gh-1", "paypal-gh-2", "paypal-docs-44" ] }, { "productId": "paypal", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal ships a well-documented official MCP server in both local (npx @paypal/mcp) and remote hosted forms (mcp.sandbox.paypal.com / mcp.paypal.com) with SSE and Streamable HTTP transports, OAuth-based auth, and a broad tool inventory (orders, invoices, subscriptions, disputes, catalog, insights) usable from any MCP client; docs also confirm support for Anthropic/OpenAI LLMs. Missing for 10: independent/community hands-on validation of the MCP server itself (only vendor docs cited).", "evidenceIds": [ "paypal-docs-10", "paypal-supp-remote-mcp", "paypal-supp-agent-tools-inventory", "paypal-supp-toolkit-frameworks", "paypal-supp-llm-support", "paypal-docs-44", "paypal-probe-3" ] }, { "productId": "paypal", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal ships an official MCP server (local and remote) plus an Agent Toolkit supporting multiple agent frameworks, letting users/agents issue natural-language commands to create orders, invoices, subscriptions, refunds, and get merchant insights, and also supports agentic commerce protocols (ACP/UCP) for conversational checkout. missing for 10: independent/hands-on user reports confirming reliability of natural-language command execution, and some commerce tools are gated behind access requests or feature flags (gift-cards-only, limited to US physical goods).", "evidenceIds": [ "paypal-docs-10", "paypal-gh-1", "paypal-gh-2", "paypal-supp-remote-mcp", "paypal-supp-agent-tools-inventory", "paypal-supp-toolkit-frameworks", "paypal-supp-llm-support", "paypal-supp-agentic-commerce-services", "paypal-supp-store-sync", "paypal-docs-46" ] }, { "productId": "paypal", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers PayPal's REST APIs, SDKs, MCP server, and agent toolkit, but no official CLI tool is mentioned anywhere in the docs or GitHub references. Missing for 10: any documented PayPal CLI, command-line tool, or terminal-based interface for developers/agents.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal has extensive, well-documented public REST APIs (OAuth token exchange, checkout, subscriptions, invoicing, payouts, disputes, webhooks) plus an OpenAPI spec/codegen tooling and a sandbox environment, all directly consumable by an AI-native user or agent. It also ships an official MCP server (local and remote), an agent toolkit for LangChain/CrewAI/OpenAI Agents SDK/Bedrock, and documented agentic commerce protocols (ACP/UCP), showing the API is explicitly built for agent-driven use. Missing for 10: independent/third-party developer corroboration of API reliability or friction beyond PayPal's own docs.", "evidenceIds": [ "paypal-docs-1", "paypal-docs-54", "paypal-docs-11", "paypal-docs-9", "paypal-gh-1", "paypal-supp-remote-mcp", "paypal-supp-agent-tools-inventory", "paypal-supp-toolkit-frameworks", "paypal-supp-agent-ready-protocols" ] }, { "productId": "paypal", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only standard OAuth client-credentials token exchange (client ID/secret → access token) and general agent-toolkit/MCP integration, but nothing documenting scoped, restricted, or least-privilege credential issuance specifically for agent use (e.g., limited-permission API keys, granular scopes, or per-agent restricted tokens).", "evidenceIds": [ "paypal-docs-1", "paypal-docs-18", "paypal-supp-remote-mcp", "paypal-supp-llm-support" ] }, { "productId": "paypal", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal ships official REST API SDKs, OpenAPI specs with codegen, and a dedicated open-source Agent Toolkit (GitHub) supporting LangChain, OpenAI Agents SDK, CrewAI, Vercel AI SDK, Bedrock, and MCP for building AI-native payment workflows, backed by sandbox testing and detailed tool docs. Missing for 10: independent/hands-on developer corroboration of SDK quality beyond first-party docs and GitHub README.", "evidenceIds": [ "paypal-gh-1", "paypal-gh-2", "paypal-docs-44", "paypal-supp-toolkit-frameworks", "paypal-supp-agent-tools-inventory", "paypal-docs-54", "paypal-docs-11", "paypal-docs-16" ] }, { "productId": "paypal", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal's REST API documents webhooks as HTTPS posts to a subscribed endpoint whenever a specified event occurs, with a clear subscription setup flow (paypal-docs-9, paypal-docs-28). This is a standard developer-facing capability well documented for programmatic/agentic integration. Missing for 10: no independent/hands-on corroboration of webhook reliability or delivery guarantees, and no explicit mention of AI-agent-specific webhook consumption patterns.", "evidenceIds": [ "paypal-docs-9", "paypal-docs-28" ] }, { "productId": "paypal", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's docs let you generate client code and import OpenAPI specs, and Braintree's GraphQL developer hub explicitly offers 'an in-browser API Explorer for testing queries' with runnable example integrations — concrete evidence of an interactive, runnable API reference for at least one product line. However, no evidence shows an equivalent try-it-now/runnable console for the core PayPal REST APIs (orders, checkout, subscriptions, etc.) themselves. Missing for 10: in-browser runnable examples for the main REST API reference, independent/hands-on confirmation of the interactive experience quality.", "evidenceIds": [ "paypal-docs-54", "paypal-docs-16", "paypal-supp-braintree-graphql" ] }, { "productId": "paypal", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal explicitly documents downloadable/importable OpenAPI specs: 'Explore our REST API descriptions, generate code for your API clients, and import OpenAPI documents into compatible third-party tools' and provides a GitHub repo (paypal-rest-api-specifications) with actual OpenAPI JSON files used for codegen. Missing for 10: no independent third-party confirmation of spec completeness/versioning outside PayPal's own repo.", "evidenceIds": [ "paypal-docs-54", "paypal-docs-16" ] }, { "productId": "paypal", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal documents a dedicated sandbox as 'a self-contained, virtual testing environment that simulates the live PayPal production environment' (paypal-docs-11), and the agent toolkit explicitly instructs AI-native builders to 'Always use the sandbox environment for initial testing to avoid real transactions' (paypal-supp-toolkit-frameworks), with both local and remote MCP servers supporting PAYPAL_ENVIRONMENT=SANDBOX and a distinct sandbox endpoint (mcp.sandbox.paypal.com) separate from production (paypal-supp-remote-mcp). missing for 10: independent/hands-on confirmation that sandbox behavior fully mirrors production for agentic/AI workflows, and more detail on how sandbox data isolation is verified beyond vendor docs.", "evidenceIds": [ "paypal-docs-11", "paypal-supp-toolkit-frameworks", "paypal-supp-remote-mcp", "paypal-docs-44" ] }, { "productId": "paypal", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows PayPal APIs use version numbers (e.g., 'checkout_orders_v2.json') and OpenAPI specs, but no evidence pack item documents a formal deprecation policy, sunset timeline, or versioning support commitment that an AI-native integrator could rely on.", "evidenceIds": [ "paypal-docs-16" ] }, { "productId": "paypal", "storyId": "automatic-tax-calculation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers currency codes, checkout, invoicing, subscriptions, payouts, disputes, and AI/agent tooling, but contains no mention of automated sales tax, VAT, or GST calculation/collection engines or tax-rate rules per jurisdiction. This is a fair capability to expect from a payments platform serving finance-ops, but no evidence shows PayPal delivers it.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's Payouts API explicitly supports true bulk operations — sending money to 'thousands of recipients at once' via email, phone, or PayPal ID in a single batch call — which is a strong general REST-API bulk capability accessible to automation. However, the AI-agent-specific surface (MCP server / Agent Toolkit tool inventory) exposes only single-item tools (create_order, get_invoice, list_transaction, etc.) with no documented batch/bulk tool for an AI agent to invoke across many items at once. Missing for 10: an AI-native (MCP/agent-toolkit) tool that explicitly performs bulk/batch actions, and any hands-on evidence of an agent successfully driving the Payouts batch API end-to-end.", "evidenceIds": [ "paypal-docs-5", "paypal-docs-24", "paypal-docs-41", "paypal-docs-58", "paypal-supp-agent-tools-inventory" ] }, { "productId": "paypal", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "PayPal exposes webhooks that fire on transaction/dispute/subscription events (paypal-docs-9, paypal-docs-28) and has some built-in automated behaviors like automated payment recovery for failed subscriptions (paypal-docs-40) and a Disputes API for automating dispute actions (paypal-docs-26), which together give developers the raw event/trigger primitives needed to build 'if event then action' automation. However, there is no evidence of a declarative rules interface where an AI-native user defines conditions and actions without writing custom server-side handling code — webhooks require the developer to build the listener and action logic themselves. Missing for 10: a no-code/low-code rule-definition UI or API, support for arbitrary conditional logic across events, and evidence that AI agents can create/manage such rules via the MCP/agent toolkit (which only exposes discrete action tools, not rule/trigger definitions).", "evidenceIds": [ "paypal-docs-9", "paypal-docs-28", "paypal-docs-26", "paypal-docs-40", "paypal-supp-agent-tools-inventory" ] }, { "productId": "paypal", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's Subscriptions API lets merchants (and, via the documented agent-toolkit, AI agents) create/update/cancel recurring billing plans with fixed intervals, trials, and automated payment recovery, which is a form of 'recurring job' automation exposed to AI-native tooling. However this is scoped strictly to billing/payment cycles, not a general-purpose scheduler for arbitrary recurring workflows or tasks that an AI agent could set up and manage. Missing for 10: a generic workflow/job scheduling primitive (e.g., cron-like triggers, scheduled webhooks, or task orchestration) beyond subscription billing, and independent evidence of AI agents actually using this to schedule non-payment workflows.", "evidenceIds": [ "paypal-docs-20", "paypal-docs-40", "paypal-docs-57", "paypal-supp-agent-tools-inventory", "paypal-docs-64" ] }, { "productId": "paypal", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal is a payments platform, not an automation/workflow builder; there is no concept of versioning, reviewing, or rolling back 'automations' (e.g., agent workflows or scripted rules) in its evidence. This story applies to workflow/automation orchestration tools, not to a payments API/MCP provider.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "dunning-failed-payment-recovery", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal's Subscriptions docs explicitly list 'Automate payment recovery for failed payments' as a built-in capability, directly matching the dunning/retry story, but the evidence is a single bullet point with no detail on retry schedules, dunning logic, or recovery email customization/branding. Invoicing docs also mention 'automatic payment reminders' but that's for invoices, not subscription dunning specifically.\n\nmissing for 10: detailed documentation of retry cadence/logic, evidence of customizable recovery email templates, and independent/hands-on confirmation that dunning actually reduces churn.", "evidenceIds": [ "paypal-docs-40", "paypal-docs-57", "paypal-docs-50" ] }, { "productId": "paypal", "storyId": "embedded-checkout-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal Checkout docs confirm embeddable buttons and card fields ('card field customization with your business branding') plus server-side endpoints for refunds/voids/captures, allowing developers to embed payment UI without full redirect to a hosted PayPal page. However, evidence leans heavily on button/card-field embedding rather than deep low-level UI customization (e.g., fully styled custom checkout forms), and PayPal's classic checkout flow still often redirects/pops up an approval window rather than a fully inline, brandless flow. missing for 10: detailed documentation on styling/theming APIs for embedded components, independent/hands-on confirmation that redirect can be fully eliminated, and clarity on which products (Checkout vs Braintree) offer the most customizable embedded UI.", "evidenceIds": [ "paypal-docs-2", "paypal-docs-37", "paypal-docs-27", "paypal-docs-19", "paypal-docs-38", "paypal-docs-39", "paypal-docs-30" ] }, { "productId": "paypal", "storyId": "fraud-screening-rules", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers disputes handling (Resolution Center, Disputes API) and general risk/compliance mentions, but there is no documentation of ML-based fraud scoring or a rules engine for finance-ops to write custom block/review/allow rules. Missing for 10: any mention of fraud risk scores, a rules/policy engine, or finance-ops configurable block/review/allow controls.", "evidenceIds": [ "paypal-docs-6", "paypal-docs-7", "paypal-docs-25", "paypal-docs-26" ] }, { "productId": "paypal", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal Checkout provides a hosted PayPal button/payment page where customers pay via their PayPal-linked funding sources, and Invoicing explicitly offers 'a secure PayPal payment page, without building their own payment flow' — both are vendor-hosted, conversion-optimized checkout surfaces requiring only redirect/embed integration plus server-side endpoints for capture/void/refund. Missing for 10: no independent conversion-rate benchmarking or hands-on developer review confirming the 'conversion-optimized' claim beyond PayPal's own marketing copy.", "evidenceIds": [ "paypal-docs-2", "paypal-docs-37", "paypal-docs-19", "paypal-docs-22", "paypal-docs-30", "paypal-docs-38", "paypal-docs-39" ] }, { "productId": "paypal", "storyId": "idempotent-api-retries", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item mentions idempotency keys, PayPal-Request-Id header, or any mechanism for safely retrying API requests to prevent duplicate charges, despite extensive docs on REST API auth, checkout, webhooks, and MCP tools.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "integrate-from-docs-in-a-day", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal's dev docs cover the core building blocks needed for a checkout integration—OAuth token exchange, the Checkout REST flow, webhooks, and a sandbox test environment—plus a mention of generating client code for multiple languages and per-language SDK codegen (Java example shown). However, the evidence pack doesn't show concrete copy-paste code samples in multiple languages (e.g., Node/PHP/Python snippets) nor any independent confirmation that a developer can go from zero to working payment flow in under a day. missing for 10: multi-language copy-paste code snippets, independent time-to-integrate validation, end-to-end quickstart walkthrough evidence.", "evidenceIds": [ "paypal-docs-1", "paypal-docs-2", "paypal-docs-9", "paypal-docs-11", "paypal-docs-54", "paypal-docs-16", "paypal-docs-19" ] }, { "productId": "paypal", "storyId": "marketplace-split-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal's Complete Payments Platform explicitly targets marketplaces/platforms with seller onboarding under local regulations, expanded checkout, and multiparty payment processing (paypal-docs-8, paypal-docs-42, paypal-docs-27), while Payouts supports splitting/sending funds to thousands of recipients via email/phone/PayPal ID in various currencies (paypal-docs-5, paypal-docs-24, paypal-docs-41), and REST auth/webhooks/sandbox round out the developer integration story (paypal-docs-1, paypal-docs-9, paypal-docs-11). missing for 10: no explicit hands-on/independent case study of a full marketplace build (onboarding+split+payout) working end-to-end, and details on partner/seller onboarding flows (e.g., Partner Referrals API specifics) are only briefly summarized rather than deeply documented.", "evidenceIds": [ "paypal-docs-8", "paypal-docs-42", "paypal-docs-27", "paypal-docs-5", "paypal-docs-24", "paypal-docs-41", "paypal-docs-1", "paypal-docs-9", "paypal-docs-11" ] }, { "productId": "paypal", "storyId": "multi-currency-charge-settle", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal supports multi-currency transactions (ISO-4217 currency codes, blocking payments in currencies not held, multi-currency payouts) and can accept payments from customers globally, but the evidence pack provides no explicit documentation of automatic FX conversion mechanics, disclosed FX margin/spread, or a transparent rate-and-fee breakdown at settlement — a specific founder concern given community reports of fund holds and account limitations (paypal-comm-3, paypal-comm-8) that could affect predictable settlement. missing for 10: documented FX conversion rate/margin transparency, explicit multi-currency settlement-to-single-bank-account flow, and independent confirmation that FX handling is clear/predictable in practice.", "evidenceIds": [ "paypal-docs-17", "paypal-docs-33", "paypal-docs-24", "paypal-docs-41", "paypal-comm-3", "paypal-comm-8" ] }, { "productId": "paypal", "storyId": "no-code-payment-links", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal's business site directly documents no-code Payment Links: 'Swiftly create a Payment Link to share on your website, via email, on social media, or through text. No coding skills required,' alongside broad acceptance of PayPal, Venmo, cards, and Pay Later. This directly matches the founder story of creating a shareable link with no code and selling immediately. Missing for 10: independent hands-on confirmation of the payment-link creation flow beyond vendor docs.", "evidenceIds": [ "paypal-docs-31", "paypal-docs-29", "paypal-docs-12" ] }, { "productId": "paypal", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal documents strong API/UI parity for core merchant flows (checkout, subscriptions, invoicing, payouts, disputes via API vs. Resolution Center, webhooks, platform onboarding) and even an MCP/agent-toolkit layer for natural-language access to many of these (create_order, create_invoice, list_disputes, get_merchant_insights, etc.). However, several consumer-facing PayPal.com UI features (Pay in 4, Savings account APY, debit card cashback, 'pool money' group gifts, Fastlane autofill) have no documented API equivalent, and agentic commerce tools are explicitly gated/limited (e.g., commerce tools 'for gift cards only for now', Store Sync restricted to US physical goods in USD). missing for 10: API parity for consumer money-app features (Pay in 4, Savings, cashback, group pooling), unrestricted access to agentic commerce tools without approval gating.", "evidenceIds": [ "paypal-docs-6", "paypal-docs-7", "paypal-docs-25", "paypal-docs-26", "paypal-docs-53", "paypal-docs-65", "paypal-supp-agent-tools-inventory", "paypal-supp-insights-tool", "paypal-supp-store-sync", "paypal-supp-agentic-commerce-services", "paypal-docs-35", "paypal-docs-36", "paypal-docs-15", "paypal-docs-30" ] }, { "productId": "paypal", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any user-facing data export feature or open-format data portability tool; PayPal's evidence pack covers APIs, payments, and AI/agent tooling but nothing about exporting a user's own account/transaction data in open formats or account closure/data portability guarantees.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal is a closed-source commercial payments platform/SaaS product, not open-source software; asking to read its source under an open license is a category error for this kind of product (its GitHub repos are SDKs/toolkits, not the product itself).", "evidenceIds": [] }, { "productId": "paypal", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PayPal is a centralized payments/financial services platform; self-hosting the core product is a category error since payment processing inherently requires PayPal's regulated infrastructure, not something a buyer would expect to run themselves.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "payout-schedule-control", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers PayPal's mass Payouts API (sending batch payments) and general merchant insights/analytics, but nothing documents controlling a payout schedule or a reconciliation view mapping each payout to its constituent charges, fees, and refunds.", "evidenceIds": [ "paypal-docs-5", "paypal-docs-24", "paypal-docs-41", "paypal-docs-58", "paypal-supp-insights-tool" ] }, { "productId": "paypal", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "PayPal's hosted checkout button and 'card field customization' checkout (paypal-docs-2, paypal-docs-27) plus Braintree's GraphQL 'Vault a payment method' (paypal-supp-braintree-graphql) imply that raw card data can be tokenized/hosted rather than touching merchant servers, and server-side endpoints only handle refunds/captures rather than card numbers (paypal-docs-19). However, none of the evidence explicitly states PCI DSS scope reduction, SAQ-A eligibility, or a formal compliance statement. Missing for 10: explicit PCI DSS/SAQ-A documentation, third-party compliance audit or certification evidence, and confirmation that card fields are always iframe-hosted (vs. merchant-collected) across all checkout flows.", "evidenceIds": [ "paypal-docs-2", "paypal-docs-27", "paypal-docs-19", "paypal-supp-braintree-graphql" ] }, { "productId": "paypal", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack discusses data residency, regional data storage options, or configurable data location for PayPal accounts or its AI tools; this is a fair privacy-posture question for a payments platform handling personal/financial data, but no supporting documentation is present.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "PayPal is a payments platform, not an AI model provider, but data-privacy/AI-training opt-out is still a fair consumer privacy question for any company handling personal financial data; no evidence in the pack addresses AI training data usage or an opt-out control. missing for 10: any privacy policy or settings documentation on AI/ML training use of customer data, an opt-out mechanism, or related statements.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items discuss data retention policies, data deletion controls, or user-facing privacy/data management settings for AI-native usage of PayPal; the material covers payments, APIs, MCP tools, and unrelated community complaints about fund holds/disputes. missing for 10: documentation of data retention periods, user/agent-initiated deletion or export controls, and any AI-specific data governance policy.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of any telemetry opt-out or usage tracking controls for AI-native users; PayPal's docs focus on payments APIs, and community items discuss account freezes/disputes, not telemetry settings.", "evidenceIds": [] }, { "productId": "paypal", "storyId": "recurring-subscription-billing", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PayPal's Subscriptions API docs explicitly cover creating fixed/variable billing plans, free/discounted trials, upgrade/downgrade of plans, and automated payment recovery for failed payments — covering plans, trials, upgrades and proration-like variable billing. Dashboard management and REST API integration paths are both documented. Missing for 10: no independent/hands-on third-party corroboration of proration mechanics or edge-case billing behavior.", "evidenceIds": [ "paypal-docs-3", "paypal-docs-20", "paypal-docs-21", "paypal-docs-40", "paypal-docs-57", "paypal-docs-53", "paypal-docs-65" ] }, { "productId": "paypal", "storyId": "refunds-full-partial", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Evidence confirms API-side refund capability (create_refund, get_refund tools; 'Add server-side endpoints to handle refunds, voids, delayed captures') and dashboard-side refund ability ('Merchants can also add tracking, mark shipments, and issue refunds directly in the PayPal business dashboard'), covering both API and dashboard channels. However, there is no explicit documentation of partial vs full refund distinction, no dedicated Refunds API reference page, and community evidence shows disputes/chargeback handling can be inconsistent, though not specifically contradicting refund issuance itself. Missing for 10: explicit partial-refund API documentation/parameters, a dedicated Refunds API reference, and independent/hands-on confirmation of dashboard refund workflow.", "evidenceIds": [ "paypal-docs-19", "paypal-docs-66", "paypal-supp-agent-tools-inventory" ] }, { "productId": "paypal", "storyId": "respond-to-disputes-evidence", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PayPal documents both a no-code Resolution Center for manually responding to and monitoring disputes and a Disputes API for automating dispute actions (paypal-docs-6/7/25/26), and the agent-toolkit inventory adds list_disputes/get_dispute/accept_dispute_claim tools for programmatic dispute tracking. However, the pack never documents actual structured-evidence submission (e.g., uploading proof of delivery/tracking, evidence codes) as part of the API, and accept_dispute_claim only resolves disputes in the buyer's favor rather than contesting a chargeback. Community reports (paypal-comm-4/5/6/7) describe merchants losing chargebacks despite appeals/evidence and arbitrary outcomes, raising real doubts about resolution reliability though not proving the API/dashboard mechanics themselves fail. missing for 10: explicit evidence-submission/upload API documentation, a documented merchant-side evidence code list, and independent confirmation that submitted evidence measurably improves dispute outcomes.", "evidenceIds": [ "paypal-docs-6", "paypal-docs-7", "paypal-docs-25", "paypal-docs-26", "paypal-supp-agent-tools-inventory", "paypal-comm-4", "paypal-comm-5", "paypal-comm-6", "paypal-comm-7" ] }, { "productId": "paypal", "storyId": "sandbox-test-mode-fidelity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PayPal documents a dedicated sandbox that 'simulates the live PayPal production environment' (paypal-docs-11), and the agent-toolkit docs explicitly recommend 'Always use the sandbox environment for initial testing' with a PAYPAL_ENVIRONMENT=SANDBOX flag (paypal-supp-toolkit-frameworks), confirming sandbox/production parity for both REST and MCP flows. However, the evidence pack contains no documentation of specific test card numbers or scenario coverage (e.g., simulating declines, chargebacks, or disputes) within the sandbox — only that a live Disputes API and Resolution Center exist for production dispute handling. Missing for 10: documented test card list/scenarios for declines, dispute simulation tooling in sandbox, and independent developer corroboration of sandbox fidelity.", "evidenceIds": [ "paypal-docs-11", "paypal-supp-toolkit-frameworks", "paypal-docs-7", "paypal-docs-26" ] }, { "productId": "paypal", "storyId": "send-hosted-invoices", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal Invoicing API/product explicitly supports creating, sending, and managing hosted invoices with a secure payment page, branding, and automatic payment reminders (paypal-docs-4, paypal-docs-22, paypal-docs-50), and the agent-tools inventory confirms send_invoice and send_invoice_reminder tools. missing for 10: independent/hands-on corroboration of reminder cadence/customization and no third-party review confirming real-world reliability of the reminder feature.", "evidenceIds": [ "paypal-docs-4", "paypal-docs-22", "paypal-docs-23", "paypal-docs-50", "paypal-supp-agent-tools-inventory" ] }, { "productId": "paypal", "storyId": "settlement-reconciliation-reports", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "PayPal's evidence shows transaction-level reporting and dispute/refund tooling (get_merchant_insights, list_transaction, dispute and refund APIs) that could feed reconciliation workflows, but there is no documented settlement report or bank-deposit-matching feature tying fees, refunds, and chargebacks together. missing for 10: dedicated settlement/reconciliation report, bank deposit matching, itemized fee breakdown tied to payouts.", "evidenceIds": [ "paypal-supp-agent-tools-inventory", "paypal-supp-insights-tool", "paypal-docs-26", "paypal-docs-19" ] }, { "productId": "paypal", "storyId": "wallets-local-payment-methods", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PayPal Checkout explicitly bundles wallet funding sources (any linked PayPal funding source), Pay in 4 BNPL, and in-store tap-to-pay with Apple Pay/Google Pay/Samsung Pay via a single PayPal Open/Checkout integration, plus Expanded Checkout adds card fields and branding under the same account. This covers wallets, BNPL, and digital wallet acceptance from one integration, though bank redirect methods (e.g., iDEAL, SEPA, giropay) and full country-by-country local payment method coverage aren't explicitly enumerated in evidence. missing for 10: explicit documentation of bank-redirect/local APM coverage (iDEAL, SOFORT, giropay, etc.) and confirmation these are enabled via the same single API call without extra per-method integration work.", "evidenceIds": [ "paypal-docs-2", "paypal-docs-15", "paypal-docs-27", "paypal-docs-29", "paypal-docs-32", "paypal-docs-37", "paypal-docs-51" ] }, { "productId": "paypal", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "PayPal documents basic webhooks (HTTPS POSTs to a subscribed endpoint) but the evidence pack contains no mention of signature verification/signing, automatic retry behavior, an event log/dashboard, or a replay/redelivery mechanism. Missing for 10: documented webhook signature verification, retry policy details, event log/dashboard access, and replay/resend capability.", "evidenceIds": [ "paypal-docs-9", "paypal-docs-28" ] }, { "productId": "polar", "storyId": "accept-card-payment-online", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Polar documents fast onboarding ('minutes from an existing store'), no-code Checkout Links you can 'share the URL anywhere,' embedded checkout, and a Merchant-of-Record model that lets founders accept international card payments without setting up separate processors — plus a sandbox to test cards before going live. This directly supports going from signup to accepting a real card payment within a day. Missing for 10: independent/hands-on account confirming actual time-to-first-live-payment (all evidence is vendor docs) and no explicit account approval/KYC timeline that could delay live payments.", "evidenceIds": [ "polar-docs-3", "polar-docs-7", "polar-docs-9", "polar-docs-40", "polar-supp-checkout-links", "polar-supp-sandbox", "polar-docs-26" ] }, { "productId": "polar", "storyId": "agent-handles-dispute-end-to-end", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of a disputes/chargebacks feature, API, or workflow at all — only refunds, failed payments/dunning, and payouts are documented. As a Merchant of Record, dispute handling is a plausible expected capability, but nothing shows Polar exposes dispute retrieval, evidence assembly, or response submission via API for an agent to act on end-to-end.", "evidenceIds": [ "polar-docs-25", "polar-supp-dunning", "polar-docs-43" ] }, { "productId": "polar", "storyId": "agent-monitors-dunning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Polar documents automated dunning (fixed retry schedule 2/5/7/7 days, past_due state, customer emails) plus webhooks for async notifications and an official MCP server letting agents 'look up data and take actions' across subscriptions/orders — enough for an agent to monitor failed payments and dunning state via API/webhooks. However, dunning/retries are built-in automatic Polar behavior rather than agent-driven; there's no documented API/webhook event specifically for failed-charge notification or an endpoint for an agent to manually trigger a retry or custom outreach message. Missing for 10: explicit failed-payment webhook event schema, an API to trigger/override retry attempts, and evidence of agent-customized dunning outreach beyond Polar's built-in emails.", "evidenceIds": [ "polar-supp-dunning", "polar-docs-11", "polar-supp-mcp", "polar-docs-21", "polar-docs-13" ] }, { "productId": "polar", "storyId": "agent-provisions-payment-link", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Polar documents a remote MCP server giving agents OAuth-secured access to 'take actions across your products, customers, subscriptions, orders, benefits, and more,' plus a full API/SDK stack (Checkout Session API, versioned OpenAPI specs, llms.txt) that would let an agent create a product, price, and payment link programmatically in one session. However, there's no first-party walkthrough or hands-on example explicitly chaining product+price+payment-link creation via MCP or API in a single session. Missing for 10: an explicit documented example/tutorial showing an agent creating product, price, and checkout link together in one session, and independent confirmation the MCP tool schema exposes create-product/create-price actions (not just 'look up' access).", "evidenceIds": [ "polar-supp-mcp", "polar-docs-24", "polar-supp-checkout-links", "polar-docs-8", "polar-supp-openapi-llms", "polar-docs-23" ] }, { "productId": "polar", "storyId": "agent-reconciles-payouts", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Polar documents payout thresholds and balance visibility (polar-docs-14, polar-docs-15), a full typed API/SDK (polar-docs-23, polar-docs-38), webhooks, and a remote MCP server letting agents access 'products, customers, subscriptions, orders, benefits' (polar-supp-mcp). However, there is no explicit documentation of a balance-transaction/ledger API endpoint, nor confirmation that the MCP server or SDK exposes payout/balance data specifically (the MCP scope list omits payouts/balance), so reconciling deposits to charges via an agent is only indirectly supported. Missing for 10: explicit balance-transaction API endpoint docs, MCP/agent access to payout and balance data, and any documented reconciliation workflow or example.", "evidenceIds": [ "polar-docs-14", "polar-docs-15", "polar-docs-23", "polar-supp-mcp", "polar-docs-38", "polar-supp-openapi-llms" ] }, { "productId": "polar", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar publishes an llms.txt at /docs/llms.txt (also live-probed at /llms.txt returning HTTP 200) with .md siblings for every doc page and versioned OpenAPI specs, explicitly designed for agent legibility; this is corroborated by a direct probe hit. Missing for 10: independent third-party confirmation that AI agents actually consume these docs successfully in practice (only first-party docs and probes provided), and the root-level docs.md probe returned 404, showing coverage isn't perfectly uniform across all URL patterns.", "evidenceIds": [ "polar-docs-3", "polar-supp-openapi-llms", "polar-probe-1", "polar-probe-2" ] }, { "productId": "polar", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Polar's evidence covers billing, checkout, usage metering, webhooks, and an MCP server for external agent access, but nothing describes the product itself generating AI insights, suggestions, or analytics narratives from customer/revenue data for the user inside the dashboard.", "evidenceIds": [] }, { "productId": "polar", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Polar ships genuine autonomous background automations — automated dunning/payment retries on a fixed schedule, automatic subscription renewal and proration, async webhooks instead of polling, and usage meters that compute continuously — and its MCP server lets AI agents take actions on the account. However, none of this is presented as a user-configurable 'automation builder' or agent-driven workflow scheduler; the autonomy is built into Polar's own billing engine rather than something the AI-native user 'sets up' themselves. Missing for 10: evidence of user-defined trigger/action automation rules, scheduled/cron-like agent workflows, or any explicit 'automation' feature beyond fixed billing/dunning logic.", "evidenceIds": [ "polar-supp-dunning", "polar-docs-10", "polar-docs-12", "polar-supp-webhooks", "polar-supp-mcp", "polar-docs-32" ] }, { "productId": "polar", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Polar's evidence shows an MCP server that lets external AI agents connect to Polar's data/actions (polar-docs-24, polar-supp-mcp), which is the reverse of the story — it's Polar being used as a tool by outside agents, not a built-in assistant inside Polar's own product that a user can delegate tasks to. No evidence of any in-product chat/assistant UI exists in the pack.", "evidenceIds": [ "polar-docs-24", "polar-supp-mcp", "polar-probe-4" ] }, { "productId": "polar", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Polar exposes a full API/SDKs (Python, TypeScript), a CLI (`polar listen` for webhook forwarding) and an isolated sandbox environment for testing without live money, all of which could be scripted into CI pipelines, and its OpenAPI/llms.txt makes it machine-legible for automation. However there is no explicit documentation of running Polar itself headlessly or CI/CD integration guidance (e.g., GitHub Actions examples, automated test suites against sandbox). missing for 10: explicit CI/CD pipeline documentation or examples, statement of headless/automation mode, independent evidence of running the CLI/SDKs unattended in a build pipeline.", "evidenceIds": [ "polar-docs-37", "polar-supp-sandbox", "polar-docs-38", "polar-supp-openapi-llms", "polar-docs-23" ] }, { "productId": "polar", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Polar is a payments/billing platform, not an AI agent or assistant that itself consumes tools from external MCP servers. All MCP evidence describes Polar exposing its own remote MCed server for other AI agents to call (the reverse direction), not Polar acting as an MCP client that plugs in and uses other servers' tools — that capability is outside this product's category.", "evidenceIds": [] }, { "productId": "polar", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar (a SaaS billing platform, not itself an agent) documents an official remote MCP server with production and sandbox endpoints, OAuth-based auth, and setup instructions for Cursor, Claude Code, ChatGPT, and Claude Desktop, letting agents securely act on the organization's data. Missing for 10: independent/community hands-on confirmation beyond vendor docs and probes.", "evidenceIds": [ "polar-docs-24", "polar-supp-mcp", "polar-probe-4" ] }, { "productId": "polar", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Polar ships a documented remote MCP server (OAuth-secured) that lets AI agents look up data and take actions across products, customers, subscriptions, orders, and benefits, with explicit setup for Claude Code, Cursor, ChatGPT, and Claude Desktop — enabling natural-language operation of the product via an agent client. Missing for 10: independent/hands-on validation of the MCP server working in practice and concrete examples of successful natural-language command execution beyond vendor docs.", "evidenceIds": [ "polar-docs-24", "polar-supp-mcp", "polar-probe-4" ] }, { "productId": "polar", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "The docs show a single CLI invocation, `polar listen http://localhost:3000/`, implying an official Polar CLI for local webhook forwarding/testing, but there's no dedicated CLI reference page, installation instructions, or list of subcommands beyond this one snippet. missing for 10: CLI installation/setup docs, full command reference, independent confirmation of broader CLI usage.", "evidenceIds": [ "polar-docs-37" ] }, { "productId": "polar", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar publishes a documented, versioned OpenAPI 3.1 spec, official typed SDKs (TypeScript/Python), webhooks, and llms.txt/agent-legible docs, giving AI-native users a fully documented public API surface to drive the product programmatically. missing for 10: independent third-party corroboration of the API's stability/completeness beyond first-party docs, and the probe showing openapi.json not reachable at the root domain (spec is only under /docs).", "evidenceIds": [ "polar-docs-23", "polar-supp-openapi-llms", "polar-docs-38", "polar-supp-webhooks", "polar-probe-3", "polar-probe-1" ] }, { "productId": "polar", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Polar's MCP server uses OAuth so agents authorize access to an organization via browser rather than embedding a raw API key, which is a step toward safer agent credentialing, but the docs describe org-level authorization only, not fine-grained/least-privilege scopes (e.g., read-only vs write, per-resource permissions) for issuing agent-specific credentials. Missing for 10: documented scope/permission granularity for API keys or OAuth tokens, ability to restrict an agent to specific resources/actions, and any explicit 'least privilege' credential-issuance workflow.", "evidenceIds": [ "polar-docs-24", "polar-supp-mcp", "polar-probe-4" ] }, { "productId": "polar", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Polar documents official TypeScript and Python SDKs with full type safety, fully typed sync/async clients, framework adapters, versioned OpenAPI specs, and machine-legible llms.txt docs—clear support for AI-native developers building against official SDKs. missing for 10: independent third-party corroboration of SDK quality/coverage beyond vendor docs, and the openapi probe found no public root-level spec (though versioned specs are documented within docs).", "evidenceIds": [ "polar-docs-23", "polar-docs-38", "polar-docs-39", "polar-supp-openapi-llms", "polar-docs-22" ] }, { "productId": "polar", "storyId": "agentic-webhooks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar provides comprehensive webhook subscription support: documented endpoint configuration, async event notifications instead of polling, Standard Webhooks spec compliance, typed payloads, signature validation SDK helpers, local testing via `polar listen`, and CRUD API for webhook endpoints — directly enabling event-driven/agentic integration patterns. missing for 10: independent third-party corroboration of webhook reliability at scale beyond vendor docs.", "evidenceIds": [ "polar-docs-21", "polar-docs-22", "polar-docs-36", "polar-docs-37", "polar-supp-webhooks", "polar-docs-34" ] }, { "productId": "polar", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Polar publishes versioned OpenAPI specs and machine-readable docs (llms.txt/.md pages) plus a sandbox environment for testing API calls with test cards, which supports API exploration, but there is no evidence of an actual interactive API reference UI (e.g., a Swagger/Redoc-style console) with embedded runnable examples directly in the docs. Missing for 10: an in-docs interactive 'try it' console, embedded runnable code examples per endpoint, and independent confirmation the OpenAPI spec renders as an explorable reference.", "evidenceIds": [ "polar-supp-openapi-llms", "polar-supp-sandbox", "polar-docs-20", "polar-probe-3" ] }, { "productId": "polar", "storyId": "api-machine-spec", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Polar's docs explicitly state it serves versioned OpenAPI 3.1.0 specs (2026-04.openapi.json, 2026-10.openapi.json) directly from the docs site alongside llms.txt and per-page .md files, giving AI-native users machine-readable spec access. However, probes only tested root-domain paths (polar.sh/openapi.json etc., all 404) rather than the actual documented docs-site paths, so there's no independent confirmation of a successful direct download. Missing for 10: independent verification of the exact documented OpenAPI URL resolving successfully, and no mention of spec discoverability via standard well-known paths.", "evidenceIds": [ "polar-supp-openapi-llms", "polar-probe-1", "polar-probe-3" ] }, { "productId": "polar", "storyId": "api-sandbox", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar documents a fully isolated sandbox environment (separate server, unlimited test accounts/orgs) that supports end-to-end testing including checkout with Stripe test cards, explicitly to avoid touching production data or money — and a dedicated sandbox MCP endpoint further supports AI-agent testing workflows. missing for 10: independent/hands-on third-party confirmation beyond vendor docs.", "evidenceIds": [ "polar-docs-20", "polar-docs-35", "polar-supp-sandbox", "polar-supp-mcp" ] }, { "productId": "polar", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Evidence shows Polar publishes dated, versioned OpenAPI specs (2026-04.openapi.json and 2026-10.openapi.json) alongside machine-readable docs (llms.txt), indicating an API versioning scheme exists. However, no evidence describes an explicit deprecation policy, sunset timelines, or migration guidance between API versions; probes for a root-level openapi.json also 404 outside the documented docs-site paths. Missing for 10: documented deprecation/sunset policy, version lifecycle timelines, migration guides between dated API versions, independent confirmation of long-term version support.", "evidenceIds": [ "polar-supp-openapi-llms", "polar-probe-3" ] }, { "productId": "polar", "storyId": "automatic-tax-calculation", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Polar acts as Merchant of Record and documents that it calculates, collects, and remits sales tax/VAT/GST worldwide, taking on international tax liability so sellers don't need to manage it, plus configurable tax-inclusive pricing controls. missing for 10: no independent/hands-on corroboration of actual tax calculation accuracy across jurisdictions, and no detail on specific tax rate/rule coverage per country.", "evidenceIds": [ "polar-docs-2", "polar-docs-40", "polar-docs-18", "polar-supp-mor-fees", "polar-docs-26" ] }, { "productId": "polar", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar's docs describe individual resource APIs, webhooks, SDKs, and an MCP server for agents to look up/take actions, but nothing in the evidence pack describes batch or bulk endpoints (e.g., bulk refunds, bulk customer/product updates, batch import) that would let an AI-native user act on many items in one call.", "evidenceIds": [] }, { "productId": "polar", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Polar ships built-in automated behaviors for specific billing events (auto-renewal, dunning/retry schedules, proration) and webhooks that notify external systems asynchronously when events occur, which a user can wire up to trigger their own actions. However, there is no evidence of a native rule-definition engine (e.g., 'if event X then do Y' conditions/workflows) inside Polar itself — automation requires building a webhook consumer outside the product. Missing for 10: a first-party rules/workflow builder, conditional logic on events, and any evidence of user-authored automation rules beyond webhook delivery.", "evidenceIds": [ "polar-docs-21", "polar-docs-36", "polar-supp-webhooks", "polar-supp-dunning", "polar-docs-43", "polar-docs-37" ] }, { "productId": "polar", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar's automation is limited to internal billing mechanics (auto-renewing subscriptions, fixed dunning retry schedules, meter aggregation) rather than a general-purpose job/workflow scheduler that an AI-native user or agent could configure for arbitrary recurring tasks. The MCP server lets agents take one-off actions on billing data, but there is no evidence of scheduling recurring jobs or workflows via API, MCP, or dashboard.", "evidenceIds": [ "polar-docs-10", "polar-supp-dunning", "polar-docs-4", "polar-supp-mcp" ] }, { "productId": "polar", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar has automated flows (webhooks, dunning, usage-based billing meters, subscriptions) that could plausibly be configured and changed, but nothing in the evidence describes version history, review workflows, or rollback for these configurations — no changelog, no audit trail, no revert capability is documented.", "evidenceIds": [] }, { "productId": "polar", "storyId": "dunning-failed-payment-recovery", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Polar documents automated dunning explicitly: failed charges move the subscription to past_due, trigger a fixed retry schedule (2,5,7,7 days up to 21 days), stamp next_payment_attempt_at, and send the customer a recovery email with a Customer Portal link to update payment method rather than canceling immediately. This directly matches the story's core ask of automatic retries with recovery emails. Missing for 10: no evidence of customizable dunning schedules, multi-channel (SMS/in-app) recovery notifications, or independent/hands-on confirmation beyond vendor docs.", "evidenceIds": [ "polar-docs-11", "polar-docs-43", "polar-supp-dunning", "polar-docs-16" ] }, { "productId": "polar", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Polar documents an embedded checkout explicitly designed to avoid redirecting users off-site, plus a Checkout Session API for deeper custom integration, alongside the simpler hosted checkout links option — directly matching the story's ask for embeddable, customizable in-app payment components. Missing for 10: independent/hands-on confirmation of embed customization depth (styling, component-level control) beyond first-party docs.", "evidenceIds": [ "polar-docs-9", "polar-docs-8", "polar-supp-checkout-links", "polar-docs-7" ] }, { "productId": "polar", "storyId": "fraud-screening-rules", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Polar is a merchant-of-record billing/payments platform for digital products and subscriptions; there is no evidence of, nor is it a natural fit for, ML-based fraud scoring or custom block/review/allow rule engines aimed at finance-ops transaction screening. This is a wrong-axis question for a billing/MoR product, not a gap in an applicable capability.", "evidenceIds": [] }, { "productId": "polar", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar documents no-code Checkout Links that developers configure once and redirect to (share URL anywhere, hosted, Polar handles the rest), plus a Checkout Session API for deeper redirect flows, and a sandbox to test the full checkout funnel end-to-end — directly matching a vendor-hosted redirect checkout without building custom payment UI. missing for 10: independent third-party review of checkout conversion/UX quality beyond vendor docs.", "evidenceIds": [ "polar-docs-7", "polar-docs-8", "polar-supp-checkout-links", "polar-supp-sandbox", "polar-docs-20" ] }, { "productId": "polar", "storyId": "idempotent-api-retries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers checkout, subscriptions, webhooks, SDKs, and dunning/retry logic for failed payments, but nowhere mentions idempotency keys or a documented mechanism for safely retrying API requests to prevent duplicate charges. This is a standard, fair expectation for a payments API, so its absence is 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "polar", "storyId": "integrate-from-docs-in-a-day", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Polar's docs provide copy-paste checkout flows (links, embed, session API), official TypeScript & Python SDKs, framework adapters, a full sandbox with test cards, local webhook testing CLI, and an explicit '6 lines of code' quick-start claim—together covering a realistic under-a-day integration path. Missing for 10: independent/hands-on confirmation of the 'under a day' timeline, broader language SDK coverage beyond TS/Python/adapters, and corroboration beyond first-party docs.", "evidenceIds": [ "polar-docs-7", "polar-docs-8", "polar-docs-9", "polar-docs-20", "polar-supp-sandbox", "polar-docs-23", "polar-docs-38", "polar-docs-39", "polar-docs-37", "polar-docs-31" ] }, { "productId": "polar", "storyId": "marketplace-split-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar's evidence describes single-organization merchant-of-record billing, payouts, and balances for one seller, but nothing about onboarding multiple sellers/sub-accounts, splitting a single transaction's proceeds between parties, or a Connect-like marketplace primitive. The axis is plausible for a payments platform, but no evidence supports multi-seller marketplace functionality.", "evidenceIds": [ "polar-docs-14", "polar-docs-15", "polar-docs-40", "polar-supp-mor-fees" ] }, { "productId": "polar", "storyId": "multi-currency-charge-settle", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar's docs cover MoR tax handling, payouts, and pricing plans, but none of the evidence describes charging customers in their local currency or explains FX conversion/settlement transparency — payouts are described only in terms of a single 'account currency' threshold, with no mention of multi-currency checkout or FX rate disclosure.", "evidenceIds": [ "polar-docs-14", "polar-docs-15", "polar-docs-40", "polar-supp-mor-fees" ] }, { "productId": "polar", "storyId": "no-code-payment-links", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Polar explicitly documents no-code Checkout Links: 'Configure once in the dashboard, share the URL anywhere... and Polar handles the rest,' as one of three checkout surfaces alongside embedded and API-driven flows, and Polar acts as Merchant of Record so a founder can sell immediately without separate tax/payment setup. Missing for 10: independent/hands-on confirmation of the dashboard link-creation flow beyond vendor docs, and no third-party account of actual end-to-end usage.", "evidenceIds": [ "polar-docs-7", "polar-supp-checkout-links", "polar-docs-40", "polar-docs-3" ] }, { "productId": "polar", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Polar documents a broad, versioned API/SDK surface covering checkout, subscriptions, meters/usage billing, customer state, webhooks, refunds, and payouts, plus an official MCP server letting agents 'look up data and take actions across your products, customers, subscriptions, orders, benefits, and more' without needing the UI, and agent-legible docs (llms.txt, OpenAPI specs). However, no explicit vendor statement guarantees 1:1 UI/API parity, some dashboard-only mentions (e.g., 'create and manage your meters from the dashboard') aren't cross-confirmed with an API equivalent in the pack, and root-level openapi.json probes 404'd (spec is only reachable via versioned docs paths). Missing for 10: an explicit parity claim/audit, confirmation every dashboard action (e.g., payouts, balance views) has a documented API call, and independent corroboration of full API/UI equivalence.", "evidenceIds": [ "polar-docs-6", "polar-docs-8", "polar-docs-9", "polar-supp-checkout-links", "polar-supp-usage-billing", "polar-supp-mcp", "polar-supp-openapi-llms", "polar-docs-23", "polar-probe-3" ] }, { "productId": "polar", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar is a merchant-of-record billing/payments platform; the evidence pack covers API access, webhooks, MCP, and OpenAPI specs for developers to integrate with, but there is no mention of a data export feature letting a user (customer or merchant) export all of their own data (orders, subscriptions, customer records, transaction history) in an open, portable format for the purpose of leaving the platform. Having an API is not the same as a documented bulk data-export/portability capability.", "evidenceIds": [] }, { "productId": "polar", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Polar's own repo (github.com/polarsource/polar) is documented as open source under Apache-2.0 with 10k+ stars, meaning the product's source is publicly readable under a permissive OSI license, and this is reinforced by docs/site language positioning Polar as 'Open Source & Global Merchant of Record.' missing for 10: no independent third-party audit of license file contents or contribution history beyond the single citation.", "evidenceIds": [ "polar-supp-oss", "polar-docs-31" ] }, { "productId": "polar", "storyId": "openness-self-host", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Polar's core codebase is confirmed open source (Apache-2.0, 10k+ stars on GitHub) which technically permits self-hosting, but the evidence contains no documented self-hosting guide, deployment instructions, or Docker/infra setup for running the full platform independently — and the core value proposition (Merchant of Record tax handling, payment processing) inherently depends on Polar's own hosted compliance/payment infrastructure, which cannot be self-hosted. Missing for 10: explicit self-hosting documentation/tutorial, confirmation that MoR/tax/payment features work outside Polar's hosted service, and any community reports of successful self-hosted deployments.", "evidenceIds": [ "polar-supp-oss", "polar-docs-40", "polar-docs-26" ] }, { "productId": "polar", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Polar documents balance visibility and a manual withdrawal/payout mechanism gated by a minimum threshold, plus refunds and order/charge tracking, giving finance-ops some reconciliation ability. However, there's no evidence of a configurable payout schedule (e.g., automatic weekly/monthly payout cadence) or a consolidated payout report itemizing which specific charges, fees, and refunds roll up into a given payout. missing for 10: documented payout scheduling/cadence controls, a per-payout itemized breakdown of constituent charges/fees/refunds, and any reconciliation report or export tying payouts to transactions.", "evidenceIds": [ "polar-docs-14", "polar-docs-15", "polar-docs-25", "polar-supp-mor-fees" ] }, { "productId": "polar", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Polar's checkout is hosted/embedded (never redirecting raw card data to the developer's own servers) and it acts as Merchant of Record, handling payment processing, tax and compliance obligations, which strongly implies card data tokenization keeps most PCI scope off the developer's infrastructure (polar-docs-7, polar-docs-8, polar-docs-9, polar-supp-checkout-links, polar-docs-40, polar-docs-26). However, the evidence pack never explicitly states a PCI DSS compliance certification or scope-reduction claim, and off-session/saved-card charges (polar-docs-13) aren't tied to any documented tokenization/PCI statement. Missing for 10: an explicit PCI DSS SAQ-A or compliance statement, documentation of card tokenization mechanics, and independent/third-party confirmation of reduced PCI scope.", "evidenceIds": [ "polar-docs-7", "polar-docs-8", "polar-docs-9", "polar-supp-checkout-links", "polar-docs-40", "polar-docs-26", "polar-docs-13" ] }, { "productId": "polar", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Polar is a merchant-of-record billing/payments platform, not an infrastructure/data-storage product; data residency/region selection is not a fair axis for this product category, and no evidence pack material addresses it.", "evidenceIds": [] }, { "productId": "polar", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Polar is a payments/billing infrastructure product (Merchant of Record, subscriptions, usage billing), not a data/AI-model-training product; there is no user data corpus subject to AI training that this story's privacy control would apply to. This is a category error—wrong axis for this product type.", "evidenceIds": [] }, { "productId": "polar", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers billing, checkout, subscriptions, webhooks, MCP integration, and merchant-of-record tax handling, but contains no mention of data retention policies, customer data deletion, GDPR/right-to-be-forgotten controls, or any user-facing mechanism to purge or manage stored data. As a platform that stores customer and transaction data, this is a fair question, but no capability is documented.", "evidenceIds": [] }, { "productId": "polar", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry/usage-tracking opt-out; Polar's docs focus on billing, checkout, MCP, webhooks, and merchant-of-record features with no mention of a privacy/telemetry setting.", "evidenceIds": [] }, { "productId": "polar", "storyId": "recurring-subscription-billing", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Polar documents recurring subscriptions with automatic renewal, plan upgrades/downgrades with immediate rate changes, configurable proration behavior (org-level or per-call), trials are implied via subscription lifecycle, and dunning/failed-payment retry schedules; seat-based proration is also documented. Missing for 10: explicit first-party documentation of trial period configuration (only inferred, not directly cited) and independent/hands-on corroboration beyond vendor docs.", "evidenceIds": [ "polar-docs-10", "polar-docs-12", "polar-docs-19", "polar-docs-11", "polar-supp-dunning", "polar-docs-28", "polar-docs-43" ] }, { "productId": "polar", "storyId": "refunds-full-partial", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Polar's docs explicitly state that full and partial refunds can be issued regardless of refund policy (polar-docs-25), and the product exposes a general typed API/SDK for all resources (polar-docs-23), implying refund actions are API-accessible. However, no evidence explicitly confirms a dedicated refunds API endpoint or dashboard refund UI walkthrough — missing for 10: explicit refunds API endpoint documentation, dashboard UI screenshot/flow evidence, and independent confirmation that partial refund amounts can be specified via API.", "evidenceIds": [ "polar-docs-25", "polar-docs-23" ] }, { "productId": "polar", "storyId": "respond-to-disputes-evidence", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers refunds, failed payments/dunning, payouts, checkout, and usage billing extensively, but contains no mention of chargebacks, dispute evidence submission, or a dispute lifecycle tracking feature anywhere in the docs or probes.", "evidenceIds": [] }, { "productId": "polar", "storyId": "sandbox-test-mode-fidelity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Polar documents a dedicated, isolated sandbox environment that mirrors the full checkout/customer funnel and supports Stripe test card numbers (e.g., 4242...), letting developers test payment flows without real money. However, evidence does not confirm dedicated test cards for every scenario (e.g., specific decline codes, dispute/chargeback simulation) — it relies on generic Stripe test cards with no documented list of scenario-specific cards or dispute-simulation tooling. missing for 10: explicit test-card matrix for various decline reasons, documented way to simulate disputes/chargebacks in sandbox, independent/hands-on confirmation of sandbox fidelity.", "evidenceIds": [ "polar-docs-20", "polar-supp-sandbox", "polar-docs-35" ] }, { "productId": "polar", "storyId": "send-hosted-invoices", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar's documented feature set covers checkout links/sessions, subscriptions, usage-based billing, and payment-failure dunning (retry emails when a subscription charge fails), but there is no evidence of a distinct 'invoice' object — i.e., a finance-ops workflow to issue a one-off hosted invoice with a due date and automatic reminders for an unpaid bill. The dunning flow (polar-supp-dunning) only fires after a failed subscription charge, not as a general invoicing/reminder tool.", "evidenceIds": [] }, { "productId": "polar", "storyId": "settlement-reconciliation-reports", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Polar's docs cover payouts, balance tracking, and refunds, but there is no evidence of itemized reconciliation reports matching settlements to bank deposits, nor any mention of chargeback handling or reporting at all.", "evidenceIds": [ "polar-docs-14", "polar-docs-15", "polar-docs-25" ] }, { "productId": "polar", "storyId": "wallets-local-payment-methods", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack extensively documents Polar's checkout flows (links, embedded, API-driven), merchant-of-record tax handling, subscriptions, and payments infrastructure, but nowhere mentions specific payment method support such as Apple Pay, Google Pay, bank redirects, or BNPL options. Sandbox testing is documented only via Stripe test card numbers, not wallet/local payment coverage.", "evidenceIds": [ "polar-docs-7", "polar-docs-8", "polar-docs-9", "polar-supp-checkout-links", "polar-docs-20" ] }, { "productId": "polar", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Polar's webhooks are signed per the Standard Webhooks spec with SDK-side signature validation, typed payloads, and a Webhook Events API for endpoint management, plus delivery monitoring and Slack/Discord alerts. However, the evidence does not document automatic retry behavior for webhook deliveries specifically, nor event logs of delivery attempts, nor a replay/redeliver mechanism — the retry/dunning schedule cited is for failed payment charges, not webhook redelivery. missing for 10: explicit webhook delivery retry policy, delivery attempt/event log UI, and a replay/resend mechanism for missed webhooks.", "evidenceIds": [ "polar-supp-webhooks", "polar-docs-21", "polar-docs-22", "polar-docs-36", "polar-docs-37" ] }, { "productId": "square", "storyId": "accept-card-payment-online", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Square documents self-serve signup with a Web Payments SDK, Card Payments API, and prebuilt eCommerce integrations that 'can be completed in just a few clicks,' plus a Sandbox for immediate testing—consistent with a founder going from signup to live online card acceptance quickly without sales calls. Missing for 10: explicit 'time-to-first-payment' documentation or independent/hands-on account of actual signup-to-live timing.", "evidenceIds": [ "square-docs-31", "square-docs-5", "square-docs-46", "square-docs-21", "square-docs-24" ] }, { "productId": "square", "storyId": "agent-handles-dispute-end-to-end", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square publishes a Disputes API (retrieve disputes, process them, sandbox testing) and its MCP server's service catalog explicitly includes 'disputes' alongside a generic make_api_request tool, so an agent could plausibly retrieve a dispute and call dispute-related endpoints programmatically. However, there is no documented evidence-assembly workflow (e.g., specific evidence-submission endpoint, required evidence fields) or any hands-on/community example of an agent completing a dispute end-to-end via the API or MCP. missing for 10: explicit evidence-submission API details, a demonstrated end-to-end agent workflow, and independent confirmation the MCP disputes tools work as claimed.", "evidenceIds": [ "square-docs-15", "square-docs-38", "square-docs-16", "square-supp-mcp-tools", "square-supp-mcp-remote" ] }, { "productId": "square", "storyId": "agent-monitors-dunning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Square documents webhooks, a Subscriptions API, and Payments API, but the evidence pack has no mention of failed-payment monitoring, automated retry logic, or dunning outreach features/APIs; the community note even flags subscriptions as a historical gap. An agent could theoretically be built on top of webhooks, but no first-party capability or workflow for this specific story is evidenced.", "evidenceIds": [ "square-docs-19", "square-docs-23", "square-comm-1" ] }, { "productId": "square", "storyId": "agent-provisions-payment-link", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Square's remote/local MCP server (square-mcp-server) exposes a discovery-oriented `make_api_request` tool spanning Catalog, Checkout, and Payments services, and Square's llms.txt explicitly frames the API as agent-consumable with idempotency-key guidance for writes — together these support an agent creating a catalog item (product), its price, and a payment link (via Checkout/Payment Links API) in one session using a single access token/OAuth session. However, no evidence pack item shows an actual end-to-end worked example or transcript of an agent doing product+price+payment-link creation in one session, and Payment Links API itself is not separately documented in the pack (only Checkout/Catalog mentioned generically). missing for 10: an explicit end-to-end tutorial/example chaining catalog item + price + payment link creation, and independent/hands-on confirmation the MCP tool can complete this multi-step flow in a single session.", "evidenceIds": [ "square-supp-mcp-tools", "square-supp-mcp-remote", "square-supp-llms-agent-guidance", "square-docs-44", "square-docs-49" ] }, { "productId": "square", "storyId": "agent-reconciles-payouts", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square has a documented Payouts API and API access (via SDK, MCP server, GraphQL, webhooks) that an agent could use to pull payout and balance-transaction data programmatically, and payments/refunds/disputes APIs provide the underlying charge data needed for reconciliation. However, there is no direct evidence of a balance-transactions endpoint equivalent to Stripe's, nor documentation showing how payout line items map to underlying charges/fees for reconciliation workflows. missing for 10: explicit balance-transaction/payout-entries API detail, worked reconciliation example or docs linking deposits to charges, independent/hands-on confirmation of this specific workflow.", "evidenceIds": [ "square-docs-17", "square-supp-mcp-tools", "square-supp-mcp-remote", "square-docs-41", "square-docs-19" ] }, { "productId": "square", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Square publishes a live, verified llms.txt (probe confirms HTTP 200) explicitly designed for AI agents, with agent-specific guidance on idempotency keys, pagination, and instructions to fetch llms-full.txt or per-page .md files instead of loading the whole corpus; docs pages also render as raw markdown. This is corroborated by an independent probe hit. missing for 10: no independent third-party (non-vendor) confirmation that agents successfully consume this file in practice, and the docs.md/openapi fallback endpoints 404 rather than existing.", "evidenceIds": [ "square-supp-llms-agent-guidance", "square-probe-1", "square-probe-2", "square-probe-3", "square-docs-44" ] }, { "productId": "square", "storyId": "agentic-ai-insights", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square AI (Beta) is a first-party in-product assistant that answers natural-language questions over the seller's own sales/inventory data, surfaces proactive insights, and even pulls in web data (weather, events, reviews), with seller testimonials confirming real use for sales analysis. Missing for 10: independent/third-party validation beyond vendor testimonials and more detail on breadth/accuracy of suggestions across all data types.", "evidenceIds": [ "square-supp-square-ai-assistant", "square-docs-54" ] }, { "productId": "square", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Square provides building blocks (Webhooks for event-driven triggers, Subscriptions API for recurring billing, and an MCP server letting AI tools call the API) that a developer could wire into an autonomous background automation, but there is no evidence of a native workflow/automation engine or scheduled-agent feature that runs independently without custom integration work. Square AI is described as an on-demand insight assistant, not an autonomous background automation runner. Missing for 10: a documented no-code/low-code automation or workflow builder, evidence of scheduled/triggered autonomous agent execution, and confirmation that MCP-driven agents can run unattended in the background rather than only via an interactive AI client.", "evidenceIds": [ "square-docs-19", "square-docs-23", "square-supp-mcp-remote", "square-supp-mcp-tools", "square-supp-square-ai-assistant" ] }, { "productId": "square", "storyId": "agentic-builtin-assistant", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Square AI (Beta) is documented as an in-product assistant built into seller tools that answers natural-language questions over sales/inventory data, handles routine tasks, and pulls in web data, with seller testimonials of real usage. Missing for 10: independent/hands-on verification beyond vendor testimonials, and detail on the breadth of tasks it can autonomously execute versus just answer questions.", "evidenceIds": [ "square-supp-square-ai-assistant", "square-docs-54" ] }, { "productId": "square", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square's platform is fundamentally API/SDK-driven (Node.js SDK, REST/GraphQL APIs, idempotency keys) and ships a dedicated Sandbox environment explicitly for testing automation, plus a local MCP server mode (`npx square-mcp-server start`) with env-var controls like SANDBOX=true and DISALLOW_WRITES=true that suit scripted/CI use. However, there is no explicit CI/CD pipeline documentation, GitHub Actions integration, or hands-on evidence of running Square headlessly in an actual CI pipeline. Missing for 10: explicit CI/pipeline integration guides, documented headless automation examples beyond sandbox testing, independent confirmation of CI usage.", "evidenceIds": [ "square-docs-21", "square-docs-40", "square-docs-22", "square-supp-mcp-tools", "square-gh-3", "square-gh-4" ] }, { "productId": "square", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a payments/commerce platform, not an AI agent or assistant that itself consumes external MCP servers to extend its own tool use. The evidence shows Square instead *publishes* an MCP server for other AI clients (Claude, Cursor, etc.) to plug into and call Square's APIs — the reverse of this story's client-role axis, which doesn't apply to this kind of product.", "evidenceIds": [] }, { "productId": "square", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Square documents an official hosted remote MCP server (mcp.squareup.com/mcp) with OAuth-based scoped auth plus an open-source local server, both exposing the full Square API platform, and provides setup guidance for Claude, Cursor, Windsurf, Goose. This is well-documented first-party evidence with a public GitHub repo, though independent hands-on user validation is limited. Missing for 10: independent/community confirmation of real-world agent usage beyond vendor docs.", "evidenceIds": [ "square-docs-44", "square-docs-45", "square-supp-mcp-remote", "square-supp-mcp-tools", "square-docs-52", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Square ships a first-party beta 'Square AI' seller assistant for natural-language queries over sales/inventory data, and a documented MCP server (local + hosted, OAuth-scoped) that lets AI agents like Claude/Cursor issue natural-language-driven API calls (payments, orders, catalog, etc.) via discovery tools. This gives real NL-command operability, but it's split across a beta insights assistant (limited to analysis/reporting) and third-party agent integration (MCP) rather than a single native NL control surface for all product actions. Missing for 10: evidence that Square AI itself can execute broad write/operational commands (not just analysis), and independent/hands-on validation of MCP agent workflows beyond vendor docs.", "evidenceIds": [ "square-supp-square-ai-assistant", "square-supp-mcp-remote", "square-supp-mcp-tools", "square-supp-llms-agent-guidance", "square-docs-54" ] }, { "productId": "square", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Square's evidence shows an MCP server, SDKs, GraphQL, and API Explorer, but no dedicated official CLI tool (e.g., a 'square' command-line utility for managing resources, testing APIs, or agentic workflows) is documented anywhere in the pack. The `npx square-mcp-server start` command is for launching an MCP server, not a general-purpose CLI.", "evidenceIds": [ "square-docs-45", "square-supp-mcp-tools", "square-docs-43" ] }, { "productId": "square", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Square publishes an extensive documented public REST API (payments, refunds, disputes, subscriptions, invoices, webhooks) plus GraphQL, SDKs (e.g. square-nodejs-sdk), API Explorer, sandbox testing, OAuth scopes, and an explicit llms.txt/llms-full.txt agent-consumption index with agent-specific guidance (idempotency keys, pagination) — directly supporting AI-native, agentic driving of the product. Missing for 10: no public OpenAPI/swagger spec discoverable (probe returned 404s), and no independent third-party corroboration beyond vendor docs.", "evidenceIds": [ "square-docs-44", "square-supp-llms-agent-guidance", "square-supp-graphql", "square-supp-api-explorer", "square-supp-oauth-scopes", "square-gh-4", "square-probe-1", "square-probe-3", "square-docs-21" ] }, { "productId": "square", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square supports OAuth with per-permission scopes for granular access control, and its remote MCP server explicitly uses OAuth login to 'authorize only the scopes your application needs' for agent connections; the local MCP server also supports a DISALLOW_WRITES read-only mode and SANDBOX flag for least-privilege agent setups. Missing for 10: no independent/hands-on verification of scope granularity in practice, and no explicit documentation of fine-grained scope lists specifically tailored for agent use cases beyond general OAuth scopes.", "evidenceIds": [ "square-supp-oauth-scopes", "square-supp-mcp-remote", "square-supp-mcp-tools", "square-docs-42", "square-docs-52" ] }, { "productId": "square", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square ships official, first-party SDKs (e.g. square-nodejs-sdk/TypeScript library) with documented code examples for payments, versioning, and client setup, plus broader API coverage (REST, GraphQL, OAuth, webhooks, sandbox) that AI-native developers can build against, reinforced by an explicit llms.txt/agent-guidance file and an official MCP server for programmatic AI tool access. Missing for 10: independent/hands-on developer corroboration of SDK quality beyond GitHub README snippets, and broader multi-language SDK evidence beyond Node/TypeScript.", "evidenceIds": [ "square-gh-1", "square-gh-2", "square-gh-3", "square-gh-4", "square-supp-llms-agent-guidance", "square-docs-44", "square-supp-mcp-remote", "square-supp-graphql", "square-docs-42" ] }, { "productId": "square", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square provides a documented Webhooks system with subscribing to event notifications, verifying/validating events, sandbox testing, and event logs — a standard webhook mechanism usable by any AI-native integration (including via its MCP server/API access). missing for 10: no explicit example of an AI agent programmatically subscribing to webhooks, and no independent hands-on corroboration beyond first-party docs.", "evidenceIds": [ "square-docs-19", "square-docs-20", "square-docs-39", "square-supp-api-explorer" ] }, { "productId": "square", "storyId": "api-interactive-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square documents a genuine interactive API Explorer that builds/sends real HTTP requests against Sandbox or production resources (customers, orders, catalog), plus a GraphQL Explorer for runnable queries, giving developers a hands-on interactive reference. Missing for 10: no independent/third-party corroboration of the API Explorer's usability and no discoverable OpenAPI spec (probe confirms 404s), so tooling depth is documented only by the vendor.", "evidenceIds": [ "square-supp-api-explorer", "square-docs-43", "square-docs-48", "square-supp-graphql", "square-probe-3" ] }, { "productId": "square", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No documentation page or probe in the evidence pack shows a downloadable OpenAPI/Swagger spec; explicit probes for common OpenAPI paths (openapi.json, swagger.json, etc.) all returned 404, and no docs page links to a machine-readable spec file (only an interactive API Explorer, GraphQL schema, and SDKs are mentioned).", "evidenceIds": [ "square-probe-3", "square-probe-2", "square-docs-43", "square-supp-api-explorer" ] }, { "productId": "square", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square documents a dedicated Sandbox environment (square-docs-21, square-docs-40) with sandbox testing for disputes/payments, and the API Explorer and MCP server explicitly support running against Sandbox resources instead of production (square-docs-48, square-supp-api-explorer, square-supp-mcp-remote with 'run a local instance configured to access a seller's Sandbox environment', and SANDBOX=true env var in square-supp-mcp-tools). This directly enables AI-native agents to test without touching production data. Missing for 10: independent/hands-on confirmation that sandbox parity with production is complete and that MCP sandbox mode is broadly validated by third-party users rather than only vendor docs.", "evidenceIds": [ "square-docs-21", "square-docs-40", "square-docs-48", "square-supp-api-explorer", "square-supp-mcp-remote", "square-supp-mcp-tools", "square-docs-16" ] }, { "productId": "square", "storyId": "api-versioning-policy", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square's API clearly supports date-based versioning — SDK calls can override the API version (\"version: '2024-05-04'\") and the MCP tool documents a SQUARE_VERSION pinning control — showing a live, explicit versioning scheme. However, no evidence in the pack shows a documented deprecation policy (timelines, sunset notices, migration guides) that would let an AI-native user reliably plan around version lifecycle changes. Missing for 10: an explicit deprecation/sunset policy document, version changelog, or migration guidance referenced anywhere in the evidence.", "evidenceIds": [ "square-gh-2", "square-supp-mcp-tools", "square-docs-22" ] }, { "productId": "square", "storyId": "automatic-tax-calculation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers payments, refunds, disputes, webhooks, invoices, and MCP tooling but contains no mention of tax calculation, tax rates, VAT/GST handling, or automated tax collection features.", "evidenceIds": [] }, { "productId": "square", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows GraphQL reducing multiple API calls into one query (square-docs-41/square-supp-graphql) and a generic MCP `make_api_request` tool, but no documentation or example of true bulk/batch operations (e.g., batch-upserting catalog items, bulk inventory adjustments, or bulk order processing) that would let an AI-native user act across many items in one call.", "evidenceIds": [ "square-docs-41", "square-supp-graphql", "square-supp-mcp-tools" ] }, { "productId": "square", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Square exposes webhooks/event notifications that let a developer wire custom code to react to events (square-docs-19, square-docs-39) and has narrow built-in 'custom rules and alerts' for fraud/risk management (square-docs-28), but there is no general-purpose, user-definable rules/automation engine ('if event X then action Y') across the platform's business events. Missing for 10: a documented no-code/low-code rule builder, broader event-trigger coverage beyond payments/fraud, and evidence of the AI-native user directly authoring such rules (vs. developers writing webhook handlers).", "evidenceIds": [ "square-docs-19", "square-docs-39", "square-docs-28", "square-docs-20" ] }, { "productId": "square", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Square's Subscriptions API and Invoices API let sellers configure recurring billing plans, which is a form of scheduled recurring workflow accessible via the platform's API/MCP surface, but there is no evidence of a general-purpose job/task scheduler or cron-like automation mechanism that an AI agent could use to schedule arbitrary recurring workflows beyond billing. missing for 10: a generic scheduling/automation API (cron, timers, recurring task triggers) independent of payments/subscriptions, evidence of MCP tools exposing scheduling controls, and any hands-on confirmation of recurring workflow automation working end-to-end.", "evidenceIds": [ "square-docs-23", "square-docs-18", "square-supp-mcp-tools" ] }, { "productId": "square", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a payments/commerce platform, not an automation-builder with a concept of versioned, reviewable, rollback-capable 'automations' (like workflow/rules engines in no-code tools); nothing in the evidence describes automation version control or rollback, and this is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "square", "storyId": "dunning-failed-payment-recovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Square documents a Subscriptions API and general payments/invoicing capabilities, but no evidence describes automated retry logic, smart dunning, or recovery emails for failed subscription payments; a community comment even questions whether Square's subscription handling is mature.", "evidenceIds": [ "square-docs-23", "square-comm-1" ] }, { "productId": "square", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square's Web Payments SDK is explicitly documented for embedding customizable card/ACH/Cash App/Afterpay payment components directly into a developer's own site rather than redirecting to a hosted checkout page, and this is backed by a full Payments API, Node SDK, and sandbox testing tools. missing for 10: no independent/hands-on developer report confirming ease of customization or styling flexibility beyond first-party docs.", "evidenceIds": [ "square-docs-31", "square-docs-5", "square-docs-6", "square-docs-7", "square-docs-8", "square-gh-1", "square-docs-21", "square-docs-24" ] }, { "productId": "square", "storyId": "fraud-screening-rules", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Square's marketing docs explicitly claim ML-based fraud blocking and custom rules and alerts to manage risk, matching the story's core ask, but this is a single marketing page with no API or developer documentation detailing how block, review, and allow rules are configured or how fraud scores are surfaced to finance-ops users. missing for 10: developer-facing API/dashboard docs for configuring block vs review vs allow rules, detail on the fraud-score output format, independent or hands-on corroboration of the ML scoring and rule engine.", "evidenceIds": [ "square-docs-28", "square-docs-29" ] }, { "productId": "square", "storyId": "hosted-checkout-page", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Square's Payments API, Web Payments SDK (embeddable UI), Invoices, and various backend APIs, but never mentions a vendor-hosted, conversion-optimized checkout page (e.g., a Checkout API or Payment Links) that a developer could redirect customers to without building payment UI. Web Payments SDK (square-docs-31) actually requires building your own UI, the opposite of this story.", "evidenceIds": [] }, { "productId": "square", "storyId": "idempotent-api-retries", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square has a dedicated 'Idempotency' documentation page and its agent-facing llms.txt explicitly states 'every write endpoint accepts an idempotency key' to prevent duplicate charges from retries. This directly matches the story's core requirement. Missing for 10: independent/hands-on developer confirmation of idempotency behavior under real network-failure retries, and more detail on key expiration/scope beyond the doc title.", "evidenceIds": [ "square-docs-22", "square-supp-llms-agent-guidance" ] }, { "productId": "square", "storyId": "integrate-from-docs-in-a-day", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square provides extensive first-party docs for card, ACH, Cash App, Afterpay payments, plus sandbox testing and idempotency guidance, and the Node.js/TypeScript SDK shows concrete copy-paste code (client.payments.create). This supports fast integration, but the evidence pack shows only one language's SDK example, no explicit 'under a day' quickstart guide, and no cross-language parity proof (Python, Java, PHP, etc.) or independent developer testimony confirming a same-day integration timeline. missing for 10: multi-language copy-paste examples, an explicit time-to-integrate quickstart, independent hands-on confirmation of a sub-day integration.", "evidenceIds": [ "square-docs-5", "square-docs-21", "square-docs-22", "square-gh-1", "square-gh-3", "square-gh-4", "square-docs-40" ] }, { "productId": "square", "storyId": "marketplace-split-payments", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square provides the core building blocks for a marketplace: OAuth to onboard sellers to their own Square accounts (square-docs-42, square-docs-51), the OAuth access-token scope model (square-supp-oauth-scopes), Payments API with 'Collect Application Fees' for platform fee splitting (square-docs-37), and a Payouts API for disbursing funds to sellers (square-docs-17). However, the evidence never documents a unified 'split payment across multiple parties in one transaction' primitive or destination-account payout routing akin to Stripe Connect transfers—application fees and payouts appear as separate mechanisms rather than an integrated marketplace split-and-payout flow, and there's no dedicated marketplace/platform guide or case study. missing for 10: explicit multi-party split-payment/transfer API documentation, an end-to-end marketplace onboarding+split+payout guide, and independent/hands-on validation that this pattern works in production.", "evidenceIds": [ "square-docs-42", "square-docs-51", "square-supp-oauth-scopes", "square-docs-37", "square-docs-17", "square-docs-50" ] }, { "productId": "square", "storyId": "multi-currency-charge-settle", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of multi-currency charging, FX conversion, or cross-currency settlement anywhere in Square's docs, GraphQL/REST APIs, MCP server, or payments pages — all payment method docs (cards, ACH, Afterpay, Cash App) are silent on currency handling. This is a fair axis for a payments platform, so absence of evidence yields none rather than na.", "evidenceIds": [ "square-docs-5", "square-docs-6", "square-docs-7", "square-docs-8", "square-docs-17", "square-docs-24" ] }, { "productId": "square", "storyId": "no-code-payment-links", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack focuses almost entirely on Square's developer APIs, SDKs, and MCP/AI tooling for building payment integrations, not on the no-code merchant dashboard feature of generating a shareable payment link. No citation mentions 'Payment Links' or a dashboard flow for founders to create a link without coding.", "evidenceIds": [] }, { "productId": "square", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Square's developer platform exposes an extensive set of APIs (payments, refunds, disputes, invoices, subscriptions, payouts, webhooks, OAuth, GraphQL, catalog/customers/orders/inventory/labor) plus an MCP server giving 'programmatic access to everything the APIs offer', suggesting broad UI/API parity for core commerce and back-office functions. However, some UI-only surfaces (e.g., the in-product Square AI seller assistant, POS idle-screen customization, dashboard reporting UI) are not shown to have full API equivalents, and there is no explicit vendor or independent claim of 100% UI-API parity. missing for 10: an explicit parity statement or audit confirming every UI feature (e.g., Square AI insights, POS-specific dashboard views) is fully API-accessible, and independent/hands-on verification of edge-case coverage.", "evidenceIds": [ "square-docs-17", "square-docs-18", "square-docs-23", "square-docs-38", "square-docs-39", "square-docs-41", "square-docs-42", "square-docs-44", "square-supp-mcp-tools", "square-supp-square-ai-assistant" ] }, { "productId": "square", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Square's docs describe extensive APIs to create/read individual objects (payments, customers, orders, catalog) and even an MCP/GraphQL layer, but there is no evidence of a bulk data-export feature, standard open-format export (CSV/JSON dump), or documented account-closure/data-portability process letting a user take all their data and leave.", "evidenceIds": [] }, { "productId": "square", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Square is a closed-source SaaS payments platform; the evidence only shows open-source client SDKs (square-nodejs-sdk) and an MCP server wrapper on GitHub, not the core product/platform source under an open license. No documentation states Square's actual service code is open-sourced or licensed for public reading.", "evidenceIds": [ "square-gh-4", "square-docs-45", "square-supp-mcp-tools" ] }, { "productId": "square", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a proprietary, hosted payments/commerce platform (SaaS with cloud APIs) — self-hosting the core product is not a coherent capability for this category of service, as payment processing inherently requires Square's own infrastructure.", "evidenceIds": [] }, { "productId": "square", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Square exposes a Payouts API (square-docs-17) which presumably supports payout schedule and reconciliation data, but the evidence pack gives no detail on schedule controls (e.g., daily/weekly/manual), nor on how payouts break down into constituent charges, fees, and refunds. missing for 10: documentation of payout schedule configuration options, payout entries/line-item breakdown by charge/fee/refund, and any independent/hands-on confirmation of reconciliation accuracy.", "evidenceIds": [ "square-docs-17", "square-docs-13", "square-docs-14" ] }, { "productId": "square", "storyId": "pci-scope-reduction", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square's Web Payments SDK and Card Payments API use client-side tokenization (e.g., sourceId/ccof: tokens in the SDK, 'Save Card on File') so raw card numbers are handled by Square's SDK rather than the developer's server, which is the standard architecture for reducing PCI scope. However, the evidence pack contains no explicit statement about PCI DSS compliance level, SAQ A eligibility, or scope-reduction guidance from Square itself. Missing for 10: an explicit PCI DSS/SAQ-A scope statement, documentation of compliance certifications, and independent confirmation that using these SDKs actually reduces a merchant's PCI scope.", "evidenceIds": [ "square-docs-31", "square-docs-5", "square-gh-1", "square-docs-9" ] }, { "productId": "square", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions data residency, regional data storage options, or geographic control over where Square account/API data is stored; the pack covers payments features, MCP/AI tooling, and dev tools but never addresses data residency.", "evidenceIds": [] }, { "productId": "square", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a payments/commerce platform, not an AI model provider or consumer-data product with AI-training data usage; the evidence pack contains no mention of AI training data opt-out or model-training data controls, and this axis is not a natural fit for its product category.", "evidenceIds": [] }, { "productId": "square", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses data retention policies, data deletion capabilities, or privacy controls for AI/MCP interactions with Square data. While OAuth scopes and access-token controls are documented, nothing speaks to retaining or deleting data collected via AI tools or the MCP server.", "evidenceIds": [] }, { "productId": "square", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a payments/commerce platform (and its MCP/AI tooling), not an AI coding tool or agent whose own telemetry collection is a relevant privacy concern for AI-native users; no evidence pack content addresses telemetry opt-out for any Square tool, so this axis is a category mismatch rather than a missing capability.", "evidenceIds": [] }, { "productId": "square", "storyId": "recurring-subscription-billing", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square documents a dedicated Subscriptions API (square-docs-23), confirming recurring billing support, but the evidence pack gives no detail on plan configuration, trial periods, upgrade/downgrade flows, or proration logic. An old community comment (square-comm-1) also shows subscriptions were historically seen as a gap, though this predates the current API's existence.\nMissing for 10: documented support for trials, plan upgrades/downgrades, and proration calculations; independent/hands-on confirmation these work as expected.", "evidenceIds": [ "square-docs-23", "square-comm-1" ] }, { "productId": "square", "storyId": "refunds-full-partial", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Square documents a dedicated Refunds API supporting both linked and unlinked refunds (full/partial refunds for existing or off-platform payments), which covers the API side, and the dashboard is implied via the broader Square seller product but not explicitly documented for refund issuance in the evidence pack. missing for 10: explicit dashboard UI documentation/screenshots showing refund issuance from the Seller Dashboard, and confirmation of partial-amount refund support in docs text.", "evidenceIds": [ "square-docs-13", "square-docs-14", "square-docs-36" ] }, { "productId": "square", "storyId": "respond-to-disputes-evidence", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square documents a dedicated Disputes API with a 'Process Disputes' guide and sandbox testing support, indicating sellers/developers can submit evidence and interact with dispute records programmatically. However, the evidence pack lacks detail on structured evidence-submission fields, dispute status/lifecycle event types, or webhook notifications specific to dispute state changes, and marketing copy suggests Square often manages the dispute process on the seller's behalf rather than the user actively tracking it end-to-end. Missing for 10: detailed evidence-field schema, dispute status/lifecycle event documentation, and independent confirmation of end-to-end resolution tracking.", "evidenceIds": [ "square-docs-15", "square-docs-16", "square-docs-38", "square-docs-30" ] }, { "productId": "square", "storyId": "sandbox-test-mode-fidelity", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Square documents a dedicated Sandbox environment (square-docs-21, square-docs-40) with Sandbox Payments docs, sandbox-specific dispute testing (square-docs-16), and an API Explorer that lets developers run requests against actual Sandbox or production resources (square-docs-48, square-supp-api-explorer), covering the core sandbox/test-mode workflow for payments and disputes. missing for 10: explicit enumeration of test card numbers for every decline/dispute scenario and independent developer corroboration that the sandbox fully mirrors production edge cases.", "evidenceIds": [ "square-docs-21", "square-docs-40", "square-docs-16", "square-docs-48", "square-supp-api-explorer" ] }, { "productId": "square", "storyId": "send-hosted-invoices", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Square has a documented Invoices API confirming hosted invoicing exists, but the evidence pack lacks detail on automatic reminders, online payment collection specifics within invoices, or hosted invoice pages. Missing for 10: documentation on automatic reminder scheduling, hosted payment page details, and independent/hands-on confirmation of the invoicing workflow.", "evidenceIds": [ "square-docs-18" ] }, { "productId": "square", "storyId": "settlement-reconciliation-reports", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square provides a Payouts API for settlement data and separate Refunds and Disputes APIs, plus marketing copy about seeing 'all your sales in one report' to reduce reconciliation effort, but there's no dedicated documentation showing an itemized report that ties bank deposits to fees, refunds, and chargebacks in one place. missing for 10: explicit itemized payout/settlement report schema breaking down fees, refunds, chargebacks; documentation linking payout amounts directly to bank deposit records; independent confirmation from finance-ops users that reconciliation works end-to-end.", "evidenceIds": [ "square-docs-17", "square-docs-13", "square-docs-15", "square-docs-26" ] }, { "productId": "square", "storyId": "wallets-local-payment-methods", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square's Payments API and Web Payments SDK docs confirm ACH bank transfers, Afterpay/Clearpay (BNPL), Cash App, and card payments in one integration, but the evidence never explicitly documents Apple Pay or Google Pay wallet support alongside these, nor generic 'bank redirect' methods beyond ACH. missing for 10: explicit Apple Pay/Google Pay digital wallet docs, broader local bank-redirect methods (iDEAL, etc.), and independent confirmation that all these methods coexist in a single unified checkout flow.", "evidenceIds": [ "square-docs-6", "square-docs-7", "square-docs-8", "square-docs-31", "square-docs-5", "square-docs-32", "square-docs-33", "square-docs-34" ] }, { "productId": "square", "storyId": "webhook-delivery-reliability", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square documents webhook subscriptions and signature verification/validation of event notifications, plus mentions of webhook event logs in the dev tools, which covers signed delivery and basic observability. However, the evidence pack contains no explicit documentation of automatic retry behavior or an event replay mechanism, which are core parts of the story. missing for 10: documented automatic retry policy for failed webhook deliveries, explicit event replay/resend capability, independent confirmation of retry/replay behavior.", "evidenceIds": [ "square-docs-19", "square-docs-20", "square-docs-39", "square-supp-api-explorer" ] }, { "productId": "stripe", "storyId": "accept-card-payment-online", "verdict": "disputed", "quality": 6, "confidence": "medium", "rationale": "Stripe's docs strongly support rapid onboarding: no-code Payment Links, hosted Checkout pages, and a live testimonial confirms setup and recurring payments working 'in less than an hour' (stripe-docs-4, stripe-docs-2, stripe-comm-9). However, independent community reports concretely contradict universal same-day acceptance — users report Stripe denying account creation entirely or 'nuking' an existing business's payment capability without quick support resolution (stripe-comm-1, stripe-comm-4, stripe-comm-5), showing that for some founders (especially certain geographies/business types) the promised fast, frictionless activation does not materialize. missing for 10: evidence resolving how common these denials/delays are, and first-party docs addressing account approval timelines or geographic/business restrictions.", "evidenceIds": [ "stripe-docs-4", "stripe-docs-2", "stripe-docs-50", "stripe-comm-9", "stripe-comm-1", "stripe-comm-4", "stripe-comm-5" ] }, { "productId": "stripe", "storyId": "agent-handles-dispute-end-to-end", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe docs explicitly state the Disputes API supports retrieving, uploading evidence, responding to disputes, and receiving dispute webhook events, and the hosted MCP server's documented tool surface includes 'disputes (update)' alongside generic read/write API access, restricted-key scoping for agents, and webhook-based event delivery — covering the retrieve→assemble→submit flow programmatically. Missing for 10: a concrete end-to-end worked example (e.g., a sample agent script that assembles and submits evidence), and clarity on whether dispute submission falls under the human-confirmation gate applied to other write actions.", "evidenceIds": [ "stripe-docs-18", "stripe-docs-41", "stripe-supp-mcp-tools", "stripe-docs-8", "stripe-supp-restricted-keys-agents" ] }, { "productId": "stripe", "storyId": "agent-monitors-dunning", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe documents the full loop an agent needs: webhooks/event destinations for detecting failed payments and dispute events (stripe-docs-8, stripe-docs-53, stripe-supp-event-destinations), Smart Retries and no-code revenue recovery/dunning automation with recovery analytics (stripe-docs-14, stripe-docs-15, stripe-docs-56), and API/MCP write access (subscriptions, invoices, disputes) with restricted-key scoping and human-confirmation guardrails so an agent can drive retries and outreach programmatically (stripe-supp-mcp-tools, stripe-supp-mcp-write-confirmation, stripe-supp-restricted-keys-agents, stripe-docs-41). Idempotency support further protects automated retry logic (stripe-docs-9). missing for 10: no first-party or hands-on example of an agent specifically orchestrating dunning outreach (e.g., emails/SMS) end-to-end, and no independent/community confirmation of this exact agent workflow in production.", "evidenceIds": [ "stripe-docs-8", "stripe-docs-53", "stripe-docs-14", "stripe-docs-15", "stripe-docs-56", "stripe-docs-9", "stripe-docs-41", "stripe-supp-mcp-tools", "stripe-supp-mcp-write-confirmation", "stripe-supp-restricted-keys-agents", "stripe-supp-event-destinations" ] }, { "productId": "stripe", "storyId": "agent-provisions-payment-link", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's MCP server documents stripe_api_write with create/update support for products, prices, and payment links, plus stripe_implementation_planner to guide multi-step builds, enabling an agent to provision a product, price, and payment link in one session via a single authenticated MCP/API connection; the CLI/sandbox provisioning (stripe sandbox create) also lets agents get working keys without manual account setup. Missing for 10: a hands-on end-to-end transcript/independent report of an agent actually completing this exact three-step chain in one session, and clarity on whether human-confirmation gating (required for refunds/payments) also intercepts routine create-product/price/payment-link calls.", "evidenceIds": [ "stripe-supp-mcp-tools", "stripe-docs-16", "stripe-supp-mcp-write-confirmation", "stripe-docs-4", "stripe-supp-cli-agent-setup" ] }, { "productId": "stripe", "storyId": "agent-reconciles-payouts", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Stripe's API and MCP tooling explicitly expose payout and balance-transaction data for programmatic/agent access — the documented stripe_api_read method list includes 'payouts, and balance transactions', and stripe_analytics/stripe_report can run balance and payout financial reports, letting an agent pull the data needed to match deposits to charges (stripe-supp-mcp-tools, stripe-supp-analytics-ai, stripe-docs-34/52/68). However, there is no first-party tutorial or worked example specifically demonstrating automated reconciliation logic (matching a bank deposit to its underlying charges), and no independent/hands-on evidence confirming this reconciliation workflow works end-to-end. Missing for 10: a documented reconciliation workflow/tutorial tying payout amounts to constituent balance-transaction charges, and independent verification of an agent successfully performing this reconciliation.", "evidenceIds": [ "stripe-supp-mcp-tools", "stripe-supp-analytics-ai", "stripe-docs-34", "stripe-docs-52", "stripe-docs-68" ] }, { "productId": "stripe", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe hosts a live llms.txt (probe confirms HTTP 200 with agent-oriented guidance), a full .md-suffixed docs mirror (docs.stripe.com/*.md), a machine-readable skills index at /.well-known/skills/index.json, and dedicated agent-oriented docs (agents.md, mcp.md, directory.md) explicitly designed for pointing agents at. This is independently verified by probes, not just vendor claims. missing for 10: no independent third-party (non-Stripe) report of an agent successfully consuming llms.txt end-to-end in production.", "evidenceIds": [ "stripe-probe-1", "stripe-probe-2", "stripe-supp-skills-catalog", "stripe-probe-7", "stripe-docs-29", "stripe-docs-13" ] }, { "productId": "stripe", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe supports AI-generated insights primarily through its MCP `stripe_analytics`/`stripe_report` tools, which let an AI agent query metrics like MRR, churn rate, and run custom SQL against reporting tables, and Radar applies AI algorithms to score fraud risk in real time. However, these insights are largely agent-mediated (via MCP) rather than a native in-Dashboard AI assistant proactively surfacing suggestions to the user. Missing for 10: evidence of a built-in conversational/insights UI inside the Dashboard itself (not just via external agent+MCP), broader proactive 'suggestions' beyond analytics queries, and independent/hands-on validation of insight quality.", "evidenceIds": [ "stripe-docs-74", "stripe-supp-analytics-ai", "stripe-docs-22", "stripe-docs-15" ] }, { "productId": "stripe", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Stripe ships substantial infrastructure for background automation — webhooks that push real-time events for asynchronous processing, Billing's automated recurring payments/renewals, Smart Retries and revenue-recovery automation that requires no code, Radar's automatic fraud scoring, and an MCP server plus agent plugins that let AI agents act on Stripe data continuously. However, Stripe explicitly gates autonomous execution: 'Stripe requires human confirmation before it takes certain stripe_api_write actions, such as refunds and outbound payments,' meaning fully unattended agentic automation is capped for sensitive operations, and there's no independent/hands-on evidence of long-running autonomous background agent workflows in production. Missing for 10: evidence of fully unattended agent automations without human-in-the-loop gating, and independent corroboration of real-world background agent runs.", "evidenceIds": [ "stripe-docs-8", "stripe-docs-14", "stripe-docs-15", "stripe-docs-22", "stripe-supp-mcp-write-confirmation", "stripe-supp-agent-plugin", "stripe-supp-machine-payments" ] }, { "productId": "stripe", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Stripe exposing an MCP server, CLI, SDKs, and agent plugins so *external* AI agents (Claude, Codex, Cursor, etc.) can act on Stripe's behalf, and it describes AI-driven backend features (Radar fraud scoring, smart retries). But none of the evidence describes a built-in, in-product AI assistant/chat feature embedded in the Stripe Dashboard itself that a user converses with to delegate tasks — the 'analyze with AI' and analytics tooling are also delivered via the external MCP interface rather than a native assistant UI.", "evidenceIds": [ "stripe-docs-74", "stripe-supp-analytics-ai", "stripe-docs-22" ] }, { "productId": "stripe", "storyId": "agentic-headless", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe's CLI and Workbench Shell provide scriptable, non-interactive access (stripe sandbox create, stripe products create, stripe listen, agent setup) usable in CI pipelines, backed by idempotency keys, restricted API keys, and a documented sandbox that requires no account registration — all designed for headless/automated use including by coding agents. missing for 10: no explicit first-party CI example (e.g. GitHub Actions workflow) or independent hands-on report of running the CLI in a CI pipeline.", "evidenceIds": [ "stripe-docs-16", "stripe-docs-30", "stripe-supp-workbench-shell", "stripe-supp-cli-agent-setup", "stripe-docs-9", "stripe-supp-restricted-keys-agents", "stripe-docs-32" ] }, { "productId": "stripe", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe is a payments platform/API, not an agent host or assistant application that a user configures with pluggable MCP servers for its own use; all evidence instead shows Stripe publishing its own MCP server (server role) and shipping plugins/skills for other agents like Claude Code/Cursor to consume, which is the opposite direction from this story's client-role axis.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe ships a well-documented, independently probed official hosted MCP server (mcp.stripe.com) exposing API tools, analytics, and knowledge-base search, with OAuth-based auth/governance, human-confirmation for write actions, and connected-account support; a live probe confirms the OAuth-gated endpoint is real and functioning. Missing for 10: no independent third-party hands-on review of actual agent usage beyond Stripe's own docs/probes.", "evidenceIds": [ "stripe-docs-13", "stripe-docs-28", "stripe-probe-4", "stripe-probe-6", "stripe-supp-mcp-tools", "stripe-supp-mcp-write-confirmation", "stripe-supp-mcp-sessions-governance", "stripe-supp-mcp-connected-accounts" ] }, { "productId": "stripe", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "Stripe exposes an MCP server plus Directory/Analytics tools that let AI agents perform natural-language-driven actions (search products, read/write API resources, query MRR, run implementation planner) confirmed live via probe, and CLI/agent-plugin tooling lets coding agents set up sandboxes and integrations via NL prompts. However, this is agent-mediated (a separate AI agent translates NL into MCP/CLI calls) rather than the product itself having a native NL command interface, and write actions require human confirmation clicks rather than pure NL operation. missing for 10: evidence of a first-party conversational NL interface within Stripe's own Dashboard/product (not via third-party agent), and confirmation that full workflows can complete end-to-end via NL without manual approval steps.", "evidenceIds": [ "stripe-probe-6", "stripe-supp-mcp-tools", "stripe-supp-mcp-write-confirmation", "stripe-supp-analytics-ai", "stripe-supp-agent-plugin", "stripe-docs-70", "stripe-supp-directory-search", "stripe-supp-cli-agent-setup" ] }, { "productId": "stripe", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe ships a well-documented official CLI (docs.stripe.com/stripe-cli) for building, testing, and managing integrations, explicitly positioned as 'agent-ready tooling' with commands like `stripe agent setup` (auto-configures Claude Code/Codex/Cursor), `stripe sandbox create` for keyless agent provisioning, `stripe directory search`, and `stripe projects init`. This is corroborated by an independent probe confirming the docs page exists and by Workbench's browser-based Shell mirroring CLI commands. Missing for 10: independent hands-on/community review specifically validating CLI usability for AI-native workflows beyond Stripe's own docs.", "evidenceIds": [ "stripe-docs-30", "stripe-docs-75", "stripe-probe-5", "stripe-supp-cli-agent-setup", "stripe-supp-agent-plugin", "stripe-docs-16", "stripe-supp-projects-provisioning", "stripe-supp-directory-search" ] }, { "productId": "stripe", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe exposes a comprehensive, well-documented REST API with idempotency, restricted keys, versioning, sandboxes, webhooks, OpenAPI-generated SDKs, and CLI/Workbench tooling, and this is independently corroborated by a probe confirming the API and llms.txt are live and reachable. missing for 10: no independent third-party benchmark of raw API completeness beyond docs/probes, and OpenAPI spec discovery via well-known paths returned 404s per stripe-probe-3.", "evidenceIds": [ "stripe-docs-9", "stripe-docs-25", "stripe-docs-58", "stripe-docs-67", "stripe-docs-45", "stripe-docs-59", "stripe-docs-46", "stripe-probe-2", "stripe-probe-1", "stripe-probe-3", "stripe-docs-30", "stripe-supp-workbench-shell" ] }, { "productId": "stripe", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe explicitly documents restricted API keys (RAKs) as the recommended least-privilege credential for AI agents—developers select per-resource Read/Write/None permissions—and pairs this with MCP OAuth sessions (per-client revocation, connected-account scoping via Stripe-Account header, human confirmation for write actions like refunds, and Workbench tool-call logs), giving concrete scoped-credential issuance and governance for agents. This is corroborated by a live probe confirming the OAuth-gated MCP endpoint. Missing for 10: independent/hands-on developer confirmation of the RAK issuance workflow in practice beyond first-party docs.", "evidenceIds": [ "stripe-docs-67", "stripe-supp-restricted-keys-agents", "stripe-supp-mcp-sessions-governance", "stripe-supp-mcp-connected-accounts", "stripe-supp-mcp-write-confirmation", "stripe-probe-6" ] }, { "productId": "stripe", "storyId": "agentic-sdks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe publishes official SDKs/client libraries generated from OpenAPI specs, plus AI-native additions like @stripe/agent-toolkit, @stripe/ai-sdk, token-meter, a hosted OAuth-gated MCP server, agent plugins for Claude/Codex/Cursor, and a machine-readable skills catalog — strongly evidencing an AI-native developer can build against official SDKs. missing for 10: independent (non-Stripe) hands-on developer reports specifically validating the newer agent-toolkit/ai-sdk packages in production.", "evidenceIds": [ "stripe-docs-46", "stripe-supp-ai-sdks", "stripe-supp-agent-plugin", "stripe-supp-skills-catalog", "stripe-probe-6", "stripe-probe-7", "stripe-docs-13", "stripe-gh-3" ] }, { "productId": "stripe", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe supports registering HTTPS webhook endpoints that push real-time events (payment success, disputes, subscription renewals, etc.), and this is directly usable by AI agents via the MCP server's stripe_api_write tool (webhook endpoint creation is explicitly listed as a supported MCP method) and via event-destinations delivering to multiple destination types. missing for 10: no hands-on/independent example of an agent actually subscribing to and consuming webhook events end-to-end, and no dedicated agent-specific webhook subscription API distinct from the standard developer webhook flow.", "evidenceIds": [ "stripe-docs-8", "stripe-docs-35", "stripe-docs-53", "stripe-docs-63", "stripe-supp-mcp-tools", "stripe-supp-event-destinations" ] }, { "productId": "stripe", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe's Workbench includes an in-Dashboard API Explorer/Shell that lets users visually explore API resources and execute real, runnable API calls (including against sandboxes), and Workbench's shell exposes CLI/API autocompletion — this is a genuine interactive, runnable API reference. However, evidence doesn't show a public-facing interactive API reference page (like a standalone docs.stripe.com/api with try-it-now runnable code snippets) accessible without Dashboard login, nor independent/community confirmation of the experience quality. missing for 10: evidence of a public runnable API reference outside the authenticated Dashboard, independent/hands-on user reviews of the API explorer experience, confirmation that all endpoints are runnable (not just Shell CLI-style commands).", "evidenceIds": [ "stripe-supp-workbench-shell", "stripe-docs-75", "stripe-probe-2" ] }, { "productId": "stripe", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe publishes machine-readable OpenAPI spec files explicitly for generating SDKs/clients (stripe-docs-46, github.com/stripe/openapi), and docs.stripe.com also serves machine-readable .md versions of every doc page plus an llms.txt index (stripe-probe-1, stripe-probe-2), directly serving AI-native consumption needs. However, a direct openapi.json/swagger.json was not found at the docs.stripe.com domain itself (stripe-probe-3 shows 404s on guessed paths), meaning discovery requires knowing the separate GitHub repo rather than a single canonical documented download link. Missing for 10: a first-party documented URL/endpoint for the OpenAPI spec directly from docs.stripe.com (not just GitHub), and independent hands-on confirmation of spec completeness/versioning.", "evidenceIds": [ "stripe-docs-46", "stripe-probe-1", "stripe-probe-2", "stripe-probe-3" ] }, { "productId": "stripe", "storyId": "api-sandbox", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe documents a dedicated sandbox environment isolated from live/production data (stripe-docs-32, stripe-docs-43, stripe-docs-57), test cards/values that simulate transactions without moving real funds (stripe-docs-10, stripe-docs-65), and anonymous sandbox provisioning explicitly for coding agents via CLI (stripe-docs-16), plus MCP/Workbench access scoped per sandbox vs live mode (stripe-supp-mcp-sessions-governance, stripe-supp-workbench-shell). Missing for 10: independent hands-on confirmation from a third party that agent-driven sandbox testing works end-to-end without friction.", "evidenceIds": [ "stripe-docs-32", "stripe-docs-43", "stripe-docs-57", "stripe-docs-10", "stripe-docs-65", "stripe-docs-16", "stripe-supp-mcp-sessions-governance", "stripe-supp-workbench-shell", "stripe-supp-cli-agent-setup" ] }, { "productId": "stripe", "storyId": "api-versioning-policy", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe documents a clear API versioning policy: monthly releases contain only backward-compatible changes, and users can safely upgrade without breaking existing code, with explicit versioning docs. This directly matches the story's requirement of versioned APIs with a documented deprecation/compatibility policy. Missing for 10: no explicit deprecation timeline/sunset schedule detail or independent hands-on verification of long-term version support beyond the docs' own claims.", "evidenceIds": [ "stripe-docs-45", "stripe-docs-59" ] }, { "productId": "stripe", "storyId": "automatic-tax-calculation", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Stripe Tax explicitly automates sales tax, VAT, and GST calculation and collection across transactions, including no-code tax collection on Payment Links, backed by first-party docs. Missing for 10: independent/hands-on corroboration of accuracy across jurisdictions and any detail on filing/remittance support beyond calculation and collection.", "evidenceIds": [ "stripe-docs-20", "stripe-docs-48" ] }, { "productId": "stripe", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe supports some bulk-style operations relevant to AI agents — bulk product catalog import via the v2 Product Catalog Import API (CSV up to 4GB, upsert/replace modes), List CheckoutSessions for bulk fulfillment, and MCP/analytics tools that can query/report across many objects (stripe_analytics, stripe_report) — but there is no documented generic bulk-write or batch-update API (e.g., bulk refunds, bulk subscription updates, bulk customer edits) that an AI agent could invoke across many arbitrary items at once; most single-object write tools (stripe_api_write, Refunds API, etc.) operate one record at a time with idempotency keys rather than true batch semantics. missing for 10: a documented bulk/batch API for core objects (customers, charges, subscriptions, refunds) beyond catalog import, evidence of MCP or CLI tools performing multi-item operations in one call, and independent/hands-on confirmation of bulk operation reliability.", "evidenceIds": [ "stripe-supp-acs-catalog-import", "stripe-supp-acs-orders-attribution", "stripe-supp-analytics-ai", "stripe-supp-mcp-tools", "stripe-docs-9" ] }, { "productId": "stripe", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe provides the event backbone needed for rule-based automation — webhooks/event destinations that fire on account events (stripe-docs-8, stripe-docs-53, stripe-supp-event-destinations) — plus some built-in automated actions like Smart Retries and Radar's real-time risk rules (stripe-docs-14, stripe-docs-22). A third-party Dashboard app (Kyber) explicitly offers a no-code rule builder that 'assigns tasks and automates common workflows based on Stripe events' (e.g., Slack alert on dispute), which matches the story closely (stripe-intdir-6). However, this rule-definition UI is a third-party app, not a native first-party Stripe rules engine, and there's no evidence of a built-in general-purpose 'if event X then action Y' configurator inside Stripe itself. Missing for 10: a native first-party no-code/low-code rule engine for arbitrary event-triggered actions, and independent hands-on confirmation of such rule-based automation in practice.", "evidenceIds": [ "stripe-docs-8", "stripe-docs-53", "stripe-docs-63", "stripe-docs-22", "stripe-docs-14", "stripe-intdir-6", "stripe-supp-event-destinations" ] }, { "productId": "stripe", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Billing natively automates recurring payment jobs (subscriptions, invoicing, trials, renewals, smart retries) and this can be driven via API/MCP by an AI agent, plus Stripe Projects/CLI/Workbench let agents script and schedule integration tasks. However there is no evidence of a general-purpose 'schedule any workflow/job' primitive (e.g. cron-like task scheduler for arbitrary agent workflows) beyond payment/billing-specific recurrence. missing for 10: a generic workflow/job scheduler beyond billing recurrence, evidence of agents autonomously scheduling multi-step workflows (not just recurring payments), independent hands-on confirmation of this automation depth.", "evidenceIds": [ "stripe-docs-6", "stripe-docs-14", "stripe-docs-51", "stripe-supp-projects-provisioning", "stripe-supp-mcp-tools", "stripe-docs-74" ] }, { "productId": "stripe", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Stripe's automation features (Billing recurring rules, Smart Retries, Radar rules, webhooks, Kyber no-code flows) have no documented version-history, review/diff, or rollback mechanism in the evidence. API versioning (stripe-docs-45/59) covers backward-compatible monthly API releases, not versioning of a user's automation configurations, so it doesn't satisfy this story.", "evidenceIds": [ "stripe-docs-45", "stripe-docs-59", "stripe-docs-14", "stripe-docs-51", "stripe-intdir-6" ] }, { "productId": "stripe", "storyId": "dunning-failed-payment-recovery", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Billing's revenue-recovery docs explicitly document Smart Retries for automatically retrying failed subscription payments plus recovery analytics, and this is a no-code feature within Billing. Missing for 10: explicit documentation of automated dunning/recovery email templates and independent hands-on validation of recovery email effectiveness.", "evidenceIds": [ "stripe-docs-14", "stripe-docs-15", "stripe-docs-31", "stripe-docs-56", "stripe-docs-66", "stripe-docs-6", "stripe-docs-51" ] }, { "productId": "stripe", "storyId": "embedded-checkout-components", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe Elements and Checkout Sessions API let developers embed a fully customizable payment page directly in their own site (as opposed to only redirecting to a hosted page), with support for 125+ payment methods, subscriptions, and prebuilt/custom UI options documented extensively. Missing for 10: no independent/hands-on developer report specifically praising the embedded (non-redirect) Elements experience beyond docs.", "evidenceIds": [ "stripe-docs-1", "stripe-docs-2", "stripe-docs-23", "stripe-docs-50", "stripe-docs-3" ] }, { "productId": "stripe", "storyId": "fraud-screening-rules", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe Radar is documented to use AI/ML algorithms in real time to assess fraud risk across transactions, accounts, and customers, which covers the ML fraud-scoring part of the story; however, the evidence pack does not show custom rule-writing capability (block/review/allow rules) beyond the single Radar mention, no details on rule builder UI, thresholds, or list management. missing for 10: documentation of custom rule creation/editing (block, review, allow lists), rule logic examples, and independent/hands-on confirmation of Radar's rule-writing workflow.", "evidenceIds": [ "stripe-docs-22" ] }, { "productId": "stripe", "storyId": "hosted-checkout-page", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs explicitly describe Stripe Checkout as a Stripe-hosted redirect page ('via a redirect to a Stripe-hosted page') with prebuilt UI via Checkout Sessions API, plus Payment Links for a fully no-code hosted checkout URL — directly matching the story. Multiple docs reinforce it supports many payment methods, currencies, tax collection, and no-code refunds on these hosted pages. missing for 10: no independent/hands-on corroboration of the hosted page's conversion-optimization claims beyond Stripe's own docs.", "evidenceIds": [ "stripe-docs-2", "stripe-docs-50", "stripe-docs-4", "stripe-docs-36", "stripe-docs-48", "stripe-docs-3" ] }, { "productId": "stripe", "storyId": "idempotent-api-retries", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe's API docs explicitly document idempotency keys for safely retrying requests after connection errors without creating duplicate objects/charges, directly matching the story, and this is a well-known, widely used first-party API feature. Missing for 10: independent hands-on developer corroboration specifically testing idempotency behavior (community evidence in the pack is unrelated to this feature).", "evidenceIds": [ "stripe-docs-9", "stripe-docs-25", "stripe-docs-42", "stripe-docs-69" ] }, { "productId": "stripe", "storyId": "integrate-from-docs-in-a-day", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's docs offer copy-paste checkout/payment-link/Elements integrations, sandbox testing with test cards, idempotency, webhooks, and API keys, and community testimony confirms fast integration ('up and running and accepting recurring payments in less than an hour', clear documentation) despite some unrelated support gripes. missing for 10: explicit multi-language SDK code-sample evidence in the pack (only generic doc references, not shown per-language snippets) and a broader/more recent independent corroboration beyond one old HN thread.", "evidenceIds": [ "stripe-docs-1", "stripe-docs-2", "stripe-docs-10", "stripe-docs-65", "stripe-docs-9", "stripe-docs-53", "stripe-comm-9" ] }, { "productId": "stripe", "storyId": "marketplace-split-payments", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe Connect is explicitly documented as the product for building marketplaces/platforms that onboard sellers, split payments, and pay out to multiple parties, backed by supporting payouts, payment collection, refunds, disputes, and tax infrastructure. Missing for 10: independent hands-on evidence specifically of a marketplace/Connect integration (community evidence covers Stripe generally, not Connect specifically).", "evidenceIds": [ "stripe-docs-12", "stripe-docs-38", "stripe-docs-34", "stripe-docs-52", "stripe-docs-68", "stripe-docs-33", "stripe-docs-41" ] }, { "productId": "stripe", "storyId": "multi-currency-charge-settle", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe documents charging in 135+ currencies with payout settlement in a merchant's preferred currency (stripe-docs-19), localized checkout/payment links that let customers pay in their own currency (stripe-docs-36), automated payout tracking to bank accounts (stripe-docs-34, stripe-docs-52, stripe-docs-68), and automated tax compliance across jurisdictions (stripe-docs-20, stripe-docs-48). This directly covers charging locally and settling in the founder's currency. Missing for 10: explicit documentation of FX conversion rate transparency/fee disclosure mechanics and independent/hands-on confirmation of FX rate fairness or settlement accuracy.", "evidenceIds": [ "stripe-docs-19", "stripe-docs-36", "stripe-docs-34", "stripe-docs-52", "stripe-docs-68", "stripe-docs-20", "stripe-docs-48" ] }, { "productId": "stripe", "storyId": "no-code-payment-links", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe Payment Links is explicitly documented as a no-code way to create a shareable payment link from the dashboard, supporting local currencies/payment methods, no-code tax collection, and no-code refunds — matching the founder story closely. Missing for 10: independent hands-on account of actually creating a payment link end-to-end (community evidence is general Stripe sentiment, not specific to Payment Links).", "evidenceIds": [ "stripe-docs-4", "stripe-docs-5", "stripe-docs-36", "stripe-docs-48" ] }, { "productId": "stripe", "storyId": "openness-api-parity", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's core resources (payments, refunds, subscriptions, invoices, disputes, payouts, tax, Connect) are all documented as available via the REST API with idempotency, versioning, and restricted keys, and the MCP server explicitly exposes generic stripe_api_read/stripe_api_write tools plus task-specific tools mirroring Dashboard actions across most objects. Workbench Shell/CLI further lets agents run the same commands as the CLI/API interactively. missing for 10: independent confirmation that every Dashboard-only feature (e.g., third-party Stripe Apps like Kyber no-code automations) has a full API equivalent, and note that sensitive stripe_api_write actions require human confirmation rather than being fully autonomous.", "evidenceIds": [ "stripe-supp-mcp-tools", "stripe-docs-18", "stripe-docs-41", "stripe-docs-9", "stripe-docs-59", "stripe-docs-67", "stripe-supp-workbench-shell", "stripe-docs-30", "stripe-supp-mcp-write-confirmation" ] }, { "productId": "stripe", "storyId": "openness-full-export", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence shows only narrow CSV export of specific financial reports (balance, payouts, activity, tax, Revenue Recognition) via stripe_report/Workbench, not a comprehensive account data export mechanism for a user to leave the platform. Missing for 10: a documented full account/data export tool (customers, charges, subscriptions, full transaction history) in open/portable formats, and any explicit data-portability or account-closure export workflow.", "evidenceIds": [ "stripe-supp-analytics-ai", "stripe-docs-46" ] }, { "productId": "stripe", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Stripe's core payments platform is proprietary SaaS; the evidence pack shows only open-source SDKs/CLI/agent-toolkit wrappers (e.g. stripe/ai, stripe-cli) but no license for the actual product/service source code, so there is no basis to claim the product itself is open-license readable.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe is a hosted, regulated financial-services platform (payment processing, PCI compliance, banking rails, fraud detection via aggregated network data) — self-hosting the core product is a category error for this kind of service, not a capability gap.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "payout-schedule-control", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe documents payout basics (funds sent from balance to bank account, dashboard tracking of payouts and expected deposit dates, setting up bank accounts) and financial reporting via stripe_report/analytics (balance, payouts, activity reports downloadable as CSV), which supports reconciliation. However, evidence does not show explicit payout schedule controls (e.g., setting manual vs automatic schedule, daily/weekly/monthly cadence) nor a documented per-payout breakdown view showing exact charges/fees/refunds composing each payout. missing for 10: explicit payout schedule configuration docs, a documented itemized payout reconciliation report/API showing constituent charges/fees/refunds per payout, independent/hands-on confirmation of this reconciliation workflow.", "evidenceIds": [ "stripe-docs-34", "stripe-docs-52", "stripe-docs-68", "stripe-supp-analytics-ai" ] }, { "productId": "stripe", "storyId": "pci-scope-reduction", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe's docs explicitly state that low-risk integrations (Checkout, Elements, hosted payment pages) collect and transmit payment data directly to Stripe without it passing through the developer's servers, explicitly reducing PCI obligations/scope, and these are backed by concrete hosted/embeddable products (Checkout, Payment Links, Elements). missing for 10: independent third-party PCI audit or compliance-report corroboration beyond Stripe's own docs.", "evidenceIds": [ "stripe-docs-11", "stripe-docs-27", "stripe-docs-37", "stripe-docs-1", "stripe-docs-2", "stripe-docs-4" ] }, { "productId": "stripe", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack discusses data residency, regional data storage choices, or GDPR/EU data localization options for Stripe accounts; the evidence covers payments, billing, MCP/agents, sandboxes, etc. but never data residency controls.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe is a payments infrastructure platform, not an AI model provider or chatbot that trains models on user data; the story about opting out of AI-model-training data usage is a category error for this product type — there is no evidence Stripe trains generative AI models on customer data as a core offering, so this privacy-posture axis about AI training opt-out does not apply.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers sandbox isolation, restricted API keys, MCP OAuth session revocation, and webhook/event architecture, but none of it addresses data retention policies or a mechanism for users to request deletion/erasure of stored payment or customer data. As a platform processing sensitive financial and personal data, this is a fair and applicable axis, but no documentation shows retention controls or deletion capabilities for AI-native users.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe is a payments platform, not an AI dev tool with client-side telemetry to opt out of; this privacy-posture axis about telemetry/usage tracking opt-out is a category error for this product type and no evidence contradicts that.", "evidenceIds": [] }, { "productId": "stripe", "storyId": "recurring-subscription-billing", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Billing explicitly automates recurring payments, custom pricing plans, trials, renewals, and subscription upgrades, plus a customer portal for self-service management, revenue recovery (smart retries), and subscription migration docs. Documentation confirms core subscription lifecycle features via first-party docs, though proration is only implied via 'upgrades' rather than explicitly named, and no independent/hands-on corroboration of proration mechanics is present. Missing for 10: explicit proration documentation/examples, independent developer corroboration of subscription setup experience.", "evidenceIds": [ "stripe-docs-6", "stripe-docs-51", "stripe-docs-62", "stripe-docs-7", "stripe-docs-24", "stripe-docs-14", "stripe-docs-15", "stripe-docs-31" ] }, { "productId": "stripe", "storyId": "refunds-full-partial", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs explicitly state refunds can be issued via both the Refunds API and the Dashboard, including full or partial amounts, and refunded payments are viewable in the Dashboard. No-code refunds are also supported on Payment Links. missing for 10: no independent/hands-on confirmation of partial-refund UX in the dashboard.", "evidenceIds": [ "stripe-docs-17", "stripe-docs-33", "stripe-docs-47", "stripe-docs-64", "stripe-docs-5" ] }, { "productId": "stripe", "storyId": "respond-to-disputes-evidence", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's Disputes API lets finance-ops programmatically manage disputes, upload structured evidence, respond to disputes, and receive dispute lifecycle events via webhooks, plus dispute events surface in the Dashboard/Radar for tracking; MCP tooling also exposes a 'disputes: update' method for agent-assisted workflows. missing for 10: no independent/hands-on account of the full evidence-submission UX or explicit dispute-resolution outcome tracking beyond webhook events.", "evidenceIds": [ "stripe-docs-18", "stripe-docs-41", "stripe-docs-8", "stripe-docs-22", "stripe-supp-mcp-tools" ] }, { "productId": "stripe", "storyId": "sandbox-test-mode-fidelity", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe provides a documented sandbox environment mirroring production (isolated per-team sandboxes, no live-data impact) plus an extensive test-card matrix covering successes, declines, fraud, and invalid data, and a full disputes API for simulating/handling chargebacks. CLI and Workbench also support building/testing/debugging integrations end-to-end. Missing for 10: no independent/hands-on developer testimonial specifically validating sandbox fidelity or test-card coverage beyond first-party docs.", "evidenceIds": [ "stripe-docs-10", "stripe-docs-32", "stripe-docs-43", "stripe-docs-49", "stripe-docs-57", "stripe-docs-65", "stripe-docs-18", "stripe-docs-41", "stripe-docs-75", "stripe-docs-30" ] }, { "productId": "stripe", "storyId": "send-hosted-invoices", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe clearly supports creating and sending hosted, customizable invoices with online payment collection, no code required (stripe-docs-21, stripe-docs-60, stripe-docs-51). However, the evidence pack does not explicitly document automatic reminder emails for unpaid invoices — the closest analog is 'Smart Retries' and revenue-recovery dunning for subscription payment failures (stripe-docs-14, stripe-docs-31), which is a related but distinct capability from invoice due-date reminders. Missing for 10: explicit documentation of automatic invoice payment reminder emails, and independent/hands-on confirmation of the reminder feature working in practice.", "evidenceIds": [ "stripe-docs-21", "stripe-docs-60", "stripe-docs-51", "stripe-docs-14", "stripe-docs-31", "stripe-docs-56" ] }, { "productId": "stripe", "storyId": "settlement-reconciliation-reports", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe documents payouts to bank accounts with expected deposit dates (stripe-docs-34, stripe-docs-52), refunds and dispute management via API/Dashboard (stripe-docs-17, stripe-docs-33, stripe-docs-41), and AI-assisted analytics/report runs including a documented 'balance summary' report and other financial report types (stripe-supp-analytics-ai). However, there is no evidence of a purpose-built, itemized settlement-to-deposit reconciliation report that breaks out fees, refunds, and chargebacks against a specific bank deposit in one view — the closest evidence (report types: balance, payouts, activity, tax) implies this exists but doesn't confirm itemization matching finance-ops reconciliation workflows, and third-party accounting sync (QuickBooks, Xero) is only listed as partner integrations rather than native itemized reconciliation. missing for 10: a documented native 'payout reconciliation report' itemizing fees/refunds/chargebacks per deposit, confirmation of automatic matching to bank statement lines, and independent/hands-on evidence from finance-ops users that this reconciliation workflow works well in practice.", "evidenceIds": [ "stripe-docs-34", "stripe-docs-52", "stripe-docs-17", "stripe-docs-33", "stripe-docs-41", "stripe-supp-analytics-ai", "stripe-intdir-1", "stripe-intdir-5" ] }, { "productId": "stripe", "storyId": "wallets-local-payment-methods", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Stripe Checkout/Elements documentation confirms 125+ local payment methods and localized payment links, which covers digital wallets, bank redirects, and local methods from one integration; however, the evidence never explicitly names Apple Pay, Google Pay, or specific BNPL providers, and there's no independent/hands-on confirmation of the exact method mix. missing for 10: explicit mention of Apple Pay/Google Pay support, named BNPL providers (e.g., Klarna/Afterpay), and independent verification of the full payment-method list.", "evidenceIds": [ "stripe-docs-3", "stripe-docs-1", "stripe-docs-2", "stripe-docs-36" ] }, { "productId": "stripe", "storyId": "webhook-delivery-reliability", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs cover signed/HTTPS webhook endpoints, real-time event pushes, idempotency for safe retries, dispute/event handling via API+webhooks, and the newer event destinations feature with versioned snapshot/thin events; sandbox testing supports simulating webhook flows. However, explicit documentation of automatic retry schedules for failed webhook deliveries and a dedicated 'replay' UI/feature isn't directly cited (event destinations mention versioning but not an explicit replay tool), and there's no independent/hands-on corroboration of retry reliability. missing for 10: explicit docs on automatic webhook retry backoff schedule, a dedicated event replay feature/UI, independent developer corroboration of retry/replay reliability.", "evidenceIds": [ "stripe-docs-8", "stripe-docs-35", "stripe-docs-53", "stripe-docs-63", "stripe-docs-9", "stripe-docs-25", "stripe-docs-42", "stripe-docs-69", "stripe-docs-18", "stripe-docs-41", "stripe-supp-event-destinations", "stripe-docs-75" ] } ]