[ { "productId": "adyen-pos", "storyId": "accept-cards-and-wallets", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen's POS docs explicitly cover chip/contactless via certified terminals, Tap to Pay on iPhone for contactless mobile acceptance, and global/local payment methods including wallets; PCI PTS certified terminals and offline resilience are documented. missing for 10: explicit named support for Apple Pay/Google Pay wallet acceptance at the terminal (only 'global and local payment methods' is generic) and independent hands-on validation beyond one negative community integration anecdote unrelated to this core capability.", "evidenceIds": [ "adyen-pos-docs-7", "adyen-pos-docs-15", "adyen-pos-docs-25", "adyen-pos-docs-33", "adyen-pos-docs-34", "adyen-pos-docs-8" ] }, { "productId": "adyen-pos", "storyId": "agent-monitors-disputes", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen provides a Disputes API to retrieve dispute information, defend/accept disputes, and upload defense documents, plus general webhook infrastructure for async status changes, which an agent could poll or subscribe to for building dispute workflows. However, there's no evidence of dispute-deadline-specific webhook events, deadline tracking, or any AI-assisted evidence-drafting capability. missing for 10: dispute-deadline webhook events, automated evidence-response drafting/generation feature, explicit deadline field/tracking in the API.", "evidenceIds": [ "adyen-pos-docs-23", "adyen-pos-docs-14", "adyen-pos-docs-21" ] }, { "productId": "adyen-pos", "storyId": "agent-provisions-new-location", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Adyen's Management API explicitly supports ordering/registering terminals via API calls instead of the Customer Area (adyen-pos-docs-11), which covers the reader-registration half of the story, and general API-first architecture is documented (adyen-pos-docs-1, adyen-pos-docs-2). However, no evidence describes an API endpoint or workflow for creating/provisioning a new physical 'location' object itself — location management is only shown via the Customer Area UI (adyen-pos-docs-3), not agent-drivable API. missing for 10: explicit API endpoint/documentation for creating a location object, end-to-end example combining location creation + reader registration in one automated flow.", "evidenceIds": [ "adyen-pos-docs-11", "adyen-pos-docs-3", "adyen-pos-docs-1", "adyen-pos-docs-2" ] }, { "productId": "adyen-pos", "storyId": "agent-reconciles-daily-takings", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen exposes APIs for terminal payments, refunds, disputes, and a getting-paid/payout settings endpoint, plus webhooks and an MCP server that could let an agent pull transaction data via natural language, but there is no documented payouts/transactions reporting API or reconciliation report endpoint (e.g. Balance Platform/Reporting API) evidenced here, and no example of an agent actually reconciling daily takings into a ledger. missing for 10: dedicated payouts/settlement reporting API evidence, reconciliation report/ledger-matching documentation, and a concrete example of an agent workflow pulling transactions+payouts and reconciling them.", "evidenceIds": [ "adyen-pos-docs-22", "adyen-pos-docs-23", "adyen-pos-docs-21", "adyen-pos-docs-20", "adyen-pos-docs-13", "adyen-pos-probe-4" ] }, { "productId": "adyen-pos", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Probe evidence confirms a live llms.txt at docs.adyen.com/llms.txt (HTTP 200) plus .md-formatted agent-friendly docs (e.g. point-of-sale.md returning 200), directly satisfying the story of pointing an agent at llms.txt/agent-oriented docs; there's also a documented MCP server as further agentic tooling. Missing for 10: independent third-party confirmation of an agent successfully consuming these docs in practice.", "evidenceIds": [ "adyen-pos-probe-1", "adyen-pos-probe-2", "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-probe-4" ] }, { "productId": "adyen-pos", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers payment terminal integration, refunds, tipping, offline payments, and an MCP server for developers to build with natural language—but nothing shows AI-generated insights or suggestions surfaced from merchant transaction/sales data inside the product itself.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Adyen POS is a payments API/terminal platform; there is no evidence of a feature allowing autonomous background automations to run (e.g. scheduled or event-triggered agent workflows). Webhooks and MCP server enable integration/event notification, but nothing describes autonomous background automation setup as a product capability. Missing for full/partial: any documented automation builder, scheduler, or autonomous-agent workflow feature.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Adyen's evidence only shows an MCP server that lets external LLM clients connect to Adyen's platform via natural language (docs-13, docs-20, probe-4) — this is the reverse of a built-in assistant embedded in the product for task delegation. No evidence of an in-product AI assistant that users can delegate tasks to.", "evidenceIds": [ "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-probe-4" ] }, { "productId": "adyen-pos", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Adyen's Terminal/Management APIs are JSON/HTTP based and programmatic, and a basic testing system exists to simulate transactions for integration testing without live hardware, which could support scripted/automated pipelines. However there is no explicit documentation of running the product headlessly in CI, no CLI, and the core product still relies on physical terminals for real transactions. Missing for 10: explicit CI/headless automation guidance, a documented CLI or SDK for scripted runs, and evidence of automated test suites beyond manual simulation.", "evidenceIds": [ "adyen-pos-docs-17", "adyen-pos-docs-11", "adyen-pos-docs-28", "adyen-pos-docs-32" ] }, { "productId": "adyen-pos", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a payments/POS platform, not an AI agent or LLM client host; the evidence only shows Adyen exposing its own MCP server for others to query it via natural language, not the product itself acting as an MCP client that ingests external MCP servers' tools. This axis (plugging MCP servers into the product) is a category mismatch for a payment terminal/API product.", "evidenceIds": [ "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-probe-4" ] }, { "productId": "adyen-pos", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Adyen documents an official MCP server that lets developers/agents interact with Adyen's platform using natural language via an LLM client, confirmed both in docs and a dedicated probe. Missing for 10: independent/hands-on community corroboration of the MCP server's real-world reliability and integration depth.", "evidenceIds": [ "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-probe-4" ] }, { "productId": "adyen-pos", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen documents an official MCP server that lets developers 'use natural language with your chosen LLM client' to connect to Adyen's platform and build payment solutions faster, which supports agentic/natural-language interaction with Adyen's APIs (including POS-related endpoints). However, this is scoped to development/integration tasks rather than an end-user natural-language interface for operating in-person payments (terminals, transactions, refunds) directly. Missing for 10: evidence of natural-language control over live POS operations (transactions, terminal management, refunds) rather than just developer-side API/documentation querying, and any independent/hands-on validation of the MCP server's real-world use.", "evidenceIds": [ "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-probe-4" ] }, { "productId": "adyen-pos", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Adyen is a payments platform; the evidence shows an MCP server, APIs, and OpenAPI spec but no mention of an official CLI tool for AI-native or any workflow. This axis applies (a payments platform could plausibly ship a CLI) but no evidence supports it.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen documents a full public Terminal API and Management API using JSON messages, provides an official OpenAPI specification repository (adyen-pos-gh-1), and ships an MCP server enabling natural-language/AI-native interaction with the platform (adyen-pos-docs-13, adyen-pos-docs-20, adyen-pos-probe-4). Extensive docs cover payments, refunds, webhooks, disputes, and testing, all API-driven. Missing for 10: a discoverable machine-readable OpenAPI endpoint directly under docs.adyen.com (probe found 404s) and independent hands-on confirmation beyond one dated negative community anecdote about a legacy integration path.", "evidenceIds": [ "adyen-pos-docs-17", "adyen-pos-docs-11", "adyen-pos-gh-1", "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-probe-4", "adyen-pos-probe-3" ] }, { "productId": "adyen-pos", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of scoped/least-privilege API credential issuance for agents; docs mention general API keys, Customer Area management, and an MCP server for natural-language access, but nothing about granular/scoped credential minting or per-agent permission scoping.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows only an OpenAPI spec repo (adyen-openapi) and JSON-based Terminal/Management APIs; one doc even states integration works 'without the need for libraries,' and no official language SDKs (Java, Node, Python, etc.) are documented for AI-native building. Missing for 10: explicit official SDK libraries, SDK docs/quickstarts, and any AI-native SDK tooling beyond the separate MCP server.", "evidenceIds": [ "adyen-pos-docs-1", "adyen-pos-docs-17", "adyen-pos-gh-1" ] }, { "productId": "adyen-pos", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Adyen documents webhooks explicitly for asynchronous status updates, letting integrators subscribe to events instead of polling, which applies to POS/payment outcomes. Missing for 10: POS-specific webhook event catalog/payload examples and independent/community confirmation of webhook reliability in POS context.", "evidenceIds": [ "adyen-pos-docs-14", "adyen-pos-docs-21" ] }, { "productId": "adyen-pos", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only static docs, an OpenAPI spec repo, and an MCP server, but no interactive API reference with runnable/try-it examples; probes for openapi.json/swagger explorer endpoints returned 404. Missing for 10: any evidence of an interactive 'try it' console or runnable code sandbox in the docs.", "evidenceIds": [ "adyen-pos-gh-1", "adyen-pos-probe-3", "adyen-pos-docs-13" ] }, { "productId": "adyen-pos", "storyId": "api-machine-spec", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen maintains an official GitHub repo of OpenAPI Specification files for its APIs (adyen-pos-gh-1), which is machine-readable and downloadable, but a live probe of the docs site found no standard hosted openapi.json/swagger.json endpoint (adyen-pos-probe-3), meaning access requires going to GitHub rather than a first-class docs-site download link. Missing for 10: a directly hosted/downloadable spec endpoint on docs.adyen.com, and explicit confirmation the GitHub spec covers the Terminal/POS API specifically.", "evidenceIds": [ "adyen-pos-gh-1", "adyen-pos-probe-3", "adyen-pos-docs-17" ] }, { "productId": "adyen-pos", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Adyen documents a dedicated test Customer Area with test cards and a 'basic testing system to simulate transaction scenarios' before switching to a live integration, explicitly separating sandbox from production data/transactions. Missing for 10: no independent/hands-on confirmation of sandbox fidelity or explicit data-isolation guarantees, and no AI-specific sandbox tooling beyond generic docs.", "evidenceIds": [ "adyen-pos-docs-12", "adyen-pos-docs-19", "adyen-pos-docs-28", "adyen-pos-docs-32" ] }, { "productId": "adyen-pos", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Adyen has OpenAPI definitions and extensive docs, but nowhere does it mention API version numbers or a documented deprecation/sunset policy for the Terminal API or Management API. Missing for 10: explicit versioning scheme documentation, deprecation/sunset policy, migration guides between API versions.", "evidenceIds": [ "adyen-pos-gh-1", "adyen-pos-docs-17" ] }, { "productId": "adyen-pos", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence covers individual terminal/payment API operations (single refunds, single terminal orders, single transactions) but nowhere mentions batch/bulk endpoints for processing many items at once (e.g., bulk refunds, bulk terminal provisioning, batch transaction imports). This is a fair question for a payments/POS platform but no supporting evidence exists.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Adyen provides webhooks that notify external systems of payment events, which developers can use to build their own automation, but there is no evidence of a native rules engine or UI where users define conditional triggers/actions within Adyen itself. Missing for 10: a documented rules/automation engine, conditional logic builder, or no-code trigger-action configuration; independent evidence of end-to-end automated workflows.", "evidenceIds": [ "adyen-pos-docs-14", "adyen-pos-docs-21" ] }, { "productId": "adyen-pos", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a payments/POS API and terminal product, not a workflow/automation scheduling tool; scheduling recurring jobs or workflows is outside its product category. Webhooks and an MCP server exist for event-driven integration, but no scheduling/cron capability is claimed or implied, and this axis is a category error for this kind of product.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a payments/POS platform, not an automation/workflow-building tool; there is no concept of 'automations' with version history, review, or rollback in this product's domain, so this axis is a category error rather than a missing feature.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "catalog-inventory-sync", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a payment-processing and terminal API product; catalog/inventory management with cross-channel stock sync is a retail/ERP capability outside its product category. Evidence only covers payment terminals, refunds, tipping, and Terminal API, with no mention of item catalogs or inventory counts.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "digital-receipts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers POS integration, tipping, refunds, testing, and terminals but contains no mention of issuing digital (email/SMS) or printed receipts, nor any reference to card-network receipt requirements. Receipt generation is a standard POS capability, so this axis applies, but no evidence shows Adyen delivering it.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "dispute-evidence-workflow", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen's Disputes API explicitly supports retrieving dispute information, defending or accepting disputes, and uploading defense documents, which covers the core dispute-evidence submission workflow. However, evidence does not confirm merchant-ops notification mechanisms (e.g., dashboard alerts or automated deadline reminders) specific to chargebacks, though generic webhooks exist that could plausibly relay dispute events. missing for 10: explicit documentation of chargeback notification/alerting to merchant-ops users, deadline-tracking UI, and independent/hands-on confirmation of the dispute workflow in practice.", "evidenceIds": [ "adyen-pos-docs-23", "adyen-pos-docs-14", "adyen-pos-docs-21" ] }, { "productId": "adyen-pos", "storyId": "multi-location-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen's docs show fleet-friendly capabilities: a unified Customer Area to manage terminals and transactions across sites, a Management API to order terminals for delivery to specific locations, and per-merchant-account payout settings, which together support multi-location device management. However, there is no explicit documentation of per-location reporting dashboards or location-specific configuration granularity beyond terminal ordering and merchant-account-level settings. missing for 10: explicit per-location reporting/analytics views, granular per-location settings management beyond account-level payout config, and independent/hands-on validation of multi-site operations at scale.", "evidenceIds": [ "adyen-pos-docs-3", "adyen-pos-docs-11", "adyen-pos-docs-22", "adyen-pos-docs-33" ] }, { "productId": "adyen-pos", "storyId": "native-mobile-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Adyen documents a Tap to Pay on iPhone solution for embedding contactless in-person payments directly into an iOS app, but there is no evidence of an equivalent official Android SDK for in-app card-present payments — the pack only shows generic Terminal API/POS integration docs. missing for 10: official Android SDK/Tap to Pay for Android evidence, and independent developer corroboration of ease-of-integration for either platform.", "evidenceIds": [ "adyen-pos-docs-7", "adyen-pos-docs-15" ] }, { "productId": "adyen-pos", "storyId": "offline-payments", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen's docs explicitly confirm offline payment support ('when there is a temporary loss of internet connectivity, you can continue making point-of-sale payments if offline payments have been enabled') and marketing claims terminals 'stay up and running, even when the internet is down.' However, evidence lacks detail on store-and-forward mechanics, limits/risk controls during offline mode, or independent hands-on confirmation of reliability. missing for 10: technical detail on transaction queuing/forwarding limits, risk/fraud handling for offline auth, and independent verification of real-world offline resilience.", "evidenceIds": [ "adyen-pos-docs-8", "adyen-pos-docs-25" ] }, { "productId": "adyen-pos", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen documents strong API coverage for core in-person payment actions (Terminal API for payments/refunds/tipping, Management API for ordering terminals 'instead of the Customer Area', Disputes API for dispute management) plus an official MCP server for natural-language/agent access, showing broad but not exhaustive UI-API parity. However, some functions (e.g., unified Customer Area terminal/transaction management, some refund flows) are explicitly still done via UI, and a community report describes friction requiring non-JSON integration work, undercutting a claim of full parity. Missing for 10: explicit vendor statement of complete UI/API feature parity, independent verification that every Customer Area action has an API equivalent.", "evidenceIds": [ "adyen-pos-docs-3", "adyen-pos-docs-11", "adyen-pos-docs-17", "adyen-pos-docs-23", "adyen-pos-docs-27", "adyen-pos-docs-13", "adyen-pos-docs-20", "adyen-pos-comm-1" ] }, { "productId": "adyen-pos", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a data export feature or open-format data portability for merchants leaving Adyen; documentation covers APIs, terminals, tipping, refunds, MCP server, but nothing about exporting transaction/customer data in open formats or account offboarding processes.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a closed commercial payments platform; the only public repo cited (adyen-openapi) contains API definition files, not the product's actual source code, and no evidence indicates any open-license release of the underlying software.", "evidenceIds": [ "adyen-pos-gh-1" ] }, { "productId": "adyen-pos", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a managed payments/hardware SaaS platform tied to Adyen's processing infrastructure and certified terminals; self-hosting the core payment processing service is not a coherent concept for this product category, unlike open-source software.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "payment-event-webhooks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen's docs confirm webhooks exist to notify on asynchronous payment outcomes (avoiding polling) and a separate Disputes API lets you retrieve/manage dispute events, which together cover the core of this story. However, the evidence pack doesn't show the specific webhook event types (AUTHORISATION, CAPTURE, REFUND, DISPUTE) or subscription/configuration details for POS-specific transactions. Missing for 10: explicit list of supported webhook event types for POS transactions, configuration/subscription docs, and independent/hands-on confirmation that dispute or refund webhooks fire reliably in production.", "evidenceIds": [ "adyen-pos-docs-14", "adyen-pos-docs-21", "adyen-pos-docs-23" ] }, { "productId": "adyen-pos", "storyId": "payout-timing-control", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack only vaguely mentions that merchants can 'change how you get paid' (adyen-pos-docs-22), with no documentation of payout timing visibility, payout status tracking, or an option to expedite payouts to next-day/instant. No dashboard, API, or docs evidence describes seeing payout schedules or triggering faster payouts.", "evidenceIds": [ "adyen-pos-docs-22" ] }, { "productId": "adyen-pos", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack discusses data residency, regional data storage options, or configurable region controls for Adyen's payment/data processing; the docs cover POS features, terminals, refunds, and MCP but not residency choices.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data usage or opt-out controls for Adyen In-Person Payments; the documentation focuses on POS integration, payments, and an MCP server, not AI model training data policies.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers POS integration, terminals, refunds, tipping, testing, and MCP server for natural-language API access, but contains no mention of data retention controls, deletion policies, or privacy/data lifecycle management features for an AI-native user. Missing for 10: any documentation of data retention settings, deletion APIs/workflows, or privacy controls relevant to AI agent usage.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Adyen In-Person Payments is a payment terminal/API product; there is no mention anywhere in the evidence of a telemetry/usage-tracking opt-out mechanism for AI-native or any users, despite the axis being plausible for a developer platform with docs, SDKs, and an MCP server.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "reader-pairing-setup", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs describe ordering/managing terminals via Customer Area or Management API, standalone terminal setup, and Terminal API integration for POS apps, implying setup is possible, but there is no evidence of an actual quick-pairing/registration flow or a documented 'minutes to first payment' onboarding experience; a community anecdote also describes hundreds of hours spent integrating card-present readers before abandoning Adyen. missing for 10: concrete pairing/registration UX steps, time-to-first-payment evidence, independent hands-on confirmation that setup is fast, and resolution of the contradicting community integration-pain report.", "evidenceIds": [ "adyen-pos-docs-4", "adyen-pos-docs-11", "adyen-pos-docs-3", "adyen-pos-docs-33", "adyen-pos-comm-1" ] }, { "productId": "adyen-pos", "storyId": "reconcile-takings-reports", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows only payout-method configuration (docs-22) and dispute handling (docs-23), but nothing about itemized transaction/fee reports or a reconciliation workflow tying daily takings to payouts. Missing for 10: settlement/reconciliation reports, itemized fee breakdowns, payout-to-transaction matching tools or reports API evidence.", "evidenceIds": [ "adyen-pos-docs-22", "adyen-pos-docs-23" ] }, { "productId": "adyen-pos", "storyId": "reduced-pci-scope", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm Adyen terminals are PCI PTS/PCI-compliant certified and capture card data via the Terminal API, supporting reduced PCI scope for card-present integrations, but there is no explicit vendor guidance document addressing the developer's residual PCI-DSS obligations (e.g., SAQ type, cardholder-data handling responsibilities) beyond terminal certification. missing for 10: explicit documentation of remaining PCI-DSS obligations/SAQ guidance for the integrating developer, independent audit confirmation of scope reduction.", "evidenceIds": [ "adyen-pos-docs-25", "adyen-pos-docs-33", "adyen-pos-docs-17", "adyen-pos-docs-3" ] }, { "productId": "adyen-pos", "storyId": "refunds-from-pos", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs confirm refunds via Terminal API (referenced and unreferenced refunds to original card), via Customer Area dashboard, and via API integration, covering POS, dashboard, and API channels for full/partial amounts. missing for 10: no independent/hands-on corroboration of refund success, and no explicit confirmation that partial refund amounts are supported (only 'any amount' language for unreferenced refunds).", "evidenceIds": [ "adyen-pos-docs-10", "adyen-pos-docs-17", "adyen-pos-docs-27", "adyen-pos-docs-31" ] }, { "productId": "adyen-pos", "storyId": "server-driven-terminal-checkout", "verdict": "disputed", "quality": 6, "confidence": "medium", "rationale": "Adyen's docs clearly describe a server-driven Terminal API using JSON messages to make payments, refunds, tipping, and testing (adyen-pos-docs-17, -1, -9, -10, -12), which matches the story. However, a hands-on community report describes being forced into an older COM-based integration rather than the promised JSON-only flow, costing hundreds of hours before abandoning Adyen, directly contradicting the simplicity claim for at least some POS hardware/integration paths (adyen-pos-comm-1). missing for 10: independent corroboration that the JSON Terminal API works smoothly in practice across common POS hardware, and resolution of the COM-vs-JSON discrepancy.", "evidenceIds": [ "adyen-pos-docs-17", "adyen-pos-docs-1", "adyen-pos-docs-9", "adyen-pos-docs-10", "adyen-pos-docs-12", "adyen-pos-comm-1" ] }, { "productId": "adyen-pos", "storyId": "simulated-reader-testing", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Adyen docs explicitly describe a dedicated testing system for POS integrations with test cards to simulate card brands, CVMs, and declined payments, allowing developers to validate their integration before going live. This is well documented across multiple doc pages with clear intent (pre-production validation). Missing for 10: no independent/hands-on developer report confirming the simulator's fidelity or ease of use, and no detail on a fully simulated virtual reader (only physical test cards/terminals are described).", "evidenceIds": [ "adyen-pos-docs-12", "adyen-pos-docs-19", "adyen-pos-docs-28", "adyen-pos-docs-32" ] }, { "productId": "adyen-pos", "storyId": "split-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item addresses split-tender/split-payment functionality (splitting a single sale across multiple payment methods or multiple payers) — coverage exists for refunds, tipping, offline payments, currency options, etc., but nothing on split payments. There is also a negative community anecdote about omnichannel card-present integration difficulty, but it does not concretely address split-tender capability either.", "evidenceIds": [] }, { "productId": "adyen-pos", "storyId": "start-accepting-same-week", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Docs show hardware can be ordered via the Management API or Customer Area (adyen-pos-docs-11, adyen-pos-docs-3, adyen-pos-docs-25) and Adyen offers a standalone terminal option for fast setup (adyen-pos-docs-4), but there is no evidence on signup/approval timelines, and a hands-on community report describes hundreds of hours spent integrating card-present/POS before ultimately abandoning Adyen (adyen-pos-comm-1), directly contradicting a 'same week' onboarding claim. missing for 10: evidence of signup/approval speed, independent confirmation that hardware ordering and go-live actually happens within a week, resolution of the contradicting integration-time complaint.", "evidenceIds": [ "adyen-pos-docs-11", "adyen-pos-docs-3", "adyen-pos-docs-4", "adyen-pos-docs-25", "adyen-pos-comm-1" ] }, { "productId": "adyen-pos", "storyId": "tap-to-pay-on-own-phone", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Adyen explicitly documents Tap to Pay on iPhone, letting merchants accept contactless payments directly on an iPhone as the payment interface with no extra hardware, and marketing material confirms 'No extra hardware required' for compatible smartphones/tablets. Missing for 10: independent/hands-on confirmation of the founder-scale onboarding experience and Android Tap to Pay coverage details.", "evidenceIds": [ "adyen-pos-docs-7", "adyen-pos-docs-15" ] }, { "productId": "adyen-pos", "storyId": "terminal-fleet-management-api", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Adyen docs mention a Management API for ordering terminals via API (adyen-pos-docs-11) and a unified Customer Area for managing terminals (adyen-pos-docs-3), which touches part of the fleet-management story, but there is no evidence of API-based device registration, status monitoring, or remote configuration updates. missing for 10: API endpoints for registering devices, retrieving/monitoring device status, and remotely updating terminal configuration; independent/hands-on confirmation of these capabilities.", "evidenceIds": [ "adyen-pos-docs-11", "adyen-pos-docs-3" ] }, { "productId": "adyen-pos", "storyId": "tipping-flows", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Adyen docs confirm tipping is supported via terminal/POS app/receipt, and that a tip amount can be suggested by the POS app for the customer to accept, change, or decline on the terminal (adyen-pos-docs-26, adyen-pos-docs-30, adyen-pos-docs-9). However, the evidence never details merchant-ops-configurable smart-tip percentage tiers or custom-amount prompt configuration UI—only that tip amounts are set in the payment request. Missing for 10: explicit documentation of percentage-based smart tipping configuration, custom tip entry flows, and merchant-ops-facing configuration tools (vs. developer-set tip amounts).", "evidenceIds": [ "adyen-pos-docs-9", "adyen-pos-docs-26", "adyen-pos-docs-30" ] }, { "productId": "square", "storyId": "accept-cards-and-wallets", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square's docs explicitly document Tap to Pay on iPhone for accepting contactless cards, Apple Pay, and other digital wallets in person, plus Terminal API support for tip collection at checkout, and Mobile Payments SDK for chip/contactless via hardware readers. Community commentary corroborates real-world merchant use of Square hardware for in-person card acceptance. Missing for 10: explicit mention of Google Pay support in-person and independent hands-on verification of contactless/chip reliability beyond older magstripe-era anecdotes.", "evidenceIds": [ "square-docs-1", "square-docs-2", "square-docs-4", "square-docs-26", "square-comm-8", "square-comm-9" ] }, { "productId": "square", "storyId": "agent-monitors-disputes", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square's Disputes API and Webhooks docs (square-docs-11, square-docs-12) provide the building blocks for an agent to monitor dispute status/deadlines and submit evidence programmatically, and Square also documents an official MCP server (square-docs-14) that could expose these to an AI agent. However, there's no evidence of deadline-specific webhook events, evidence-drafting assistance, or any AI-native workflow purpose-built for this use case. Missing for 10: explicit deadline/expiration fields or events in the Disputes API, any documented AI-assisted evidence drafting feature, and independent confirmation of agents using this workflow.", "evidenceIds": [ "square-docs-11", "square-docs-12", "square-docs-14" ] }, { "productId": "square", "storyId": "agent-provisions-new-location", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Square's Locations API supports creating new locations programmatically (square-docs-9, square-docs-24), and there's a broad API/SDK ecosystem (square-gh-1, square-docs-3) an agent could drive. However, no evidence in the pack shows an API for registering/provisioning physical readers (e.g., a Devices API or reader pairing endpoint) — Terminal API only covers checkout flows on already-paired devices (square-docs-26). Missing for 10: reader/device registration API documentation, end-to-end example combining location creation with reader provisioning, and any hands-on confirmation of this workflow.", "evidenceIds": [ "square-docs-9", "square-docs-24", "square-docs-26", "square-docs-3" ] }, { "productId": "square", "storyId": "agent-reconciles-daily-takings", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Square documents a Payouts API (list-payouts) and Payments/Orders APIs accessible via SDKs, plus webhooks for transaction events and a sandbox for testing, all of which an agent could use to pull transactions/payouts. Square also ships an official MCP server, letting an AI agent programmatically query these APIs, directly supporting agent-driven reconciliation workflows. Missing for 10: explicit dedicated 'transactions' endpoint documentation, a built-in reconciliation/ledger feature, and independent hands-on evidence of an agent actually performing daily reconciliation.", "evidenceIds": [ "square-docs-25", "square-docs-12", "square-docs-13", "square-docs-14", "square-probe-4", "square-gh-1", "square-gh-2" ] }, { "productId": "square", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Square hosts a working llms.txt at developer.squareup.com/llms.txt (HTTP 200, confirmed by probe) and an llms-full.txt with detailed doc content, directly enabling agents to consume agent-oriented docs. Missing for 10: no independent/community confirmation of agents actually using it, and openapi/docs.md alternatives return 404.", "evidenceIds": [ "square-probe-1", "square-docs-28" ] }, { "productId": "square", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Square as a payments/commerce platform with APIs, dashboards, and an MCP server for developer integration, but nothing indicates Square itself surfaces AI-generated insights or suggestions from a seller's data inside its product. missing for 10: any documentation of built-in AI analytics, insight dashboards, or suggestion features within Square's product surface.", "evidenceIds": [] }, { "productId": "square", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Square exposes webhooks and an MCP server that could let an AI agent trigger or observe events and act autonomously, but there's no documented native 'automation builder' or scheduled/background workflow feature in Square itself — it only provides raw APIs/events for developers to wire up their own automations. Missing for 10: evidence of a first-party automation/workflow engine, scheduling or trigger-action system, and confirmation that MCP server actions can run unattended in the background.", "evidenceIds": [ "square-docs-12", "square-docs-14", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows Square offers an MCP server for external AI agents to call Square APIs (square-docs-14, square-probe-4), but this is the reverse of the story—no evidence of a built-in AI assistant inside Square's own product (Dashboard/POS) that users can delegate tasks to.", "evidenceIds": [ "square-docs-14", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-headless", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square exposes a full REST API with official SDKs (e.g., Node/TypeScript client) that let developers create payments, manage catalog/inventory/orders programmatically, and a dedicated Sandbox environment for testing outside the Dashboard UI — all of which support scripted/automated, non-interactive use suitable for CI pipelines. However, there is no explicit documentation of CI/CD integration, GitHub Actions examples, or headless deployment guidance. missing for 10: explicit CI/CD or headless automation documentation, examples of running SDK calls in an automated pipeline.", "evidenceIds": [ "square-gh-1", "square-gh-2", "square-docs-3", "square-docs-13", "square-docs-19" ] }, { "productId": "square", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "medium", "rationale": "Square is a payments/commerce SaaS platform, not an AI agent or orchestrator that would consume tools via MCP client connections. The only MCP-related evidence shows Square publishing its own MCP server so other agents can call Square's APIs (square-docs-14, square-probe-4) — the reverse role from this story, which asks whether Square itself can plug into and use external MCP servers' tools.", "evidenceIds": [ "square-docs-14", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Square documents an official 'Square Model Context Protocol Server' with dedicated docs, and this is independently confirmed by a probe hitting that URL directly. Missing for 10: independent/hands-on community corroboration of the MCP server working in practice and deeper docs detail on setup/capabilities.", "evidenceIds": [ "square-docs-14", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Square documents an official MCP server (square-docs-14, square-probe-4), which would let AI agents interact with Square's APIs via natural-language-driven tool calls, but there is no detailed documentation of the NL command set, no first-party or independent evidence of it working end-to-end, and no mention of a native chat/NL interface for merchants themselves. missing for 10: detailed MCP tool/command documentation, hands-on or independent verification of NL operation, evidence of a built-in conversational interface beyond the MCP server stub.", "evidenceIds": [ "square-docs-14", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack mentions an official Square CLI; the docs reference SDKs, APIs, sandbox, and an MCP server but nothing about a command-line tool for developers or AI-native workflows.", "evidenceIds": [] }, { "productId": "square", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square provides an extensive, well-documented public REST API with catalog, inventory, orders, payments, webhooks, sandbox testing, and official SDKs (e.g., TypeScript SDK), plus an llms.txt for AI discoverability and even a dedicated MCP server for agentic access. This clearly enables AI-native users to programmatically drive the product. Missing for 10: a publicly discoverable OpenAPI/swagger spec (probe returned 404s) and independent hands-on developer corroboration beyond official docs.", "evidenceIds": [ "square-docs-3", "square-docs-6", "square-docs-7", "square-docs-8", "square-docs-10", "square-docs-12", "square-docs-13", "square-docs-14", "square-gh-1", "square-probe-1", "square-probe-3", "square-probe-4" ] }, { "productId": "square", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack documents Square's APIs, SDKs, sandbox testing, and an MCP server, but contains no mention of OAuth scopes, restricted/scoped API keys, or any mechanism for issuing least-privilege credentials specifically for an AI agent. This axis is fair for an API platform like Square, but no evidence supports it.", "evidenceIds": [] }, { "productId": "square", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square provides official SDKs across multiple languages (e.g., TypeScript/Node.js SDK on GitHub) with documented usage examples, plus a broad developer platform with sandbox testing and multiple pre-built client libraries referenced in official docs. Missing for 10: independent third-party validation of SDK quality/reliability beyond GitHub repo, and broader multi-language SDK evidence (only TypeScript repo cited explicitly).", "evidenceIds": [ "square-gh-1", "square-gh-2", "square-docs-19", "square-docs-29", "square-docs-13", "square-docs-4" ] }, { "productId": "square", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square Webhooks documentation ([square-docs-12]) provides an official subscription mechanism for events (payments, orders, disputes, etc.), and sandbox testing support ([square-docs-13]) exists for validating webhook subscriptions. missing for 10: independent/hands-on corroboration of webhook reliability and no explicit mention of event filtering/retry semantics in the evidence pack.", "evidenceIds": [ "square-docs-12", "square-docs-13" ] }, { "productId": "square", "storyId": "api-interactive-docs", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Square provides a developer sandbox for testing API calls (square-docs-13) and 'Connect Examples' working sample apps (square-docs-29), plus SDKs with code snippets (square-gh-2), which give some runnable-example experience, but there is no evidence of an interactive API reference (e.g., Swagger/OpenAPI explorer) — probes show openapi.json/swagger.json all 404 (square-probe-3) and no docs.md (square-probe-2). missing for 10: a true interactive API explorer with live try-it-now requests, OpenAPI spec exposure, in-browser runnable examples tied directly to reference docs.", "evidenceIds": [ "square-docs-13", "square-docs-29", "square-gh-2", "square-probe-3", "square-probe-2" ] }, { "productId": "square", "storyId": "api-machine-spec", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square maintains a public 'connect-api-specification' repo whose README explicitly discusses the API specification used to generate SDKs, implying a machine-readable spec is available for download, and the docs reference pre-built clients derived from it. However, direct probes of developer.squareup.com show no openapi.json/swagger.json endpoint (404s), so the spec isn't served in an obviously discoverable machine-readable format from the docs site itself. Missing for 10: a directly linked/downloadable OpenAPI file on the docs domain, and independent confirmation that the GitHub spec is kept current and complete.", "evidenceIds": [ "square-docs-19", "square-docs-29", "square-probe-3" ] }, { "productId": "square", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square provides a dedicated Sandbox environment for testing APIs without touching production data, documented directly in developer docs [square-docs-13], plus SDKs/examples that support pointing to sandbox credentials/environment [square-gh-1][square-docs-19]. Missing for 10: independent hands-on confirmation of sandbox fidelity and no explicit mention of sandbox data reset/isolation guarantees.", "evidenceIds": [ "square-docs-13", "square-gh-1", "square-docs-19" ] }, { "productId": "square", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of API versioning scheme (e.g., Square-Version header) or a deprecation policy—only general API/SDK docs, sandbox testing, and webhooks are covered. Missing for 10: explicit versioning documentation, deprecation/EOL policy, changelog or migration guides.", "evidenceIds": [] }, { "productId": "square", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence shows Square's Catalog, Inventory, and Orders APIs exist, but nothing in the pack documents batch/bulk endpoints (e.g., bulk catalog upsert, bulk inventory adjustment) or any AI-native bulk-action tooling. Missing for 10: explicit bulk/batch API documentation, evidence of bulk operations across items, and any hands-on confirmation of such functionality.", "evidenceIds": [ "square-docs-7", "square-docs-8", "square-docs-10" ] }, { "productId": "square", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square offers webhooks for event notification (square-docs-12) which could be paired with external automation tools to trigger actions on events, but there is no evidence of a native rules engine or built-in conditional automation ('when X happens, do Y') within Square itself. missing for 10: a documented native automation/rules builder, examples of event-triggered actions configured directly in Square, and independent confirmation of such workflows in practice.", "evidenceIds": [ "square-docs-12", "square-docs-13" ] }, { "productId": "square", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a payments/commerce platform; scheduling recurring jobs or automated workflows is not a capability category it addresses (webhooks are event-driven, not job scheduling). This is a category error rather than a missing feature for this product type.", "evidenceIds": [] }, { "productId": "square", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a commerce/payments platform, not an automation/workflow builder with an 'automation' concept to version, review, or roll back; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "square", "storyId": "catalog-inventory-sync", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square documents a dedicated Catalog API for item/modifier management and an Inventory API explicitly for tracking counts, plus multi-location support (Locations API) and marketing copy touting 'Track inventory' across the business, implying sync across registers/channels. missing for 10: no explicit hands-on/independent verification that inventory sync across multiple registers/channels works reliably in practice, and no detail on conflict resolution or real-time sync guarantees.", "evidenceIds": [ "square-docs-7", "square-docs-8", "square-docs-9", "square-docs-24", "square-docs-21", "square-docs-10" ] }, { "productId": "square", "storyId": "digital-receipts", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square's Locations API supports custom receipt text fields, and Terminal/Payments APIs are documented to generate digital receipts as part of transaction flows, indicating receipt issuance capability tied to card-network-compliant transactions. However, there is no explicit documentation confirming email/SMS receipt delivery mechanics or explicit card-network compliance requirements for receipt content. missing for 10: explicit docs on email/SMS receipt delivery flow, explicit statement of card-network receipt compliance requirements, independent/hands-on confirmation of receipt issuance working as described.", "evidenceIds": [ "square-docs-27", "square-docs-26", "square-docs-9", "square-docs-15" ] }, { "productId": "square", "storyId": "dispute-evidence-workflow", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square has a dedicated Disputes API (square-docs-11) for retrieving dispute details and submitting evidence, and Webhooks (square-docs-12) that can notify merchants of new disputes/chargebacks. However, evidence lacks detail on deadline tracking/reminders or Dashboard-native notification workflows, and there's no independent confirmation of the evidence-submission UX working end-to-end. Missing for 10: explicit deadline-reminder mechanism, Dashboard notification UI details, hands-on/independent validation of the dispute submission flow.", "evidenceIds": [ "square-docs-11", "square-docs-12" ] }, { "productId": "square", "storyId": "multi-location-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square's Locations API confirms merchants can create and manage multiple locations, each with its own settings (e.g., custom receipt text) editable via the Dashboard or API, and location data can be retrieved/updated per-location. However, there's no explicit evidence of per-location device fleet management or per-location reporting dashboards beyond the basic Locations API. missing for 10: dedicated per-location device provisioning/management docs, per-location reporting/analytics evidence.", "evidenceIds": [ "square-docs-9", "square-docs-15", "square-docs-24", "square-docs-27" ] }, { "productId": "square", "storyId": "native-mobile-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square documents a Mobile Payments SDK for iOS/Android plus Tap to Pay on iPhone and offline payments support, directly enabling developers to embed in-person payments into native mobile apps. missing for 10: independent third-party hands-on validation of the mobile SDK integration and Android-specific Tap to Pay parity details.", "evidenceIds": [ "square-docs-2", "square-docs-4", "square-docs-5", "square-docs-1" ] }, { "productId": "square", "storyId": "offline-payments", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square's Mobile Payments SDK documents an explicit 'Offline Payments' feature for Android that stores transactions locally and forwards them when connectivity returns, directly matching the story; however this is documented only for the Android SDK path, not confirmed for the core POS app/hardware terminals broadly, and there's no independent/hands-on corroboration of reliability in practice. missing for 10: confirmation offline mode applies across Square's main POS app/hardware (not just Android SDK integrations), details on transaction limits/risk holds during offline queuing, and independent verification of real-world behavior.", "evidenceIds": [ "square-docs-5", "square-docs-4", "square-docs-3" ] }, { "productId": "square", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square exposes extensive APIs for payments, catalog, inventory, orders, locations, disputes, payouts, webhooks, and team management (square-docs-3,6,7,8,9,10,11,12,17,25), suggesting broad API/UI parity, but there is no explicit statement or independent audit confirming that every UI feature (e.g., dashboard customization, marketing/engagement tools, reporting views) is fully mirrored via API. missing for 10: explicit parity claim or audit, coverage of marketing/engagement and reporting UI features, independent verification of completeness.", "evidenceIds": [ "square-docs-3", "square-docs-6", "square-docs-7", "square-docs-8", "square-docs-9", "square-docs-10", "square-docs-11", "square-docs-12", "square-docs-17", "square-docs-25" ] }, { "productId": "square", "storyId": "openness-full-export", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Square exposes JSON-based APIs for catalog, inventory, orders, locations, and payouts data (square-docs-7,8,9,10,25), which technically allows a user to programmatically extract much of their business data in an open format, but there is no documented single 'export all my data and leave' feature, no bulk account-export tool, and no GDPR-style full data dump mentioned anywhere in the evidence. Missing for 10: a dedicated full-account data export tool, explicit open-format bulk export (e.g., CSV/JSON dump of entire account), and confirmation that all data types (customer engagement, team/payroll, disputes) are exportable via API.", "evidenceIds": [ "square-docs-7", "square-docs-8", "square-docs-9", "square-docs-10", "square-docs-25", "square-docs-18" ] }, { "productId": "square", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Square is a closed-source SaaS payments platform; only thin client SDK wrappers (e.g., square-nodejs-sdk) are open source on GitHub, not the actual product/service source code. No evidence indicates the core platform, backend, or application logic is available under any open license.", "evidenceIds": [ "square-gh-1", "square-docs-19" ] }, { "productId": "square", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Square is a hosted payments/commerce SaaS platform (payments, catalog, inventory, payroll); self-hosting the 'core product' is a category error, as there is no on-premise or open-source deployment option for its core commerce/payments infrastructure.", "evidenceIds": [] }, { "productId": "square", "storyId": "payment-event-webhooks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square has documented webhooks (square-docs-12) and a dedicated Disputes API (square-docs-11), suggesting lifecycle events like disputes and payments can be subscribed to; sandbox testing is also documented (square-docs-13). However, evidence doesn't explicitly enumerate specific webhook event types (authorized, captured, refunded, disputed) or show sample payloads/subscription config details. missing for 10: explicit list of supported webhook event types, payload examples, independent/hands-on confirmation of reliability.", "evidenceIds": [ "square-docs-12", "square-docs-11", "square-docs-13" ] }, { "productId": "square", "storyId": "payout-timing-control", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Square's Payouts API (list-payouts) lets a business see payout records, and 'Manage your cash flow' hints at cash-flow visibility, but the evidence pack has no documentation of an instant or next-day payout acceleration option that a founder could trigger. Missing for 10: explicit instant/next-day payout feature docs, UI/dashboard evidence of speeding up a payout, and any confirmation of fees/timing for expedited payouts.", "evidenceIds": [ "square-docs-25", "square-docs-23" ] }, { "productId": "square", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items mention data residency, region selection, or storage location options for Square merchant/customer data; all evidence concerns payments, catalog, inventory, and MCP features. Missing for 10: any documentation of regional data centers, data residency controls, or storage location choice.", "evidenceIds": [] }, { "productId": "square", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses AI training data usage, opt-out controls, or privacy policy language about model training for Square products; this is an applicable axis for any data-handling platform but no supporting documentation exists.", "evidenceIds": [] }, { "productId": "square", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items address data retention policies, deletion controls, or AI-native data lifecycle management; docs focus on payments, catalog, inventory, and MCP server access but not privacy/retention controls.", "evidenceIds": [] }, { "productId": "square", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry opt-out or usage tracking controls for AI-native users; the documentation covers payments, APIs, and MCP server but nothing about privacy/telemetry settings. Missing for 10: any telemetry disclosure, opt-out mechanism, or privacy policy documentation addressing AI usage tracking.", "evidenceIds": [] }, { "productId": "square", "storyId": "reader-pairing-setup", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square documents multiple ways to accept in-person payments (Tap to Pay on iPhone, Terminal API for hardware readers, general 'process payments on Square hardware' claims) and community comments corroborate that Square's card-reader hardware (magstripe/audio-jack, later Terminal) enables fast in-person checkout. However, there is no explicit evidence pack content describing the actual pairing/registration flow (Bluetooth pairing, account registration steps, time-to-first-payment) for a physical reader with the POS app. Missing for 10: explicit reader pairing/setup documentation, hands-on time-to-payment confirmation, and independent verification of ease of registering a reader to an account.", "evidenceIds": [ "square-docs-1", "square-docs-2", "square-docs-3", "square-docs-26", "square-comm-7", "square-comm-8", "square-comm-10" ] }, { "productId": "square", "storyId": "reconcile-takings-reports", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square provides a Payouts API (List Payouts) and dashboard-level cash flow management, giving a starting point for reconciling payouts, but there is no evidence of itemized fee breakdowns, transaction-to-payout matching reports, or a dedicated reconciliation report tool. missing for 10: itemized fee reporting API/docs, dashboard reconciliation report walkthrough, independent/hands-on confirmation of reconciling takings vs payouts.", "evidenceIds": [ "square-docs-25", "square-docs-23" ] }, { "productId": "square", "storyId": "reduced-pci-scope", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Square's SDK uses tokenized sourceId (never raw card numbers) in payment creation calls, and certified hardware/Tap to Pay readers capture card data directly, both of which structurally reduce a developer's PCI exposure. However, the evidence pack contains no explicit PCI-DSS documentation, SAQ level guidance, or statement of the developer's remaining compliance obligations. Missing for 10: explicit PCI compliance/SAQ documentation, vendor statements on residual merchant obligations, and any certification details (e.g., PCI-validated P2PE) tied to the readers.", "evidenceIds": [ "square-docs-1", "square-docs-2", "square-gh-2", "square-docs-4" ] }, { "productId": "square", "storyId": "refunds-from-pos", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers payments creation, disputes, catalog, inventory, and other APIs but contains no documentation or reference to a Refunds API, POS refund flow, or dashboard refund capability. Since Square is a payments platform, refund support is a plausible and expected axis, but no evidence in the pack confirms it.", "evidenceIds": [] }, { "productId": "square", "storyId": "server-driven-terminal-checkout", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square's Terminal API is explicitly documented for driving Square hardware terminals from a backend (tip collection, signature screens, custom tip amounts), alongside the broader server-driven APIs (Orders, Payments, Catalog, Sandbox testing, webhooks) needed to build a custom checkout flow. Official SDKs (e.g., Node.js) further support server-driven integration. Missing for 10: no independent/hands-on developer report validating real-world Terminal API integration experience, and no public OpenAPI spec was found via probe.", "evidenceIds": [ "square-docs-26", "square-docs-3", "square-docs-10", "square-docs-12", "square-docs-13", "square-gh-1", "square-probe-1" ] }, { "productId": "square", "storyId": "simulated-reader-testing", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Square documents a general Sandbox for testing API calls (square-docs-13) and a Terminal API for in-person checkout flows like tip collection (square-docs-26), implying some pre-production testing path, but the evidence never explicitly describes a simulated card reader or test-card environment tailored to the in-person/Terminal API flow. missing for 10: explicit documentation of Terminal API sandbox/test reader behavior, sample test card numbers for in-person transactions, and independent developer confirmation that end-to-end in-person testing works before going live.", "evidenceIds": [ "square-docs-13", "square-docs-26", "square-docs-4" ] }, { "productId": "square", "storyId": "split-payments", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item mentions split tender, splitting a sale across multiple payment methods, or splitting a bill among multiple payers; docs focus on single payment creation, catalog, inventory, and other unrelated APIs.", "evidenceIds": [] }, { "productId": "square", "storyId": "start-accepting-same-week", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence confirms Square lets sellers accept in-person payments quickly via Tap to Pay on iPhone (no extra hardware needed) and references a dashboard ('Switch to Square', location management) and community commentary that hardware complements the merchant-services core, but there's no concrete evidence of the sign-up/approval workflow, hardware ordering process from the dashboard, or a documented same-week timeline. missing for 10: explicit onboarding/approval flow details, evidence of ordering hardware directly from the dashboard, confirmation of same-week turnaround.", "evidenceIds": [ "square-docs-1", "square-docs-16", "square-docs-20", "square-comm-8", "square-comm-9" ] }, { "productId": "square", "storyId": "tap-to-pay-on-own-phone", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Square explicitly documents Tap to Pay on iPhone, allowing contactless card and digital wallet payments directly on an off-the-shelf iPhone without additional reader hardware, both on the consumer marketing page and developer SDK docs. Missing for 10: independent hands-on confirmation/review of Tap to Pay working reliably, and no mention of Android tap-to-pay support.", "evidenceIds": [ "square-docs-1", "square-docs-2", "square-docs-4" ] }, { "productId": "square", "storyId": "terminal-fleet-management-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The pack shows Square has physical hardware (Terminal API for payments, Tap to Pay) but no evidence of a device-fleet management API for registering devices, monitoring status, or remotely updating terminal/reader configuration — the only terminal-related doc (square-docs-26) covers payment/tip flows, not fleet administration.", "evidenceIds": [ "square-docs-26", "square-docs-3" ] }, { "productId": "square", "storyId": "tipping-flows", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Square's Terminal API explicitly documents tip collection with a separate tip screen and custom tip amounts on the reader/terminal (square-docs-26), which directly supports the story's core need. However, evidence is developer-API-focused rather than showing merchant-ops-friendly configuration (e.g., no direct mention of preset percentage options or 'smart tip amounts' UI, nor Dashboard-level tipping settings). missing for 10: explicit smart/percentage tip presets configuration, merchant-facing Dashboard UI evidence, and independent/hands-on confirmation of the tipping prompt experience.", "evidenceIds": [ "square-docs-26" ] }, { "productId": "stripe-terminal", "storyId": "accept-cards-and-wallets", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs explicitly confirm chip/contactless card reader support, Tap to Pay on iPhone and Android contactless via SDK, and Apple Pay/Google Pay via Stripe's payment methods on Terminal-compatible readers/devices, plus real-world community validation of the API-based in-person integration. Missing for 10: independent hands-on confirmation specifically of Apple Pay/Google Pay wallet taps on readers (evidence focuses more on contactless generally) and no dispute found.", "evidenceIds": [ "stripe-terminal-docs-2", "stripe-terminal-docs-19", "stripe-terminal-docs-18", "stripe-terminal-docs-26", "stripe-terminal-comm-1", "stripe-terminal-comm-3" ] }, { "productId": "stripe-terminal", "storyId": "agent-monitors-disputes", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe provides webhooks and API access to dispute data plus a Smart Disputes feature to automate evidence collection/submission, and an MCP server that could let agents interact with the Stripe API — but there is no evidence of an agent-specific workflow that monitors dispute deadlines and drafts evidence responses for human review; this is inferred by combining generic webhook/dispute docs. missing for 10: explicit documentation of agent-driven deadline monitoring, evidence-drafting workflow tailored for AI agents, and confirmation that Smart Disputes integrates with the MCP/agent tooling rather than being a Dashboard-only automation.", "evidenceIds": [ "stripe-terminal-docs-38", "stripe-terminal-docs-40", "stripe-terminal-docs-35", "stripe-terminal-docs-36" ] }, { "productId": "stripe-terminal", "storyId": "agent-provisions-new-location", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe Terminal's docs explicitly describe API-based management of locations/zones and reader registration (by serial number, registration code, or order number), and require readers be registered to a location before use — all doable via API calls without physical device access, which an agent could drive end-to-end. Stripe also has a general MCP server for agents to interact with the Stripe API. Missing for 10: no explicit example or confirmation that the MCP server's toolset covers Terminal locations/readers specifically, and no hands-on/independent evidence of an agent actually performing this end-to-end flow.", "evidenceIds": [ "stripe-terminal-docs-4", "stripe-terminal-docs-5", "stripe-terminal-docs-13", "stripe-terminal-docs-20", "stripe-terminal-docs-44", "stripe-terminal-docs-35", "stripe-terminal-probe-4" ] }, { "productId": "stripe-terminal", "storyId": "agent-reconciles-daily-takings", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe's platform (which Terminal sits within) exposes a Payouts API, webhooks for real-time transaction events, and an official MCP server that lets AI agents call the Stripe API directly, which together could support an agent pulling transactions/payouts data programmatically. However, there is no Terminal-specific documentation or example of an agent-driven reconciliation workflow, ledger-matching, or 'daily takings' summary feature. Missing for 10: explicit reconciliation/ledger-matching tooling, a documented end-to-end example of an agent pulling Terminal transactions+payouts and reconciling them, and independent/hands-on evidence of this working in practice.", "evidenceIds": [ "stripe-terminal-docs-35", "stripe-terminal-docs-39", "stripe-terminal-docs-38", "stripe-terminal-docs-28", "stripe-terminal-probe-4" ] }, { "productId": "stripe-terminal", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe's documentation confirms an llms.txt is live (HTTP 200) and individual docs pages are available as .md files (e.g., terminal.md), confirmed by direct probes, letting an agent be pointed at agent-oriented docs. Missing for 10: no independent/community confirmation that agents actually consume this successfully in practice.", "evidenceIds": [ "stripe-terminal-probe-1", "stripe-terminal-probe-2", "stripe-terminal-docs-35", "stripe-terminal-docs-36" ] }, { "productId": "stripe-terminal", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence that Stripe Terminal surfaces AI-generated insights or suggestions from transaction/business data inside its dashboard or SDKs. The MCP server and agent tooling references (docs-35, docs-36) enable external AI agents to call the Stripe API, but that is not the same as the product itself generating insights/suggestions from a user's data.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Stripe's broader platform offers building blocks for background automation—webhooks that trigger automatic reactions to events (e.g., completed Terminal payments), Smart Disputes that automate evidence collection, and an MCP server letting AI agents call the Stripe API—but none of this is a dedicated 'set up an autonomous background automation' feature specific to Terminal itself; it requires the developer to wire up webhook listeners or agent integrations themselves. Missing for 10: a first-party Terminal-specific automation/workflow engine, evidence of autonomous scheduled/triggered Terminal actions, and independent confirmation that these pieces compose into hands-off background automations.", "evidenceIds": [ "stripe-terminal-docs-38", "stripe-terminal-docs-40", "stripe-terminal-docs-35", "stripe-terminal-docs-36" ] }, { "productId": "stripe-terminal", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Stripe offers an MCP server so external AI agents can call the Stripe API, and general 'Agents and AI on Stripe' agent-first tooling, but nothing indicates Stripe Terminal itself embeds a built-in AI assistant that a user can delegate tasks to within the product.", "evidenceIds": [ "stripe-terminal-docs-35", "stripe-terminal-docs-36", "stripe-terminal-probe-4" ] }, { "productId": "stripe-terminal", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Stripe Terminal SDKs ship a built-in simulated card reader so developers can build/test integrations without physical hardware (docs-9), and the Stripe CLI (docs-37) supports scripting Stripe integrations, which together enable some automated/CI-style testing. However, there's no explicit documentation of running Terminal itself headlessly in CI pipelines, GitHub Actions examples, or automated end-to-end payment flows without human/device interaction, since the product's core function requires physical readers for real transactions. missing for 10: explicit CI/automation docs or examples (GitHub Actions, headless test harness), confirmation that simulated-reader testing can run fully unattended in CI, and evidence of production-grade headless orchestration beyond manual SDK/CLI use.", "evidenceIds": [ "stripe-terminal-docs-9", "stripe-terminal-docs-37" ] }, { "productId": "stripe-terminal", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Terminal is a payment-acceptance SDK/hardware product for in-person transactions, not an AI agent or agent framework that would itself consume external tools via MCP. The evidence about an MCP server (docs-35) describes Stripe exposing tools *to* AI agents, which is the opposite relationship and not about Terminal acting as an MCP client.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "agentic-mcp-server", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe (the parent platform) documents an official MCP server that lets AI agents interact with 'the Stripe API' and search Stripe's knowledge base, and this is corroborated by a probe confirming the live docs page; since Stripe Terminal is exposed via the Stripe API, this MCP server plausibly covers Terminal use cases, but no evidence explicitly names Terminal-specific tools or endpoints within the MCP server. missing for 10: explicit documentation that the MCP server exposes Terminal-specific actions (e.g., reader registration, payment collection) rather than generic Stripe API access, and independent/hands-on confirmation of Terminal agent workflows via MCP.", "evidenceIds": [ "stripe-terminal-docs-35", "stripe-terminal-probe-4", "stripe-terminal-docs-36" ] }, { "productId": "stripe-terminal", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Stripe (the parent platform) documents an official MCP server that lets AI agents interact with 'the Stripe API' and search documentation, which could in principle route Terminal-related API calls through natural-language agent commands, but there is no Terminal-specific evidence of natural-language control of readers, payments, or fleet management. missing for 10: Terminal-specific natural-language command support, agent-driven reader/payment control examples, independent corroboration of MCP-driven Terminal operations.", "evidenceIds": [ "stripe-terminal-docs-35", "stripe-terminal-probe-4", "stripe-terminal-docs-36" ] }, { "productId": "stripe-terminal", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe provides an official CLI ('Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal'), which applies to Stripe's platform including Terminal integrations, and this is corroborated by a dedicated docs probe confirming its existence. missing for 10: no evidence of Terminal-specific CLI subcommands or independent hands-on validation of CLI usage for Terminal workflows specifically.", "evidenceIds": [ "stripe-terminal-docs-37", "stripe-terminal-probe-5" ] }, { "productId": "stripe-terminal", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe Terminal is documented as an API-based integration with SDKs, and Stripe provides a public OpenAPI spec repo, CLI, and webhooks, giving AI-native users a fully documented programmatic surface to drive the product; community evidence corroborates deep API-level integration in production use. Missing for 10: a dedicated OpenAPI endpoint hosted directly under docs.stripe.com (probe found 404s) and independent hands-on AI-agent usage evidence specific to Terminal.", "evidenceIds": [ "stripe-terminal-docs-1", "stripe-terminal-docs-18", "stripe-terminal-docs-41", "stripe-terminal-docs-37", "stripe-terminal-docs-38", "stripe-terminal-comm-1", "stripe-terminal-probe-3" ] }, { "productId": "stripe-terminal", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers Terminal's POS/hardware features, MCP server availability, and general agent commerce framing, but contains no mention of restricted/scoped API keys, granular permissions, or any mechanism for issuing least-privilege credentials specifically for an AI agent using Terminal's API.", "evidenceIds": [ "stripe-terminal-docs-35", "stripe-terminal-docs-36" ] }, { "productId": "stripe-terminal", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Terminal ships official SDKs for Android, iOS, JavaScript (with a public GitHub repo), and React Native plus a server-driven API integration, backed by an OpenAPI spec and CLI for tooling — all first-party documented and corroborated by a hands-on developer report praising the API-level integration power for building custom terminals. Missing for 10: independent third-party benchmarking/reviews of the SDKs' developer experience specifically for AI-native/agentic workflows beyond the general MCP/agents docs.", "evidenceIds": [ "stripe-terminal-docs-1", "stripe-terminal-docs-18", "stripe-terminal-gh-1", "stripe-terminal-docs-41", "stripe-terminal-docs-37", "stripe-terminal-comm-1", "stripe-terminal-probe-2" ] }, { "productId": "stripe-terminal", "storyId": "agentic-webhooks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe's platform-wide webhooks system (registering HTTPS endpoints, receiving real-time event pushes to trigger automated reactions) is documented and applies to Terminal-generated events like payment_intent updates. missing for 10: Terminal-specific webhook event documentation and independent/hands-on confirmation that Terminal transactions reliably trigger these webhooks.", "evidenceIds": [ "stripe-terminal-docs-38" ] }, { "productId": "stripe-terminal", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack shows extensive Terminal docs, SDKs, and an OpenAPI spec repo, but nothing describes an interactive API reference with runnable/executable examples (e.g., a live 'try it' console); a probe even shows openapi.json endpoints returning 404 at the docs site, suggesting no readily discoverable interactive spec integration.", "evidenceIds": [ "stripe-terminal-probe-3", "stripe-terminal-docs-41", "stripe-terminal-probe-2" ] }, { "productId": "stripe-terminal", "storyId": "api-machine-spec", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe publishes a public OpenAPI specification repository for its API (stripe/openapi) which underlies Terminal's API-based integration, giving AI-native users a machine-readable spec to consume; probe attempts at docs.stripe.com-hosted openapi.json paths 404 but the canonical GitHub-hosted spec is well documented. missing for 10: no direct download link from Terminal-specific docs pages, and probe could not confirm a docs.stripe.com-hosted openapi.json endpoint.", "evidenceIds": [ "stripe-terminal-docs-41", "stripe-terminal-probe-3" ] }, { "productId": "stripe-terminal", "storyId": "api-sandbox", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Stripe Terminal SDKs include a built-in simulated card reader for developing and testing without physical hardware, and Stripe broadly supports test mode (sandbox) separate from live/production data. missing for 10: explicit mention of full sandbox parity (test API keys/test mode) specific to Terminal payments beyond the simulated reader, and independent hands-on confirmation of sandbox isolation.", "evidenceIds": [ "stripe-terminal-docs-9" ] }, { "productId": "stripe-terminal", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack includes general Terminal docs, SDKs, CLI, and MCP references, but nothing documents API versioning conventions or a deprecation policy for the Stripe API/Terminal endpoints (e.g. no mention of API version headers, changelogs, or sunset timelines). The OpenAPI spec repo (stripe-terminal-docs-41) only points to spec files, not a versioning/deprecation policy.", "evidenceIds": [ "stripe-terminal-docs-41" ] }, { "productId": "stripe-terminal", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Stripe Terminal docs describe managing multiple readers via locations/zones and registering readers individually, but there is no evidence of a bulk/batch API (e.g., batch payment processing, bulk reader configuration, or bulk refunds) that an AI agent could invoke to operate on many items in a single call. missing for 10: batch/bulk API endpoints for Terminal, evidence of programmatic bulk operations on payments or readers, AI-agent-oriented bulk automation examples.", "evidenceIds": [ "stripe-terminal-docs-4", "stripe-terminal-docs-5", "stripe-terminal-docs-20" ] }, { "productId": "stripe-terminal", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe provides generic webhook infrastructure (\"Listen for events from Stripe... so your integration can automatically trigger reactions\") which lets developers build event-driven automation on top of Terminal transactions, and Smart Disputes shows some automated action-on-event behavior. However, there is no Terminal-specific rules engine or no-code trigger/action builder — automation still requires custom webhook-handling code rather than user-defined rules. Missing for 10: a declarative rules/trigger UI or API specific to Terminal events, and evidence of AI-native users defining conditional automations without writing webhook handlers.", "evidenceIds": [ "stripe-terminal-docs-38", "stripe-terminal-docs-40" ] }, { "productId": "stripe-terminal", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Terminal is a POS/payment-hardware SDK product; scheduling recurring jobs or workflows is not part of its product category (no orchestration/scheduling capability is a fair expectation here), so this axis is a category error.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Terminal is a POS/payments hardware-integration product, not an automation/workflow-building tool; there is no concept of 'automations' with versioning, review, or rollback in this product category.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "catalog-inventory-sync", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Terminal is a payment-acceptance/hardware SDK product focused on card-present transactions, reader fleet management, tipping, receipts, and offline payments—not an inventory/catalog management system. Managing an item catalog with synced inventory counts across registers/channels is a POS/inventory-software concern, outside Terminal's product category.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "digital-receipts", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Terminal docs explicitly state merchants must offer physical or email receipts, prebuilt email receipts include all card-network-required fields, and receipts can be customized while retaining required information. This directly matches the story of issuing digital/printed receipts meeting card-network requirements. Missing for 10: independent/hands-on verification of receipt compliance and no explicit mention of SMS receipts (only email/print).", "evidenceIds": [ "stripe-terminal-docs-8", "stripe-terminal-docs-25", "stripe-terminal-docs-29", "stripe-terminal-docs-34", "stripe-terminal-docs-16" ] }, { "productId": "stripe-terminal", "storyId": "dispute-evidence-workflow", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Stripe (the broader platform) documents a dispute workflow in the Dashboard, guiding merchants through evidence submission and offering 'Smart Disputes' to automate evidence collection for eligible disputes, which covers the core of this story. However, this evidence is generic Stripe platform documentation, not specific to Stripe Terminal or in-person/card-present disputes, and there's no explicit mention of chargeback notification mechanisms (e.g., webhook events for disputes) tied to Terminal transactions. Missing for 10: Terminal-specific dispute handling details, explicit notification/webhook triggers for disputes, deadline tracking specifics, and any hands-on/independent corroboration of the dispute workflow.", "evidenceIds": [ "stripe-terminal-docs-40", "stripe-terminal-docs-38" ] }, { "productId": "stripe-terminal", "storyId": "multi-location-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly support a fleet model: readers are grouped into 'locations and zones' to manage multiple physical sites, registered to a specific location, and can be ordered/configured/monitored from the Dashboard (stripe-terminal-docs-4, -5, -13, -20, -32, -44). However, evidence does not show per-location reporting breakdowns or per-location configurable settings (e.g., distinct tipping/receipt/tax rules per site) beyond the general reader/location grouping. missing for 10: explicit per-location reporting/analytics in the Dashboard, per-location settings customization (receipts, tipping, tax), and independent/hands-on confirmation of multi-location fleet operations at scale.", "evidenceIds": [ "stripe-terminal-docs-4", "stripe-terminal-docs-5", "stripe-terminal-docs-13", "stripe-terminal-docs-20", "stripe-terminal-docs-32", "stripe-terminal-docs-44" ] }, { "productId": "stripe-terminal", "storyId": "native-mobile-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly confirm official Terminal SDKs for iOS and Android (plus JS/React Native) for building custom in-person payment integrations, with support for Tap to Pay on iPhone, offline payment storage, tipping, receipts, and built-in simulated readers for testing without hardware. Community evidence corroborates real-world developers building custom POS apps on top of the Terminal SDK/API, reinforcing that this is a viable, used integration path. Missing for 10: independent hands-on review of the actual mobile SDK integration experience (vs. docs only) and more detail on SDK API specifics/version history.", "evidenceIds": [ "stripe-terminal-docs-1", "stripe-terminal-docs-18", "stripe-terminal-docs-19", "stripe-terminal-docs-2", "stripe-terminal-docs-9", "stripe-terminal-docs-30", "stripe-terminal-comm-1" ] }, { "productId": "stripe-terminal", "storyId": "offline-payments", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe's docs explicitly describe offline payment storage on POS device/smart reader with automatic forwarding once connectivity resumes, directly matching the story. Missing for 10: independent/hands-on merchant evidence corroborating real-world offline behavior and details on limits/timeouts of offline storage.", "evidenceIds": [ "stripe-terminal-docs-6", "stripe-terminal-docs-15", "stripe-terminal-docs-27", "stripe-terminal-docs-33" ] }, { "productId": "stripe-terminal", "storyId": "openness-api-parity", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Stripe Terminal documents a full API-based integration path (reader registration/config via API, offline payment storage, receipts generated from API data, tips, refunds via API or Dashboard) and independent commentary confirms deep API-level control over terminal hardware, suggesting most Dashboard actions are API-accessible. However, some Dashboard-centric features (e.g., Smart Disputes automation, fleet monitoring dashboards) aren't explicitly confirmed as fully API-equivalent. Missing for 10: explicit API parity for dispute management/analytics dashboards, and stronger independent verification that every UI action has a documented API equivalent.", "evidenceIds": [ "stripe-terminal-docs-1", "stripe-terminal-docs-4", "stripe-terminal-docs-5", "stripe-terminal-docs-8", "stripe-terminal-docs-20", "stripe-terminal-docs-28", "stripe-terminal-docs-32", "stripe-terminal-comm-1" ] }, { "productId": "stripe-terminal", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Stripe Terminal's evidence pack covers payments, hardware, receipts, offline mode, and Connect integration, but contains no mention of bulk data export in open formats (e.g., CSV/JSON exports of transaction/customer data) or any facility for a user to extract all their data and migrate away from the platform.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "openness-open-license", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Stripe publishes open client SDK source (e.g., the Terminal JS SDK repo) and the OpenAPI spec repo, but the core Stripe Terminal service/backend and hardware firmware are proprietary and not available under an open license. missing for 10: no open-source license for the core Terminal service/backend, no evidence of an open license file on the SDK repos, no independent confirmation of full source availability beyond a thin client library.", "evidenceIds": [ "stripe-terminal-gh-1", "stripe-terminal-docs-41" ] }, { "productId": "stripe-terminal", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Terminal is a hosted SaaS payments/hardware platform, not software distributed for self-hosting; self-hosting the core product is a category error for this type of service.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "payment-event-webhooks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Stripe's general webhook system is well documented (docs-38: register an HTTPS endpoint and receive real-time events), and Terminal payments flow through core Stripe objects (PaymentIntents, Refunds, Disputes) that are webhook-eligible, with dispute (docs-40) and refund (docs-24, docs-28) API/dashboard support shown. However, the evidence never explicitly enumerates Terminal-specific webhook event types (e.g., terminal.reader.action_succeeded, payment_intent.succeeded for in-person) or shows a Terminal webhook integration example. Missing for 10: explicit list of Terminal-triggered webhook event names, a Terminal-specific webhook code sample, and independent developer confirmation that lifecycle events (authorized/captured/refunded/disputed) fire reliably for in-person transactions.", "evidenceIds": [ "stripe-terminal-docs-38", "stripe-terminal-docs-24", "stripe-terminal-docs-28", "stripe-terminal-docs-40" ] }, { "productId": "stripe-terminal", "storyId": "payout-timing-control", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe's general payouts docs confirm funds move from available balance to bank account and that Instant Payouts can be triggered anytime with funds landing in ~30 minutes, which would apply to Terminal-collected funds as well. However, this is generic Stripe platform documentation, not Terminal-specific, and there's no evidence of a dashboard view for tracking individual payout status/timing or an explicit next-day payout toggle description tied to in-person transactions. Missing for 10: Terminal-specific payout scheduling/dashboard visibility, explicit next-day payout option details, and any reconciliation UI tying Terminal transactions to payout batches.", "evidenceIds": [ "stripe-terminal-docs-39" ] }, { "productId": "stripe-terminal", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack addresses data residency, region selection, or data storage location controls for Stripe Terminal; the docs cover payments, receipts, offline storage of transactions, and fleet management but never data residency options.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Stripe Terminal is a payment-hardware/POS integration product; it has no AI-model-training data usage at all, so opting out of AI training is a category error for this product type rather than a missing feature.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence describes data retention controls, deletion mechanisms, or privacy-posture settings for Stripe Terminal data; evidence pack covers payments, hardware, receipts, and unrelated compliance/dispute topics only. Missing for 10: any documentation of data retention policy, customer data deletion API/process, or configurable retention windows.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack mentions telemetry opt-out or usage-tracking controls for Stripe Terminal; the docs cover payments, hardware, receipts, and MCP/agent tooling but nothing about disabling analytics/telemetry collection.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "reader-pairing-setup", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs detail multiple quick registration paths (serial number usable immediately after unboxing, registration code, order number), no-code acceptance, and Dashboard-based reader/location management, directly matching the 'pair and take a payment within minutes' story. Community accounts corroborate that Terminal's hardware/API integration is powerful and solves real in-store pain points for merchants moving off legacy POS hardware. Missing for 10: independent hands-on timing evidence explicitly confirming a 'within minutes' setup experience.", "evidenceIds": [ "stripe-terminal-docs-5", "stripe-terminal-docs-20", "stripe-terminal-docs-13", "stripe-terminal-docs-21", "stripe-terminal-docs-32", "stripe-terminal-docs-4", "stripe-terminal-comm-1", "stripe-terminal-comm-3" ] }, { "productId": "stripe-terminal", "storyId": "reconcile-takings-reports", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Stripe docs confirm payouts (funds sent to bank accounts) and a unified Dashboard showing in-person and online payments together, which supports basic reconciliation, but there is no evidence of a dedicated itemized transaction/fee report or reconciliation tool tailored to Terminal payouts. missing for 10: itemized fee-report documentation, explicit payout-to-transaction reconciliation feature, and any reporting API/export evidence specific to Terminal.", "evidenceIds": [ "stripe-terminal-docs-39", "stripe-terminal-docs-10", "stripe-terminal-docs-17", "stripe-terminal-docs-32" ] }, { "productId": "stripe-terminal", "storyId": "reduced-pci-scope", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes Stripe Terminal's SDKs, readers, offline handling, receipts, and fleet management, but nowhere does it mention PCI DSS, PCI scope, certified reader compliance guidance, or vendor documentation on the developer's remaining compliance obligations. missing for 10: any documentation of PCI DSS certification for Terminal readers, explicit vendor guidance on developer PCI scope reduction, and confirmation that card data never touches developer servers/code.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "refunds-from-pos", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs confirm refunds can be issued via Dashboard (docs-24) or Refunds API (docs-28), covering original card refunds initiated from dashboard/API; Terminal's unified in-person/online payment management (docs-10, docs-17) implies POS-originated payments are refundable through these same channels. Missing for 10: explicit documentation of partial refund support and a POS/reader-native refund flow (as opposed to only dashboard/API) plus independent hands-on confirmation.", "evidenceIds": [ "stripe-terminal-docs-24", "stripe-terminal-docs-28", "stripe-terminal-docs-10", "stripe-terminal-docs-17" ] }, { "productId": "stripe-terminal", "storyId": "server-driven-terminal-checkout", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs explicitly confirm an API-based, server-driven integration path (in addition to SDKs) for building a custom POS, with supporting infrastructure like reader registration, locations/zones, offline payment storage, and a simulated reader for testing without hardware; a hands-on developer account corroborates building a fully custom terminal integration via the API. missing for 10: no independent third-party benchmark of the raw REST/server-driven API surface itself (only docs + one anecdotal HN account).", "evidenceIds": [ "stripe-terminal-docs-1", "stripe-terminal-docs-18", "stripe-terminal-docs-42", "stripe-terminal-docs-9", "stripe-terminal-docs-5", "stripe-terminal-docs-4", "stripe-terminal-comm-1" ] }, { "productId": "stripe-terminal", "storyId": "simulated-reader-testing", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs explicitly state Terminal SDKs and server-driven integration include a built-in simulated card reader for developing/testing without physical hardware, and the Stripe CLI supports building/testing integrations. missing for 10: no independent/hands-on developer account confirming the simulated reader workflow end-to-end, and no detail on test card numbers specific to Terminal.", "evidenceIds": [ "stripe-terminal-docs-9", "stripe-terminal-docs-37", "stripe-terminal-probe-5" ] }, { "productId": "stripe-terminal", "storyId": "split-payments", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack describes split-tender functionality (splitting one sale across multiple payment methods or payers); documentation covers tipping, refunds, receipts, offline payments, and fleet management but nothing about multi-tender or split payment splitting at checkout.", "evidenceIds": [] }, { "productId": "stripe-terminal", "storyId": "start-accepting-same-week", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs confirm hardware ordering and reader registration/configuration directly from the Dashboard (docs-32, docs-5, docs-20, docs-44) and no-code acceptance options (docs-21, docs-26, docs-31), supporting a founder's ability to get set up for in-person payments quickly. However, there is no evidence describing the account signup/approval process, approval timelines, or shipping/delivery speed for hardware, so the 'same week' claim is unverified.\nmissing for 10: evidence of signup/approval flow and timeline, hardware shipping/delivery speed, independent confirmation of onboarding speed.", "evidenceIds": [ "stripe-terminal-docs-32", "stripe-terminal-docs-5", "stripe-terminal-docs-20", "stripe-terminal-docs-44", "stripe-terminal-docs-21", "stripe-terminal-docs-26" ] }, { "productId": "stripe-terminal", "storyId": "tap-to-pay-on-own-phone", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Stripe Terminal explicitly documents Tap to Pay on iPhone (and Android) for accepting contactless payments on a compatible off-the-shelf phone without a separate physical reader, directly matching the story. Missing for 10: independent/hands-on confirmation of the Tap to Pay experience specifically (community evidence covers general Terminal use, not Tap to Pay directly).", "evidenceIds": [ "stripe-terminal-docs-2", "stripe-terminal-docs-19", "stripe-terminal-docs-18" ] }, { "productId": "stripe-terminal", "storyId": "terminal-fleet-management-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Stripe Terminal docs explicitly cover fleet management via API: registering readers by serial number/registration code/order number, organizing devices with locations and zones across sites, and 'order, register, configure, and monitor readers from the Dashboard' with an equivalent API-based integration path. Community evidence corroborates that API-level control over terminals/hardware fleet is a key strength of the product. Missing for 10: independent hands-on confirmation of remote configuration updates specifically via API (docs emphasize Dashboard for monitor/configure) and no direct code sample of a fleet-status API call.", "evidenceIds": [ "stripe-terminal-docs-4", "stripe-terminal-docs-5", "stripe-terminal-docs-13", "stripe-terminal-docs-20", "stripe-terminal-docs-32", "stripe-terminal-comm-1" ] }, { "productId": "stripe-terminal", "storyId": "tipping-flows", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly describe on-reader tipping with suggested tip prompts before payment collection, plus on-receipt tipping as an alternative, directly matching the story's percentage/smart-amount/custom-tip prompt configuration on the terminal. Missing for 10: no explicit documentation of configuring specific percentage values or 'smart amount' algorithms, nor independent/hands-on merchant confirmation of the tipping UX.", "evidenceIds": [ "stripe-terminal-docs-7", "stripe-terminal-docs-14", "stripe-terminal-docs-23", "stripe-terminal-docs-43" ] }, { "productId": "sumup", "storyId": "accept-cards-and-wallets", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp's docs explicitly describe in-person acceptance of card payments via physical readers (chip/contactless via Solo/Go readers, Cloud API) and Tap to Pay for direct contactless acceptance on a compatible phone, covering chip, contactless, and mobile-wallet-capable in-person flows. Missing for 10: explicit named confirmation of Apple Pay/Google Pay wallet support specifically (only 'contactless' and 'mobile-wallet' terminals generically referenced) and independent/hands-on corroboration beyond vendor docs.", "evidenceIds": [ "sumup-docs-9", "sumup-docs-29", "sumup-docs-37", "sumup-docs-6", "sumup-docs-38" ] }, { "productId": "sumup", "storyId": "agent-monitors-disputes", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "SumUp's docs cover checkouts, refunds, webhooks for checkout status, and MCP/agent tooling, but there is no evidence of a disputes/chargebacks API, dispute deadline data, or evidence-submission endpoints that an agent could monitor or draft responses against.", "evidenceIds": [ "sumup-docs-15", "sumup-docs-24", "sumup-docs-41", "sumup-docs-16", "sumup-docs-23" ] }, { "productId": "sumup", "storyId": "agent-provisions-new-location", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows reader pairing/naming and Cloud API triggering payments, but there is no documented API for creating a 'location' entity or registering readers to a location end-to-end — no location resource, no provisioning workflow evidenced. missing for 10: location creation API, reader-to-location registration endpoint, any end-to-end provisioning example.", "evidenceIds": [ "sumup-docs-7", "sumup-docs-45", "sumup-docs-37" ] }, { "productId": "sumup", "storyId": "agent-reconciles-daily-takings", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "SumUp exposes API access (SDK, MCP server, Agent Toolkit) that could let an agent create checkouts and manage payments, and webhooks/refund guides show some transaction-status visibility, but there is no evidence of a payouts endpoint or a documented transactions/payouts listing API for reconciliation into a ledger. missing for 10: dedicated payouts API/endpoint, transaction history/list API, ledger/reconciliation-specific documentation or examples, independent confirmation of agent-driven reconciliation workflows.", "evidenceIds": [ "sumup-docs-11", "sumup-docs-12", "sumup-docs-14", "sumup-docs-15", "sumup-docs-27", "sumup-docs-43" ] }, { "productId": "sumup", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "SumUp explicitly publishes llms.txt/llms-small.txt (verified live by probe) plus a dedicated agent-oriented docs section describing Markdown-accessible docs, an MCP server, and an Agent Toolkit for LangChain/AI SDK/OpenAI Agents SDK, directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: independent/community confirmation of an agent actually consuming llms.txt successfully.", "evidenceIds": [ "sumup-docs-30", "sumup-docs-4", "sumup-probe-1", "sumup-docs-25", "sumup-docs-11" ] }, { "productId": "sumup", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform; the evidence shows API/MCP/agent-toolkit integrations for building agentic payment apps, but nothing about SumUp itself surfacing AI-generated insights or suggestions from merchant data inside its own product UI. Generating in-product analytics insights is a different axis than exposing APIs for external agents to build on, so this is a category mismatch rather than a missing feature.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "SumUp is a payments API/platform with webhooks, an MCP server, and an agent toolkit for building agentic integrations, but there is no evidence of a native automation/workflow feature that runs autonomously in the background (e.g., scheduled jobs, triggers, rules engine) within SumUp itself — it only exposes APIs/tools that a third party would need to orchestrate.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "SumUp's evidence only shows it exposes an MCP server and Agent Toolkit so that external AI agents/coding assistants can call SumUp APIs — this is SumUp acting as a tool provider for other agents, not a built-in AI assistant embedded in the SumUp product itself that a user can delegate tasks to.", "evidenceIds": [ "sumup-docs-11", "sumup-docs-12", "sumup-docs-25", "sumup-docs-26" ] }, { "productId": "sumup", "storyId": "agentic-headless", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "SumUp provides a Node.js SDK (works in headless runtimes like Node 18+, Cloudflare Workers), static API keys for programmatic access, and sandbox accounts with test cards to simulate payment flows—together enabling scripted, non-interactive automation suitable for CI-like testing. However, there is no explicit CI/CD documentation, headless test runner, or automation pipeline example, and webhooks are limited to checkout status only, limiting full automation of end-to-end flows. Missing for 10: explicit CI/CD integration guide, documented automated test suite/harness, broader event webhooks beyond checkout status.", "evidenceIds": [ "sumup-docs-17", "sumup-docs-27", "sumup-docs-14", "sumup-docs-42", "sumup-docs-41" ] }, { "productId": "sumup", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments API/platform, not an AI agent or assistant host; the evidence shows it ships its own MCP server and Agent Toolkit so that other agents/clients can consume SumUp's tools, which is the opposite direction from a user plugging external MCP servers into SumUp to extend its own tool use. This axis (being an MCP client) doesn't fit SumUp's product category.", "evidenceIds": [ "sumup-docs-11", "sumup-docs-25", "sumup-docs-12" ] }, { "productId": "sumup", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp documents an official managed MCP server at https://mcp.sumup.com/mcp that lets MCP clients manage accounts, create checkouts, and process payments, corroborated by an independent probe confirming the docs page. Missing for 10: independent hands-on third-party test of the MCP server actually working, and details on auth/setup limitations.", "evidenceIds": [ "sumup-docs-11", "sumup-docs-25", "sumup-docs-31", "sumup-docs-43", "sumup-probe-3" ] }, { "productId": "sumup", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "SumUp exposes a managed MCP server and an Agent Toolkit that let MCP-compatible AI assistants create checkouts, manage accounts, and process payments via natural-language-driven agents (sumup-docs-11, sumup-docs-25, sumup-docs-12, sumup-docs-43). This is first-party documentation only, with no independent or hands-on report confirming smooth natural-language operation in practice. Missing for 10: independent/hands-on corroboration of the MCP server's natural-language workflows, and any evidence of a native NL command interface outside the MCP/agent-toolkit integration path.", "evidenceIds": [ "sumup-docs-11", "sumup-docs-25", "sumup-docs-12", "sumup-docs-43", "sumup-probe-3" ] }, { "productId": "sumup", "storyId": "agentic-official-cli", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform, not a developer tool with a command-line workflow; there is no evidence of, or plausible need for, an official CLI. This story concerns AI-native CLI tooling, which is not a fair axis for a payments API/SDK provider whose AI integrations are MCP server and agent toolkit based.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp publishes extensive developer documentation covering checkout creation, refunds, webhooks, terminal Cloud API, and JS/TS SDKs, with sandbox testing support and API-key auth, and an independent developer confirms building on the public API in production. This clearly satisfies a documented, drivable public API for AI-native or programmatic use. missing for 10: a formal machine-readable OpenAPI/Swagger spec (probe shows 404s for standard OpenAPI endpoints), broader independent hands-on confirmation beyond one anecdote.", "evidenceIds": [ "sumup-docs-1", "sumup-docs-13", "sumup-docs-14", "sumup-docs-17", "sumup-docs-27", "sumup-docs-40", "sumup-comm-1", "sumup-probe-2" ] }, { "productId": "sumup", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "SumUp docs describe API keys as static, account-wide credentials ('act on behalf of the merchant account that created the key') with no mention of scopes, permissions, or least-privilege options for agents or sub-credentials. No evidence of OAuth scopes, restricted-permission keys, or agent-specific credential issuance.", "evidenceIds": [ "sumup-docs-14" ] }, { "productId": "sumup", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp offers an official JavaScript SDK (@sumup/sdk) with TypeScript declarations for modern runtimes, plus an official Agent Toolkit adding SumUp tools to LangChain, AI SDK, OpenAI Agents SDK, and MCP, and a managed MCP server for AI clients. This directly supports building against official SDKs in an AI-native/agentic context. Missing for 10: independent/hands-on developer corroboration of the SDK or agent toolkit in practice, and broader multi-language SDK coverage beyond JavaScript.", "evidenceIds": [ "sumup-docs-27", "sumup-docs-42", "sumup-docs-12", "sumup-docs-26", "sumup-docs-11", "sumup-docs-43", "sumup-probe-3" ] }, { "productId": "sumup", "storyId": "agentic-webhooks", "verdict": "partial", "quality": 4, "confidence": "high", "rationale": "SumUp documents a narrow webhook mechanism: a `return_url` parameter set at checkout creation lets you get notified only about checkout status changes, not a general event subscription/webhook system covering other event types. missing for 10: broader event catalog beyond checkout status, a dedicated webhook subscription/management API, and any signature-verification or delivery-retry docs.", "evidenceIds": [ "sumup-docs-15", "sumup-docs-24", "sumup-docs-41" ] }, { "productId": "sumup", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docs include code snippets (e.g., sumup-docs-13) and markdown-based documentation, but there is no evidence of an interactive, runnable API reference (like Swagger/OpenAPI explorer or Postman console); a direct probe for OpenAPI/Swagger specs returned 404s (sumup-probe-2), indicating no such interactive reference exists.", "evidenceIds": [ "sumup-docs-13", "sumup-probe-2", "sumup-probe-1" ] }, { "productId": "sumup", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe for OpenAPI/Swagger specs at all standard candidate paths returned 404, and no evidence pack item points to a downloadable machine-readable API spec; the documentation instead offers Markdown/llms.txt files and an MCP server, not an OpenAPI spec.", "evidenceIds": [ "sumup-probe-2", "sumup-probe-1" ] }, { "productId": "sumup", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp docs explicitly provide sandbox merchant accounts, test cards, and 3D Secure simulation for testing payment flows without touching production data, plus a Virtual Solo option for terminal testing before switching to a physical reader. This covers the AI-native testing need well, though missing for 10: explicit guidance on using sandbox specifically via the MCP server/agent toolkit, and independent hands-on confirmation of sandbox fidelity.", "evidenceIds": [ "sumup-docs-17", "sumup-docs-1", "sumup-docs-8", "sumup-docs-3", "sumup-docs-2" ] }, { "productId": "sumup", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item mentions API versioning scheme or any documented deprecation policy; probes even show OpenAPI spec URLs returning 404, and no changelog/versioning docs are referenced.", "evidenceIds": [ "sumup-probe-2" ] }, { "productId": "sumup", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The docs mention the Cloud API can run simultaneous transactions across multiple paired Solo readers, which is the only hint of parallel/batch-like operation, but there is no evidence of a genuine bulk API (e.g., batch checkout creation, bulk refunds, or list-based operations) that an AI agent could invoke to act on many items in one call. Missing for 10: bulk/batch endpoints for checkouts or refunds, documented multi-item request payloads, and confirmation that MCP/Agent Toolkit tools support batch calls rather than one-at-a-time operations.", "evidenceIds": [ "sumup-docs-7", "sumup-docs-22", "sumup-docs-45", "sumup-docs-11", "sumup-docs-12" ] }, { "productId": "sumup", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "SumUp's docs show only basic webhook notifications for checkout status changes (via return_url), not a rules engine allowing users to define custom conditions/actions across events; no evidence of any automation/rules builder.", "evidenceIds": [ "sumup-docs-15", "sumup-docs-24", "sumup-docs-41" ] }, { "productId": "sumup", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform, not a workflow/scheduling automation product; there is no concept of scheduling recurring jobs (webhooks are event-based status notifications, not recurring job scheduling). Scheduling recurring workflows is outside its product category.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments API/platform, not an automation-building tool with a concept of versioned, reviewable automations to roll back — this axis is a category error for its product type.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "catalog-inventory-sync", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers payment processing, checkout, terminal readers, refunds, webhooks, and SDKs, but nothing describes an item/product catalog with inventory counts synced across registers and channels — a core POS/inventory feature is absent from all provided documentation.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "digital-receipts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of a native email/SMS or printed receipt feature, nor any mention of card-network receipt compliance. The only related item is a community post describing a developer having to hack a receipt-printer integration via the public API because SumUp's app didn't natively support it, which suggests the absence of a first-party receipt-issuance capability rather than confirming one.", "evidenceIds": [ "sumup-comm-1" ] }, { "productId": "sumup", "storyId": "dispute-evidence-workflow", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence shows webhooks only notify on checkout status changes and refund guides, with no mention of chargeback notifications or a dispute-evidence submission workflow/deadline tracking anywhere in the docs.", "evidenceIds": [ "sumup-docs-15", "sumup-docs-24", "sumup-docs-41", "sumup-docs-16", "sumup-docs-40" ] }, { "productId": "sumup", "storyId": "multi-location-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers payment API/reader integrations, MCP tools, and pricing tiers, but there is no mention of multi-location management, per-location settings, or per-location reporting/dashboards for merchant-ops. Multiple readers can be paired/named but nothing ties this to a location-based hierarchy or reporting.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "native-mobile-sdks", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "SumUp docs explicitly describe embedding payment acceptance directly in iOS/Android apps via Reader SDKs, controlling the reader over Bluetooth or using Tap to Pay, and offline transactions support, covering the core of the story. missing for 10: explicit named SDK package/repo links for iOS/Android (e.g. CocoaPods/Gradle artifacts), independent developer corroboration of SDK integration experience, and detailed API reference docs beyond high-level descriptions.", "evidenceIds": [ "sumup-docs-5", "sumup-docs-21", "sumup-docs-38", "sumup-docs-29", "sumup-docs-10", "sumup-docs-44" ] }, { "productId": "sumup", "storyId": "offline-payments", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "SumUp documents a dedicated Offline Transactions feature for terminal SDKs explicitly describing a store-and-forward flow where card data is captured and cached securely on-device and uploaded later for processing when connectivity returns. This directly matches the story; missing for 10: independent/hands-on confirmation of reliability in real outage scenarios and details on limits (e.g., risk caps, duration offline).", "evidenceIds": [ "sumup-docs-10", "sumup-docs-44" ] }, { "productId": "sumup", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "SumUp's docs show broad API/SDK coverage for core payment operations—checkouts, refunds, terminal/reader management, webhooks—and even an MCP server/agent toolkit for AI-driven use, but webhooks are explicitly limited ('only allows notified about a status change') and no evidence shows API parity for account settings, reporting, disputes, or other dashboard/UI-only features found on a typical SumUp merchant account. missing for 10: evidence of full account/reporting/dispute management parity via API, explicit statement of 1:1 UI-API feature parity, and independent confirmation beyond vendor docs.", "evidenceIds": [ "sumup-docs-13", "sumup-docs-16", "sumup-docs-24", "sumup-docs-41", "sumup-docs-11", "sumup-docs-25", "sumup-probe-3" ] }, { "productId": "sumup", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform holding transaction/merchant data, and the evidence pack has no mention of any data export feature (open formats like CSV/JSON export of transactions, merchant data, or account closure/data portability tooling); it covers payment APIs, MCP/agent tooling, and checkout flows but nothing about exporting user data and leaving.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "SumUp is a closed-source commercial payments platform; no evidence of any open-source license or public source repository for the core product, only API docs and SDK wrappers.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "openness-self-host", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a hosted payments/fintech SaaS platform; self-hosting the core product (payment processing infrastructure) is not a plausible axis for this category, as it inherently requires SumUp's managed merchant/payment network infrastructure.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "payment-event-webhooks", "verdict": "partial", "quality": 4, "confidence": "high", "rationale": "SumUp docs confirm webhooks exist but explicitly state the system 'only allows you to get notified about a status change for a checkout' — a single generic event type, not the granular authorized/captured/refunded/disputed lifecycle events the story requests. Refunds are documented as a separate API-driven action, not as a distinct webhook event, and disputes are not mentioned at all in the webhook docs. missing for 10: distinct webhook events for authorization, capture, dispute; documented dispute webhook; independent/hands-on confirmation of webhook reliability.", "evidenceIds": [ "sumup-docs-15", "sumup-docs-24", "sumup-docs-41", "sumup-docs-16", "sumup-docs-40" ] }, { "productId": "sumup", "storyId": "payout-timing-control", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions payout timing, payout schedules, next-day/instant payout options, or any mechanism to view or accelerate payouts; the docs focus on checkouts, terminal payments, refunds, webhooks, and MCP/agent tooling.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform and no evidence pack item mentions data residency, region selection, or data storage location controls; the docs focus on payments, checkout, MCP tools, and pricing without any data residency configuration.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform, not an AI model provider or chatbot; there is no evidence of any AI training data policy or opt-out mechanism, and this axis is a category error for a payments API/SDK product.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence of any data retention/deletion controls, privacy dashboard, or GDPR-style data export/delete APIs in the SumUp docs pack; the evidence focuses on payments, SDKs, and MCP tooling with no mention of user data lifecycle management.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SumUp is a payments platform, not an AI agent/tool whose telemetry a developer would need to opt out of; the evidence pack contains no telemetry/usage-tracking controls at all since this axis doesn't apply to a payment API/SDK product.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "reader-pairing-setup", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "SumUp's docs describe pairing Solo/Go readers with an account (docs-45), naming readers for streamlined checkout, and using a Virtual Solo to test the pairing flow before switching to a physical reader (docs-8), plus Cloud API triggering payments over HTTPS (docs-6) and Tap to Pay as a no-reader option (docs-9). However there's no explicit first-party or hands-on evidence of the end-to-end time-to-first-payment ('within minutes') claim, and no independent corroboration of the pairing UX itself. Missing for 10: explicit speed/time claim for pairing-to-payment, independent/hands-on account of the pairing experience.", "evidenceIds": [ "sumup-docs-45", "sumup-docs-8", "sumup-docs-6", "sumup-docs-9", "sumup-docs-37" ] }, { "productId": "sumup", "storyId": "reconcile-takings-reports", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers checkout, terminal payments, refunds, webhooks, and pricing pages, but there is no mention of reconciliation reports, payout statements, itemized fee breakdowns, or any dashboard/export feature for matching daily takings to payouts.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "reduced-pci-scope", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "SumUp's architecture (hosted Checkout, embedded Payment Widget, certified Solo/Go readers over Bluetooth/HTTPS, offline transactions with secure on-device caching) is consistent with minimizing merchant PCI scope, since card data is captured/processed by SumUp-certified hardware or hosted pages rather than the merchant's own systems (sumup-docs-35, sumup-docs-36, sumup-docs-9, sumup-docs-44, sumup-docs-6). However, there is no explicit vendor documentation cited that discusses PCI DSS scope reduction, SAQ eligibility, or guidance on the developer's remaining compliance obligations. Missing for 10: explicit PCI DSS/SAQ guidance pages, statements of PCI certification levels for readers, and any developer-facing compliance checklist.", "evidenceIds": [ "sumup-docs-35", "sumup-docs-36", "sumup-docs-9", "sumup-docs-44", "sumup-docs-6", "sumup-docs-21" ] }, { "productId": "sumup", "storyId": "refunds-from-pos", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "SumUp's developer docs explicitly describe both full and partial refunds for a previously processed payment via the API (sumup-docs-16, -23, -40), covering the API leg of the story clearly. However, there is no evidence in the pack describing refund initiation from the point-of-sale device or the merchant dashboard UI, so only one of the three channels is substantiated. missing for 10: dashboard-based refund flow, POS/terminal refund flow, independent/hands-on confirmation of refund completion.", "evidenceIds": [ "sumup-docs-16", "sumup-docs-23", "sumup-docs-40" ] }, { "productId": "sumup", "storyId": "server-driven-terminal-checkout", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp's Cloud API explicitly lets a POS on any platform drive Solo/Go readers via HTTPS requests from the backend, with docs covering pairing, multi-reader support, sandbox/virtual testing, and offline transactions, plus community evidence of a real developer building a custom integration against the public API. Missing for 10: a public OpenAPI/swagger spec (probe found only 404s) and more independent hands-on validation beyond one HN anecdote.", "evidenceIds": [ "sumup-docs-5", "sumup-docs-6", "sumup-docs-7", "sumup-docs-8", "sumup-docs-37", "sumup-docs-44", "sumup-comm-1", "sumup-probe-2" ] }, { "productId": "sumup", "storyId": "simulated-reader-testing", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "SumUp docs explicitly describe sandbox merchant accounts, test cards, and simulated 3D Secure flows for testing before going live, plus a Virtual Solo reader that can be paired with a sandbox account to test checkout flow prior to using a physical device. This directly covers both simulated-reader and test-card scenarios for in-person integration. Missing for 10: independent/hands-on developer confirmation of the sandbox/test-card workflow in practice beyond vendor docs.", "evidenceIds": [ "sumup-docs-17", "sumup-docs-8", "sumup-docs-1", "sumup-docs-3" ] }, { "productId": "sumup", "storyId": "split-payments", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence anywhere in the docs describes splitting a single sale across multiple payment methods or multiple payers — checkouts, refunds, terminal payments, and offline flows are all described as single-payer/single-method transactions. This is a plausible axis for a payments product but SumUp's evidence pack shows no split-tender or split-payment capability.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "start-accepting-same-week", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack is entirely developer-API documentation (checkouts, SDKs, MCP servers, cloud API, refunds) and pricing claims; it contains no evidence about the merchant signup/approval workflow or ordering hardware from a dashboard, which is the core of this founder-onboarding story.", "evidenceIds": [] }, { "productId": "sumup", "storyId": "tap-to-pay-on-own-phone", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "SumUp's docs explicitly describe Tap to Pay: accepting in-person contactless payments directly on a compatible phone without a separate card reader, embedded in the merchant's app. Missing for 10: independent hands-on confirmation of the founder-facing app experience and specifics on supported phone models/onboarding steps.", "evidenceIds": [ "sumup-docs-9", "sumup-docs-29", "sumup-docs-38" ] }, { "productId": "sumup", "storyId": "terminal-fleet-management-api", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "SumUp's Cloud API supports pairing and naming multiple Solo readers and triggering payments via HTTPS, which is a thin form of device registration, but there is no evidence of true fleet management — no API for monitoring device status/health or remotely updating reader configuration. Missing for 10: device status/health monitoring endpoints, remote configuration/firmware update API, fleet-wide management dashboard or bulk operations.", "evidenceIds": [ "sumup-docs-7", "sumup-docs-45", "sumup-docs-37", "sumup-docs-6" ] }, { "productId": "sumup", "storyId": "tipping-flows", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers checkout creation, terminal payment integrations, refunds, webhooks, offline transactions, and MCP/agent tooling, but nowhere mentions tipping prompts, tip percentages, smart tip amounts, or custom tip configuration on readers/terminals. This is a plausible feature for a payments platform's reader/terminal product, so the axis applies, but there is no supporting evidence at all.", "evidenceIds": [] } ]