[ { "productId": "adyen-for-platforms", "storyId": "agent-buyer-readiness", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers split payments, onboarding, payouts, and even an MCP server for developer tooling, but nothing addresses agent-initiated checkout, agentic-commerce protocols, or delegated payment credentials for AI agent buyers on marketplace transactions. No mention of agent commerce standards (e.g., Agentic Commerce Protocol, delegated tokens) exists in the pack.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "agent-onboards-sellers", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen for Platforms exposes API-driven seller onboarding (create legal entities, balance accounts, submit KYC data) via docs-6/8/9, and Adyen documents a first-party MCP server for natural-language interaction with its platform (docs-14, probe-4), which together make agent-driven account creation and onboarding plausible. However, there is no evidence the MCP server specifically exposes onboarding/requirements-due workflows, no documentation of scoped/limited credentials for agent use, and no explicit mention of programmatically checking or resolving 'requirements due' verification states. Missing for 10: MCP server tool list/scope confirming onboarding operations, scoped-credential/permission model for agent access, and explicit API/MCP support for querying and resolving requirements-due status.", "evidenceIds": [ "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-4" ] }, { "productId": "adyen-for-platforms", "storyId": "agent-platform-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen for Platforms exposes documented APIs for balances, payouts, legal entities, and split/chargeback handling (docs-8,9,10,11,12), webhooks for async status changes (docs-13), and even a first-party MCP server for natural-language integration (docs-14, probe-4), which supports an agent-native access pattern. However, there is no direct evidence of an endpoint or workflow specifically for 'investigating a missing payout' or 'drafting dispute evidence' — only general chargeback-handling docs — and the openapi probe returned 404s, suggesting no single machine-readable spec for full API discovery. Missing for 10: explicit payout-investigation workflow docs, dispute-evidence drafting API/docs, and a discoverable OpenAPI/machine-readable schema confirming full agent tool coverage.", "evidenceIds": [ "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-11", "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-3", "adyen-for-platforms-probe-4" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "A probe confirms llms.txt returns HTTP 200 at docs.adyen.com/llms.txt with a description of the docs corpus, and individual docs pages are also available as .md files (e.g. platforms.md, onboard-users.md), directly supporting agent-oriented consumption. Missing for 10: no independent/community confirmation of an agent successfully using llms.txt in practice.", "evidenceIds": [ "adyen-for-platforms-probe-1", "adyen-for-platforms-docs-1" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers onboarding, payouts, fraud rules, reconciliation reports, and an MCP server for developer integration, but nothing describes AI-generated insights or suggestions surfaced to end users from their platform data. No dashboard AI features, analytics recommendations, or generative summaries are mentioned anywhere.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen for Platforms documents background automation mechanics well suited to autonomous operation — managed payout schedules that run without manual intervention (docs-12), webhooks to avoid polling for async status changes (docs-13), and automated fraud/risk monitoring rules (docs-4, docs-18) — plus an MCP server that lets AI agents connect via natural language (docs-14, probe-4). However, there's no evidence tying these into an AI-agent-orchestrated 'set it up once and it runs autonomously' workflow specifically for AI-native users. Missing for 10: documentation of AI agents configuring/scheduling these automations via the MCP server end-to-end, evidence of persistent agent-driven task execution, and any hands-on/independent confirmation of autonomous agent use.", "evidenceIds": [ "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-4", "adyen-for-platforms-docs-18", "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-4" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a payments infrastructure product, not an agentic assistant application; the evidence shows an MCP server for developer connectivity, not a built-in AI assistant users can delegate tasks to. This is a category mismatch — the axis of 'built-in AI assistant to delegate tasks to' does not apply to a payments platform API/dashboard product.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen for Platforms is API-first and offers a full REST API for onboarding, legal entity management, balance accounts, and split payments, plus webhooks for async status checks instead of polling — these are usable headlessly/in CI. However, there is no explicit CI/CD example, no CLI tool, and part of the onboarding flow relies on Adyen-hosted UI pages rather than pure headless flow. missing for 10: explicit CI/automation pipeline examples, a CLI or SDK automation guide, confirmation that all onboarding steps (not just hosted-page flow) can run fully headless without human/UI interaction.", "evidenceIds": [ "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-7", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-15" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a payments/marketplace backend service, not an AI agent or assistant capable of consuming MCP servers as a client. The only MCP-related evidence shows Adyen exposing its own MCP server for others to connect to (the reverse role), which does not make the 'plug MCP servers into this product' client story applicable.", "evidenceIds": [ "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-4" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen documents an official MCP server enabling natural-language connections to build on Adyen's platform, which is directly on-topic and applicable since Adyen is a payments platform, not an agent itself. However, evidence is limited to a single doc-page reference and generic description without detail on setup, scope of coverage for Platforms-specific APIs, or independent/hands-on confirmation. Missing for 10: detailed docs on MCP server capabilities/tools exposed, confirmation it covers Platforms-specific endpoints, and independent corroboration of real-world usage.", "evidenceIds": [ "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-4" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen documents an official MCP server explicitly designed to let developers 'use natural language to connect with Adyen's platform more easily and build new payment solutions faster,' which is direct evidence of natural-language operability. However, this is scoped to developer/build-time use rather than full operational control (onboarding, payouts, fraud monitoring, reconciliation are still driven via traditional REST APIs and dashboards per the rest of the pack). Missing for 10: evidence that end-to-end platform operations (onboarding, payouts, dispute handling, reporting) can be driven via natural language, and independent/hands-on confirmation of the MCP server's real-world coverage and reliability.", "evidenceIds": [ "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-4" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows API docs, webhooks, and an MCP server for natural-language integration, but no mention of an official CLI tool for Adyen for Platforms; the openapi/CLI probes came back 404. missing for 10: any documentation of an official CLI, its install/usage, or command reference.", "evidenceIds": [ "adyen-for-platforms-probe-3", "adyen-for-platforms-docs-14" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen for Platforms is driven entirely through documented REST APIs (Legal Entity Management, Configuration API, Balance Accounts, split transactions), webhooks for async events, and even an official MCP server for natural-language/agentic access. Missing for 10: a discoverable OpenAPI/swagger spec (probe found 404s) and independent third-party corroboration of API completeness beyond vendor docs.", "evidenceIds": [ "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-14", "adyen-for-platforms-probe-4", "adyen-for-platforms-probe-3" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses issuing scoped or least-privilege API credentials for an AI agent; the docs cover onboarding, payouts, fraud monitoring, webhooks, and an MCP server, but nothing about API key/credential scoping or permission granularity for agents.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only documents API endpoints (Legal Entity Management API, Configuration API, Checkout/webhooks) and an MCP server for natural-language access, but never mentions official client SDKs or language-specific libraries for building against Adyen for Platforms. Missing for 10: any citation of an official SDK, its languages, or GitHub repo/package documentation.", "evidenceIds": [ "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-14" ] }, { "productId": "adyen-for-platforms", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Adyen documents a dedicated webhooks system for asynchronous event notifications, explicitly framed as an alternative to polling, which aligns well with an AI-agent-driven subscribe-to-events workflow. Missing for 10: no details on webhook subscription management API, event type catalog, or independent/hands-on corroboration of reliability.", "evidenceIds": [ "adyen-for-platforms-docs-13" ] }, { "productId": "adyen-for-platforms", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows only static docs pages and confirms openapi/swagger endpoints return 404, with no mention of an interactive API reference or runnable code examples/try-it console.", "evidenceIds": [ "adyen-for-platforms-probe-3", "adyen-for-platforms-probe-2" ] }, { "productId": "adyen-for-platforms", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows explicit probes for OpenAPI/Swagger spec files at all standard candidate paths returning 404, and no other citation confirms a downloadable machine-readable API spec for Adyen for Platforms. While Adyen is an API-first product where this axis clearly applies, there is no evidence in the pack that a machine-readable spec is actually published or downloadable.", "evidenceIds": [ "adyen-for-platforms-probe-3", "adyen-for-platforms-probe-2" ] }, { "productId": "adyen-for-platforms", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly describe using test credentials to test different transaction types against Adyen's integration before going live, which is a standard sandbox-vs-production separation for API-driven platforms. Missing for 10: no explicit mention of isolated sandbox data reset/cleanup tools, no independent/hands-on corroboration of sandbox fidelity, and no detail on how sandbox test data is kept separate from production records.", "evidenceIds": [ "adyen-for-platforms-docs-15" ] }, { "productId": "adyen-for-platforms", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack references API versioning, version numbers, or a deprecation policy/timeline for Adyen's APIs; probes for OpenAPI specs returned 404. This is a fair axis for a payments API platform, but nothing documents a versioning or deprecation policy, so it counts as none.", "evidenceIds": [ "adyen-for-platforms-probe-3" ] }, { "productId": "adyen-for-platforms", "storyId": "application-fee-monetization", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen for Platforms explicitly supports splitting payments and deducting costs/fees per transaction via the Split Transactions API, and markets 'control fees and use payments as a competitive edge' plus bookkeeping/reconciliation reports (docs-2, docs-10, docs-16, docs-5). However, there's no explicit documentation of per-seller custom fee/pricing configuration or a dedicated report that separates platform monetization revenue from underlying processing costs. Missing for 10: explicit per-seller pricing/fee-schedule configuration, dedicated revenue-vs-cost reporting or dashboard view distinguishing platform fee income from interchange/processing costs.", "evidenceIds": [ "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-16", "adyen-for-platforms-docs-5", "adyen-for-platforms-docs-11" ] }, { "productId": "adyen-for-platforms", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence shows per-resource API operations (create legal entities, balance accounts, split payments) but nothing about batch/bulk endpoints for processing many items in a single call, nor bulk import/export tooling for AI-native workflows.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen for Platforms supports event-driven automation via webhooks (avoiding polling) and lets platforms 'configure your own monitoring rules and mitigations' for fraud/risk, plus custom payout schedules and split-payment instructions triggered by transaction events, but this is limited to a few pre-defined domains (payouts, risk, chargebacks) rather than a general-purpose rules engine for arbitrary events/actions. Missing for 10: a documented general rules/automation engine covering diverse event types and custom actions, and independent evidence of real-world automation workflows built on these primitives.", "evidenceIds": [ "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-18", "adyen-for-platforms-docs-4", "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-10" ] }, { "productId": "adyen-for-platforms", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Adyen for Platforms supports one specific recurring scheduling feature — managed payout schedules that recur based on location/currency for balance accounts — but this is a narrow payments-domain feature, not a general-purpose recurring job/workflow scheduler for AI-native automation use cases. Missing for 10: evidence of a general workflow/job scheduling API or automation framework beyond payout timing, no support for scheduling arbitrary recurring API workflows, and no AI-native orchestration hooks tied to scheduling.", "evidenceIds": [ "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-17", "adyen-for-platforms-docs-20" ] }, { "productId": "adyen-for-platforms", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a payments/marketplace infrastructure product, not an automation/workflow tool with 'automations' that a user builds, versions, and rolls back — this axis is a category error for a payments API platform.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "buy-rate-pricing-control", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen documents that platforms can control fees/sell rates (docs-16), split payments and deduct costs (docs-2), and use Adyen-generated reports for reconciliation (docs-5), which supports sell-rate freedom and some cost visibility. However, there is no explicit documentation of a defined 'buy rate' from Adyen or interchange-level cost breakdowns to manage the spread precisely. Missing for 10: documented buy-rate/cost basis from Adyen, interchange-level fee transparency in reporting, explicit spread-management guidance.", "evidenceIds": [ "adyen-for-platforms-docs-16", "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-5" ] }, { "productId": "adyen-for-platforms", "storyId": "cross-border-payouts", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs show global seller onboarding, managed/custom payout scheduling, and balance accounts tied to a single currency and location, implying some local-currency payout capability, but there's no explicit documentation of FX conversion mechanics, published FX rates/markups, or confirmation that payouts settle via local bank rails rather than wires. missing for 10: explicit FX handling/rate documentation, confirmation of local bank rail settlement vs wire transfers, multi-currency payout examples, independent verification of cost savings.", "evidenceIds": [ "adyen-for-platforms-docs-19", "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-17", "adyen-for-platforms-docs-20" ] }, { "productId": "adyen-for-platforms", "storyId": "embedded-seller-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen provides APIs to build your own UI for onboarding, balances, and transaction data (docs-6, docs-9, docs-8), and split payments/payouts data can be surfaced in a platform's own UI under its brand, satisfying the core embeddable/white-label ask via API-first approach. However, evidence does not show pre-built embeddable UI components (like white-label widgets) specifically for balances, payouts, or transaction history — only raw APIs plus an Adyen-hosted onboarding page (docs-7), which is not white-labeled inside the platform's own product. Missing for 10: dedicated white-label UI components/SDKs for balance/payout/transaction display, documentation of embeddable widgets, and independent/hands-on confirmation of branding customization depth.", "evidenceIds": [ "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-7", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-12" ] }, { "productId": "adyen-for-platforms", "storyId": "global-seller-coverage", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows generic marketing claims like 'onboard global sellers with one integration' (docs-19) and generic onboarding/legal-entity API docs, but no documented coverage map listing supported onboarding countries, local payment methods, or local-currency settlement per market — the exact ticket-by-ticket problem the story flags. Missing for 10: a published country/payment-method/currency coverage map or matrix, evidence of self-serve discovery of local rails per country.", "evidenceIds": [ "adyen-for-platforms-docs-19", "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-8" ] }, { "productId": "adyen-for-platforms", "storyId": "holds-delayed-release", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen for Platforms lets you hold funds in balance accounts and split/deduct amounts until payout (docs-2, docs-9), and gives full control over payout timing via custom payouts or managed payout schedules triggered on your own schedule (docs-3, docs-12, docs-17, docs-20). This covers the core 'hold until release' mechanic, but there is no explicit escrow terminology, no documented dispute-window integration, and no stated limits (max hold duration, balance caps) governing the hold — missing for 10: explicit escrow/dispute-window semantics, documented hold-duration or balance limits, independent confirmation of behavior at scale.", "evidenceIds": [ "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-3", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-17", "adyen-for-platforms-docs-20" ] }, { "productId": "adyen-for-platforms", "storyId": "in-person-omnichannel", "verdict": "partial", "quality": 2, "confidence": "low", "rationale": "The evidence pack for Adyen for Platforms is entirely about online split payments, payouts, balance accounts, and onboarding — it never explicitly documents terminals or tap-to-pay SDKs settling into the same seller balance accounts. The only hint is a generic mention that Adyen's docs cover 'point-of-sale' alongside Platforms, which is not tied to unified balance/reporting for in-person sales. Missing for 10: explicit documentation of terminal/tap-to-pay SDK integration, confirmation that in-person transactions post to the same balance accounts and split-payment/reporting pipeline as online payments, and any hands-on or independent corroboration of this unified flow.", "evidenceIds": [ "adyen-for-platforms-probe-1", "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-5" ] }, { "productId": "adyen-for-platforms", "storyId": "liability-responsibility-split", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence describes onboarding, verification, fraud monitoring, payouts, and split-payment mechanics, but nowhere is there an explicit statement of which party (Adyen vs. platform) bears legal/financial responsibility for KYC/AML compliance, card-network rule adherence, fraud losses, or seller misconduct. Docs describe capabilities ('Adyen verifies', 'outsource risk management to Adyen') but do not delineate a liability/ownership split in plain-language documentation as the story requires. Missing for 10: explicit liability-allocation documentation, a dedicated responsibility-matrix or compliance-ownership page, statements on who absorbs fraud/chargeback losses or seller misconduct liability.", "evidenceIds": [ "adyen-for-platforms-docs-1", "adyen-for-platforms-docs-4", "adyen-for-platforms-docs-11", "adyen-for-platforms-docs-18", "adyen-for-platforms-docs-19" ] }, { "productId": "adyen-for-platforms", "storyId": "multi-entity-treasury", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs confirm balance accounts hold/segregate funds per user and describe payout timing, splits, and reconciliation reports, giving some visibility into where in-flight and held funds sit. However, there is no mention of whether balances earn yield/interest, and no explicit statement on legal/regulatory segregation of platform funds from Adyen's own corporate accounts (safeguarding, e-money regulations, etc.). missing for 10: yield/interest treatment on balances, explicit fund-segregation/safeguarding disclosures, independent audit or regulatory confirmation of asset protection.", "evidenceIds": [ "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-5", "adyen-for-platforms-docs-12" ] }, { "productId": "adyen-for-platforms", "storyId": "negative-balance-recovery", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm split-chargeback handling with multiple configurable liability options (docs-11), split/deduct instructions for chargebacks (docs-10), and general balance/payout controls, implying negative balances can be recovered via future earnings splits. However, there is no explicit documentation of automatic debit against a seller's bank account or a clearly documented 'liability order' sequence (e.g., balance → future earnings → bank debit) as a finance-lead would need. Missing for 10: explicit bank-account debit/recovery mechanism for negative balances, documented liability/waterfall order, and independent confirmation of this recovery flow working in practice.", "evidenceIds": [ "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-11", "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-12" ] }, { "productId": "adyen-for-platforms", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show extensive API coverage for platform operations (Legal Entity Management API for onboarding, Configuration API for balance accounts, split payments/chargebacks endpoints, webhooks instead of polling), and users can 'build your own UI' entirely via API rather than using Adyen-hosted pages. However, some controls like fee configuration are explicitly described as 'managed in your Adyen Dashboard', and no consolidated OpenAPI spec was discoverable (404s), so full UI/API parity isn't clearly evidenced. Missing for 10: explicit confirmation that dashboard-only features (fee control, monitoring rule configuration) have API equivalents, and a discoverable complete API reference/spec proving full parity.", "evidenceIds": [ "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-7", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-16", "adyen-for-platforms-probe-3" ] }, { "productId": "adyen-for-platforms", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any data export/portability feature or open-format data dump capability; documentation covers onboarding, payouts, fraud, reporting, and API integration but never data export or account closure/portability. Reports (docs-5) are for bookkeeping, not full data export in open formats.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a closed commercial payments/fintech SaaS product, not an open-source software project; source code availability under an open license is not an applicable axis for this kind of product.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a hosted, regulated payments/fintech SaaS platform; self-hosting is not a coherent capability for this category — it's a wrong-axis question, not an absent feature.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "payfac-graduation-path", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen for Platforms documents a spectrum of control (managed vs. custom payouts, outsourced vs. self-configured risk, fee control) within the same platform, which implies increasing control without switching providers, but there is no explicit documentation of a formal path to registered PayFac status or licensing progression with more economics/control retained by the founder. missing for 10: explicit registered-PayFac graduation path, documentation of economics/liability shift, evidence of no-replatform migration mechanics.", "evidenceIds": [ "adyen-for-platforms-docs-3", "adyen-for-platforms-docs-16", "adyen-for-platforms-docs-17", "adyen-for-platforms-docs-18", "adyen-for-platforms-docs-20" ] }, { "productId": "adyen-for-platforms", "storyId": "payout-scheduling", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "Adyen documents managed payout schedules applied to balance accounts (daily/weekly/monthly cadence) as well as custom payout timing via API, plus CashOut for instant access to funds, directly matching the story's scheduling and instant-payout needs. However, the evidence doesn't spell out per-seller granularity (schedules are applied per location/currency group) or specifics on instant payouts to cards/real-time rails. Missing for 10: explicit per-seller schedule configuration detail, instant-to-card/real-time-rail specifics, and independent confirmation beyond vendor docs.", "evidenceIds": [ "adyen-for-platforms-docs-3", "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-17", "adyen-for-platforms-docs-20" ] }, { "productId": "adyen-for-platforms", "storyId": "platform-ledger-visibility", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm balance accounts per seller/platform, split payments with fee deduction, chargeback splitting, managed/custom payouts, and Adyen-generated reports for bookkeeping/reconciliation, which directly supports per-seller and per-fee-account balance visibility and reconciliation. However, there's no concrete evidence of penny-level traceability from charge through split to payout (e.g., detailed report schemas, transaction-level audit trail examples, or reconciliation report samples) or independent/hands-on validation of reconciliation accuracy. Missing for 10: sample reconciliation reports/schemas showing charge-to-payout linkage, evidence of penny-accurate reconciliation, and independent/third-party confirmation of ledger accuracy.", "evidenceIds": [ "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-5", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-11", "adyen-for-platforms-docs-12" ] }, { "productId": "adyen-for-platforms", "storyId": "platform-risk-monitoring", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm fraud/risk monitoring capabilities (\"identify fraudulent behavior, stop suspicious payouts, and flag unusual user activities\") and configurable monitoring rules/mitigations, plus ability to pause/control payouts and manage users. However, there is no evidence of a dedicated portfolio-wide dashboard view per sub-merchant, specific anomaly-alerting mechanics, or explicit offboarding tooling described in detail. Missing for 10: per-seller risk dashboard/scoring UI, alert configuration details, explicit offboarding workflow documentation, and independent/hands-on validation of these fraud tools in practice.", "evidenceIds": [ "adyen-for-platforms-docs-4", "adyen-for-platforms-docs-18", "adyen-for-platforms-docs-3", "adyen-for-platforms-docs-12" ] }, { "productId": "adyen-for-platforms", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers platform payments features (onboarding, payouts, splits, fraud, MCP server) but contains no mention of data residency, regional data storage options, or configurable geographic data controls.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a payments/marketplace infrastructure product, not an AI model or data-processing service where 'AI training opt-out' is a meaningful axis; the evidence pack covers payment splitting, onboarding, payouts, and an MCP server for developer tooling, none of which relate to controlling AI training data usage.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers payment platform features (onboarding, payouts, splits, fraud, reporting, MCP server) but contains no mention of data retention policies, deletion controls, or privacy/data-lifecycle management for AI-native users.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen for Platforms is a payments/marketplace infrastructure product, not an AI assistant or developer tool with telemetry collection concerns relevant to an AI-native user's own usage data; opting out of telemetry/usage tracking is a category mismatch for this axis.", "evidenceIds": [] }, { "productId": "adyen-for-platforms", "storyId": "programmatic-seller-onboarding", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly cover both API-driven onboarding (build your own UI, submit user data via API) and hosted onboarding pages managed by Adyen, plus Legal Entity Management API for KYB/KYC and balance account/bank linking. Terms acceptance and hosted flow are directly referenced in onboard-users.md and platforms.md. missing for 10: no explicit mention of embeddable/drop-in onboarding components (only 'build your own UI' vs 'hosted page'), and no independent/hands-on corroboration beyond first-party docs.", "evidenceIds": [ "adyen-for-platforms-docs-1", "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-7", "adyen-for-platforms-docs-8", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-19" ] }, { "productId": "adyen-for-platforms", "storyId": "progressive-onboarding", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen for Platforms clearly supports onboarding via API or hosted UI and states verification happens 'before paying out' (docs-1, docs-6, docs-7), implying some ability to sell before full KYC is complete, and Legal Entity Management API (docs-8) suggests granular data collection. However there is no explicit documentation of configurable onboarding thresholds, a 'requirements-due' status per seller, or tunable minimum-data-to-start-selling flows. Missing for 10: explicit docs on per-seller requirement/due states, configurable minimum-onboarding-to-payout thresholds, and any hands-on/independent confirmation of this tunability.", "evidenceIds": [ "adyen-for-platforms-docs-1", "adyen-for-platforms-docs-6", "adyen-for-platforms-docs-7", "adyen-for-platforms-docs-8" ] }, { "productId": "adyen-for-platforms", "storyId": "reconciliation-reporting-exports", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen documents Adyen-generated reports for bookkeeping/reconciliation, webhooks for async status updates instead of polling, and APIs for balance accounts, legal entities, and split transactions that support per-seller and rolled-up reconciliation data. However, evidence doesn't detail scheduled file delivery formats, per-seller vs platform-rolled-up report structures, or specifics on how finance stacks consume these on a schedule. missing for 10: documented report scheduling/delivery mechanics (SFTP/file cadence), explicit per-seller vs aggregate report examples, third-party finance-tool integration evidence.", "evidenceIds": [ "adyen-for-platforms-docs-5", "adyen-for-platforms-docs-13", "adyen-for-platforms-docs-9", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-8" ] }, { "productId": "adyen-for-platforms", "storyId": "seller-reporting-statements", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen provides platform-level reconciliation reports and managed payouts (docs-5, docs-12) that the operator can use, but there is no evidence of a seller-facing self-serve portal, per-seller statements, or bookkeeper-ready exports that sellers can access directly without going through the ops user. missing for 10: seller-facing statement/export UI, evidence of self-serve access for sub-merchants, bookkeeper-specific export formats.", "evidenceIds": [ "adyen-for-platforms-docs-5", "adyen-for-platforms-docs-12", "adyen-for-platforms-docs-16" ] }, { "productId": "adyen-for-platforms", "storyId": "split-payments-routing", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs confirm split payments as first-class API objects — splitting funds among multiple sellers/parties, deducting platform fees, and even split-chargeback handling with three configurable methods for reversing/adjusting after the fact. However, there's no explicit evidence of later adjusting/modifying a split after settlement outside of chargebacks, nor independent/hands-on corroboration of the split-transaction API's flexibility. Missing for 10: evidence of post-settlement split adjustment beyond chargebacks, independent verification/hands-on API examples.", "evidenceIds": [ "adyen-for-platforms-docs-2", "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-11", "adyen-for-platforms-docs-9" ] }, { "productId": "adyen-for-platforms", "storyId": "submerchant-dispute-handling", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm per-transaction chargeback splitting instructions tied to sub-merchants (docs-10) and three configurable ways to handle chargebacks (docs-11), plus webhooks for async status updates (docs-13) that could feed balance updates. However, there's no explicit evidence of a dedicated dispute-evidence submission workflow (API or dashboard) or confirmation that dispute outcomes automatically flow back into seller balances beyond generic split/chargeback allocation. Missing for 10: explicit evidence-submission API/dashboard flow for disputes, documented automatic balance reconciliation post-dispute-outcome, and independent/hands-on confirmation of per-seller dispute routing.", "evidenceIds": [ "adyen-for-platforms-docs-10", "adyen-for-platforms-docs-11", "adyen-for-platforms-docs-13" ] }, { "productId": "adyen-for-platforms", "storyId": "tax-form-generation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers onboarding, payouts, splits, chargebacks, reconciliation reports, and fraud monitoring, but contains no mention of 1099-K threshold tracking, tax form generation/delivery/filing, or a data corrections workflow for tax reporting.", "evidenceIds": [] }, { "productId": "finix", "storyId": "agent-buyer-readiness", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of agent-initiated checkout support, agentic-commerce protocols, or delegated payment credentials tied to marketplace split-funds flows; docs only cover standard onboarding, payouts, disputes, and an MCP server for asking questions about the API, not enabling agent-driven purchases.", "evidenceIds": [ "finix-docs-21", "finix-probe-2", "finix-docs-9", "finix-docs-12" ] }, { "productId": "finix", "storyId": "agent-onboards-sellers", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Finix has API-based seller onboarding (create accounts, onboarding forms, API onboarding flows) and an official MCP server for the docs/API, but the MCP server is documented as a Q&A assistant ('ask an AI agent questions about the Finix API') rather than an actionable surface for agents to create accounts, drive onboarding, or query/answer requirements-due states. No evidence of scoped credentials for agent-driven actions or of onboarding-status/requirements-due endpoints being exposed via MCP. missing for 10: evidence that the MCP server supports actionable operations (account creation, onboarding progression) rather than just Q&A, documentation of requirements-due/onboarding-status API endpoints, and evidence of scoped/agent-specific credentialing.", "evidenceIds": [ "finix-docs-6", "finix-docs-9", "finix-docs-10", "finix-docs-21", "finix-probe-2", "finix-docs-20" ] }, { "productId": "finix", "storyId": "agent-platform-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Finix documents API/dashboard surfaces for reading payouts, diagnosing failed payouts, and uploading dispute evidence (finix-docs-7,12,13,16,17,18), and it ships an official MCP server so agents can query API documentation (finix-docs-21, finix-probe-2). However, the MCP server is explicitly for answering questions about the API, not for performing agent actions like reading live balances or drafting/submitting dispute evidence directly — that still requires building against the REST API. Missing for 10: evidence of an agent actually executing balance/payout reads or dispute-evidence actions via the MCP server or an agent SDK, and independent/hands-on confirmation of agent usability.", "evidenceIds": [ "finix-docs-7", "finix-docs-12", "finix-docs-13", "finix-docs-16", "finix-docs-17", "finix-docs-18", "finix-docs-21", "finix-probe-2" ] }, { "productId": "finix", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Finix has a confirmed llms.txt endpoint returning HTTP 200 with a description of the docs, plus documented agent-oriented resources including an official MCP server for AI agents to query the API. This directly satisfies the story of pointing an agent at llms.txt or agent-oriented docs. Missing for 10: independent/community corroboration of actual agent usage against llms.txt or MCP server in practice.", "evidenceIds": [ "finix-probe-1", "finix-probe-2", "finix-docs-21" ] }, { "productId": "finix", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of AI-generated insights or suggestions surfaced from user data within Finix's dashboard or product; the MCP server evidence only supports asking an AI agent questions about the API, not in-product data insights.", "evidenceIds": [] }, { "productId": "finix", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "finix", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only an MCP server for querying API documentation ([finix-probe-2], [finix-docs-21]) — a developer reference tool, not a built-in AI assistant inside the Finix product that can be delegated tasks (e.g., managing payouts, disputes, onboarding). No evidence of any in-product agentic assistant.", "evidenceIds": [ "finix-docs-21", "finix-probe-2" ] }, { "productId": "finix", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Finix is a payments infrastructure API with developer docs, sandbox environments, and an MCP server for querying API docs, but there is no evidence of a CLI, SDK automation tool, or headless mode designed for CI/automation pipelines. missing for 10: CLI tool, CI/CD integration examples, headless automation documentation, evidence of running Finix operations in scripted/automated pipelines.", "evidenceIds": [] }, { "productId": "finix", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Finix is a payments platform/API, not an AI agent or assistant product; the evidence only shows Finix exposing its own MCP server for external AI agents to query its API (finix-docs-21, finix-probe-2), not Finix itself consuming or plugging in external MCP servers to gain new tool capabilities. This client-side 'plug MCP servers in' story is a category mismatch for a payments SaaS with no agentic core.", "evidenceIds": [ "finix-docs-21", "finix-probe-2" ] }, { "productId": "finix", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Finix documents an official MCP server allowing AI agents to query the Finix API for accurate answers, confirmed by both docs and a probe hit on the dedicated mcp-server page. Missing for 10: no independent/hands-on corroboration of the MCP server working, and no detail on setup, transport, or tool coverage beyond the brief description.", "evidenceIds": [ "finix-docs-21", "finix-probe-2" ] }, { "productId": "finix", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Finix documents an official MCP server that lets an AI agent 'ask questions about the Finix API to get accurate, current answers' (finix-docs-21, finix-probe-2), showing some agentic/natural-language interface exists, but the evidence describes it as a Q&A/documentation lookup tool rather than a way to actually issue commands (e.g., create payouts, onboard sellers) via natural language. Missing for 10: evidence that natural-language commands can trigger real API actions (payouts, onboarding, disputes) rather than just answer questions, and any independent confirmation of this working end-to-end.", "evidenceIds": [ "finix-docs-21", "finix-probe-2" ] }, { "productId": "finix", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official CLI tool; Finix's docs cover APIs, Dashboard, and an MCP server but nothing about a command-line interface for developers.", "evidenceIds": [] }, { "productId": "finix", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Finix provides extensive documented public APIs for onboarding, payouts, disputes, subscriptions, and webhooks, plus a sandbox environment and an llms.txt discovery file for AI agents, showing clear support for programmatic/API-driven use. missing for 10: independent third-party hands-on confirmation of API usability, and more detail on API completeness/versioning beyond docs listing.", "evidenceIds": [ "finix-docs-9", "finix-docs-10", "finix-docs-12", "finix-docs-19", "finix-docs-20", "finix-probe-1" ] }, { "productId": "finix", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Finix docs mention separate Sandbox/Live API credentials but give no evidence of scoped or least-privilege credential issuance (e.g., role-based keys, permission scopes) for agent use cases; the MCP server doc is about querying API docs, not credential scoping.", "evidenceIds": [ "finix-docs-20", "finix-docs-21" ] }, { "productId": "finix", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack repeatedly references Finix's APIs, dashboard, and an MCP server for AI agents to query documentation, but never mentions official SDKs (e.g., Python, Node, Java client libraries) for developers to build against. Missing for 10: any mention of official SDKs, supported languages, or SDK documentation/repos.", "evidenceIds": [ "finix-docs-9", "finix-docs-10", "finix-docs-21", "finix-probe-2" ] }, { "productId": "finix", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Finix has documented webhook support for programmatic notifications when API resources are created/updated, matching the core subscribe-to-events story. missing for 10: no detail on payload schema/signature verification, no independent/hands-on corroboration of webhook reliability, and no explicit AI-agent-specific webhook consumption examples.", "evidenceIds": [ "finix-docs-19" ] }, { "productId": "finix", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Finix has documentation, sandbox/live environments, and an MCP server, but nothing describes an interactive API reference with runnable/executable examples (e.g., no mention of embedded code sandboxes, 'try it' consoles, or in-docs request execution). Missing for 10: evidence of an interactive/runnable API reference tool, any 'try it' console feature, or runnable code snippets in docs.", "evidenceIds": [ "finix-docs-20", "finix-probe-1" ] }, { "productId": "finix", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of a downloadable OpenAPI spec or machine-readable API schema; docs mention guides, an llms.txt file, and an MCP server, but nothing about an OpenAPI/Swagger spec download.", "evidenceIds": [] }, { "productId": "finix", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Finix explicitly documents separate Sandbox and Live accounts with distinct API credentials, and a dedicated test environment that simulates live payments (test cards, fee schemas, payout schedules) without touching production data. missing for 10: independent/hands-on confirmation from a developer using the sandbox, and explicit detail on data isolation guarantees between sandbox and production.", "evidenceIds": [ "finix-docs-20", "finix-docs-26" ] }, { "productId": "finix", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions API versioning scheme or a documented deprecation policy; docs cover product features, sandbox/live environments, webhooks, and an MCP server but nothing about version lifecycle or deprecation commitments.", "evidenceIds": [] }, { "productId": "finix", "storyId": "application-fee-monetization", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Finix explicitly documents platform monetization: per-seller fee customization (international charges, volume discounts, per-method fees), a dedicated 'Monetizing Payments' guide, and dashboard reporting that separates transactions, disputes, and fees across 10+ automated report types. This directly supports application fees/markup, per-seller pricing, and distinct revenue reporting. Missing for 10: no independent/hands-on verification of the revenue-vs-cost reporting split or real-world confirmation that markup fees appear as distinct line items in the dashboard.", "evidenceIds": [ "finix-docs-11", "finix-docs-24", "finix-docs-25", "finix-docs-26", "finix-docs-22" ] }, { "productId": "finix", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Finix's evidence covers payments/payouts/onboarding APIs and an MCP server for querying API docs, but there is no mention of bulk operations, batch endpoints, or multi-item processing capabilities for AI-native automation.", "evidenceIds": [] }, { "productId": "finix", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Finix offers webhooks to receive event notifications, but there is no evidence of a rules engine or automation layer that lets users define conditional triggers/actions on those events—webhooks only push data, requiring external logic to act on it.", "evidenceIds": [] }, { "productId": "finix", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Finix documents recurring billing via Subscriptions and configurable payout schedules in its test environment, which are forms of recurring financial jobs, but there is no evidence of a general-purpose workflow/automation scheduler, cron-like triggers, or AI-agent-driven recurring task orchestration beyond these payment-specific features. Missing for 10: generic recurring workflow/automation engine, scheduling API beyond payouts/subscriptions, AI-agent orchestration of recurring tasks.", "evidenceIds": [ "finix-docs-3", "finix-docs-26", "finix-docs-13" ] }, { "productId": "finix", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Finix is a payments infrastructure API/platform, not an automation-building tool; there is no concept of 'automations' to version, review, or roll back in its product surface—this axis is a category error for a payments processor.", "evidenceIds": [] }, { "productId": "finix", "storyId": "buy-rate-pricing-control", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Finix documents platform monetization tools — fee customization (international charges, volume discounts, per-payment-method fees), configurable fee schemas in test/sandbox, and dashboard reports covering transactions, disputes, and fees — which supports setting a sell rate and viewing cost data. However there is no explicit documentation of a 'buy rate' contract from Finix itself or interchange-level cost breakdowns for spread management. Missing for 10: documented buy rate/cost-plus pricing terms, interchange-level line-item visibility, and independent confirmation of spread transparency.", "evidenceIds": [ "finix-docs-11", "finix-docs-24", "finix-docs-25", "finix-docs-26" ] }, { "productId": "finix", "storyId": "cross-border-payouts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Finix's documented payouts focus on US rails (ACH, wire, card, real-time bank payouts) and its only international-related mention is a fee customization for 'International charges' (finix-docs-25), not multi-currency payout support, FX handling, or local settlement rails. No evidence describes local-currency payouts to international sellers or settlement via local bank networks.", "evidenceIds": [ "finix-docs-13", "finix-docs-15", "finix-docs-25", "finix-docs-12" ] }, { "productId": "finix", "storyId": "embedded-seller-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Finix documents APIs to build custom onboarding, payout, and dispute experiences under the platform's own brand (finix-docs-9, finix-docs-10, finix-docs-12, finix-docs-17) plus dashboard-based reporting (finix-docs-24), suggesting sellers' financial data/actions can be surfaced via API in a host product. However, there is no explicit mention of pre-built white-label UI components/widgets (e.g., embeddable balance or transaction-history widgets) — only APIs and Finix's own hosted Dashboard/forms are described. missing for 10: explicit embeddable/white-label UI component library for balances/transaction history, evidence of branding customization on hosted components, independent confirmation of embedding experience.", "evidenceIds": [ "finix-docs-9", "finix-docs-10", "finix-docs-12", "finix-docs-17", "finix-docs-24", "finix-docs-5" ] }, { "productId": "finix", "storyId": "global-seller-coverage", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers merchant onboarding mechanics (forms, APIs) but there is no documented coverage map of supported onboarding countries, local payment methods, or local-currency settlement — nothing resembling a country/currency/payment-method matrix appears anywhere in the pack.", "evidenceIds": [] }, { "productId": "finix", "storyId": "holds-delayed-release", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Finix documents controlling seller payouts on your own schedule via Dashboard or API and topping up/holding a platform balance before disbursing funds (finix-docs-12, finix-docs-13, finix-docs-15), which supports delaying seller payouts, and it has dispute-handling workflows (finix-docs-17, finix-docs-18). But there is no dedicated 'escrow' feature description — no documented hold-until-delivery mechanism, dispute-window-linked release triggers, or stated limits on how long funds can be held. Missing for 10: explicit escrow/hold-fund mechanics tied to delivery or dispute windows, documented release triggers/automation, and stated limits or edge cases of such holds.", "evidenceIds": [ "finix-docs-12", "finix-docs-13", "finix-docs-15", "finix-docs-17", "finix-docs-18" ] }, { "productId": "finix", "storyId": "in-person-omnichannel", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Finix's online payments, payouts, onboarding, disputes, and reporting APIs, but there is no mention of in-person/card-present capabilities such as terminals, tap-to-pay SDKs, or POS hardware integrations that settle into the same seller balances as online payments. Without any documentation of card-present/terminal support, this applicable capability is unevidenced.", "evidenceIds": [] }, { "productId": "finix", "storyId": "liability-responsibility-split", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence pack shows only feature-level docs (onboarding, payouts, disputes, tokenization) with no explicit documentation splitting liability for KYC/AML, card-network compliance, fraud losses, or seller misconduct between Finix and the platform/ops user. Community items are unrelated commentary about branding/positioning, not liability allocation.", "evidenceIds": [] }, { "productId": "finix", "storyId": "multi-entity-treasury", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers payouts, onboarding, disputes, and dashboard reporting, but contains no mention of where held/in-flight funds are custodied, whether balances earn yield, or how platform funds are segregated from Finix's own accounts — a standard and expected disclosure for a payments/platform-ledger product. missing for 10: any documentation of fund custody/segregation structure, statements on yield/interest on held balances, and disclosure of banking partner or FBO account arrangements.", "evidenceIds": [ "finix-docs-15", "finix-docs-13" ] }, { "productId": "finix", "storyId": "negative-balance-recovery", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence covers disputes monitoring/response, payouts, and balance top-ups, but nothing describes automatic debiting of a seller's future earnings or bank account to recover chargeback/refund losses, nor any documented liability waterfall/order. missing for 10: documentation of automatic negative-balance recovery, debit reversal against future payouts or linked bank account, and liability order documentation.", "evidenceIds": [ "finix-docs-17", "finix-docs-18", "finix-docs-13", "finix-docs-15" ] }, { "productId": "finix", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs repeatedly note dual access via 'Dashboard or API' for payouts, seller payouts, disputes, and onboarding (finix-docs-6,7,8,12,17), indicating most core operations are API-accessible, and a Sandbox/Live environment plus webhooks support programmatic workflows (finix-docs-19,20). However, some UI-only surfaces like reporting/dashboard analytics and pricing/fee customization tools are described only in dashboard terms (finix-docs-22,24,25) without explicit API parity confirmation. Missing for 10: explicit API equivalents for dashboard reporting/analytics and fee-customization UI, and independent/hands-on confirmation that no UI action is API-inaccessible.", "evidenceIds": [ "finix-docs-6", "finix-docs-7", "finix-docs-8", "finix-docs-12", "finix-docs-17", "finix-docs-19", "finix-docs-20", "finix-docs-22", "finix-docs-24" ] }, { "productId": "finix", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence describes an ability to export all account/transaction data in open formats or facilitate leaving the platform; only dashboard reporting features are mentioned, not full data export/portability. Missing for 10: documented bulk data export, open format guarantees (CSV/JSON), or data portability/exit tooling.", "evidenceIds": [] }, { "productId": "finix", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Finix is a proprietary payments API/platform, not an open-source project; source availability under an open license is not a fair axis for this category of product.", "evidenceIds": [] }, { "productId": "finix", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Finix is a hosted payments infrastructure/API platform, not software designed for self-hosting; the evidence pack is entirely about cloud dashboard/API features with no self-host offering. Self-hosting the core product is a category error for this type of SaaS payments platform.", "evidenceIds": [] }, { "productId": "finix", "storyId": "payfac-graduation-path", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Finix's platform-payments features (seller onboarding, payouts, monetization, disputes) but nowhere describes a staged path from a managed/PayFac-as-a-service model to full registered payment facilitation, nor any assurance that such a transition avoids replatforming. This specific payfac-liability graduation story is unaddressed in the pack.", "evidenceIds": [] }, { "productId": "finix", "storyId": "payout-scheduling", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Finix docs confirm real-time payouts to bank accounts or cards, payout links, top-up via ACH/wire, and a test environment where you can 'set payout schedules,' plus per-seller payout management via Dashboard or API. However, there's no explicit documentation of configurable daily/weekly/monthly/manual cadence options per seller or instant-payout-to-real-time-rails distinctions beyond cards. missing for 10: explicit per-seller schedule configuration UI/API (daily/weekly/monthly/manual options), documentation of real-time rail support beyond cards, and independent/hands-on confirmation of scheduling flexibility.", "evidenceIds": [ "finix-docs-7", "finix-docs-12", "finix-docs-13", "finix-docs-15", "finix-docs-26" ] }, { "productId": "finix", "storyId": "platform-ledger-visibility", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Finix provides fee/monetization tooling, a Payouts Dashboard, 10+ automated report types (transactions, disputes, fees), sandbox/live environments and webhooks for tracking resource state changes, which together support financial visibility and reconciliation workflows. However, there is no explicit documentation of a unified ledger view showing per-seller balances alongside platform fee-account balances, or a single traceable charge→split→payout audit trail guaranteed to reconcile to the penny. Missing for 10: dedicated seller-balance/fee-account balance dashboard, explicit charge-to-payout traceability/audit-trail documentation, penny-level reconciliation guarantees or tooling.", "evidenceIds": [ "finix-docs-1", "finix-docs-12", "finix-docs-15", "finix-docs-19", "finix-docs-24", "finix-docs-25", "finix-docs-26" ] }, { "productId": "finix", "storyId": "platform-risk-monitoring", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Finix documents dispute monitoring/response tools, payout dashboards, and automated reports covering transactions/disputes/fees, which partially support portfolio oversight and dispute handling. However there is no evidence of fraud or credit-risk scoring per sub-merchant, anomaly alerts on sellers, or explicit tools to pause payouts or offboard bad actors. missing for 10: fraud/credit-risk signal scoring per sub-merchant, anomaly detection alerts, explicit payout-pause/offboarding controls, independent validation of these risk tools.", "evidenceIds": [ "finix-docs-17", "finix-docs-18", "finix-docs-22", "finix-docs-24", "finix-docs-1" ] }, { "productId": "finix", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack of data residency/region selection controls, storage location options, or compliance-region certifications; Finix's documentation is entirely about payments/payouts/onboarding functionality with no mention of data residency choices.", "evidenceIds": [] }, { "productId": "finix", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Finix is a payments infrastructure platform, not an AI model or data-processing tool; the notion of opting out of AI training data usage is a category error for this product type, not something evidenced or expected in its docs.", "evidenceIds": [] }, { "productId": "finix", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items address data retention policies, deletion controls, or privacy/data lifecycle management for Finix; docs focus entirely on payments, payouts, onboarding, and disputes.", "evidenceIds": [] }, { "productId": "finix", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Finix is a payments infrastructure API/platform, not an AI agent or developer tool with client-side telemetry to opt out of; this privacy-posture story about telemetry opt-out is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "finix", "storyId": "programmatic-seller-onboarding", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Finix docs clearly describe API-based seller onboarding (finix-docs-6, finix-docs-9, finix-docs-10) and hosted 'Onboarding Forms' to save developers from building UI (finix-docs-5), plus general merchant onboarding guidance (finix-docs-4). However, the evidence pack never explicitly details KYC/KYB data collection, bank account linking, or terms-of-service acceptance steps, nor confirms an embeddable (non-hosted-redirect) component distinct from the hosted forms. Missing for 10: explicit KYC/KYB field documentation, bank-account-linking flow details, terms-acceptance step, and confirmation of embeddable UI components (vs. only hosted forms).", "evidenceIds": [ "finix-docs-4", "finix-docs-5", "finix-docs-6", "finix-docs-9", "finix-docs-10" ] }, { "productId": "finix", "storyId": "progressive-onboarding", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Finix docs show onboarding forms and APIs for onboarding sellers, plus dashboard/API controls for seller payouts, implying some flexibility in what's collected before payout, but there's no explicit documentation of a tunable 'minimum to start selling then collect more before payout thresholds' workflow or explicit per-seller requirements-due states. missing for 10: explicit documentation of configurable onboarding requirement tiers, requirements-due state tracking per seller, and evidence of payout-threshold gating tied to progressive data collection.", "evidenceIds": [ "finix-docs-5", "finix-docs-6", "finix-docs-9", "finix-docs-10", "finix-docs-12" ] }, { "productId": "finix", "storyId": "reconciliation-reporting-exports", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Finix docs mention automated dashboard reports (10+ report types covering transactions, disputes, fees) and webhooks for programmatic event notifications, plus seller payout management via API, which together support some reconciliation workflows. However, there is no explicit documentation of scheduled file delivery, per-seller vs rolled-up settlement/balance report APIs, or a dedicated reconciliation/reporting API for finance-stack consumption. Missing for 10: explicit scheduled report export (files/API), per-seller vs aggregate balance reconciliation endpoints, and confirmation of finance-stack integration patterns.", "evidenceIds": [ "finix-docs-24", "finix-docs-12", "finix-docs-19", "finix-docs-17" ] }, { "productId": "finix", "storyId": "seller-reporting-statements", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Finix documents a Payouts Dashboard and >10 automated report types (transactions, disputes, fees) plus seller-payout management tools, which could support reconciliation and reporting, but there's no explicit evidence of a seller-facing self-serve statement/export portal that sellers or their bookkeepers can access directly without going through the platform's ops team. Missing for 10: seller-facing self-serve statement/export UI, explicit reconciliation report for bookkeeper close-out, and any confirmation that sellers (not just the platform) can pull these reports themselves.", "evidenceIds": [ "finix-docs-1", "finix-docs-12", "finix-docs-24", "finix-docs-9" ] }, { "productId": "finix", "storyId": "split-payments-routing", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Finix's platform-payments docs show sellers can be onboarded and paid out, and platforms can 'monetize' payments and customize fees, which implies a split between seller and platform, but no evidence describes a first-class 'split' object spanning multiple sellers on one charge, nor mechanisms to reverse or adjust splits after the fact. missing for 10: explicit multi-party split/transfer API object, ability to route one charge to several sellers simultaneously, and reversal/adjustment of splits post-charge.", "evidenceIds": [ "finix-docs-9", "finix-docs-11", "finix-docs-12", "finix-docs-25" ] }, { "productId": "finix", "storyId": "submerchant-dispute-handling", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Finix documents general dispute management (monitor/act via Dashboard or API, upload evidence, submit response) and separately documents platform/seller-based architecture (onboarding sellers, seller payouts, sub-merchant balances), implying disputes could be tied to sub-merchants, but no docs explicitly confirm chargebacks are routed per-seller or that outcomes automatically adjust seller balances. missing for 10: explicit documentation of chargebacks landing against the correct sub-merchant, and automatic balance reconciliation after dispute resolution.", "evidenceIds": [ "finix-docs-17", "finix-docs-18", "finix-docs-12", "finix-docs-9" ] }, { "productId": "finix", "storyId": "tax-form-generation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions 1099-K thresholds, tax form generation/filing, delivery to sellers, or any data-correction workflow for tax reporting; coverage is limited to payouts, onboarding, disputes, and reporting on transactions/fees.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agent-buyer-readiness", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of agent-initiated checkout, agentic-commerce protocols, or delegated payment credentials; documentation covers wallets, payouts, disputes, FX, and webhooks but nothing about AI/agent buyer flows integrated with split funds. Missing for 10: any mention of agent checkout protocols, delegated payment credential support, or agent-specific API/documentation tying to split funds flows.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agent-onboards-sellers", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mangopay exposes a full API (with OpenAPI) and an official MCP server, plus docs on managing users/accounts in compliance, which supports agent-driven seller operations in principle. However, no evidence explicitly documents onboarding completion flows, KYC 'requirements-due' status handling, or scoped/limited credentials for agent use via the MCP surface. missing for 10: explicit onboarding-completion workflow docs, requirements-due state handling, scoped-credential/permission model for agent access.", "evidenceIds": [ "mangopay-probe-2", "mangopay-probe-3", "mangopay-docs-4", "mangopay-docs-3" ] }, { "productId": "mangopay", "storyId": "agent-platform-operations", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Mangopay ships genuinely agent-usable surfaces: a documented OpenAPI spec, llms.txt agent instructions, and an official MCP server, plus docs on wallets/balances, payouts (with domestic-rail routing details useful for investigating a delayed payout), and disputes/chargebacks (including contesting with proof, which maps to 'draft dispute evidence'). However there's no explicit example or endpoint description for reading balances/payout status programmatically or a worked 'investigate missing payout' or 'draft dispute evidence' agent workflow — these are inferred from adjacent guides rather than directly documented. Missing for 10: explicit balance/payout-status API examples, a documented dispute-evidence submission workflow, and independent/hands-on confirmation the MCP server actually exposes these operations.", "evidenceIds": [ "mangopay-probe-2", "mangopay-probe-3", "mangopay-docs-11", "mangopay-docs-18", "mangopay-docs-19", "mangopay-docs-12", "mangopay-docs-13", "mangopay-docs-20" ] }, { "productId": "mangopay", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mangopay provides a confirmed llms.txt (HTTP 200) explicitly instructing AI agents on retrieving clean Markdown docs, plus a documented OpenAPI spec and even an MCP server endpoint, directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: independent/community confirmation of actual agent usage against these endpoints.", "evidenceIds": [ "mangopay-probe-1", "mangopay-probe-2", "mangopay-probe-3", "mangopay-docs-20" ] }, { "productId": "mangopay", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Mangopay is a payments infrastructure API; evidence covers wallets, payouts, disputes, webhooks, and even an MCP server, but nothing describes AI-generated insights or suggestions surfaced from a user's own data inside a Mangopay product interface. Missing for 10: any dashboard analytics/AI insight feature, any AI-generated suggestion capability, any documentation of such a feature at all.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Mangopay offers webhooks for event-driven notifications and an API/SDKs that could be used to build background automations like automated payouts and fraud checks, but there is no evidence of a native scheduling, workflow, or agentic automation framework that runs autonomously without external orchestration. missing for 10: no first-party automation/scheduler product, no evidence of autonomous background job execution, no documented agent/automation orchestration layer beyond webhooks and API calls.", "evidenceIds": [ "mangopay-docs-14", "mangopay-docs-15", "mangopay-docs-9", "mangopay-docs-7" ] }, { "productId": "mangopay", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mangopay is a payments infrastructure API/platform, not a product with an interactive assistant for end-users to delegate tasks to; the evidence covers wallets, payouts, disputes, webhooks, and an MCP server for developer/agent integration, none of which is a built-in AI assistant for task delegation.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mangopay is a REST API/SDK payments platform with a documented OpenAPI spec, sandbox, and multi-language SDKs, which naturally supports headless/CI automation (scripted API calls, no UI required). However, there is no explicit evidence of CI-specific tooling, CLI, test automation examples, or hands-on confirmation of running it in a CI pipeline. missing for 10: dedicated CLI or CI/CD integration guide, hands-on CI pipeline examples, independent confirmation of headless automation workflows.", "evidenceIds": [ "mangopay-docs-2", "mangopay-docs-3", "mangopay-probe-2" ] }, { "productId": "mangopay", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mangopay is a payments API platform, not an AI agent/assistant that itself consumes tools via MCP; the only MCP-related evidence shows Mangopay publishing its own MCP server for others to consume (the reverse role), not a capability to plug external MCP servers into Mangopay so it can use their tools. This client-side axis is a category mismatch for a payments backend product.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Mangopay is a payments API platform (not an agent itself), so publishing an official MCP server is a valid axis; evidence shows a documented official MCP server endpoint at docs.mangopay.com/_mcp/server alongside llms.txt and OpenAPI probes confirming AI-native tooling support. Missing for 10: no independent/hands-on confirmation of connecting an agent to this MCP server, and no detail on its tool coverage or setup docs beyond the endpoint existing.", "evidenceIds": [ "mangopay-probe-3", "mangopay-probe-1", "mangopay-probe-2" ] }, { "productId": "mangopay", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Mangopay documents an official MCP server (mangopay-probe-3) and an llms.txt with agent-oriented instructions (mangopay-probe-1), which enables AI agents to invoke Mangopay's API via natural-language-mediated tool calls rather than raw SDK code. However there is no direct evidence of a natural-language command interface, chat-based operation, or hands-on confirmation that this works end-to-end. Missing for 10: evidence of actual NL command usage/testing, documentation of specific MCP tools exposed, and any user-facing chat/agent interface beyond the MCP endpoint declaration.", "evidenceIds": [ "mangopay-probe-3", "mangopay-probe-1", "mangopay-docs-3" ] }, { "productId": "mangopay", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official CLI tool; only SDKs in multiple languages, docs, and an MCP server are mentioned, none of which constitute a CLI.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Mangopay provides a documented public REST API with OpenAPI spec, SDKs in multiple languages, sandbox environment, and confirmed live openapi.json endpoint, clearly supporting programmatic/AI-driven use. Missing for 10: independent third-party confirmation of AI-agent usage in production beyond vendor docs/probes.", "evidenceIds": [ "mangopay-docs-2", "mangopay-docs-3", "mangopay-probe-2", "mangopay-probe-1" ] }, { "productId": "mangopay", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of scoped or least-privilege API key/credential issuance for agents — docs cover wallets, payouts, webhooks, FX, disputes, but nothing about API key scoping, permission granularity, or credential minting for automated/agent use.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mangopay documents official SDKs across Node.js, PHP, Python, .NET, Java, and Ruby, plus a public OpenAPI spec, giving AI-native users concrete language-specific starting points and machine-readable API definitions to build against. Missing for 10: independent/hands-on developer corroboration of SDK quality or GitHub repo activity beyond docs claims.", "evidenceIds": [ "mangopay-docs-3", "mangopay-probe-2", "mangopay-docs-2" ] }, { "productId": "mangopay", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Mangopay documents a clear webhook subscription system for event notifications on API objects, configurable via Dashboard or API, which supports agentic/automated integration patterns; docs are also machine-readable (llms.txt, OpenAPI, MCP server) aiding AI-native consumption. Missing for 10: explicit documentation of programmatic webhook creation via API (only Dashboard flow shown) and no independent/hands-on confirmation of webhook reliability.", "evidenceIds": [ "mangopay-docs-14", "mangopay-docs-15", "mangopay-probe-1", "mangopay-probe-2" ] }, { "productId": "mangopay", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mangopay provides sandbox API access, a documented OpenAPI spec, and multi-language getting-started guides, indicating a functional API reference; there's no explicit evidence of an interactive 'try it now' console with runnable examples embedded in the docs UI. missing for 10: explicit interactive try-it-now console evidence, independent hands-on confirmation of runnable examples in the reference itself.", "evidenceIds": [ "mangopay-docs-2", "mangopay-docs-3", "mangopay-probe-2", "mangopay-probe-1" ] }, { "productId": "mangopay", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "A live probe confirms an OpenAPI JSON spec is served at https://docs.mangopay.com/openapi.json returning HTTP 200 with an \"openapi\" key, directly satisfying the machine-readable spec requirement. Missing for 10: independent third-party confirmation or documentation explicitly advertising the OpenAPI download link in the docs UI.", "evidenceIds": [ "mangopay-probe-2" ] }, { "productId": "mangopay", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Mangopay docs explicitly describe a dedicated Sandbox API with simulated test payments, test payment methods (e.g., 3DS2 test cards), and accept/refuse payin simulation flows, allowing full testing without touching production data. Missing for 10: no independent/hands-on confirmation of sandbox-to-production parity or explicit data isolation guarantees beyond docs.", "evidenceIds": [ "mangopay-docs-1", "mangopay-docs-2", "mangopay-docs-16", "mangopay-docs-17" ] }, { "productId": "mangopay", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows an OpenAPI spec and sandbox API docs, but there is no mention of API versioning scheme or a documented deprecation policy anywhere in the pack. missing for 10: explicit API version numbering/headers, changelog of breaking changes, documented deprecation timeline/policy.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "application-fee-monetization", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mangopay's wallet infrastructure supports splitting funds and platforms have their fees automatically wired to their bank account monthly, which supports taking a fee/markup on transactions (mangopay-docs-5, mangopay-docs-10, mangopay-docs-11). However, there is no evidence of per-seller custom pricing configuration or of dashboard/reporting that separates fee revenue from processing costs. Missing for 10: per-seller/variable fee-setting documentation, dedicated revenue-vs-cost reporting/dashboard evidence, independent confirmation of fee mechanics in production.", "evidenceIds": [ "mangopay-docs-5", "mangopay-docs-10", "mangopay-docs-11" ] }, { "productId": "mangopay", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers individual API operations (wallets, payouts, disputes, webhooks) but no documentation of batch/bulk endpoints, multi-item transaction processing, or bulk automation tooling for AI-native workflows. Absence of evidence for this applicable capability yields none. missing for 10: bulk/batch API endpoints, batch payout or transfer operations, evidence of processing many items in a single call.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mangopay provides webhooks that notify external systems on API object events, and documents 'custom logic to detect and mitigate fraud attempts', plus automatic fee/dispute deductions, showing some event-driven automation. However, there's no evidence of a native rules-definition interface or workflow engine letting users declare 'if event X then action Y' logic within Mangopay itself—automation is limited to webhook notifications that require external code to act. Missing for 10: a documented rules/workflow builder, conditional trigger-action configuration UI, and evidence of built-in automated actions beyond webhooks and fee/dispute processing.", "evidenceIds": [ "mangopay-docs-14", "mangopay-docs-15", "mangopay-docs-7", "mangopay-docs-10", "mangopay-docs-12" ] }, { "productId": "mangopay", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mangopay is a payments infrastructure API, not an automation/workflow-building tool; versioning, reviewing, and rolling back 'automations' is not a concept that applies to its product category.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "buy-rate-pricing-control", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows only generic fee/wallet documentation (e.g., fees wired monthly, wallet infrastructure) but nothing about a documented buy rate, ability to set a sell rate, or interchange-level cost breakdown for spread management. Community comments merely speculate about overall pricing being surprisingly low, not about rate transparency or spread control tools.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "cross-border-payouts", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly describe local-currency payouts via domestic bank rails (smart routing prioritizing domestic rail over wire), multi-currency sends in 24+ currencies, and embedded FX conversion for global markets, directly matching the finance-lead story. missing for 10: no explicit documented FX rate/markup transparency or fee schedule, and no independent/hands-on confirmation of settlement times or local rail coverage per country.", "evidenceIds": [ "mangopay-docs-18", "mangopay-docs-19", "mangopay-docs-6", "mangopay-docs-8", "mangopay-docs-10" ] }, { "productId": "mangopay", "storyId": "embedded-seller-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mangopay provides robust wallet, payout, and transaction APIs (docs-5, docs-6, docs-11, docs-18/19) that let developers build branded balance/payout/history experiences, plus webhooks for real-time updates (docs-14/15) — satisfying the 'APIs' half of the story. However, there is no evidence of prebuilt white-label UI components/widgets for embedding these surfaces directly, only raw API access and a dashboard for the platform itself. Missing for 10: documented drop-in UI components/widgets for balances/payouts/history, evidence of front-end SDKs for seller-facing embedding, and independent confirmation of embedding in production.", "evidenceIds": [ "mangopay-docs-5", "mangopay-docs-6", "mangopay-docs-11", "mangopay-docs-14", "mangopay-docs-15", "mangopay-docs-18", "mangopay-docs-19" ] }, { "productId": "mangopay", "storyId": "global-seller-coverage", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs mention multi-currency payouts (24+ currencies), FX conversion, smart domestic-rail routing, and automated fee settlement, implying broad geographic/currency coverage, but there is no evidence of an explicit onboarding coverage map listing supported countries, KYC requirements per region, or local payment methods per market. Founders would still need to discover country-specific onboarding requirements piecemeal. missing for 10: a documented country/coverage map, list of supported local payment methods per country, explicit onboarding country list, independent confirmation of coverage claims.", "evidenceIds": [ "mangopay-docs-6", "mangopay-docs-8", "mangopay-docs-18", "mangopay-docs-19", "mangopay-docs-10" ] }, { "productId": "mangopay", "storyId": "holds-delayed-release", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Mangopay's wallet infrastructure explicitly supports holding funds indefinitely ('as long as needed') and releasing them via API/webhook-triggered events, with dispute/chargeback mechanics documented separately, which together give escrow-like fund-holding and release-on-trigger behavior. However the evidence doesn't show a dedicated 'escrow' product or documented limits (max hold duration, fees for holding, delivery-window-specific triggers) as a unified concept. Missing for 10: explicit escrow/hold-duration limits documentation, a named delivery/dispute-window release mechanism, and independent verification of this workflow in practice.", "evidenceIds": [ "mangopay-docs-5", "mangopay-docs-11", "mangopay-docs-12", "mangopay-docs-13", "mangopay-docs-14" ] }, { "productId": "mangopay", "storyId": "in-person-omnichannel", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence pack covers wallets, payouts, FX, disputes, webhooks, and online payin testing, but there is no mention of physical POS terminals or tap-to-pay/in-person SDKs that settle into the same wallet/balance system as online payments. Missing for 10: any documentation of terminal hardware, in-person card-present SDKs, or unified online/offline settlement flows.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "liability-responsibility-split", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docs mention compliance features (KYC guidance, fraud tooling, dispute/chargeback contestation) but nowhere is there an explicit ops-facing breakdown of who owns KYC/AML, card-network compliance, fraud losses, and seller misconduct versus Mangopay — it's scattered feature docs, not a liability-split reference.", "evidenceIds": [ "mangopay-docs-4", "mangopay-docs-7", "mangopay-docs-12", "mangopay-docs-13" ] }, { "productId": "mangopay", "storyId": "multi-entity-treasury", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs confirm Mangopay's wallet infrastructure lets platforms hold, split and transfer funds and that platform fees are wired out monthly (mangopay-docs-5, mangopay-docs-10, mangopay-docs-11), giving some sense of where funds sit, but there is no evidence addressing regulatory fund segregation from Mangopay's own accounts or whether held balances earn yield. missing for 10: explicit safeguarding/segregation-of-client-funds statement, disclosure of interest/yield policy on wallet balances, third-party or regulatory confirmation of fund protection.", "evidenceIds": [ "mangopay-docs-5", "mangopay-docs-10", "mangopay-docs-11" ] }, { "productId": "mangopay", "storyId": "negative-balance-recovery", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Mangopay's dispute/e-wallet docs confirm that chargebacks trigger automatic fund deduction from the wallet and create a contestable dispute settled with Mangopay, showing some liability handling ([mangopay-docs-12], [mangopay-docs-13]). However, there is no documented mechanism for recovering shortfalls beyond wallet balance via automatic debits against future earnings or the seller's linked bank account, nor an explicit documented liability order/waterfall for such recovery. Missing for 10: explicit negative-balance recovery via future payouts, bank debit/clawback mechanics, and a documented liability order beyond the basic dispute-contest flow.", "evidenceIds": [ "mangopay-docs-12", "mangopay-docs-13", "mangopay-docs-10", "mangopay-docs-11" ] }, { "productId": "mangopay", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mangopay is API-first: docs show a full OpenAPI spec, sandbox API, and API-driven wallet, payout, dispute, and webhook management, suggesting broad functional parity. However, some flows (e.g., webhook setup, dispute proof submission) are documented via the Dashboard UI as an alternative path, and there is no explicit claim that all Dashboard actions are always mirrored in the API. Missing for 10: explicit statement of full UI/API parity, and evidence that dashboard-only admin actions (e.g., dispute contestation, account config) are fully API-accessible.", "evidenceIds": [ "mangopay-docs-2", "mangopay-probe-2", "mangopay-docs-14", "mangopay-docs-15", "mangopay-docs-13", "mangopay-docs-5" ] }, { "productId": "mangopay", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Mangopay is a payments/wallet API platform; the evidence pack shows no data export, portability, or account-closure/data-migration functionality in open formats. No documentation or community evidence addresses exporting user/transaction data for departure.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mangopay is a closed-source SaaS payments platform; open-licensed source code availability is not a fair axis for this type of product, and no evidence suggests any open-source release.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mangopay is a hosted payments/fintech SaaS API, not open-source software; self-hosting the core product is a category error for this type of product.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "payfac-graduation-path", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence describes a graduation path from managed/wallet model to registered payment-facilitator status with increased economics/control, nor any migration tooling or licensing tiers. Evidence only covers wallet infrastructure, payouts, disputes, and API onboarding — nothing about payfac-liability progression. Missing for 10: any mention of licensing tiers, BIN sponsorship, PF-of-record transition, or economics/control changes as platforms scale.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "payout-scheduling", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers wallet infrastructure, payout routing rails (domestic vs cross-border), and platform fee wiring, but contains no mention of configurable payout schedules (daily/weekly/monthly/manual) per seller, nor instant payouts to cards or real-time rails. Missing for 10: any documentation of per-seller payout scheduling, manual vs automatic payout triggers, or instant/real-time payout options.", "evidenceIds": [ "mangopay-docs-18", "mangopay-docs-19", "mangopay-docs-10", "mangopay-docs-11" ] }, { "productId": "mangopay", "storyId": "platform-ledger-visibility", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm wallet infrastructure supporting per-seller and platform fee wallets, automatic fee payout to bank, webhooks for event tracking (charge/payin, split/transfer, payout), and dispute/chargeback handling — the building blocks for traceability and reconciliation. However there is no explicit documentation of a unified ledger/reporting view, reconciliation reports, or per-penny audit trail tooling that a finance lead would use directly. Missing for 10: dedicated reconciliation/reporting API or dashboard view showing full charge-to-payout trace, statement/ledger export functionality, and independent confirmation that balances reconcile to the penny in practice.", "evidenceIds": [ "mangopay-docs-5", "mangopay-docs-10", "mangopay-docs-11", "mangopay-docs-12", "mangopay-docs-13", "mangopay-docs-14", "mangopay-docs-15" ] }, { "productId": "mangopay", "storyId": "platform-risk-monitoring", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Mangopay docs show custom fraud-detection logic, dispute/chargeback handling, and webhook event notifications that could support risk monitoring, but there is no evidence of a per-sub-merchant risk dashboard, anomaly alerts across a seller portfolio, or explicit tools to pause payouts/offboard bad actors. missing for 10: portfolio-level risk dashboard per sub-merchant, anomaly/alerting system for sellers, payout-pause or offboarding workflow.", "evidenceIds": [ "mangopay-docs-7", "mangopay-docs-12", "mangopay-docs-13", "mangopay-docs-14", "mangopay-docs-15" ] }, { "productId": "mangopay", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of data residency/region selection options in Mangopay's documentation or community reports; the evidence pack covers wallets, payouts, disputes, webhooks and testing but never mentions data storage location or residency choices.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Mangopay is a payments/wallet infrastructure API, not an AI model or AI training data consumer; opting out of AI training data usage is not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses data retention policies, deletion controls, or privacy/data-lifecycle settings for users; the docs focus on payments, wallets, payouts, and disputes. Missing for 10: any documentation on data retention periods, user data deletion APIs/requests, GDPR-style erasure workflows, or privacy control settings.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack material addresses telemetry, usage tracking, or opt-out settings for Mangopay's docs, SDKs, or MCP server; all evidence concerns payments features and pricing/community skepticism unrelated to telemetry.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "programmatic-seller-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only vaguely references 'managing a community of paying users in full compliance' and wallet/payout infrastructure, but contains no documentation of KYB/KYC onboarding APIs, hosted onboarding flows, embeddable UI components, bank account linking, or terms-of-service acceptance mechanisms — the core elements of this story are entirely unevidenced.", "evidenceIds": [ "mangopay-docs-4" ] }, { "productId": "mangopay", "storyId": "progressive-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows generic compliance and wallet/payout docs (e.g., mangopay-docs-4, mangopay-docs-11) but nothing about tiered/progressive KYC, minimum-to-start onboarding, or explicit requirements-due states tied to payout thresholds. Missing for 10: documentation of staged KYC levels, seller onboarding status states, and payout gating tied to verification completeness.", "evidenceIds": [ "mangopay-docs-4", "mangopay-docs-11" ] }, { "productId": "mangopay", "storyId": "reconciliation-reporting-exports", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Mangopay's docs show wallet balances, automatic monthly fee wiring, and webhook event notifications that could feed a finance stack, but there is no explicit documentation of settlement/balance report files or scheduled per-seller reconciliation APIs. missing for 10: dedicated reconciliation/settlement report API or downloadable file exports, explicit per-seller rollup reporting, and evidence of scheduled delivery cadence.", "evidenceIds": [ "mangopay-docs-10", "mangopay-docs-11", "mangopay-docs-14", "mangopay-docs-15" ] }, { "productId": "mangopay", "storyId": "seller-reporting-statements", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers wallets, payouts, disputes, webhooks, and FX/routing infrastructure, but contains no mention of seller-facing statements, payout reconciliation reports, or bookkeeper-ready exports that would let sellers self-serve without contacting ops. This is a fair axis for a marketplace payments platform, but no supporting documentation or feature reference exists in the pack.", "evidenceIds": [] }, { "productId": "mangopay", "storyId": "split-payments-routing", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Mangopay's wallet infrastructure explicitly supports receiving, holding, splitting and transferring funds across an unlimited number of wallets, with platform fees automatically routed to the platform's bank account, which enables multi-party fund routing and fee-taking (docs-5, docs-10, docs-11). However, evidence does not detail a first-class 'split payment' API object, nor explicit mechanisms to adjust or reverse a split after the fact beyond generic dispute/chargeback handling (docs-12, docs-13) which addresses refunds, not split adjustment. Missing for 10: explicit API object/documentation for defining a payment split across multiple recipients in one transaction, and documented reversal/adjustment of that split specifically (not just wallet transfers or chargebacks).", "evidenceIds": [ "mangopay-docs-5", "mangopay-docs-10", "mangopay-docs-11", "mangopay-docs-12", "mangopay-docs-13" ] }, { "productId": "mangopay", "storyId": "submerchant-dispute-handling", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm that disputes/chargebacks are tied to a wallet's user (i.e., per-seller) and that funds are automatically deducted and can be contested with proof (mangopay-docs-12, mangopay-docs-13), and wallets are per-platform-user (mangopay-docs-11), implying per-sub-merchant handling. However, there is no explicit documentation of an API or dashboard workflow for submitting dispute evidence, nor confirmation that outcomes automatically reconcile back into seller balances beyond the initial deduction. Missing for 10: explicit evidence-submission API/dashboard flow, confirmation of sub-merchant-specific dispute routing, and automatic balance reconciliation after outcome.", "evidenceIds": [ "mangopay-docs-11", "mangopay-docs-12", "mangopay-docs-13" ] }, { "productId": "mangopay", "storyId": "tax-form-generation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack references 1099-K thresholds, tax form generation/filing, or a tax data correction workflow; the docs cover wallets, payouts, disputes, webhooks, and FX but nothing about US tax reporting compliance. missing for 10: 1099-K threshold tracking, form generation/delivery/filing, corrections workflow documentation.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agent-buyer-readiness", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payment-processing/merchant-of-record platform for embedding payments into a software platform, not a marketplace or agent framework offering agent-initiated checkout protocols or delegated payment credentials for AI agents; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agent-onboards-sellers", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Rainforest exposes a REST API for creating merchant accounts, driving onboarding via embeddable components, and webhook notifications for status/requirements changes (rainforest-docs-5, rainforest-docs-4, rainforest-docs-8, rainforest-docs-10), which could plausibly be driven by an agent. However there is no evidence of an MCP server/surface, no mention of scoped or agent-specific credentials, and the openapi probe returned 404s suggesting no discoverable machine-readable API spec for agent tooling. missing for 10: MCP server/tool surface, scoped/agent-specific API credentials, explicit agent-orchestration documentation, discoverable OpenAPI spec.", "evidenceIds": [ "rainforest-docs-5", "rainforest-docs-4", "rainforest-docs-8", "rainforest-docs-10", "rainforest-probe-2" ] }, { "productId": "rainforest", "storyId": "agent-platform-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Rainforest documents merchant, deposit and webhook APIs (e.g. deposit frequency, event subscriptions) that touch payout mechanics, and its docs are markdown-fetchable via llms.txt for agent consumption, but there is no documented endpoint for reading balances, investigating a missing payout, or drafting dispute/chargeback evidence, and the probe found no OpenAPI spec for structured agent access. missing for 10: explicit balance/payout read endpoints, dispute-evidence drafting API, and a machine-readable OpenAPI spec.", "evidenceIds": [ "rainforest-docs-7", "rainforest-docs-8", "rainforest-docs-5", "rainforest-probe-1", "rainforest-probe-2" ] }, { "productId": "rainforest", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "A probe confirms a live llms.txt file at docs.rainforestpay.com/llms.txt (HTTP 200) that explicitly documents the docs and notes pages can be fetched as .md, and multiple doc pages are indeed available with .md suffixes as referenced elsewhere in the pack. Missing for 10: no independent/third-party confirmation of agent usage with this llms.txt, and no evidence of a broader agent-oriented docs structure beyond the single llms.txt file.", "evidenceIds": [ "rainforest-probe-1", "rainforest-docs-4", "rainforest-docs-5" ] }, { "productId": "rainforest", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments-processing/embedded-finance API platform, not a data/analytics product with an interface for AI-generated insights; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure/API platform, not a product with a built-in AI assistant UX; delegating tasks to an in-product AI assistant is a category error for this type of product and no evidence suggests otherwise.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Rainforest exposes REST APIs and webhooks, which theoretically could be scripted, but there is no evidence of a CLI, headless mode, or CI-integration tooling — the docs focus on merchant onboarding, payment components, and pricing, not automation/agentic workflows. missing for 10: CLI or SDK for automation, explicit CI/headless usage examples, any agent/automation-oriented tooling.", "evidenceIds": [ "rainforest-docs-5", "rainforest-docs-8", "rainforest-probe-2" ] }, { "productId": "rainforest", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure/API platform, not an AI agent or assistant; the evidence shows no MCP-related capability at all, and plugging MCP servers into an agent is a category error for this product type.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an official CLI tool anywhere in the docs or probes; the pack only covers REST API endpoints, webhooks, and embeddable components. Missing for 10: any mention of a CLI, its installation, or command reference.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Rainforest ships an extensive documented REST API (create/update merchant, webhooks, deposits, amount splits) with a reference doc site and an llms.txt for machine-readable docs access, showing a genuine public API surface. However, a probe for standard machine-discoverable API specs (OpenAPI/Swagger) returned 404s across all candidate paths, meaning there's no verified formal schema for automated/agentic API consumption. Missing for 10: a discoverable OpenAPI/Swagger spec, SDK/client library evidence, and explicit agent-tooling integration guidance.", "evidenceIds": [ "rainforest-docs-5", "rainforest-docs-7", "rainforest-docs-8", "rainforest-probe-1", "rainforest-probe-2" ] }, { "productId": "rainforest", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments-processing platform; evidence covers merchant onboarding, payments, webhooks, and pricing but no mention of scoped or least-privilege API credential issuance for agents, API key management, or permission scoping.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows REST API reference docs, webhooks, and embeddable components, with no mention of official client SDKs in any language; the OpenAPI probe even returned 404s for spec endpoints. Missing for 10: any documented SDK (e.g., Node/Python/Java client libraries), package registry listing, or SDK quickstart guide.", "evidenceIds": [ "rainforest-probe-2", "rainforest-docs-5", "rainforest-docs-16" ] }, { "productId": "rainforest", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Rainforest's docs explicitly describe a webhooks/notifications system where you can subscribe to events for a list of resources, directly matching the story. missing for 10: no independent/hands-on corroboration or details on payload signing/retry semantics beyond the doc listing.", "evidenceIds": [ "rainforest-docs-8" ] }, { "productId": "rainforest", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows conventional API reference pages (e.g., create_merchant.md) and general docs, but nothing describes an interactive, runnable API console or live code execution; the OpenAPI/swagger probe returned 404s, suggesting no standard interactive spec is exposed. missing for 10: evidence of a 'try it' console, runnable code samples, or OpenAPI-based interactive explorer.", "evidenceIds": [ "rainforest-docs-5", "rainforest-probe-2" ] }, { "productId": "rainforest", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Rainforest exposes a documentation site with reference pages for its API, but a direct probe for standard OpenAPI/Swagger spec locations (openapi.json, swagger.json, etc.) returned 404 across all candidates, and no other evidence shows a downloadable machine-readable spec (only an llms.txt for markdown docs).", "evidenceIds": [ "rainforest-probe-2", "rainforest-probe-1" ] }, { "productId": "rainforest", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Rainforest explicitly documents a sandbox environment for testing payments with dedicated test cards/accounts that don't touch production, plus 'full end-to-end sandbox testing' mentioned as a platform feature. Missing for 10: independent/hands-on corroboration of sandbox fidelity, and more detail on data isolation guarantees beyond card-decline behavior.", "evidenceIds": [ "rainforest-docs-9", "rainforest-docs-16" ] }, { "productId": "rainforest", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes returned 404s and docs only cover functional payment integration topics, not API lifecycle/versioning commitments.", "evidenceIds": [ "rainforest-probe-2" ] }, { "productId": "rainforest", "storyId": "application-fee-monetization", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Rainforest supports buy-rate/interchange-plus pricing with full control over what founders bill merchants, meaning markup/margin capture is real and per-merchant pricing is possible (rainforest-docs-12, rainforest-docs-13), and amount splits let platforms take a fee on each transaction (rainforest-docs-6). However, evidence does not show a dedicated 'platform revenue' reporting view that separates markup/application-fee revenue from underlying processing costs — reporting docs focus on merchant/transaction data, not platform P&L separation. missing for 10: explicit per-seller/per-merchant custom pricing configuration UI or API field, and a distinct revenue-vs-cost reporting/dashboard feature for the platform itself.", "evidenceIds": [ "rainforest-docs-12", "rainforest-docs-13", "rainforest-docs-6", "rainforest-docs-7" ] }, { "productId": "rainforest", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Rainforest is a payments processing API/platform; evidence covers merchant onboarding, payments, deposits, webhooks, and pricing, but nothing describes bulk operations across many items (e.g., batch payment processing, bulk merchant creation, or batch API endpoints). No evidence of any bulk/batch capability.", "evidenceIds": [ "rainforest-docs-5", "rainforest-docs-1", "rainforest-docs-8" ] }, { "productId": "rainforest", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Rainforest offers webhook subscriptions for resource events (e.g., merchant, payment status changes), which provides a basic event-trigger mechanism, but there is no documented rules engine or conditional 'if event X then action Y' automation layer for defining custom logic. missing for 10: rule/condition definition syntax, built-in action execution (not just external webhook delivery), examples of automated workflows triggered by rules.", "evidenceIds": [ "rainforest-docs-8" ] }, { "productId": "rainforest", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure/API platform, not an automation-building tool; versioning, reviewing, and rolling back 'automations' is not a fair axis for this product category.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "buy-rate-pricing-control", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Vendor docs explicitly state a buy-rate, interchange-plus pricing model with no revenue split, and confirm platforms fully control the sell rate charged to merchants, with pricing optimizations flowing directly to the platform's margin. Missing for 10: independent/third-party corroboration of actual interchange-level cost breakdowns in the dashboard/API and real customer confirmation of spread visibility.", "evidenceIds": [ "rainforest-docs-12", "rainforest-docs-13" ] }, { "productId": "rainforest", "storyId": "cross-border-payouts", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Rainforest's docs describe US-centric payment processing, merchant onboarding, deposits, and payouts, but there is no mention of multi-currency support, FX handling, local-currency payouts, or settlement to local bank rails in other countries — the product appears scoped to US card/ACH processing only.", "evidenceIds": [ "rainforest-docs-7", "rainforest-docs-14", "rainforest-docs-15" ] }, { "productId": "rainforest", "storyId": "embedded-seller-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Rainforest explicitly offers pre-built embeddable components for payments, reporting, chargebacks, and merchant onboarding, plus a 'payment component studio' for designing branded embedded components for platform integration, supporting white-labeled seller-facing surfaces like transaction/payment history [rainforest-docs-15, rainforest-docs-4, rainforest-docs-11]. However, deposits/payouts are only exposed via API endpoints (e.g., updating deposit frequency) with no explicit mention of a dedicated embeddable balances or payouts UI component, and no evidence of granular white-label branding controls beyond the component studio. Missing for 10: explicit embeddable balance/payout UI components, documented white-label branding/customization API for these surfaces, and independent/hands-on confirmation of branding flexibility.", "evidenceIds": [ "rainforest-docs-15", "rainforest-docs-4", "rainforest-docs-11", "rainforest-docs-7" ] }, { "productId": "rainforest", "storyId": "global-seller-coverage", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Rainforest's payment methods (card, PayPal, Venmo, ACH, Apple Pay) and onboarding/merchant creation flows, but nothing documents a coverage map of supported onboarding countries, local payment methods per country, or local-currency settlement — ACH and the overall feature set suggest a US-centric product with no cross-border documentation provided.", "evidenceIds": [ "rainforest-docs-14", "rainforest-docs-4", "rainforest-docs-5" ] }, { "productId": "rainforest", "storyId": "holds-delayed-release", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers payment processing, deposits/payout frequency, amount splits, and webhooks, but nothing describes holding seller funds in escrow until delivery or dispute windows pass, nor programmable release triggers or documented limits for such a mechanism — missing for 10: escrow/hold-funds primitive, delivery/dispute-window release logic, and documented limits on hold duration or amounts.", "evidenceIds": [ "rainforest-docs-6", "rainforest-docs-7", "rainforest-docs-8" ] }, { "productId": "rainforest", "storyId": "in-person-omnichannel", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Rainforest documents both online payments and 'Process payments with a device' (terminal-style in-person processing) under the same merchant/API model, implying shared merchant balances and reporting infrastructure (deposits, webhooks). However, there is no explicit documentation of a tap-to-pay SDK or an explicit statement confirming that in-person device payments settle into the exact same balance/reporting pipeline as online payments. missing for 10: explicit tap-to-pay SDK support, explicit confirmation that device/terminal payments unify with online payments in settlement and reporting, independent corroboration of in-person hardware integration.", "evidenceIds": [ "rainforest-docs-2", "rainforest-docs-1", "rainforest-docs-7", "rainforest-docs-8" ] }, { "productId": "rainforest", "storyId": "liability-responsibility-split", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers onboarding, payments, deposits, webhooks, and pricing docs, but nothing explicitly documents a liability/responsibility split for KYC/AML ownership, card-network compliance, fraud losses, or seller misconduct between Rainforest and the platform.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "multi-entity-treasury", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers merchant onboarding, payment processing, and deposit frequency settings, but nothing addresses where in-flight/held funds are custodied, whether balances earn yield, or how funds are segregated from Rainforest's own accounts. This is a fair question for a payments/payfac platform, so the axis applies, but no evidence supports it.", "evidenceIds": [ "rainforest-docs-7" ] }, { "productId": "rainforest", "storyId": "negative-balance-recovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The pack only shows a generic mention of a 'chargebacks' component (rainforest-docs-15) among Rainforest's embeddable features, but there is no documentation describing automatic debits against future earnings, bank account debits for negative balances, or a documented liability order for recovering losses. Missing for 10: any doc on negative-balance recovery mechanics, reserve/liability sequencing, or bank-account debit process.", "evidenceIds": [ "rainforest-docs-15" ] }, { "productId": "rainforest", "storyId": "openness-api-parity", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Rainforest's docs show a broad set of API endpoints (create/update merchant, deposits, splits, webhooks, payments) covering most core functionality, and it is fundamentally API-first with embeddable UI components layered on top rather than a separate full UI. However, there is no explicit statement or evidence mapping every UI capability (e.g., the payment component studio design flow) to an equivalent API call, so full parity is unconfirmed. Missing for 10: explicit parity documentation or changelog confirming API/UI feature equivalence, and evidence that studio/dashboard-only actions can be performed purely via API.", "evidenceIds": [ "rainforest-docs-5", "rainforest-docs-6", "rainforest-docs-7", "rainforest-docs-8", "rainforest-docs-11" ] }, { "productId": "rainforest", "storyId": "openness-full-export", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure/API platform, not a data-holding SaaS tool where users store personal content that would need bulk export in open formats to 'leave'; the story's premise (exporting all user data and leaving) is a category error for a payment processing API product.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a closed-source payments infrastructure/API platform, not an open-source project; source-code licensing is not a relevant axis for this kind of commercial SaaS product.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure/API SaaS product, not software designed for self-hosting; self-hosting a payment processing platform is a category error for this type of product.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "payfac-graduation-path", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence describes Rainforest's managed payfac model, pricing control, and onboarding components, but there is no mention of a defined path or product mechanism to graduate from Rainforest's managed platform toward becoming a registered/independent PayFac without replatforming. missing for 10: any documentation of a registered-PayFac graduation path, migration tooling, or sponsor-bank transition process.", "evidenceIds": [ "rainforest-docs-12", "rainforest-docs-13", "rainforest-docs-15" ] }, { "productId": "rainforest", "storyId": "payout-scheduling", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm per-merchant deposit frequency can be configured and updated via the API (rainforest-docs-7), supporting scheduled payouts per seller, but there is no evidence of instant/real-time payouts to cards or push-to-card rails, nor explicit mention of daily/weekly/monthly/manual options as distinct settings. missing for 10: instant payouts to cards or real-time rails, explicit enumeration of daily/weekly/monthly/manual schedule options, and any confirmation of per-seller instant payout support.", "evidenceIds": [ "rainforest-docs-7" ] }, { "productId": "rainforest", "storyId": "platform-ledger-visibility", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Rainforest documents amount splits, payout/deposit scheduling, merchant creation, and webhooks for payment-lifecycle events, plus a generic 'reporting' embeddable component, which together imply some traceability from charge to payout. However there is no explicit documentation of a ledger, seller-level balance views, fee-account tracking, or penny-level reconciliation tooling. Missing for 10: dedicated ledger/balance reporting docs, explicit reconciliation guarantees, fee-account balance visibility, and any independent confirmation of reconciliation accuracy.", "evidenceIds": [ "rainforest-docs-6", "rainforest-docs-7", "rainforest-docs-8", "rainforest-docs-15" ] }, { "productId": "rainforest", "storyId": "platform-risk-monitoring", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers merchant onboarding, payments processing, deposits, webhooks, and pricing, but nothing addresses fraud/credit-risk monitoring, anomaly alerts, or tools to pause payouts/offboard sellers as portfolio risk-management features for ops users.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments processing/embedded fintech platform, not an AI data-storage or AI-native product; data residency/region selection is not a relevant axis for this product category based on the evidence.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure/API platform, not an AI model or AI data-processing service; AI-training data opt-out is not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments processing platform, not an AI/data-handling product; the evidence pack contains no AI data-retention context, so this privacy-posture axis about AI data retention/deletion is a category mismatch.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Rainforest is a payments infrastructure API/platform, not an AI agent or dev tool with telemetry collection relevant to AI-native usage tracking opt-out; this privacy-posture axis about telemetry opt-out is a category error for this product type.", "evidenceIds": [] }, { "productId": "rainforest", "storyId": "programmatic-seller-onboarding", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs explicitly describe API-driven merchant creation (KYB/KYC via merchant application), embeddable low-code onboarding components, and pre-built components for merchant onboarding as an alternative to building forms; deposit/webhook docs suggest bank account linking is part of merchant setup. missing for 10: explicit mention of terms/e-sign acceptance flow and dedicated bank-linking API endpoint documentation, plus independent/hands-on corroboration.", "evidenceIds": [ "rainforest-docs-4", "rainforest-docs-5", "rainforest-docs-15", "rainforest-docs-11", "rainforest-docs-7" ] }, { "productId": "rainforest", "storyId": "progressive-onboarding", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers merchant creation, onboarding components, and going-live phases, but nothing describes staged/tunable onboarding requirements, minimum-to-start thresholds, or per-seller 'requirements-due' states tied to payout limits.", "evidenceIds": [ "rainforest-docs-4", "rainforest-docs-5", "rainforest-docs-10" ] }, { "productId": "rainforest", "storyId": "reconciliation-reporting-exports", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Rainforest mentions a pre-built 'reporting' embeddable component and webhooks/events for merchant and payment resources, plus deposit frequency settings per merchant, which are adjacent to reconciliation, but there is no explicit documentation of settlement/balance reports per seller and rolled up, nor of scheduled file or API delivery for a finance stack. missing for 10: dedicated settlement/balance report docs, per-seller and rollup reconciliation reports, scheduled file exports, finance-system API integration details.", "evidenceIds": [ "rainforest-docs-7", "rainforest-docs-8", "rainforest-docs-15" ] }, { "productId": "rainforest", "storyId": "seller-reporting-statements", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Rainforest advertises a pre-built embeddable 'reporting' component alongside payments, chargebacks, and onboarding, implying some seller-facing financial visibility, but the docs pack contains no specifics on per-seller statements, payout reconciliation reports, or bookkeeper-ready exports. Missing for 10: documentation of statement generation, reconciliation report format/fields, and export capabilities (CSV/PDF) for bookkeepers.", "evidenceIds": [ "rainforest-docs-15", "rainforest-docs-7" ] }, { "productId": "rainforest", "storyId": "split-payments-routing", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Rainforest documents an 'amount splits' feature implemented via API steps (rainforest-docs-6), supporting the core idea of routing a charge across parties, but there is no evidence of split objects being adjustable or reversible after the fact, no detail on how many parties can be split among, and no confirmation these splits are exposed as standalone first-class API objects rather than a payment-creation parameter. Missing for 10: adjustable/reversible split objects, multi-party routing detail, explicit object model documentation, and independent corroboration.", "evidenceIds": [ "rainforest-docs-6" ] }, { "productId": "rainforest", "storyId": "submerchant-dispute-handling", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Rainforest advertises a pre-built 'chargebacks' component alongside merchant onboarding and payments, implying dispute handling exists in a submerchant-based platform, but the evidence never details per-seller/sub-merchant dispute routing, API-based evidence submission, or automatic balance reconciliation of outcomes. missing for 10: documentation on chargeback-to-submerchant assignment, evidence submission API/dashboard specifics, and how dispute outcomes update seller balances.", "evidenceIds": [ "rainforest-docs-15" ] }, { "productId": "rainforest", "storyId": "tax-form-generation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack addresses 1099-K threshold tracking, tax form generation/delivery/filing, or a data correction workflow; evidence only covers payments, onboarding, deposits, webhooks, and pricing.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "agent-buyer-readiness", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers standard Connect marketplace/split-payment functionality (charges, payouts, onboarding, balances) but contains no mention of agent-initiated checkout, agentic-commerce protocols, or delegated payment credentials for AI agent buyers. Missing for 10: any documentation of agent/AI buyer checkout support, delegated payment credential mechanisms, or agentic-commerce protocol integration with split funds.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "agent-onboards-sellers", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Stripe Connect exposes full API surface for creating connected accounts, driving onboarding (embedded or API-based), and checking requirements via identity verification (docs-4, docs-5, docs-16), and Stripe documents an official MCP server (probe-4). However, there's no evidence the MCP server specifically exposes Connect account-creation/onboarding/requirements-due operations, nor any documentation of scoped credentials for agent-driven seller operations. Missing for 10: MCP tool list showing Connect account management functions, explicit scoped-credential/permission model for agents, and evidence of agents actually completing onboarding or resolving requirements-due states end-to-end.", "evidenceIds": [ "stripe-connect-docs-4", "stripe-connect-docs-5", "stripe-connect-docs-16", "stripe-connect-probe-4" ] }, { "productId": "stripe-connect", "storyId": "agent-platform-operations", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Stripe publishes concrete API-level surfaces an agent could use: retrieving a connected account's balance (stripe-connect-docs-18), managing/scheduling payouts (stripe-connect-docs-7, docs-13), viewing disputes (stripe-connect-docs-17), webhooks for investigating events (stripe-connect-docs-15), plus an official MCP server (stripe-connect-probe-4) and CLI (stripe-connect-probe-5) that give agents a documented, tool-callable interface rather than just human docs. However, the evidence only shows dispute *viewing* in the Dashboard, not an API/MCP-exposed workflow for drafting/submitting dispute evidence, and there's no hands-on proof of an agent actually chaining balance+payout+dispute calls to 'investigate a missing payout.' Missing for 10: documented dispute-evidence submission surface usable by an agent, and independent/hands-on evidence of an agent performing the described investigate-and-draft workflow via MCP/API.", "evidenceIds": [ "stripe-connect-docs-18", "stripe-connect-docs-7", "stripe-connect-docs-13", "stripe-connect-docs-17", "stripe-connect-docs-15", "stripe-connect-probe-4", "stripe-connect-probe-5" ] }, { "productId": "stripe-connect", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Evidence confirms an llms.txt file is live at docs.stripe.com/llms.txt (HTTP 200) alongside markdown-formatted docs pages (e.g., connect.md) accessible for agent consumption, directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: no explicit documentation describing llms.txt's intended use/structure for agents, and no independent third-party confirmation of agent usage beyond the probe.", "evidenceIds": [ "stripe-connect-probe-1", "stripe-connect-probe-2" ] }, { "productId": "stripe-connect", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments infrastructure API/platform for marketplaces, not a data analytics or insights product; nothing in the evidence pack relates to AI-generated insights or suggestions from user data within the product's UI. This story is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe Connect supports background, event-driven automation via scheduled automatic payouts and webhooks for Connect events, and an official MCP server exists for AI agent integration, but there is no documentation of end-users setting up autonomous AI-driven automations or agent workflows built on Connect. missing for 10: explicit AI-agent automation setup, orchestration/scheduling controls beyond payouts, evidence of autonomous background AI workflows using Connect.", "evidenceIds": [ "stripe-connect-docs-13", "stripe-connect-docs-15", "stripe-connect-probe-4" ] }, { "productId": "stripe-connect", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments platform infrastructure product, not an assistant/agent interface; there's no built-in AI assistant to delegate tasks to (only an unrelated MCP server enabling external agents to call Stripe APIs). This axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Connect is fundamentally API-driven (API onboarding, webhooks, testing docs) and ships an official CLI, both of which support headless/CI automation, but there is no explicit documentation or example of running it in a CI pipeline or scripted automation context. missing for 10: explicit CI/CD examples, automation-focused docs, independent evidence of CI usage.", "evidenceIds": [ "stripe-connect-docs-5", "stripe-connect-docs-14", "stripe-connect-docs-15", "stripe-connect-probe-5" ] }, { "productId": "stripe-connect", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments platform/API, not an AI agent or assistant that hosts tools and consumes MCP servers as a client. The evidence shows Stripe offers an official MCP *server* (docs.stripe.com/mcp) for AI agents to call into Stripe, which is the reverse relationship — not Stripe Connect acting as an MCP client plugging in external servers. This axis is a category error for a payments infrastructure product.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe documents an official MCP server at docs.stripe.com/mcp, confirming agents can connect via a first-party MCP endpoint; Stripe is a payments platform (not itself an agent), so the axis applies and is satisfied. Missing for 10: no detail on Connect-specific MCP tool coverage, no independent/hands-on corroboration of the MCP server working with Connect operations.", "evidenceIds": [ "stripe-connect-probe-4" ] }, { "productId": "stripe-connect", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Stripe documents an official MCP server (docs.stripe.com/mcp) which would let AI agents interact with Stripe Connect via natural-language-driven tool calls, and also has an official CLI, but the evidence pack gives no detail on what Connect-specific actions are exposed via MCP or any hands-on confirmation of natural-language operation. missing for 10: details on MCP tool coverage for Connect operations, independent/hands-on validation of natural-language control, and confirmation beyond a bare 'documented at URL' probe.", "evidenceIds": [ "stripe-connect-probe-4", "stripe-connect-probe-5" ] }, { "productId": "stripe-connect", "storyId": "agentic-official-cli", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe documents an official CLI (stripe-cli) that supports platform-wide API workflows including Connect, giving AI-native users a scriptable interface. missing for 10: no direct evidence the CLI has AI-native/agentic features (e.g., natural-language mode) or independent hands-on validation of CLI usage specifically for Connect workflows.", "evidenceIds": [ "stripe-connect-probe-5" ] }, { "productId": "stripe-connect", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Connect is fully driven through Stripe's documented public REST API (account creation, onboarding, charges, payouts, balances, webhooks) per docs, and probes confirm an official CLI and MCP server exist for programmatic/agentic access. missing for 10: no direct OpenAPI spec discovery (probe found 404s on standard OpenAPI paths) and no independent hands-on validation of AI-agent-driven API usage specifically.", "evidenceIds": [ "stripe-connect-docs-5", "stripe-connect-docs-15", "stripe-connect-docs-18", "stripe-connect-probe-4", "stripe-connect-probe-5", "stripe-connect-probe-3" ] }, { "productId": "stripe-connect", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments platform for marketplaces/platforms managing connected accounts, not an agent-facing credentialing system; scoped/least-privilege API credentials for AI agents is not a fair axis for this product's category (though Stripe does offer restricted API keys generally, no evidence ties this to agent-specific credential issuance in Connect).", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Evidence shows Stripe Connect exposes a full API (docs-5, docs-6) and references official package distribution via npm (probe-1), plus AI-friendly docs (llms.txt) and an official MCP server/CLI (probe-4, probe-5), all of which support AI-native SDK-based development. However, the pack never explicitly documents a dedicated 'Official SDKs' page or lists supported languages, so the SDK claim is inferred rather than directly evidenced. missing for 10: explicit official SDK/library documentation page, multi-language SDK examples, independent developer confirmation of SDK usage for Connect specifically.", "evidenceIds": [ "stripe-connect-docs-5", "stripe-connect-docs-6", "stripe-connect-probe-1", "stripe-connect-probe-4", "stripe-connect-probe-5" ] }, { "productId": "stripe-connect", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe Connect has documented webhook support explicitly for Connect events ('All Connect integrations should establish a webhook endpoint to listen for Connect events'), and community evidence confirms real-world usage ('The webhooks are great'). This covers the core subscribe-to-events capability. Missing for 10: explicit documentation of event types/payload schema in this pack, agentic/AI-native framing of webhook consumption, and independent verification of reliability at scale.", "evidenceIds": [ "stripe-connect-docs-15", "stripe-connect-comm-4" ] }, { "productId": "stripe-connect", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains only docs.stripe.com guide pages, an llms.txt probe, CLI/MCP mentions, and a failed openapi.json probe (404 on all candidate paths) — nothing documents an interactive API reference page or runnable/try-it code examples for Connect. Since this is a fair expectation for an API-first product, absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [ "stripe-connect-probe-3", "stripe-connect-probe-1", "stripe-connect-probe-2" ] }, { "productId": "stripe-connect", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows a direct probe for OpenAPI/swagger spec files at all standard locations returning 404, and no other evidence item shows a downloadable machine-readable API spec (only markdown docs, an MCP server, and CLI are documented).", "evidenceIds": [ "stripe-connect-probe-3" ] }, { "productId": "stripe-connect", "storyId": "api-sandbox", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly cover testing the Connect integration (account creation, identity verification, payouts) before going live, implying a sandbox/test-mode workflow, but there's no explicit description of a dedicated 'sandbox environment' distinct from production, no mention of test API keys/test clocks, or how AI agents would interact with it. missing for 10: explicit sandbox/test-mode documentation separate from production, test data isolation details, and independent/hands-on confirmation of sandbox usage.", "evidenceIds": [ "stripe-connect-docs-14", "stripe-connect-docs-15" ] }, { "productId": "stripe-connect", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of API versioning, version headers, or a documented deprecation policy for Stripe Connect's APIs; all citations describe product features (onboarding, payouts, disputes, etc.) rather than API lifecycle/versioning practices. Missing for 10: any documentation of API version pinning, deprecation notices, changelog, or migration guides.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "application-fee-monetization", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm the core mechanics of platform monetization: splitting charges to add an application fee (stripe-connect-docs-6), no-code pricing strategy tools for different sellers/use-cases (stripe-connect-docs-8), and balance/payout management per connected account (stripe-connect-docs-7, stripe-connect-docs-18). However, there is no explicit documentation of a dashboard or reporting view that separates platform application-fee revenue from Stripe's own processing costs, and community threads show real confusion over fee structure ('double dipping') rather than confirmation of clean revenue/cost separation. Missing for 10: explicit reporting/dashboard feature that isolates platform revenue vs. processing fees, and clearer documentation of per-seller custom pricing configuration beyond a general pricing-tools mention.", "evidenceIds": [ "stripe-connect-docs-6", "stripe-connect-docs-8", "stripe-connect-docs-7", "stripe-connect-docs-18", "stripe-connect-comm-11" ] }, { "productId": "stripe-connect", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Stripe Connect exposes per-resource APIs (accounts, payouts, balances) but nothing in the evidence pack describes bulk/batch operations across many connected accounts or transactions at once (e.g., batch create, bulk payout, multi-object update endpoints). Missing for 10: documented bulk/batch API endpoints, evidence of batch job or async bulk-processing tooling, and any AI-native automation examples operating on many items simultaneously.", "evidenceIds": [ "stripe-connect-docs-7", "stripe-connect-docs-9", "stripe-connect-docs-13" ] }, { "productId": "stripe-connect", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe Connect supports event-driven automation via webhooks (e.g. listening for account, payout, dispute events) and built-in automatic/scheduled payouts, but these require the platform to write custom webhook handlers rather than a declarative 'if-this-then-that' rules engine; the only no-code rule configuration mentioned is for pricing strategies, not general event-action automation. Missing for 10: a documented no-code/rules-based automation builder for arbitrary event-to-action mappings, and evidence of AI-native rule definition tooling.", "evidenceIds": [ "stripe-connect-docs-15", "stripe-connect-docs-13", "stripe-connect-docs-12", "stripe-connect-docs-8" ] }, { "productId": "stripe-connect", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments platform API/product for onboarding and paying connected accounts, not an automation-building tool with a concept of 'automations' that could be versioned, reviewed, or rolled back. This axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "buy-rate-pricing-control", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Stripe Connect lets platforms split payments and set application/sell-side fees via 'platform pricing tools' and charge splitting, and Stripe's own processing rate is publicly documented, giving a documented buy rate and sell-rate freedom. However there is no evidence of interchange-level cost visibility or granular spread management — a community thread even shows confusion over Stripe's fee structure ('double dipping') rather than clear line-item interchange transparency. Missing for 10: interchange-level fee breakdown/reporting, documented spread/cost visibility tools, and evidence resolving the community confusion about fee stacking.", "evidenceIds": [ "stripe-connect-docs-6", "stripe-connect-docs-8", "stripe-connect-docs-18", "stripe-connect-comm-11" ] }, { "productId": "stripe-connect", "storyId": "cross-border-payouts", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs confirm platforms can pay out to connected accounts, schedule payouts, and check connected-account balances, and one community comment praises Stripe Connect for enabling international marketplace payouts, but the pack contains no explicit documentation of local-currency payout rails, FX conversion mechanics, or settlement to local bank rails versus wires. An older community complaint even flags lack of international support as a pain point. missing for 10: dedicated docs on multi-currency payouts, FX conversion/fee transparency, and local bank-rail settlement for connected accounts.", "evidenceIds": [ "stripe-connect-docs-7", "stripe-connect-docs-13", "stripe-connect-docs-18", "stripe-connect-comm-8", "stripe-connect-comm-12" ] }, { "productId": "stripe-connect", "storyId": "embedded-seller-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe Connect exposes APIs for connected-account balances, payout scheduling/management, and transaction data (docs-7, docs-13, docs-18), and documents an embeddable onboarding component that lives inside the platform's own app (docs-4), supporting the general idea of white-labeled seller surfaces. However, the evidence pack only shows an embedded UI component for onboarding, not for balances, payouts, or transaction history themselves — those are described as raw APIs the developer must build UI around, not turnkey embeddable components. missing for 10: explicit documentation of embeddable balance/payout/transaction-history components (vs. only onboarding), and independent confirmation these render fully white-labeled inside a host app.", "evidenceIds": [ "stripe-connect-docs-4", "stripe-connect-docs-7", "stripe-connect-docs-13", "stripe-connect-docs-18", "stripe-connect-docs-9" ] }, { "productId": "stripe-connect", "storyId": "global-seller-coverage", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows generic onboarding, identity-verification, and payout docs, but none of the citations reference a consolidated coverage map of supported onboarding countries, local payment methods, or local-currency settlement. In fact, community evidence points the other way: complaints about lack of international support and confusion between a blog post claiming broad country support and docs limiting it to US/Canada (comm-8, comm-10), suggesting coverage info is scattered rather than a single documented map. missing for 10: an explicit supported-countries list, a local-payment-methods matrix, and a local-currency settlement reference, plus confirmation these are unified rather than discovered piecemeal.", "evidenceIds": [ "stripe-connect-comm-8", "stripe-connect-comm-10" ] }, { "productId": "stripe-connect", "storyId": "holds-delayed-release", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe Connect docs confirm the underlying primitives needed for escrow-like fund holding — connected-account balances can be checked via API (docs-18), payout timing can be scheduled or set to manual (docs-13), and dispute visibility exists in the Dashboard (docs-17) — meaning a developer can technically hold funds until a trigger and then release a payout on demand. However, there is no dedicated 'escrow' feature or documentation describing dispute-window-specific holds, delivery-triggered releases, or the compliance limits of doing so; a community thread even raises unresolved compliance concerns about using transfer holds to delay payouts (stripe-connect-comm-13), which is a caveat rather than a proven failure. missing for 10: explicit escrow/hold-until-trigger documentation, dispute-window-specific release mechanics, and clarified compliance limits for manually delaying payouts.", "evidenceIds": [ "stripe-connect-docs-13", "stripe-connect-docs-18", "stripe-connect-docs-17", "stripe-connect-docs-12", "stripe-connect-comm-13" ] }, { "productId": "stripe-connect", "storyId": "in-person-omnichannel", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Connect's online payment splitting, onboarding, payouts, identity verification, and dashboard features, but contains no mention of Stripe Terminal, in-person/tap-to-pay hardware or SDKs, or how such in-person payments would settle into the same connected-account balances/reporting as online charges. This is an applicable axis for a payments platform (Stripe does offer Terminal separately), so absence of evidence here yields 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "liability-responsibility-split", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The docs describe operational features (identity verification, dispute dashboards, payouts) but none explicitly lay out a responsibility matrix for who owns KYC/AML, card-network compliance, fraud losses, or seller misconduct — that allocation is left implicit or pushed to the underlying account agreement. Community evidence even shows a user unsure whether a specific payout pattern is compliant, underscoring the lack of a documented liability split.", "evidenceIds": [ "stripe-connect-docs-16", "stripe-connect-docs-17", "stripe-connect-comm-13" ] }, { "productId": "stripe-connect", "storyId": "multi-entity-treasury", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs show connected-account balance visibility, payout scheduling/instant payouts, and Treasury for holding funds and cash-back, giving a finance lead partial insight into where funds sit and payout timing. However there is no explicit documentation on how platform funds are legally segregated from Stripe's own accounts, nor clear policy on whether held balances earn yield/interest, and a community thread raises unresolved compliance questions about funds sitting via 'Special Case Transfer' before payout. missing for 10: explicit fund-segregation/custody disclosures, yield/interest policy on held balances, clear compliance answer to the raised concern.", "evidenceIds": [ "stripe-connect-docs-18", "stripe-connect-docs-10", "stripe-connect-docs-13", "stripe-connect-docs-12", "stripe-connect-comm-13" ] }, { "productId": "stripe-connect", "storyId": "negative-balance-recovery", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Connect supports viewing disputes (docs-17) and checking connected-account balances (docs-18), but nothing documents automatic debiting of future earnings or a connected account's bank account to cover refunds/chargebacks that exceed balance, nor any documented liability ordering. missing for 10: negative balance recovery/debit mechanics, bank-account debit fallback, documented liability order between platform and seller.", "evidenceIds": [ "stripe-connect-docs-17", "stripe-connect-docs-18" ] }, { "productId": "stripe-connect", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show Stripe Connect exposes nearly all platform operations (account creation, onboarding, charges, payouts, treasury, cards, balances, webhooks) via API, including an explicit 'API onboarding' path as an alternative to the embedded UI component (stripe-connect-docs-5), and CLI/MCP tooling further extend programmatic control (stripe-connect-probe-4, stripe-connect-probe-5). However, some capabilities like dispute review, account management, and no-code pricing tools are documented as Dashboard-centric (stripe-connect-docs-9, stripe-connect-docs-17, stripe-connect-docs-8) without explicit confirmation that every such action has a full API equivalent. Missing for 10: explicit documentation confirming 1:1 API parity for dispute resolution/dashboard review actions, and independent/hands-on confirmation that no UI-only feature exists.", "evidenceIds": [ "stripe-connect-docs-5", "stripe-connect-docs-9", "stripe-connect-docs-17", "stripe-connect-docs-8", "stripe-connect-probe-4", "stripe-connect-probe-5" ] }, { "productId": "stripe-connect", "storyId": "openness-full-export", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments platform API for building marketplaces, not a data-hosting product where end users store personal data that they'd need to export in open formats and leave; data export/portability is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is closed-source proprietary SaaS; no evidence of any open-license source availability is provided in the pack, and the axis is fair to ask (a payments platform could theoretically open-source SDKs/components) but no such evidence exists.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a hosted payments infrastructure/SaaS product; self-hosting the core service is a category error, not an applicable axis for a cloud payment processing platform.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "payfac-graduation-path", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs show Connect offers a spectrum of control—managed onboarding vs. custom API onboarding, unified identity with multiple account configurations (merchant/customer), and platform-level control over payouts, pricing, and balances—implying a platform can grow from a lighter-touch managed setup toward more direct control without switching providers. However, there is no explicit documentation of a formal path to registered payment-facilitator (PayFac) status, its licensing/economics implications, or how liability shifts as a platform matures.\nmissing for 10: explicit PayFac registration/graduation path, documentation on liability shift and licensing requirements, case studies of platforms moving from managed to PayFac model without replatforming.", "evidenceIds": [ "stripe-connect-docs-3", "stripe-connect-docs-4", "stripe-connect-docs-5", "stripe-connect-docs-7", "stripe-connect-docs-9", "stripe-connect-docs-18" ] }, { "productId": "stripe-connect", "storyId": "payout-scheduling", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs explicitly cover configurable automatic payout scheduling per connected account (daily/weekly/monthly/manual) and instant payouts to cards/real-time rails where supported, matching the story's core requirements. Missing for 10: no explicit confirmation that schedule can be set independently per-seller at scale with concrete examples, and no independent/hands-on corroboration of the scheduling flexibility beyond docs.", "evidenceIds": [ "stripe-connect-docs-13", "stripe-connect-docs-12", "stripe-connect-docs-7" ] }, { "productId": "stripe-connect", "storyId": "platform-ledger-visibility", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs show core building blocks for ledger legibility: per-connected-account balance retrieval, charge splitting between platform and sellers, payout scheduling/management, and webhook events for tracking money movement, plus dispute visibility. However there's no explicit evidence of a dedicated reconciliation/reporting API or penny-level ledger export, and community threads flag real confusion over fee 'double dipping' and payout timing/compliance that complicate exact traceability. missing for 10: explicit reconciliation/reporting tooling (e.g. balance transaction reports), documented penny-accurate audit trail from charge→split→payout, and independent confirmation that finance teams can fully reconcile without extra tooling.", "evidenceIds": [ "stripe-connect-docs-18", "stripe-connect-docs-6", "stripe-connect-docs-7", "stripe-connect-docs-13", "stripe-connect-docs-15", "stripe-connect-docs-17", "stripe-connect-comm-11", "stripe-connect-comm-13" ] }, { "productId": "stripe-connect", "storyId": "platform-risk-monitoring", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm identity verification for risk reduction, a Dashboard to review/manage connected accounts and take action, and visibility into disputes across the platform — core building blocks for portfolio risk oversight. However there is no evidence of per-seller fraud/credit-risk scoring, automated anomaly alerts, or explicit payout-pause/offboarding workflows for bad actors.\nmissing for 10: per-merchant fraud/credit-risk scoring, anomalous-seller alerting, explicit pause-payout/offboard tooling, independent evidence these risk tools work in practice.", "evidenceIds": [ "stripe-connect-docs-16", "stripe-connect-docs-17", "stripe-connect-docs-9", "stripe-connect-docs-13" ] }, { "productId": "stripe-connect", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions data residency, regional data storage, or configurable data location for Stripe Connect; the axis applies (payments platforms commonly address data residency for compliance) but no supporting documentation is present.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments/platform infrastructure product for marketplaces, not an AI model or AI service that trains on user data, so an AI-training data-opt-out control is a category error for this product type.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments/marketplace platform, not an AI agent or data-processing tool where 'data retention and deletion controls for an AI-native user' is a fair category question; no evidence pack items address AI data retention/deletion at all.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Connect is a payments/marketplace platform API, not an AI agent or telemetry-collecting developer tool where an 'opt out of telemetry' privacy control would be a fair axis; no evidence pack content addresses telemetry opt-out.", "evidenceIds": [] }, { "productId": "stripe-connect", "storyId": "programmatic-seller-onboarding", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly describe both hosted onboarding (embeddable Account onboarding component) and full API onboarding for custom UIs, plus identity verification, bank account/external account linking, and payouts — covering KYC/KYB and bank linking needs without building forms. Community quotes (OAuth flow, webhooks) corroborate ease of onboarding, though some complaints about seller-facing friction and international limits reflect UX rather than capability gaps. Missing for 10: explicit mention of terms-of-service acceptance step in onboarding flow and more recent independent hands-on validation of the embedded components.", "evidenceIds": [ "stripe-connect-docs-4", "stripe-connect-docs-5", "stripe-connect-docs-16", "stripe-connect-docs-7", "stripe-connect-comm-3", "stripe-connect-comm-4" ] }, { "productId": "stripe-connect", "storyId": "progressive-onboarding", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm flexible onboarding (embedded component or custom API-driven UI) and identity verification to reduce risk, which implies staged data collection, but no evidence explicitly describes tunable minimum-to-start thresholds or discrete 'requirements-due' states per seller. Missing for 10: explicit documentation of progressive/staggered requirement collection tied to payout thresholds, and clear surfacing of per-seller requirements-due status in the dashboard or API.", "evidenceIds": [ "stripe-connect-docs-4", "stripe-connect-docs-5", "stripe-connect-docs-16", "stripe-connect-docs-9" ] }, { "productId": "stripe-connect", "storyId": "reconciliation-reporting-exports", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs show balance-per-account retrieval and payout scheduling APIs, which are building blocks for reconciliation, but there is no evidence of a dedicated reconciliation/reporting API, scheduled file exports, or rolled-up settlement reports designed for finance-stack consumption. Missing for 10: dedicated reporting/reconciliation API (e.g. Sigma or Reporting API), scheduled file delivery mechanism, explicit rolled-up multi-seller settlement report format, and any first-party or community evidence of automated reconciliation workflows.", "evidenceIds": [ "stripe-connect-docs-18", "stripe-connect-docs-13", "stripe-connect-docs-7", "stripe-connect-docs-9" ] }, { "productId": "stripe-connect", "storyId": "seller-reporting-statements", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows platform-level Dashboard management, balance API calls, and payout scheduling for connected accounts — all requiring developer/ops involvement, not self-serve seller statements, reconciliation reports, or bookkeeper-ready exports. No mention of an Express-style seller dashboard, downloadable statements, or export tooling that would let sellers or their bookkeepers close the books without contacting the platform ops team. Missing for 10: seller-facing statement/export UI, reconciliation report generation, bookkeeper self-serve documentation.", "evidenceIds": [ "stripe-connect-docs-9", "stripe-connect-docs-18", "stripe-connect-docs-13", "stripe-connect-docs-17" ] }, { "productId": "stripe-connect", "storyId": "split-payments-routing", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs clearly show charges can be split between platform and connected accounts as first-class API objects (docs-6, docs-7), with balances and payouts manageable per account (docs-18, docs-13). However, the evidence pack lacks explicit documentation of reversing or adjusting a split after the fact (e.g., reversing transfers or partial refunds tied to application fees), only touching disputes generally (docs-17). missing for 10: explicit reversal/adjustment API documentation, independent hands-on confirmation of split modification.", "evidenceIds": [ "stripe-connect-docs-6", "stripe-connect-docs-7", "stripe-connect-docs-18", "stripe-connect-docs-13", "stripe-connect-docs-17" ] }, { "productId": "stripe-connect", "storyId": "submerchant-dispute-handling", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm disputes are tracked per connected account and viewable in the Dashboard for both platform and connected accounts, supporting the 'right sub-merchant' targeting (stripe-connect-docs-17), and connected-account balance retrieval exists (stripe-connect-docs-18). However, the evidence pack lacks explicit documentation of submitting dispute evidence via API/dashboard for connected accounts or confirmation that dispute outcomes automatically adjust seller balances. missing for 10: dedicated evidence-submission API/dashboard flow for connected-account disputes, and explicit description of automatic balance reconciliation post-dispute-resolution.", "evidenceIds": [ "stripe-connect-docs-17", "stripe-connect-docs-18" ] }, { "productId": "stripe-connect", "storyId": "tax-form-generation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers onboarding, payments, payouts, disputes, identity verification, and treasury, but contains no mention of 1099-K tracking, tax form generation/delivery/filing, or a documented data corrections workflow for tax reporting.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agent-buyer-readiness", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of agentic-commerce protocol support, delegated payment credentials, or agent-initiated checkout anywhere in the pack; documentation covers standard payment platform features (API keys, webhooks, merchant onboarding, payouts) with no mention of AI agent buyers or agent checkout flows.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agent-onboards-sellers", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Tilled's docs show API-driven merchant onboarding (create, pre-fill, and edit applications in `created`/`started` status) and dashboard progress tracking of onboarding steps, which supports part of the 'agent drives onboarding' story. However, there is no evidence of an MCP surface, no mention of scoped/restricted API credentials for agent use, and no explicit handling of 'requirements-due' states via API. missing for 10: MCP server/tool surface, scoped credential model for agents, explicit requirements-due state API.", "evidenceIds": [ "tilled-docs-7", "tilled-docs-8", "tilled-docs-12", "tilled-docs-1" ] }, { "productId": "tilled", "storyId": "agent-platform-operations", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs confirm a general API with keys and webhooks for real-time events, and payout speed/dispute management are documented, but they are explicitly described as Dashboard-based features rather than agent-callable API endpoints for reading balances, investigating payouts, or drafting dispute evidence. Missing for 10: explicit API endpoints/schemas for balances, payout investigation, and dispute evidence submission usable by an autonomous agent, plus any agent/automation-specific tooling or examples.", "evidenceIds": [ "tilled-docs-10", "tilled-docs-11", "tilled-docs-4", "tilled-docs-1" ] }, { "productId": "tilled", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of an llms.txt file, agent-oriented documentation, or any mention of AI agent-friendly docs; the evidence pack only shows standard developer documentation for payments/onboarding.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments/payouts infrastructure platform (merchant onboarding, payment processing, disputes, payouts); no AI/ML insight or suggestion feature is part of its category, and none of the evidence mentions AI-generated insights on user data. This is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments infrastructure/API platform for ISVs and merchants; there is no evidence of, or plausible expectation for, a built-in AI assistant to which tasks can be delegated. This is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments/merchant onboarding platform with no evidence of any AI agent tooling; MCP server integration is a category error for this product type, not a missing capability.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-mcp-server", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-nl-commands", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-public-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Tilled documents a public API with API keys, a quick-start guide, sandbox/test environment, and webhooks for event-driven use, indicating the product can be driven programmatically (tilled-docs-1, tilled-docs-2, tilled-docs-3, tilled-docs-4). However, the evidence pack lacks a full API reference/spec, SDK details, or independent developer corroboration of building an integration end-to-end. Missing for 10: comprehensive API reference/OpenAPI docs, SDK examples, and third-party/hands-on confirmation of programmatic control.", "evidenceIds": [ "tilled-docs-1", "tilled-docs-2", "tilled-docs-3", "tilled-docs-4" ] }, { "productId": "tilled", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows basic API key generation for platform access; there is no mention of scoped, least-privilege, or role-restricted credentials suitable for delegating to an AI agent.", "evidenceIds": [ "tilled-docs-1" ] }, { "productId": "tilled", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers API keys, sandbox testing, webhooks, merchant onboarding, and dashboard features, but contains no mention of official SDKs (e.g., language-specific libraries like Python, Node.js, Java) for developers to build against.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Tilled documents webhooks that provide real-time event notifications, confirming basic webhook subscription support, but there is no evidence of event type filtering, subscription management API, signature verification, or retry/delivery configuration details. missing for 10: documented list of subscribable event types, webhook management/configuration API, signature verification details, independent/hands-on confirmation.", "evidenceIds": [ "tilled-docs-4" ] }, { "productId": "tilled", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows standard docs (quick-start, webhooks, testing, onboarding) but no mention of an interactive API reference or runnable code examples/sandbox console embedded in docs.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item mentions an OpenAPI spec, Swagger file, or any downloadable machine-readable API specification; docs only describe API concepts and dashboard features.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Tilled explicitly offers a sandbox environment for testing, including simulating declines and mock card-present/terminal testing, without touching production data. Missing for 10: independent/hands-on corroboration beyond vendor docs, and no explicit mention of automated/agentic test workflows or CI integration.", "evidenceIds": [ "tilled-docs-2", "tilled-docs-3", "tilled-docs-6" ] }, { "productId": "tilled", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items mention API versioning, version numbers, or a deprecation policy for Tilled's API; documentation covers keys, webhooks, onboarding, and dashboard features but not lifecycle/versioning practices.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "application-fee-monetization", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Tilled documents per-seller pricing via merchant pricing templates (tilled-docs-9), which supports setting per-seller pricing, but there is no evidence of an application-fee/markup mechanism on transactions or of a dashboard/report that separates platform revenue from underlying processing costs. Missing for 10: explicit application fee or markup configuration per transaction, and a revenue-vs-processing-cost reporting view.", "evidenceIds": [ "tilled-docs-9" ] }, { "productId": "tilled", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Tilled's evidence pack covers payments API, onboarding, disputes, payouts, and webhooks, but there is no mention of bulk/batch operations across many items (e.g., bulk payment creation, bulk merchant updates, batch API endpoints for multiple resources at once). The only 'batch' reference concerns settlement batch closing for a single store's transactions, not bulk operations across many items.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Tilled offers webhooks for event notifications (tilled-docs-4) but there is no evidence of a rules engine or conditional trigger system that lets users define automated actions based on those events.", "evidenceIds": [ "tilled-docs-4" ] }, { "productId": "tilled", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments/payouts infrastructure API, not an automation-building tool with workflows to version, review, or roll back; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "buy-rate-pricing-control", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Tilled's docs mention merchant pricing templates that let platforms set pricing per payment method, implying sell-rate control (tilled-docs-9), but there is no documented buy rate from Tilled or interchange-level cost visibility described anywhere in the evidence pack. missing for 10: explicit buy rate disclosure, interchange-level cost breakdown/visibility tools, and spread-management reporting.", "evidenceIds": [ "tilled-docs-9" ] }, { "productId": "tilled", "storyId": "cross-border-payouts", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers merchant onboarding, payouts speed settings, disputes, and dashboard features, but contains no mention of international sellers, multi-currency support, FX handling, or local bank rail settlement outside the US. Tilled appears to be a US-focused payment facilitator platform with no documented cross-border/local-currency payout capability.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "embedded-seller-components", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Tilled explicitly offers white-labeling of API, onboarding, and reporting console under a partner's own domain, and documents building custom UIs on top of its API (payouts, disputes, subscriptions data are accessible via Dashboard/API). This supports embeddable seller-facing surfaces but the evidence doesn't detail specific pre-built components for balances/transaction history or give independent proof of embedding fidelity. Missing for 10: dedicated embeddable balance/transaction-history widget docs, explicit component-level white-label UI examples, and independent/hands-on confirmation of the white-label experience.", "evidenceIds": [ "tilled-docs-14", "tilled-docs-15", "tilled-docs-10", "tilled-docs-11", "tilled-docs-13" ] }, { "productId": "tilled", "storyId": "global-seller-coverage", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents a coverage map of supported onboarding countries, local payment methods, or local-currency settlement; all citations relate to API/dashboard mechanics, merchant onboarding flow, and product journal updates rather than geographic/currency coverage. missing for 10: supported-country list, local payment method coverage, local-currency settlement documentation.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "holds-delayed-release", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "tilled", "storyId": "in-person-omnichannel", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Tilled docs mention card-present terminal creation/testing and batch closing so in-person transactions settle at shift end, implying integration with the same merchant account, but there's no explicit tap-to-pay SDK or documentation showing unified balance/reporting dashboards combining online and in-person payments. Missing for 10: tap-to-pay SDK details, explicit unified reporting/balance evidence combining online and card-present transactions, and independent corroboration of terminal hardware support.", "evidenceIds": [ "tilled-docs-5", "tilled-docs-6" ] }, { "productId": "tilled", "storyId": "liability-responsibility-split", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains only integration, onboarding, testing, and dashboard feature docs; none of it addresses an explicit documented split of liability for KYC/AML, card-network compliance, fraud losses, or seller misconduct between Tilled and the platform.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "multi-entity-treasury", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items address fund segregation, custody of in-flight/held balances, yield on balances, or safeguarding from provider's own accounts; documentation covers API keys, payouts speed, disputes, and onboarding only. missing for 10: any mention of fund segregation/custody model, held-balance yield policy, or safeguarding disclosures.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "negative-balance-recovery", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Evidence only mentions that merchants can 'manage disputes' through the Dashboard, with no documentation of negative balance recovery, automatic debits against future earnings, bank account debits, or liability ordering for refunds/chargebacks exceeding balance.", "evidenceIds": [ "tilled-docs-11" ] }, { "productId": "tilled", "storyId": "openness-api-parity", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Tilled offers API access for core payment operations (payments, webhooks, batches, testing) but several UI-only functions like dispute management and payout speed viewing are explicitly documented as Dashboard-only, and merchant onboarding has a no-code Dashboard option alongside API options, suggesting UI and API are not fully at parity. missing for 10: evidence that disputes, payout configuration, and subscription management can be fully performed via API rather than only through the Dashboard, plus independent confirmation of full API/UI parity.", "evidenceIds": [ "tilled-docs-10", "tilled-docs-11", "tilled-docs-13", "tilled-docs-7", "tilled-docs-5" ] }, { "productId": "tilled", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Tilled is a payments/merchant onboarding platform and the evidence pack contains no mention of bulk data export, open data formats, or data portability features for users to leave with their data. This is a plausible axis for a SaaS platform holding merchant/transaction data, but no evidence supports it.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "openness-open-license", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a closed payments platform/API service, not an open-source project; source code availability under an open license is not a relevant axis for this kind of product.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a hosted payments infrastructure/PayFac-as-a-service platform, not open-source software; self-hosting the core product is a category error for this type of SaaS financial infrastructure product.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "payfac-graduation-path", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers Tilled's managed PayFac features (onboarding, pricing templates, webhooks, dashboards, white-labeling) but contains no mention of a graduation path toward registered payment facilitation, economics changes, or control transitions without replatforming. Missing for 10: any documentation of a registered-PayFac upgrade path, economics/revenue-share changes at that tier, or migration mechanics that avoid replatforming.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "payout-scheduling", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Only one thin reference confirms that Tilled lets ops view a merchant's 'payout speed' in the Dashboard, implying some per-merchant payout timing configuration, but there is no documentation of specific schedule options (daily/weekly/monthly/manual) or instant payouts to cards/real-time rails. Missing for 10: explicit schedule types (daily/weekly/monthly/manual), instant payout to card support, real-time rails support, and confirmation that these are configurable per seller.", "evidenceIds": [ "tilled-docs-10" ] }, { "productId": "tilled", "storyId": "platform-ledger-visibility", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs show payout speed settings, merchant pricing templates, and dispute management, implying some money-tracking infrastructure, but there is no explicit documentation of per-seller balance views, platform fee account tracking, or charge-to-split-to-payout traceability/reconciliation. Missing for 10: explicit balance-by-seller/fee-account reporting, transaction-level traceability from charge through split to payout, and reconciliation tooling or statements.", "evidenceIds": [ "tilled-docs-9", "tilled-docs-10", "tilled-docs-11" ] }, { "productId": "tilled", "storyId": "platform-risk-monitoring", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers onboarding, payouts, disputes management, webhooks, and API testing, but contains no mention of fraud/credit-risk scoring per sub-merchant, anomaly alerts, or tools to pause payouts/offboard risky sellers.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack mentions data residency, region selection, or geographic storage controls for Tilled's platform.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments infrastructure/API platform for merchant onboarding and payment processing, not an AI model or AI product that trains on user data; the AI-training opt-out axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "privacy-retention-controls", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments infrastructure/API platform, not an AI system or agent; data retention/deletion controls framed for 'AI-native user' privacy posture is a category mismatch — this axis targets AI product data handling, not a payments processor's general data policies.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Tilled is a payments infrastructure/API platform, not an AI tool or developer agent with telemetry collection concerns; the evidence pack contains no AI-native usage-tracking features at all, making telemetry opt-out a category mismatch rather than a missing capability.", "evidenceIds": [] }, { "productId": "tilled", "storyId": "programmatic-seller-onboarding", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Tilled's docs show a merchant onboarding API with multiple integration paths — a no-code hosted option and a fully custom API/UI option — plus white-labeled hosted onboarding for enterprise partners, matching the 'hosted flows and embeddable components' ask. However, the evidence never explicitly details KYC/KYB data collection, bank account linking steps, or terms-of-service acceptance as part of that flow. Missing for 10: explicit KYC/KYB field/process documentation, bank account linking API details, and terms acceptance mechanism.", "evidenceIds": [ "tilled-docs-7", "tilled-docs-8", "tilled-docs-15", "tilled-docs-14" ] }, { "productId": "tilled", "storyId": "progressive-onboarding", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Tilled docs show merchant applications have progressive statuses (created/started) that can be pre-filled and edited over time, and ISVs get an item-by-item onboarding progress view in the Dashboard, suggesting some staged onboarding exists. However there is no explicit evidence of a tunable minimum-to-sell model gated by payout thresholds or clearly defined 'requirements-due' states per seller like a formal verification/eligibility system. Missing for 10: explicit documentation of minimum data required to start accepting payments, payout-threshold-triggered requirement escalation, and named per-seller requirements-due states.", "evidenceIds": [ "tilled-docs-8", "tilled-docs-12", "tilled-docs-10" ] }, { "productId": "tilled", "storyId": "reconciliation-reporting-exports", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Evidence shows settlement-related building blocks (batch closing/settlement per docs-5, payout visibility per docs-10, webhooks for event notifications per docs-4, and a hosted reporting console per docs-14) but nothing documents automated per-seller and rolled-up reconciliation reports, scheduled delivery, or finance-stack-consumable file/API exports. missing for 10: explicit reconciliation/settlement report generation, per-seller vs rolled-up aggregation, scheduled file exports or dedicated reporting API endpoints for finance systems.", "evidenceIds": [ "tilled-docs-5", "tilled-docs-10", "tilled-docs-4", "tilled-docs-14" ] }, { "productId": "tilled", "storyId": "seller-reporting-statements", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Tilled's docs show merchants can view payout speed in a Dashboard (tilled-docs-10) and enterprise partners can white-label a 'reporting console' (tilled-docs-14), suggesting some self-serve payout visibility, but there is no evidence of per-seller statements, payout reconciliation reports, or bookkeeper-ready exports. missing for 10: per-seller statement generation, payout reconciliation report format/detail, CSV/export functionality for bookkeepers.", "evidenceIds": [ "tilled-docs-10", "tilled-docs-14" ] }, { "productId": "tilled", "storyId": "split-payments-routing", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers merchant onboarding, pricing templates, payouts, disputes, and webhooks, but nothing describes splitting a single charge across multiple parties, taking a platform cut, or reversing/adjusting such splits as API objects. Tilled's evidence centers on single-merchant payment processing and ISV platform fee/pricing templates, not multi-party charge splitting. Missing for 10: any mention of split payments, multi-party charge routing, application fees, or transfer/reversal objects for splits.", "evidenceIds": [ "tilled-docs-9", "tilled-docs-10" ] }, { "productId": "tilled", "storyId": "submerchant-dispute-handling", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Only one doc snippet confirms merchants can manage disputes via the Dashboard, implying per-merchant (sub-merchant) dispute handling, but there's no evidence of API-based evidence submission, explicit chargeback routing logic, or automatic reconciliation of outcomes into seller balances. missing for 10: API-based dispute evidence submission, explicit per-seller chargeback routing details, automatic balance reconciliation after dispute outcome.", "evidenceIds": [ "tilled-docs-11" ] }, { "productId": "tilled", "storyId": "tax-form-generation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence anywhere in the pack mentions 1099-K threshold tracking, tax form generation, delivery, filing, or a data-corrections workflow; the pack covers onboarding, payments, payouts, disputes, and dashboards but is silent on tax reporting entirely.", "evidenceIds": [] } ]