Adyen vs Square

Agent access

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

   weight 2 · round to Adyen
   Adyen✓fullprobed10/10

   Adyen has a live, probed llms.txt (HTTP 200) plus markdown-renderable docs pages (append .md), a documented full-docs ZIP mirror explicitly for feeding AI agents/code assistants, and an OpenAPI spec repo positioned as LLM context — this is direct, independently-probed confirmation of agent-oriented docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.adyen.com/online-payments.md --- title: "Online payments" description: "Accept payments with cards, …”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”

   proof ↗⚑ flag

   Square✓fullprobed9/10

   Square publishes a live, verified llms.txt (probe confirms HTTP 200) explicitly designed for AI agents, with agent-specific guidance on idempotency keys, pagination, and instructions to fetch llms-full.txt or per-page .md files instead of loading the whole corpus; docs pages also render as raw markdown. This is corroborated by an independent probe hit. missing for 10: no independent third-party (non-vendor) confirmation that agents successfully consume this file in practice, and the docs.md/openapi fallback endpoints 404 rather than existing.

   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.squareup.com/llms.txt # Square Developer Platform > Square APIs and SDKs for accepting paymen…”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.squareup.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Adyen~partialclaimed6/10

   Adyen's core integration is a server-to-server REST API (docs-1, docs-2) that can be called entirely headlessly with no UI dependency, supports idempotency keys for safe automated retries (adyen-docs-4, adyen-docs-25), and provides a dedicated test environment with test credentials explicitly meant for pre-production integration testing (adyen-docs-6, adyen-docs-18). Scoped, multiple API credentials support automated/service-account style access (adyen-docs-26, adyen-supp-api-credential-scoping). However, there is no explicit CI/CD pipeline documentation, no CLI/SDK testing harness, and the MCP server is documented as running locally via npx rather than as a CI-oriented headless service. Missing for 10: explicit CI/CD integration guides, automated test-suite/SDK tooling, and confirmation of non-interactive credential provisioning for pipelines.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Your server makes three Checkout API requests: /paymentMethods, /payments, and /payments/details.”
   • [claimed-docs] “To submit a request for idempotent processing, send a request with the `idempotency-key:` in the header.”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”
   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Test the different types of transactions with Adyen that your integration handles using test credentials.”
   • [claimed-docs] “You can also create multiple API credentials to improve security and control access.”
   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”

   proof ↗⚑ flag

   Square~partialclaimed6/10

   Square's platform is fundamentally API/SDK-driven (Node.js SDK, REST/GraphQL APIs, idempotency keys) and ships a dedicated Sandbox environment explicitly for testing automation, plus a local MCP server mode (`npx square-mcp-server start`) with env-var controls like SANDBOX=true and DISALLOW_WRITES=true that suit scripted/CI use. However, there is no explicit CI/CD pipeline documentation, GitHub Actions integration, or hands-on evidence of running Square headlessly in an actual CI pipeline. Missing for 10: explicit CI/pipeline integration guides, documented headless automation examples beyond sandbox testing, independent confirmation of CI usage.

   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Square Sandbox”
   • [claimed-docs] “Idempotency”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [github] “const client = new SquareClient({ token: "YOUR_TOKEN" });”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”

   proof ↗⚑ flag

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

   weight 3 · round to Square
   Adyen✓fullprobed8/10

   Adyen documents and ships an official MCP server (github.com/Adyen/adyen-mcp) that lets LLM clients call Checkout, payment links, modifications, and Management API tools via natural language, with clear setup (npx install), scoped API-key auth, and role-based permissions. Missing for 10: independent/hands-on third-party verification of the MCP server working in practice (only vendor docs and a live-probe confirming the doc page exists, no community usage reports) and clarity on production-readiness given its 'Alpha' status.

   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [claimed-docs] “This allows developers to use natural language to connect with Adyen's platform more easily and build new payment solutions faster.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “MCP access rides on Adyen's standard scoped credentials: "To authenticate the requests you will make using the MCP, generate an API key. Mak…”

   proof ↗⚑ flag

   Square✓fullprobed9/10

   Square documents an official hosted remote MCP server (mcp.squareup.com/mcp) with OAuth-based scoped auth plus an open-source local server, both exposing the full Square API platform, and provides setup guidance for Claude, Cursor, Windsurf, Goose. This is well-documented first-party evidence with a public GitHub repo, though independent hands-on user validation is limited. Missing for 10: independent/community confirmation of real-world agent usage beyond vendor docs.

   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “npx square-mcp-server start”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “The remote MCP is recommended as it uses OAuth authentication, allowing you to log in with your Square account directly without having to cr…”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Adyen—none0/10

   Evidence covers an MCP server, OpenAPI specs, docs tooling, and agentic-commerce protocols, but there is no mention of an official Adyen CLI for AI-native workflows anywhere in the pack.

   ⚑ flag

   Square—none0/10

   Square's evidence shows an MCP server, SDKs, GraphQL, and API Explorer, but no dedicated official CLI tool (e.g., a 'square' command-line utility for managing resources, testing APIs, or agentic workflows) is documented anywhere in the pack. The `npx square-mcp-server start` command is for launching an MCP server, not a general-purpose CLI.

   • [claimed-docs] “npx square-mcp-server start”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Adyen✓fullprobed9/10

   Adyen ships extensive documented public REST APIs (Checkout, Management, Platforms, Payouts, Agentic Commerce, etc.), an OpenAPI spec repo as 'single source of truth' for client generation, idempotency keys, scoped API credentials, webhooks, and machine-readable docs (llms.txt, .md pages, full docs mirror) explicitly aimed at AI tooling. Probes independently confirm llms.txt and .md doc endpoints return 200. Missing for 10: a live discoverable OpenAPI/swagger endpoint directly under docs.adyen.com (probe found 404s on standard paths) and independent third-party corroboration of API usability beyond vendor docs.

   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”
   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.adyen.com/online-payments.md --- title: "Online payments" description: "Accept payments with cards, …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”

   proof ↗⚑ flag

   Square✓fullprobed9/10

   Square publishes an extensive documented public REST API (payments, refunds, disputes, subscriptions, invoices, webhooks) plus GraphQL, SDKs (e.g. square-nodejs-sdk), API Explorer, sandbox testing, OAuth scopes, and an explicit llms.txt/llms-full.txt agent-consumption index with agent-specific guidance (idempotency keys, pagination) — directly supporting AI-native, agentic driving of the product. Missing for 10: no public OpenAPI/swagger spec discoverable (probe returned 404s), and no independent third-party corroboration beyond vendor docs.

   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”
   • [claimed-docs] “Square access is scope-controlled: "Access tokens are credentials that allow applications to securely interact with Square APIs. An access t…”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.squareup.com/llms.txt # Square Developer Platform > Square APIs and SDKs for accepting paymen…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Adyen✓fullclaimed8/10

   Adyen documents scoped, role-based API credentials (roles define exactly what a credential can do, e.g. limiting to initiating vs capturing payments, per-merchant-account scoping) and explicitly recommends creating multiple credentials for finer-grained access control — and the MCP server docs instruct assigning a dedicated API credential with only the specific roles needed for agent use, plus a --tools flag to limit which MCP tools are exposed. This directly supports least-privilege credential issuance for an AI agent. missing for 10: no independent/hands-on verification of least-privilege enforcement in practice, and no explicit per-agent short-lived/ephemeral credential mechanism beyond static role-scoped API keys.

   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”
   • [claimed-docs] “MCP access rides on Adyen's standard scoped credentials: "To authenticate the requests you will make using the MCP, generate an API key. Mak…”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “You can also create multiple API credentials to improve security and control access.”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square supports OAuth with per-permission scopes for granular access control, and its remote MCP server explicitly uses OAuth login to 'authorize only the scopes your application needs' for agent connections; the local MCP server also supports a DISALLOW_WRITES read-only mode and SANDBOX flag for least-privilege agent setups. Missing for 10: no independent/hands-on verification of scope granularity in practice, and no explicit documentation of fine-grained scope lists specifically tailored for agent use cases beyond general OAuth scopes.

   • [claimed-docs] “Square access is scope-controlled: "Access tokens are credentials that allow applications to securely interact with Square APIs. An access t…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”
   • [claimed-docs] “The remote MCP is recommended as it uses OAuth authentication, allowing you to log in with your Square account directly without having to cr…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Square
   Adyen~partialprobed6/10

   Adyen documents official SDKs for web/iOS/Android/React Native/Flutter and a public OpenAPI spec repo as the 'single source of truth' usable to generate client libraries, which supports SDK-based building; however, the OpenAPI/spec endpoint probes returned 404s and there's no independent/hands-on corroboration of SDK quality or completeness for AI-native workflows specifically. missing for 10: independent verification of official SDK repos/quality, working OpenAPI spec endpoint (probe returned 404s), hands-on developer confirmation of SDK-based agentic integration.

   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square ships official, first-party SDKs (e.g. square-nodejs-sdk/TypeScript library) with documented code examples for payments, versioning, and client setup, plus broader API coverage (REST, GraphQL, OAuth, webhooks, sandbox) that AI-native developers can build against, reinforced by an explicit llms.txt/agent-guidance file and an official MCP server for programmatic AI tool access. Missing for 10: independent/hands-on developer corroboration of SDK quality beyond GitHub README snippets, and broader multi-language SDK evidence beyond Node/TypeScript.

   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [github] “await client.payments.create(..., { version: "2024-05-04" // override the version used })”
   • [github] “const client = new SquareClient({ token: "YOUR_TOKEN" });”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Adyen✓fullclaimed8/10

   Adyen provides first-party webhook subscriptions to avoid polling, with event logs visible in the Customer Area, and MCP tools to list/get/test webhooks, plus agentic-commerce flows that explicitly send webhook payment outcomes to merchant servers — showing webhooks are usable both directly and via AI-native/agent tooling. missing for 10: no independent/hands-on developer confirmation of webhook subscription setup via API or MCP, and no detail on webhook event types/payload schema management through natural-language/agentic tooling.

   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Google Agentic Commerce integration: "Use this integration for processing Google Pay payments through Adyen, when Google agents (Google AI M…”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square provides a documented Webhooks system with subscribing to event notifications, verifying/validating events, sandbox testing, and event logs — a standard webhook mechanism usable by any AI-native integration (including via its MCP server/API access). missing for 10: no explicit example of an AI agent programmatically subscribing to webhooks, and no independent hands-on corroboration beyond first-party docs.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “[Verify and Validate an Event Notification](/docs/webhooks/step3validate)”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Square
   Adyen~partialclaimed6/10

   Adyen Uplift is documented as an AI layer that analyzes payment data and 'gives you recommendations that are tailored for your business' to optimize conversion, risk, and cost, and risk management includes ML-powered fraud detection using global transaction data. This matches the spirit of AI-generated insights/suggestions from account data, but it's narrowly scoped to payment-funnel optimization and fraud, not a general-purpose 'insights' feature across reporting/dashboards, and there's no independent/hands-on corroboration of how these suggestions surface in the UI. Missing for 10: broader AI-generated insights across reporting/analytics (not just Uplift/fraud), and third-party or hands-on evidence of the insights UX.

   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”
   • [claimed-docs] “Adyen Uplift helps you strike a balance between conversion, risk and cost. You get recommendations that are tailored for your business”
   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square AI (Beta) is a first-party in-product assistant that answers natural-language questions over the seller's own sales/inventory data, surfaces proactive insights, and even pulls in web data (weather, events, reviews), with seller testimonials confirming real use for sales analysis. Missing for 10: independent/third-party validation beyond vendor testimonials and more detail on breadth/accuracy of suggestions across all data types.

   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”
   • [claimed-docs] “Square AI | Unlock Growth with AI-Powered Insights”

   proof ↗⚑ flag

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

   weight 2 · round to Adyen
   Adyen~partialclaimed5/10

   Adyen supports several background/event-driven automations — webhooks that eliminate manual polling for async status changes, Uplift's AI-driven payment-funnel optimization experiments that can be started/evaluated/stopped autonomously, and risk-management rules/ML fraud detection that run continuously — but these are fixed platform features rather than a general-purpose mechanism for an AI-native user to author custom autonomous background automations. Missing for 10: a user-configurable automation/workflow builder or scheduler that an AI-native user can set up to run arbitrary agentic tasks unattended, and independent evidence of such automations running reliably in production.

   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”
   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”

   proof ↗⚑ flag

   Square~partialclaimed4/10

   Square provides building blocks (Webhooks for event-driven triggers, Subscriptions API for recurring billing, and an MCP server letting AI tools call the API) that a developer could wire into an autonomous background automation, but there is no evidence of a native workflow/automation engine or scheduled-agent feature that runs independently without custom integration work. Square AI is described as an on-demand insight assistant, not an autonomous background automation runner. Missing for 10: a documented no-code/low-code automation or workflow builder, evidence of scheduled/triggered autonomous agent execution, and confirmation that MCP-driven agents can run unattended in the background rather than only via an interactive AI client.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “Subscriptions API”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Square
   Adyen—none0/10

   Adyen documents an MCP server (for external LLM clients to call Adyen's APIs) and 'Uplift' (automated AI-driven payment optimization), but no evidence of a built-in AI assistant/copilot inside the Adyen product itself that a user can converse with or delegate tasks to interactively.

   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”

   proof ↗⚑ flag

   Square✓fullclaimed7/10

   Square AI (Beta) is documented as an in-product assistant built into seller tools that answers natural-language questions over sales/inventory data, handles routine tasks, and pulls in web data, with seller testimonials of real usage. Missing for 10: independent/hands-on verification beyond vendor testimonials, and detail on the breadth of tasks it can autonomously execute versus just answer questions.

   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”
   • [claimed-docs] “Square AI | Unlock Growth with AI-Powered Insights”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Adyen~partialprobed7/10

   Adyen ships an official MCP server (adyen-mcp) that explicitly lets users 'use natural language with your chosen LLM client' to interact with Adyen APIs (create sessions, payment links, refunds, management API), with documented scoped-credential setup — a genuine natural-language operation surface for AI-native users. However, the MCP server is explicitly marked 'Alpha', runs only locally via npx, and only exposes a documented subset of tools rather than full product coverage. Missing for 10: production-grade/GA status, independent hands-on validation of the NL interface actually working reliably, and broader coverage beyond the documented tool subset.

   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [claimed-docs] “This allows developers to use natural language to connect with Adyen's platform more easily and build new payment solutions faster.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “MCP access rides on Adyen's standard scoped credentials: "To authenticate the requests you will make using the MCP, generate an API key. Mak…”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”

   proof ↗⚑ flag

   Square~partialclaimed7/10

   Square ships a first-party beta 'Square AI' seller assistant for natural-language queries over sales/inventory data, and a documented MCP server (local + hosted, OAuth-scoped) that lets AI agents like Claude/Cursor issue natural-language-driven API calls (payments, orders, catalog, etc.) via discovery tools. This gives real NL-command operability, but it's split across a beta insights assistant (limited to analysis/reporting) and third-party agent integration (MCP) rather than a single native NL control surface for all product actions. Missing for 10: evidence that Square AI itself can execute broad write/operational commands (not just analysis), and independent/hands-on validation of MCP agent workflows beyond vendor docs.

   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “Square AI | Unlock Growth with AI-Powered Insights”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Square
   Adyen—none0/10

   The evidence describes OpenAPI specs (usable to generate Postman collections or client libraries), markdown-rendered docs, and an MCP server for natural-language API access, but there is no evidence of an actual interactive API reference/console embedded in Adyen's docs where a user can run live example requests. A probe for a standard OpenAPI/Swagger endpoint also returned 404s, and no 'try it' console or embedded runnable code examples are documented.

   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”

   proof ↗⚑ flag

   Square✓fullprobed8/10

   Square documents a genuine interactive API Explorer that builds/sends real HTTP requests against Sandbox or production resources (customers, orders, catalog), plus a GraphQL Explorer for runnable queries, giving developers a hands-on interactive reference. Missing for 10: no independent/third-party corroboration of the API Explorer's usability and no discoverable OpenAPI spec (probe confirms 404s), so tooling depth is documented only by the vendor.

   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”
   • [claimed-docs] “API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs.”
   • [claimed-docs] “API Explorer lets you test your requests using actual Sandbox or production resources in your account such as customers, orders, and catalog…”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”

   proof ↗⚑ flag

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

   weight 2 · round to Adyen
   Adyen✓fullprobed8/10

   Adyen documents a dedicated OpenAPI specification repository (github.com/Adyen/adyen-openapi) covering 'every public API Adyen offers' as the 'single source of truth,' explicitly positioned for machine consumption (client-library generation, Postman collections, and LLM/agent context). This is reinforced by llms.txt, markdown-renderable docs, and a full docs mirror ZIP for AI tooling. missing for 10: independent/hands-on confirmation that the OpenAPI repo is current and complete, and a direct in-docs discoverable openapi.json endpoint (probe found only 404s for openapi.json-style paths on the docs domain itself).

   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”

   proof ↗⚑ flag

   Square—none0/10

   No documentation page or probe in the evidence pack shows a downloadable OpenAPI/Swagger spec; explicit probes for common OpenAPI paths (openapi.json, swagger.json, etc.) all returned 404, and no docs page links to a machine-readable spec file (only an interactive API Explorer, GraphQL schema, and SDKs are mentioned).

   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.squareup.com/docs.md”
   • [claimed-docs] “API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs.”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Adyen✓fullclaimed8/10

   Adyen documents a dedicated test environment for the full integration (client- and server-side) using test credentials before going live, and this test environment is explicitly wired into AI-native workflows via the Adyen MCP server which runs with `--env=TEST` (or LIVE with a live prefix), letting an AI agent exercise Checkout, payment links, and modification tools against sandbox data. Missing for 10: no independent/hands-on confirmation that sandbox test data is fully isolated from production, and no detail on seeding/resetting sandbox state for repeatable AI-driven test runs.

   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Test the different types of transactions with Adyen that your integration handles using test credentials.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square documents a dedicated Sandbox environment (square-docs-21, square-docs-40) with sandbox testing for disputes/payments, and the API Explorer and MCP server explicitly support running against Sandbox resources instead of production (square-docs-48, square-supp-api-explorer, square-supp-mcp-remote with 'run a local instance configured to access a seller's Sandbox environment', and SANDBOX=true env var in square-supp-mcp-tools). This directly enables AI-native agents to test without touching production data. Missing for 10: independent/hands-on confirmation that sandbox parity with production is complete and that MCP sandbox mode is broadly validated by third-party users rather than only vendor docs.

   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Square Sandbox”
   • [claimed-docs] “API Explorer lets you test your requests using actual Sandbox or production resources in your account such as customers, orders, and catalog…”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”

   proof ↗⚑ flag

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

   weight 2 · round to Square
   Adyen—none0/10

   The evidence pack covers API idempotency, webhooks, credentials, OpenAPI specs, and agentic commerce integrations, but contains no documentation of API versioning scheme or a deprecation policy for older API versions. Versioning/deprecation policy is a standard and fair axis for a payments API platform, so absence of evidence yields 'none'.

   ⚑ flag

   Square~partialclaimed5/10

   Square's API clearly supports date-based versioning — SDK calls can override the API version ("version: '2024-05-04'") and the MCP tool documents a SQUARE_VERSION pinning control — showing a live, explicit versioning scheme. However, no evidence in the pack shows a documented deprecation policy (timelines, sunset notices, migration guides) that would let an AI-native user reliably plan around version lifecycle changes. Missing for 10: an explicit deprecation/sunset policy document, version changelog, or migration guidance referenced anywhere in the evidence.

   • [github] “await client.payments.create(..., { version: "2024-05-04" // override the version used })”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Idempotency”

   proof ↗⚑ flag

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

   weight 2 · round to Adyen
   Adyen~partialclaimed6/10

   Adyen documents concrete bulk operations in its agentic Product Feed API — batch ingest of up to 200 items per call and batch delete of up to 200 products per call — which is genuine 'many items at once' functionality for AI-platform inventory sync. However, evidence of bulk operations elsewhere in the platform (e.g., bulk payouts, bulk refunds/modifications, bulk reporting exports, or MCP tools operating on many resources at once) is absent; the MCP tool list is single-item oriented (create one session, one payment link, one refund). Missing for 10: bulk support evidenced across other core domains (payments, payouts, platforms/onboarding) and bulk-capable MCP tools, not just the product feed.

   • [claimed-docs] “You can upload batches of information about your inventory to Adyen, and we will synchronize it with AI platforms.”
   • [claimed-docs] “The Adyen Product Feed API is "a centralized product knowledge hub that synchronizes your inventory with AI platforms" via asynchronous batc…”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”

   proof ↗⚑ flag

   Square—none0/10

   The evidence pack shows GraphQL reducing multiple API calls into one query (square-docs-41/square-supp-graphql) and a generic MCP `make_api_request` tool, but no documentation or example of true bulk/batch operations (e.g., batch-upserting catalog items, bulk inventory adjustments, or bulk order processing) that would let an AI-native user act across many items in one call.

   • [claimed-docs] “One GraphQL query can retrieve data that requires multiple Square API calls.”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Adyen
   Adyen~partialclaimed5/10

   Adyen documents a genuine rules mechanism — the risk management rule builder lets you 'create, backtest, and label custom rules' that automatically trigger block/allow/review actions on each transaction event (adyen-docs-20, adyen-docs-28, adyen-docs-48), and webhooks notify on async status-change events (adyen-docs-3/17). This satisfies the core 'rule triggers action on event' pattern, but only within the fraud/risk-decisioning domain, not as a general-purpose automation/workflow engine, and there's no evidence of AI-native rule authoring (e.g., via the MCP server or natural language) for these rules. Missing for 10: general cross-domain event-action automation beyond fraud rules, AI/LLM-driven rule creation or triggering, and independent evidence of real-world use of the rule builder.

   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”
   • [claimed-docs] “Each payment goes through a risk evaluation. The risk evaluation reaches a decision that results in an action to block, allow, or review the…”
   • [claimed-docs] “You can detect, monitor, and mitigate fraud using Protect, Adyen's risk management system.”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”

   proof ↗⚑ flag

   Square~partialclaimed4/10

   Square exposes webhooks/event notifications that let a developer wire custom code to react to events (square-docs-19, square-docs-39) and has narrow built-in 'custom rules and alerts' for fraud/risk management (square-docs-28), but there is no general-purpose, user-definable rules/automation engine ('if event X then action Y') across the platform's business events. Missing for 10: a documented no-code/low-code rule builder, broader event-trigger coverage beyond payments/fraud, and evidence of the AI-native user directly authoring such rules (vs. developers writing webhook handlers).

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Prevent loss online. Get insights into payment fraud patterns, and set custom rules and alerts to manage risk.”
   • [claimed-docs] “[Verify and Validate an Event Notification](/docs/webhooks/step3validate)”

   proof ↗⚑ flag

Ai billing ops

1. ai-native userHave an agent monitor failed payments via API and webhooks and drive retries and dunning outreach

   weight 3 · round to Adyen
   Adyen~partialclaimed5/10

   Adyen provides the raw building blocks an agent could use—webhooks for status changes (adyen-docs-3/17/45), refusal-reason detail on failed payments (adyen-docs-7), idempotent retries (adyen-docs-4/25), and an MCP server exposing webhook list/get/test and payment tools (adyen-supp-mcp-tools)—but there is no documented dunning/subscription-retry feature, automated outreach mechanism, or agent workflow specifically for failed-payment recovery. Missing for 10: native dunning/retry orchestration, recurring-billing failed-payment workflow, and evidence of an agent actually driving retries/outreach rather than just monitoring raw webhook/API data.

   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”

   proof ↗⚑ flag

   Square—none0/10

   Square documents webhooks, a Subscriptions API, and Payments API, but the evidence pack has no mention of failed-payment monitoring, automated retry logic, or dunning outreach features/APIs; the community note even flags subscriptions as a historical gap. An agent could theoretically be built on top of webhooks, but no first-party capability or workflow for this specific story is evidenced.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “Subscriptions API”
   • [community] “Does square have a way to handle subscriptions yet? Seems to be the only thing they are missing”

   proof ↗⚑ flag

2. ai-native userHave an agent provision a new product, price, and payment link via the API in a single session

   weight 3 · round to Square
   Adyen—none0/10

   Adyen's API and MCP server cover payments, payment links, checkout sessions, and payouts, but there is no evidence of any 'product' or 'price' resource concept (billing/catalog objects like Stripe's Products/Prices) that an agent could provision alongside a payment link — Adyen is a payments processor, not a billing/invoicing product catalog system. The only 'product' references are to inventory feeds for agentic commerce (syncing existing catalog to AI platforms), not creating new products/prices via API. missing for 10: evidence of a Products/Prices API or equivalent billing object model, evidence of a single-session workflow that creates a product+price+payment link together, any documentation of provisioning billing entities (not just payment links) via API or MCP.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Offer payment links.”
   • [claimed-docs] “The Adyen Product Feed API is "a centralized product knowledge hub that synchronizes your inventory with AI platforms" via asynchronous batc…”

   proof ↗⚑ flag

   Square~partialclaimed7/10

   Square's remote/local MCP server (square-mcp-server) exposes a discovery-oriented `make_api_request` tool spanning Catalog, Checkout, and Payments services, and Square's llms.txt explicitly frames the API as agent-consumable with idempotency-key guidance for writes — together these support an agent creating a catalog item (product), its price, and a payment link (via Checkout/Payment Links API) in one session using a single access token/OAuth session. However, no evidence pack item shows an actual end-to-end worked example or transcript of an agent doing product+price+payment-link creation in one session, and Payment Links API itself is not separately documented in the pack (only Checkout/Catalog mentioned generically). missing for 10: an explicit end-to-end tutorial/example chaining catalog item + price + payment link creation, and independent/hands-on confirmation the MCP tool can complete this multi-step flow in a single session.

   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “Learn how to nest modifier lists under modifiers with the Catalog API to build multi-step customization flows”

   proof ↗⚑ flag

Invoicing

1. finance-ops userSend hosted invoices with online payment and automatic reminders

   weight 2 · round to Square
   Adyen—none0/10

   Adyen's evidence covers payment links, checkout, platforms, payouts, and agentic commerce, but there is no mention of a hosted invoicing product, invoice generation, or automatic payment reminders anywhere in the pack — only generic 'payment links' (adyen-docs-24) which is a different capability.

   • [claimed-docs] “Offer payment links.”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square has a documented Invoices API confirming hosted invoicing exists, but the evidence pack lacks detail on automatic reminders, online payment collection specifics within invoices, or hosted invoice pages. Missing for 10: documentation on automatic reminder scheduling, hosted payment page details, and independent/hands-on confirmation of the invoicing workflow.

   • [claimed-docs] “Invoices API”

   proof ↗⚑ flag

Subscriptions

1. finance-ops userAutomatically retry failed subscription payments with smart dunning and recovery emails

   weight 2 · round drawn
   Adyen—none0/10

   The evidence pack covers payments, payouts, webhooks, idempotency, risk management, platforms/marketplace payouts, and agentic commerce, but contains no mention of subscription billing, dunning management, automatic retry logic for failed recurring payments, or recovery emails. This is a plausible axis for a payments platform, but nothing in the docs or community evidence shows Adyen offering smart dunning/recovery workflows.

   ⚑ flag

   Square—none0/10

   Square documents a Subscriptions API and general payments/invoicing capabilities, but no evidence describes automated retry logic, smart dunning, or recovery emails for failed subscription payments; a community comment even questions whether Square's subscription handling is mature.

   • [claimed-docs] “Subscriptions API”
   • [community] “Does square have a way to handle subscriptions yet? Seems to be the only thing they are missing”

   proof ↗⚑ flag

2. developerSet up recurring subscription billing with plans, trials, upgrades, and proration

   weight 3 · round to Square
   Adyen—none0/10

   Adyen's evidence pack covers payments, payouts, platforms, risk, reporting, and agentic commerce, but there is no mention of subscription/recurring billing constructs like plans, trial periods, upgrades/downgrades, or proration—these are the domain of a billing/subscription-management layer (e.g. Adyen has separate tooling or partners for this) not documented here.

   ⚑ flag

   Square~partialcommunity5/10

   Square documents a dedicated Subscriptions API (square-docs-23), confirming recurring billing support, but the evidence pack gives no detail on plan configuration, trial periods, upgrade/downgrade flows, or proration logic. An old community comment (square-comm-1) also shows subscriptions were historically seen as a gap, though this predates the current API's existence. Missing for 10: documented support for trials, plan upgrades/downgrades, and proration calculations; independent/hands-on confirmation these work as expected.

   • [claimed-docs] “Subscriptions API”
   • [community] “Does square have a way to handle subscriptions yet? Seems to be the only thing they are missing”

   proof ↗⚑ flag

Card acceptance

1. founderAccept an online card payment within a day of signing up

   weight 3 · round to Square
   Adyen!disputedcontradicted4/10

   Adyen's docs describe a fast technical integration (single /sessions call, test-then-go-live flow, no setup fees) that could suggest same-day acceptance, but independent community reports concretely contradict a founder's ability to just sign up and start accepting payments quickly: Adyen reportedly refuses small clients ('under the million'), requires large reserves for subscription businesses, and one user describes a multi-hundred-hour integration effort before abandoning it. These are hands-on, specific counter-examples, not generic skepticism, so the 'within a day' claim is disputed rather than simply partial. Missing for 10: any evidence of Adyen actually onboarding a small/new founder-level merchant same-day, or a rebuttal to the reserve/minimum-volume gating reports.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Pay per transaction, with no setup or monthly fees.”
   • [community] “Adyen refuses small clients, under the million :/”
   • [community] “One of the bigger drawbacks of Adyen vs Stripe... they require a crazy reserve (in the millions) if your model is subscription based, to be …”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”
   • [community] “Adyen's pricing model looks much more attractive on paper, but the integration complexity and minimum processing volumes usually keep early-…”

   proof ↗⚑ flag

   Square✓fullclaimed7/10

   Square documents self-serve signup with a Web Payments SDK, Card Payments API, and prebuilt eCommerce integrations that 'can be completed in just a few clicks,' plus a Sandbox for immediate testing—consistent with a founder going from signup to live online card acceptance quickly without sales calls. Missing for 10: explicit 'time-to-first-payment' documentation or independent/hands-on account of actual signup-to-live timing.

   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “Square has prebuilt online payment solutions with top eCommerce providers. Most connections can be completed in just a few clicks.”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Take payments in person and online. Securely save recurring payment methods. Easily sync sales, inventory, and customer data with your Squ…”

   proof ↗⚑ flag

Checkout surfaces

1. developerEmbed customizable payment components directly in my own site or app instead of redirecting to a hosted page

   weight 3 · round drawn
   Adyen✓fullcommunity8/10

   Adyen's Web/mobile Drop-in and Components let developers embed sessions-based payment UI directly in their own site/app (web, iOS, Android, React Native, Flutter) with customizable styling and localization, rather than redirecting to a hosted page. This is a core, well-documented capability with sample flows (create session, mount Components) and cross-platform SDK support. Missing for 10: independent hands-on confirmation of embedding ease (community feedback is mixed/critical on integration complexity), and no detailed code-level customization examples in the pack.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [claimed-docs] “Customize the styling of your checkout.”
   • [claimed-docs] “Customize the styling of your checkout. Present your payment form in the local language of your shoppers with our localization support.”
   • [claimed-docs] “With the client key, you have: A single key for all your allowed origins in an environment.”
   • [community] “I implemented Adyen for a company I was consulting for. I liked it. Their integration was not as terrible as many here make it seem. It allo…”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square's Web Payments SDK is explicitly documented for embedding customizable card/ACH/Cash App/Afterpay payment components directly into a developer's own site rather than redirecting to a hosted checkout page, and this is backed by a full Payments API, Node SDK, and sandbox testing tools. missing for 10: no independent/hands-on developer report confirming ease of customization or styling flexibility beyond first-party docs.

   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “[ACH Bank Transfer Payment](/docs/payments-api/take-payments/ach-payments)”
   • [claimed-docs] “[Afterpay and Clearpay Payments](/docs/payments-api/take-payments/afterpay-payments)”
   • [claimed-docs] “[Cash App Payments](/docs/payments-api/take-payments/cash-app-payments)”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Take payments in person and online. Securely save recurring payment methods. Easily sync sales, inventory, and customer data with your Squ…”

   proof ↗⚑ flag

2. developerRedirect customers to a vendor-hosted, conversion-optimized checkout page without building my own payment UI

   weight 3 · round to Adyen
   Adyen~partialclaimed6/10

   Adyen explicitly offers hosted 'payment links' that developers can generate and redirect customers to without building payment UI (adyen-docs-24), and the MCP tool surface confirms this as a first-class API capability (create/get/expire payment links) (adyen-supp-mcp-tools). However, Adyen's primary integration path emphasized in the docs is the Sessions/Components client-side flow which requires building or embedding UI (adyen-docs-1), and there is no detailed documentation on conversion-optimization specifics of the hosted page itself. Missing for 10: dedicated documentation describing the hosted checkout page's design/conversion features, independent evidence of its effectiveness, and clarity on it being the recommended 'no-code UI' path rather than a secondary option.

   • [claimed-docs] “Offer payment links.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”

   proof ↗⚑ flag

   Square—none0/10

   The evidence pack covers Square's Payments API, Web Payments SDK (embeddable UI), Invoices, and various backend APIs, but never mentions a vendor-hosted, conversion-optimized checkout page (e.g., a Checkout API or Payment Links) that a developer could redirect customers to without building payment UI. Web Payments SDK (square-docs-31) actually requires building your own UI, the opposite of this story.

   ⚑ flag

No code selling

1. founderCreate a shareable payment link from the dashboard with no code and start selling immediately

   weight 2 · round to Adyen
   Adyen!disputedcontradicted4/10

   Adyen's docs confirm a payment-links feature exists ("Offer payment links" - adyen-docs-24) and a Customer Area dashboard for managing transactions (adyen-docs-16), but there is no evidence of a self-serve, no-code flow a founder can use to instantly start selling. Community reports concretely contradict the 'start immediately' premise for founders: Adyen is described as refusing small clients ('Adyen refuses small clients, under the million' - adyen-comm-1) and requiring underwriting/minimum volumes that keep early-stage startups away ('integration complexity and minimum processing volumes usually keep early-stage startups on Stripe' - adyen-comm-11), unlike a turnkey signup-and-sell experience. missing for 10: documented self-serve onboarding flow for small merchants, step-by-step dashboard payment-link creation, evidence that a founder can go live without a sales/underwriting process.

   • [claimed-docs] “Offer payment links.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [community] “Adyen refuses small clients, under the million :/”
   • [community] “Adyen's pricing model looks much more attractive on paper, but the integration complexity and minimum processing volumes usually keep early-…”

   proof ↗⚑ flag

   Square—none0/10

   The evidence pack focuses almost entirely on Square's developer APIs, SDKs, and MCP/AI tooling for building payment integrations, not on the no-code merchant dashboard feature of generating a shareable payment link. No citation mentions 'Payment Links' or a dashboard flow for founders to create a link without coding.

   ⚑ flag

Payment methods

1. founderOffer digital wallets and local payment methods (Apple Pay, Google Pay, bank redirects, BNPL) from the same integration

   weight 2 · round to Adyen
   Adyen✓fullcommunity8/10

   Adyen docs explicitly promise 'one integration' covering all preferred payment methods (wallets, local methods, BNPL) via a single Checkout API/sessions flow, with community corroboration that it supports native local methods like iDEAL and Sofort. Missing for 10: an explicit itemized list of Apple Pay/Google Pay/BNPL support and independent hands-on confirmation of wallet/BNPL specifically (only general local-method corroboration exists), plus some community friction reports on integration complexity.

   • [claimed-docs] “Offer your customers all their preferred payment methods with a single integration.”
   • [claimed-docs] “One integration Offer your customers all their preferred payment methods with a single integration.”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Your server makes three Checkout API requests: /paymentMethods, /payments, and /payments/details.”
   • [community] “I implemented Adyen for a company I was consulting for. I liked it. Their integration was not as terrible as many here make it seem. It allo…”

   proof ↗⚑ flag

   Square~partialclaimed6/10

   Square's Payments API and Web Payments SDK docs confirm ACH bank transfers, Afterpay/Clearpay (BNPL), Cash App, and card payments in one integration, but the evidence never explicitly documents Apple Pay or Google Pay wallet support alongside these, nor generic 'bank redirect' methods beyond ACH. missing for 10: explicit Apple Pay/Google Pay digital wallet docs, broader local bank-redirect methods (iDEAL, etc.), and independent confirmation that all these methods coexist in a single unified checkout flow.

   • [claimed-docs] “[ACH Bank Transfer Payment](/docs/payments-api/take-payments/ach-payments)”
   • [claimed-docs] “[Afterpay and Clearpay Payments](/docs/payments-api/take-payments/afterpay-payments)”
   • [claimed-docs] “[Cash App Payments](/docs/payments-api/take-payments/cash-app-payments)”
   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “ACH Bank Transfer Payment”
   • [claimed-docs] “Afterpay and Clearpay Payments”
   • [claimed-docs] “Cash App Payments”

   proof ↗⚑ flag

Pci compliance

1. developerKeep my systems out of most of PCI DSS scope because card data is tokenized and never touches my servers

   weight 2 · round drawn
   Adyen~partialclaimed5/10

   Adyen's Checkout API/sessions flow shows card data handled client-side and passed via Adyen's hosted fields/client key rather than touching the merchant's server (adyen-docs-1, adyen-docs-44), which implies the tokenization pattern developers rely on for reduced PCI scope. However, none of the evidence explicitly discusses PCI DSS, SAQ levels, or scope-reduction guidance, so the compliance benefit is only inferable from the technical integration pattern, not documented directly. missing for 10: explicit PCI DSS scope-reduction documentation, SAQ-A eligibility guidance, independent compliance certification evidence.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “With the client key, you have: A single key for all your allowed origins in an environment.”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square's Web Payments SDK and Card Payments API use client-side tokenization (e.g., sourceId/ccof: tokens in the SDK, 'Save Card on File') so raw card numbers are handled by Square's SDK rather than the developer's server, which is the standard architecture for reducing PCI scope. However, the evidence pack contains no explicit statement about PCI DSS compliance level, SAQ A eligibility, or scope-reduction guidance from Square itself. Missing for 10: an explicit PCI DSS/SAQ-A scope statement, documentation of compliance certifications, and independent confirmation that using these SDKs actually reduces a merchant's PCI scope.

   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “[Save Card on File](/docs/terminal-api/advanced-features/save-card-on-file)”

   proof ↗⚑ flag

Integration reliability

1. developerSafely retry any API request using idempotency keys so network failures never create duplicate charges

   weight 2 · round drawn
   Adyen✓fullclaimed8/10

   Adyen explicitly documents idempotency-key headers for retrying API requests without duplicate side-effects (adyen-docs-4, adyen-docs-25), directly matching the story. Missing for 10: independent/hands-on developer confirmation of idempotency behavior in production and detail on key expiration/edge cases.

   • [claimed-docs] “To submit a request for idempotent processing, send a request with the `idempotency-key:` in the header.”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”

   proof ↗⚑ flag

   Square✓fullclaimed8/10

   Square has a dedicated 'Idempotency' documentation page and its agent-facing llms.txt explicitly states 'every write endpoint accepts an idempotency key' to prevent duplicate charges from retries. This directly matches the story's core requirement. Missing for 10: independent/hands-on developer confirmation of idempotency behavior under real network-failure retries, and more detail on key expiration/scope beyond the doc title.

   • [claimed-docs] “Idempotency”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”

   proof ↗⚑ flag

2. developerRely on signed webhook deliveries with automatic retries, event logs, and replay to keep my system consistent with payment state

   weight 3 · round to Square
   Adyen~partialclaimed4/10

   Adyen documents webhook event logs in the Customer Area (adyen-docs-45) and general webhook mechanics to avoid polling (adyen-docs-3/17), plus an MCP tool to 'test' webhooks (adyen-supp-mcp-tools) that hints at replay tooling. However, the evidence pack never explicitly documents HMAC/signature verification for webhook payloads, an automatic retry policy for failed webhook deliveries, or a dedicated replay mechanism. Missing for 10: explicit signed-webhook (HMAC) verification docs, documented automatic retry/backoff schedule for webhook delivery, and a concrete replay/redeliver feature beyond the vague MCP 'test' tool.

   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “To submit a request for idempotent processing, send a request with the `idempotency-key:` in the header.”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square documents webhook subscriptions and signature verification/validation of event notifications, plus mentions of webhook event logs in the dev tools, which covers signed delivery and basic observability. However, the evidence pack contains no explicit documentation of automatic retry behavior or an event replay mechanism, which are core parts of the story. missing for 10: documented automatic retry policy for failed webhook deliveries, explicit event replay/resend capability, independent confirmation of retry/replay behavior.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “[Verify and Validate an Event Notification](/docs/webhooks/step3validate)”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

Onboarding dx

1. developerIntegrate a working payment flow from the docs alone in under a day, with copy-paste examples in my language

   weight 2 · round to Square
   Adyen!disputedcontradicted4/10

   Adyen's docs describe a clear-looking integration path (single /sessions call or paymentMethods/payments/payments/details flow, testing, webhooks) and multi-platform SDK support (web, iOS, Android, React Native, Flutter), but no evidence pack item actually shows copy-paste code samples per language, and independent hands-on reports directly contradict the 'under a day' claim: one integrator says 'after hundreds of hours invested, we ditched Adyen' and another states 'Stripe beats Adyen on ease of integration... hands down,' while a third calls it 'much more bare metal' than turnkey competitors. A counter-report says the integration 'was not as terrible as many here make it seem,' so the picture is mixed rather than uniformly negative. missing for 10: actual copy-paste language-specific code samples in the evidence, a documented time-to-first-payment benchmark, and independent confirmation that integration is fast rather than the reported multi-hundred-hour effort.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Your server makes three Checkout API requests: /paymentMethods, /payments, and /payments/details.”
   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”
   • [community] “I implemented Adyen for a company I was consulting for. I liked it. Their integration was not as terrible as many here make it seem. It allo…”
   • [community] “Adyen is much more 'bare metal.' Think more like a modern Authorize.net. Nobody comes close to Stripe's turnkey developer-friendliness.”
   • [community] “Adyen's pricing model looks much more attractive on paper, but the integration complexity and minimum processing volumes usually keep early-…”

   proof ↗⚑ flag

   Square~partialclaimed6/10

   Square provides extensive first-party docs for card, ACH, Cash App, Afterpay payments, plus sandbox testing and idempotency guidance, and the Node.js/TypeScript SDK shows concrete copy-paste code (client.payments.create). This supports fast integration, but the evidence pack shows only one language's SDK example, no explicit 'under a day' quickstart guide, and no cross-language parity proof (Python, Java, PHP, etc.) or independent developer testimony confirming a same-day integration timeline. missing for 10: multi-language copy-paste examples, an explicit time-to-integrate quickstart, independent hands-on confirmation of a sub-day integration.

   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Idempotency”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [github] “const client = new SquareClient({ token: "YOUR_TOKEN" });”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “Square Sandbox”

   proof ↗⚑ flag

Sandbox fidelity

1. developerBuild and test the entire payment flow in a sandbox or test mode that mirrors production, with test cards for every scenario including declines and disputes

   weight 3 · round to Square
   Adyen~partialcommunity6/10

   Adyen documents a dedicated test environment with test credentials for exercising different transaction types (adyen-docs-18), recommends testing the full client+server integration before going live (adyen-docs-6), and documents refusal reasons/result codes for simulating declines (adyen-docs-7). However, the pack lacks explicit documentation of test cards for disputes/chargebacks specifically, or a catalog of scenario-specific test cards, and community evidence notes real-world integration friction (adyen-comm-9) though not specifically about sandbox fidelity. Missing for 10: explicit dispute/chargeback simulation test cards, a documented full test-card matrix, and independent hands-on confirmation that sandbox mirrors production behavior.

   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Test the different types of transactions with Adyen that your integration handles using test credentials.”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”

   proof ↗⚑ flag

   Square✓fullclaimed7/10

   Square documents a dedicated Sandbox environment (square-docs-21, square-docs-40) with Sandbox Payments docs, sandbox-specific dispute testing (square-docs-16), and an API Explorer that lets developers run requests against actual Sandbox or production resources (square-docs-48, square-supp-api-explorer), covering the core sandbox/test-mode workflow for payments and disputes. missing for 10: explicit enumeration of test card numbers for every decline/dispute scenario and independent developer corroboration that the sandbox fully mirrors production edge cases.

   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Square Sandbox”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”
   • [claimed-docs] “API Explorer lets you test your requests using actual Sandbox or production resources in your account such as customers, orders, and catalog…”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

Ai disputes

1. ai-native userHave an agent handle a dispute end-to-end, retrieving it, assembling evidence, and submitting the response via the API

   weight 3 · round to Square
   Adyen—none0/10

   The evidence pack contains no mention of a Disputes API, chargeback evidence submission, or any agent/MCP workflow for handling disputes end-to-end—only risk/fraud detection (Protect), refusal reasons, and unrelated agentic-commerce checkout flows are documented. The MCP server's tool list (sessions, payment links, modifications, management API) explicitly does not include dispute retrieval or evidence submission.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “You can detect, monitor, and mitigate fraud using Protect, Adyen's risk management system.”
   • [claimed-docs] “Each payment goes through a risk evaluation. The risk evaluation reaches a decision that results in an action to block, allow, or review the…”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square publishes a Disputes API (retrieve disputes, process them, sandbox testing) and its MCP server's service catalog explicitly includes 'disputes' alongside a generic make_api_request tool, so an agent could plausibly retrieve a dispute and call dispute-related endpoints programmatically. However, there is no documented evidence-assembly workflow (e.g., specific evidence-submission endpoint, required evidence fields) or any hands-on/community example of an agent completing a dispute end-to-end via the API or MCP. missing for 10: explicit evidence-submission API details, a demonstrated end-to-end agent workflow, and independent confirmation the MCP disputes tools work as claimed.

   • [claimed-docs] “[Process Disputes](/docs/disputes-api/process-disputes)”
   • [claimed-docs] “Disputes API”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”

   proof ↗⚑ flag

Disputes

1. finance-ops userRespond to a chargeback with structured evidence and track the dispute lifecycle to resolution

   weight 3 · round to Square
   Adyen—none0/10

   The evidence pack covers Adyen's risk/fraud tooling (Protect, rule builder, ML fraud detection) but contains no documentation of a chargeback/dispute management API, structured evidence submission, or dispute lifecycle tracking/status workflow. A vague community comment says Stripe beats Adyen on chargebacks 'hands down' but gives no concrete detail to substantiate a documented-capability failure, so it doesn't rise to a disputed claim — it simply reinforces the absence of positive evidence.

   ⚑ flag

   Square~partialclaimed6/10

   Square documents a dedicated Disputes API with a 'Process Disputes' guide and sandbox testing support, indicating sellers/developers can submit evidence and interact with dispute records programmatically. However, the evidence pack lacks detail on structured evidence-submission fields, dispute status/lifecycle event types, or webhook notifications specific to dispute state changes, and marketing copy suggests Square often manages the dispute process on the seller's behalf rather than the user actively tracking it end-to-end. Missing for 10: detailed evidence-field schema, dispute status/lifecycle event documentation, and independent confirmation of end-to-end resolution tracking.

   • [claimed-docs] “[Process Disputes](/docs/disputes-api/process-disputes)”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”
   • [claimed-docs] “Disputes API”
   • [claimed-docs] “With no chargeback fees, we save you money and time by managing the credit card dispute process for you.”

   proof ↗⚑ flag

Fraud prevention

1. finance-ops userScreen transactions with machine-learning fraud scores and write custom block, review, and allow rules

   weight 3 · round to Adyen
   Adyen✓fullclaimed8/10

   Adyen's Protect risk management system explicitly provides ML-based fraud scoring plus a rule builder to create, backtest, and label custom rules, with risk evaluations resulting in block/allow/review actions — directly matching the story. Missing for 10: independent/hands-on validation of the rule builder UX and finance-ops-specific workflow evidence beyond first-party docs.

   • [claimed-docs] “You can detect, monitor, and mitigate fraud using Protect, Adyen's risk management system.”
   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”
   • [claimed-docs] “Each payment goes through a risk evaluation. The risk evaluation reaches a decision that results in an action to block, allow, or review the…”
   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square's marketing docs explicitly claim ML-based fraud blocking and custom rules and alerts to manage risk, matching the story's core ask, but this is a single marketing page with no API or developer documentation detailing how block, review, and allow rules are configured or how fraud scores are surfaced to finance-ops users. missing for 10: developer-facing API/dashboard docs for configuring block vs review vs allow rules, detail on the fraud-score output format, independent or hands-on corroboration of the ML scoring and rule engine.

   • [claimed-docs] “Prevent loss online. Get insights into payment fraud patterns, and set custom rules and alerts to manage risk.”
   • [claimed-docs] “Square uses sophisticated machine learning to spot and block payment fraud at no extra cost.”

   proof ↗⚑ flag

Refunds

1. finance-ops userIssue full or partial refunds from both the dashboard and the API

   weight 3 · round to Square
   Adyen~partialclaimed5/10

   Evidence confirms API-level refund capability (Adyen's Management/Checkout 'modifications' API allows refunding a captured payment, and the MCP tool set explicitly includes 'refund a captured payment') and dashboard access to transaction management via the Customer Area, but no citation explicitly confirms partial-refund amount support or a documented dashboard refund button/workflow. missing for 10: explicit documentation of partial refund support (specifying an amount less than the captured total), explicit dashboard refund action screenshot/flow, and any independent/hands-on confirmation that refunds work as described.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”

   proof ↗⚑ flag

   Square~partialclaimed7/10

   Square documents a dedicated Refunds API supporting both linked and unlinked refunds (full/partial refunds for existing or off-platform payments), which covers the API side, and the dashboard is implied via the broader Square seller product but not explicitly documented for refund issuance in the evidence pack. missing for 10: explicit dashboard UI documentation/screenshots showing refund issuance from the Seller Dashboard, and confirmation of partial-amount refund support in docs text.

   • [claimed-docs] “[Refund Payments](/docs/payments-api/refund-payments)”
   • [claimed-docs] “[Process an Unlinked Refund](/docs/refunds-api/unlinked-refunds)”
   • [claimed-docs] “Refund Payments”

   proof ↗⚑ flag

Multi currency

1. founderCharge customers in their local currencies and settle to my bank in mine with transparent FX handling

   weight 2 · round to Adyen
   Adyen~partialclaimed7/10

   Adyen documents accepting local payment methods/currencies, configuring multiple payout currencies per merchant account, and both local (no SWIFT fee) and cross-border (SWIFT) settlement options, plus flexible payout timing/currency choice — directly supporting charge-local/settle-in-own-currency workflows. However, there's no explicit documentation of FX rate transparency (e.g., disclosed markup, real-time rate reporting) beyond the currency/payout mechanics themselves. Missing for 10: explicit FX rate/markup transparency documentation, independent confirmation of settlement FX handling in practice.

   • [claimed-docs] “Local payouts are faster and avoid SWIFT fees. You need a local bank account in a country that uses that specific currency as the legal tend…”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “This means you have the option to change how you get paid for each of your merchant accounts.”

   proof ↗⚑ flag

   Square—none0/10

   The evidence pack contains no mention of multi-currency charging, FX conversion, or cross-currency settlement anywhere in Square's docs, GraphQL/REST APIs, MCP server, or payments pages — all payment method docs (cards, ACH, Afterpay, Cash App) are silent on currency handling. This is a fair axis for a payments platform, so absence of evidence yields none rather than na.

   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “[ACH Bank Transfer Payment](/docs/payments-api/take-payments/ach-payments)”
   • [claimed-docs] “[Afterpay and Clearpay Payments](/docs/payments-api/take-payments/afterpay-payments)”
   • [claimed-docs] “[Cash App Payments](/docs/payments-api/take-payments/cash-app-payments)”
   • [claimed-docs] “Payouts API”
   • [claimed-docs] “Take payments in person and online. Securely save recurring payment methods. Easily sync sales, inventory, and customer data with your Squ…”

   proof ↗⚑ flag

Tax

1. finance-ops userCalculate and collect the correct sales tax, VAT, or GST on every transaction automatically

   weight 3 · round drawn
   Adyen—none0/10

   Adyen's evidence pack is entirely about payment processing, payouts, platforms, risk management, and agentic-commerce integrations — nothing addresses tax calculation, VAT/GST determination, tax collection, or tax compliance/remittance features. This axis applies since a payments platform could plausibly integrate tax calculation, but no evidence shows Adyen offers this.

   ⚑ flag

   Square—none0/10

   The evidence pack covers payments, refunds, disputes, webhooks, invoices, and MCP tooling but contains no mention of tax calculation, tax rates, VAT/GST handling, or automated tax collection features.

   ⚑ flag

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

   weight 2 · round to Square
   Adyen~partialprobed5/10

   Adyen exposes extensive Management/Checkout/Platforms APIs covering payments, onboarding, payouts, webhooks, credentials, terminals, and even an MCP server wrapping many of these APIs, suggesting broad API/UI parity for core payment operations. However, some UI-only surfaces (Customer Area account/transaction overview, visual reporting dashboards) are described only as UI features with no explicit statement that every dashboard/report/action is also API-accessible, and no full OpenAPI spec was reachable at standard docs endpoints (404s), only a separate GitHub repo. Missing for 10: explicit parity claim or evidence that all Customer Area/reporting/dashboard actions have API equivalents, and a verified complete OpenAPI coverage confirmation.

   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “You can also create multiple API credentials to improve security and control access.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”

   proof ↗⚑ flag

   Square~partialclaimed7/10

   Square's developer platform exposes an extensive set of APIs (payments, refunds, disputes, invoices, subscriptions, payouts, webhooks, OAuth, GraphQL, catalog/customers/orders/inventory/labor) plus an MCP server giving 'programmatic access to everything the APIs offer', suggesting broad UI/API parity for core commerce and back-office functions. However, some UI-only surfaces (e.g., the in-product Square AI seller assistant, POS idle-screen customization, dashboard reporting UI) are not shown to have full API equivalents, and there is no explicit vendor or independent claim of 100% UI-API parity. missing for 10: an explicit parity statement or audit confirming every UI feature (e.g., Square AI insights, POS-specific dashboard views) is fully API-accessible, and independent/hands-on verification of edge-case coverage.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “Invoices API”
   • [claimed-docs] “Subscriptions API”
   • [claimed-docs] “Disputes API”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “One GraphQL query can retrieve data that requires multiple Square API calls.”
   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Adyen—none0/10

   The evidence pack shows reporting dashboards and general documentation transparency (llms.txt, markdown docs, OpenAPI specs) but nothing about a merchant being able to export their own transactional/account data in open formats or close their account and leave without lock-in. Reporting is described as visual dashboards (adyen-docs-10), not bulk open-format export, and no data-portability/account-closure mechanism is documented.

   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”

   proof ↗⚑ flag

   Square—none0/10

   Square's docs describe extensive APIs to create/read individual objects (payments, customers, orders, catalog) and even an MCP/GraphQL layer, but there is no evidence of a bulk data-export feature, standard open-format export (CSV/JSON dump), or documented account-closure/data-portability process letting a user take all their data and leave.

   ⚑ flag

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

   weight 2 · round to Adyen
   Adyen~partialclaimed3/10

   Adyen's core payment-processing platform is closed, proprietary SaaS with no evidence of the underlying service source being published under any license. However, evidence shows genuinely open-source ancillary components: the Adyen MCP server (github.com/Adyen/adyen-mcp) and the OpenAPI specification repo (github.com/Adyen/adyen-openapi) described as 'the single source of truth for our APIs,' both publicly viewable on GitHub. Missing for 10: any open license on the actual platform/service code, no stated license type for the repos, no independent confirmation of license terms, and no indication the core product itself is inspectable beyond API specs and a thin MCP client tool.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”

   proof ↗⚑ flag

   Square—none0/10

   Square is a closed-source SaaS payments platform; the evidence only shows open-source client SDKs (square-nodejs-sdk) and an MCP server wrapper on GitHub, not the core product/platform source under an open license. No documentation states Square's actual service code is open-sourced or licensed for public reading.

   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “npx square-mcp-server start”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”

   proof ↗⚑ flag

Ai reconciliation

1. ai-native userHave an agent pull payout and balance-transaction data via the API and reconcile each bank deposit to its underlying charges

   weight 3 · round to Square
   Adyen—none0/10

   The evidence pack describes payouts, payout frequency, currencies, and a dashboard 'visual representation' of balances/payouts (adyen-docs-9,10,12,30,43), but nowhere documents an API for pulling balance/transaction-level data or a reconciliation workflow that an agent could invoke — the MCP tool list (adyen-supp-mcp-tools) covers checkout, payment links, and management API objects (merchants, terminals, webhooks, credentials) with no balance-transaction or reconciliation tools. Missing for 10: documented Balance/Transaction API endpoints, evidence of agent/MCP access to payout reconciliation data, and any reconciliation workflow example.

   • [claimed-docs] “Adyen supports paying out to cards instantly, and immediately returns the result of the payout attempt.”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square has a documented Payouts API and API access (via SDK, MCP server, GraphQL, webhooks) that an agent could use to pull payout and balance-transaction data programmatically, and payments/refunds/disputes APIs provide the underlying charge data needed for reconciliation. However, there is no direct evidence of a balance-transactions endpoint equivalent to Stripe's, nor documentation showing how payout line items map to underlying charges/fees for reconciliation workflows. missing for 10: explicit balance-transaction/payout-entries API detail, worked reconciliation example or docs linking deposits to charges, independent/hands-on confirmation of this specific workflow.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “One GraphQL query can retrieve data that requires multiple Square API calls.”
   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”

   proof ↗⚑ flag

Payouts

1. finance-ops userControl the payout schedule and see exactly which charges, fees, and refunds make up each payout

   weight 2 · round to Adyen
   Adyen~partialclaimed6/10

   Docs clearly support configuring payout frequency, currency, and timing per merchant account (adyen-docs-12, adyen-docs-30, adyen-docs-50, adyen-docs-22) and note local vs cross-border payout mechanics (adyen-docs-13, adyen-docs-43). Reporting is mentioned as giving a 'visual representation of balances, sales, and payouts' (adyen-docs-10) and the Customer Area gives an overview of payment channels (adyen-docs-16), but there is no explicit evidence of a line-item payout reconciliation report breaking down which specific charges, fees, and refunds compose each payout. Missing for 10: detailed payout reconciliation report/API showing per-payout transaction breakdown, fee itemization, and refund matching.

   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “This means you have the option to change how you get paid for each of your merchant accounts.”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “Local payouts are faster and avoid SWIFT fees. You need a local bank account in a country that uses that specific currency as the legal tend…”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”

   proof ↗⚑ flag

   Square~partialclaimed4/10

   Square exposes a Payouts API (square-docs-17) which presumably supports payout schedule and reconciliation data, but the evidence pack gives no detail on schedule controls (e.g., daily/weekly/manual), nor on how payouts break down into constituent charges, fees, and refunds. missing for 10: documentation of payout schedule configuration options, payout entries/line-item breakdown by charge/fee/refund, and any independent/hands-on confirmation of reconciliation accuracy.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “[Refund Payments](/docs/payments-api/refund-payments)”
   • [claimed-docs] “[Process an Unlinked Refund](/docs/refunds-api/unlinked-refunds)”

   proof ↗⚑ flag

Reconciliation

1. finance-ops userReconcile settlements to bank deposits with itemized reports covering fees, refunds, and chargebacks

   weight 3 · round to Square
   Adyen~partialclaimed3/10

   Adyen's reporting docs mention a dashboard 'visual representation of your balances, sales, and payouts' and configurable payout frequency/currency, implying some settlement reporting exists, but nothing in the evidence describes itemized reconciliation reports that break out fees, refunds, and chargebacks against bank deposits. Missing for 10: documented settlement/reconciliation report format, explicit fee/refund/chargeback itemization, and any bank-deposit matching workflow or independent confirmation it works as needed.

   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”

   proof ↗⚑ flag

   Square~partialclaimed5/10

   Square provides a Payouts API for settlement data and separate Refunds and Disputes APIs, plus marketing copy about seeing 'all your sales in one report' to reduce reconciliation effort, but there's no dedicated documentation showing an itemized report that ties bank deposits to fees, refunds, and chargebacks in one place. missing for 10: explicit itemized payout/settlement report schema breaking down fees, refunds, chargebacks; documentation linking payout amounts directly to bank deposit records; independent confirmation from finance-ops users that reconciliation works end-to-end.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “[Refund Payments](/docs/payments-api/refund-payments)”
   • [claimed-docs] “[Process Disputes](/docs/disputes-api/process-disputes)”
   • [claimed-docs] “See all your sales in one report. Spend less time reconciling data across payment systems and more time optimizing sales based on your real-…”

   proof ↗⚑ flag

Marketplace

1. developerBuild a marketplace or platform that onboards sellers, splits payments between parties, and pays out to each seller

   weight 2 · round to Adyen
   Adyen✓fullclaimed8/10

   Adyen for Platforms is explicitly documented to onboard sellers/contractors with verification (adyen-docs-11, adyen-docs-31, adyen-docs-36), split payments between parties and hold funds until payout (adyen-docs-21, adyen-docs-37), and configure flexible payout frequency/currency/local vs cross-border payouts (adyen-docs-12, adyen-docs-13, adyen-docs-22, adyen-docs-43, adyen-docs-50). Reporting/dashboards and risk management further round out the marketplace platform story (adyen-docs-10, adyen-docs-8). missing for 10: independent/hands-on developer account of building a full marketplace integration end-to-end, and more granular API-level detail (e.g., specific split-payment API request/response schemas) beyond docs summaries.

   • [claimed-docs] “Onboard sellers, service providers, or contractors on to your platform, and let Adyen verify them before paying out.”
   • [claimed-docs] “Process payments: accept payments on behalf of your users using Adyen's payment processing platform. You can split the payments between one …”
   • [claimed-docs] “Onboard sellers, service providers, or contractors on to your platform, and let Adyen verify them before paying out. Adyen informs you of th…”
   • [claimed-docs] “Onboard and verify your users: onboard sellers, service providers, or contractors on to your platform, and let Adyen verify them before payi…”
   • [claimed-docs] “You can split the payments between one or more users, deduct costs as needed, and hold funds until payout.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Local payouts are faster and avoid SWIFT fees. You need a local bank account in a country that uses that specific currency as the legal tend…”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”
   • [claimed-docs] “Allow your users to easily sign up, sell, and receive payments all within one solution.”
   • [claimed-docs] “This means you have the option to change how you get paid for each of your merchant accounts.”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”

   proof ↗⚑ flag

   Square~partialclaimed6/10

   Square provides the core building blocks for a marketplace: OAuth to onboard sellers to their own Square accounts (square-docs-42, square-docs-51), the OAuth access-token scope model (square-supp-oauth-scopes), Payments API with 'Collect Application Fees' for platform fee splitting (square-docs-37), and a Payouts API for disbursing funds to sellers (square-docs-17). However, the evidence never documents a unified 'split payment across multiple parties in one transaction' primitive or destination-account payout routing akin to Stripe Connect transfers—application fees and payouts appear as separate mechanisms rather than an integrated marketplace split-and-payout flow, and there's no dedicated marketplace/platform guide or case study. missing for 10: explicit multi-party split-payment/transfer API documentation, an end-to-end marketplace onboarding+split+payout guide, and independent/hands-on validation that this pattern works in production.

   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”
   • [claimed-docs] “multi-tenant applications that serve multiple sellers should use OAuth access tokens”
   • [claimed-docs] “Square access is scope-controlled: "Access tokens are credentials that allow applications to securely interact with Square APIs. An access t…”
   • [claimed-docs] “Collect Application Fees”
   • [claimed-docs] “Payouts API”
   • [claimed-docs] “For custom integrations that only access your own Square account, personal access tokens are suitable for production use.”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Adyen—none0/10

   The evidence pack contains no mention of data residency, regional data storage options, or any control over where Adyen stores payment/customer data. While this is a fair question for a payments platform (compliance/data-residency is a common enterprise requirement), nothing in the docs, community posts, or agentic-commerce material addresses it.

   ⚑ flag

   Square—none0/10

   No evidence in the pack mentions data residency, regional data storage options, or geographic control over where Square account/API data is stored; the pack covers payments features, MCP/AI tooling, and dev tools but never addresses data residency.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Adyen—none0/10

   Adyen's evidence pack covers payments, payouts, risk management, and agentic commerce integrations, but there is no documentation on data retention policies, data deletion requests, or user/API-level controls to manage how long payment or transaction data is stored or how to purge it. This is a fair axis for a payments platform handling PII/PCI data, but no evidence addresses it.

   ⚑ flag

   Square—none0/10

   No evidence in the pack addresses data retention policies, data deletion capabilities, or privacy controls for AI/MCP interactions with Square data. While OAuth scopes and access-token controls are documented, nothing speaks to retaining or deleting data collected via AI tools or the MCP server.

   ⚑ flag