Square vs Adyen In-Person Payments

Onboarding

1. founderSign up, get approved, and order hardware from the dashboard so I am taking in-person payments the same week

   weight 3 · round to Square
   Square~partialcommunity4/10

   Evidence confirms Square lets sellers accept in-person payments quickly via Tap to Pay on iPhone (no extra hardware needed) and references a dashboard ('Switch to Square', location management) and community commentary that hardware complements the merchant-services core, but there's no concrete evidence of the sign-up/approval workflow, hardware ordering process from the dashboard, or a documented same-week timeline. missing for 10: explicit onboarding/approval flow details, evidence of ordering hardware directly from the dashboard, confirmation of same-week turnaround.

   • [claimed-docs] “Accept contactless cards, Apple Pay, and other digital wallets in person with Tap to Pay on iPhone.”
   • [claimed-docs] “Switch to Square”
   • [claimed-docs] “Manage orders from one place”
   • [community] “The hardware is almost a gimmick to push what is otherwise a potentially powerful service. Individuals are now empowered to take credit card…”
   • [community] “You're 100% correct. Hardware is cool, but the merchant services side is what makes Square awesome.”

   proof ↗⚑ flag

   Adyen In-Person Payments!disputedcontradicted5/10

   Docs show hardware can be ordered via the Management API or Customer Area (adyen-pos-docs-11, adyen-pos-docs-3, adyen-pos-docs-25) and Adyen offers a standalone terminal option for fast setup (adyen-pos-docs-4), but there is no evidence on signup/approval timelines, and a hands-on community report describes hundreds of hours spent integrating card-present/POS before ultimately abandoning Adyen (adyen-pos-comm-1), directly contradicting a 'same week' onboarding claim. missing for 10: evidence of signup/approval speed, independent confirmation that hardware ordering and go-live actually happens within a week, resolution of the contradicting integration-time complaint.

   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”
   • [claimed-docs] “If you do not need a fully featured API integration, and want the quickest way to accept in-person payments, we also offer a standalone term…”
   • [claimed-docs] “Get started fast with a full range of PCI PTS 6 certified terminals. They stay up and running, even when the internet is down.”
   • [community] “Adyen had a better story for omni-channel commerce with card present, but they made us integrate with COM. COM! Apparently they have card pr…”

   proof ↗⚑ flag

Payment methods

1. merchant-ops userAccept chip, contactless, and mobile-wallet (Apple Pay / Google Pay) payments in person

   weight 3 · round drawn
   Square✓fullcommunity8/10

   Square's docs explicitly document Tap to Pay on iPhone for accepting contactless cards, Apple Pay, and other digital wallets in person, plus Terminal API support for tip collection at checkout, and Mobile Payments SDK for chip/contactless via hardware readers. Community commentary corroborates real-world merchant use of Square hardware for in-person card acceptance. Missing for 10: explicit mention of Google Pay support in-person and independent hands-on verification of contactless/chip reliability beyond older magstripe-era anecdotes.

   • [claimed-docs] “Accept contactless cards, Apple Pay, and other digital wallets in person with Tap to Pay on iPhone.”
   • [claimed-docs] “Tap to Pay on iPhone”
   • [claimed-docs] “Mobile Payments SDK”
   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [community] “The hardware is almost a gimmick to push what is otherwise a potentially powerful service. Individuals are now empowered to take credit card…”
   • [community] “You're 100% correct. Hardware is cool, but the merchant services side is what makes Square awesome.”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullclaimed8/10

   Adyen's POS docs explicitly cover chip/contactless via certified terminals, Tap to Pay on iPhone for contactless mobile acceptance, and global/local payment methods including wallets; PCI PTS certified terminals and offline resilience are documented. missing for 10: explicit named support for Apple Pay/Google Pay wallet acceptance at the terminal (only 'global and local payment methods' is generic) and independent hands-on validation beyond one negative community integration anecdote unrelated to this core capability.

   • [claimed-docs] “With our Tap to Pay on iPhone solution you can accept contactless in-person payments using an iPhone as the payment interface, and process t…”
   • [claimed-docs] “Tap to Pay. Turn compatible smartphones or tablets into Tap to Pay checkouts. No extra hardware required.”
   • [claimed-docs] “Get started fast with a full range of PCI PTS 6 certified terminals. They stay up and running, even when the internet is down.”
   • [claimed-docs] “Lets you choose from a wide range of fully-certified and PCI-compliant Adyen payment terminals.”
   • [claimed-docs] “Enables you to accept global and local payment methods.”
   • [claimed-docs] “When there is a temporary loss of internet connectivity, you can continue making point-of-sale payments if offline payments have been enable…”

   proof ↗⚑ flag

2. merchant-ops userSplit a single sale across multiple payment methods or payers

   weight 2 · round drawn
   Square—none0/10

   No evidence pack item mentions split tender, splitting a sale across multiple payment methods, or splitting a bill among multiple payers; docs focus on single payment creation, catalog, inventory, and other unrelated APIs.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   No evidence pack item addresses split-tender/split-payment functionality (splitting a single sale across multiple payment methods or multiple payers) — coverage exists for refunds, tipping, offline payments, currency options, etc., but nothing on split payments. There is also a negative community anecdote about omnichannel card-present integration difficulty, but it does not concretely address split-tender capability either.

   ⚑ flag

Tap to pay

1. founderAccept contactless card payments on an off-the-shelf phone (Tap to Pay) without buying a reader

   weight 3 · round drawn
   Square✓fullclaimed8/10

   Square explicitly documents Tap to Pay on iPhone, allowing contactless card and digital wallet payments directly on an off-the-shelf iPhone without additional reader hardware, both on the consumer marketing page and developer SDK docs. Missing for 10: independent hands-on confirmation/review of Tap to Pay working reliably, and no mention of Android tap-to-pay support.

   • [claimed-docs] “Accept contactless cards, Apple Pay, and other digital wallets in person with Tap to Pay on iPhone.”
   • [claimed-docs] “Tap to Pay on iPhone”
   • [claimed-docs] “Mobile Payments SDK”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullclaimed8/10

   Adyen explicitly documents Tap to Pay on iPhone, letting merchants accept contactless payments directly on an iPhone as the payment interface with no extra hardware, and marketing material confirms 'No extra hardware required' for compatible smartphones/tablets. Missing for 10: independent/hands-on confirmation of the founder-scale onboarding experience and Android Tap to Pay coverage details.

   • [claimed-docs] “With our Tap to Pay on iPhone solution you can accept contactless in-person payments using an iPhone as the payment interface, and process t…”
   • [claimed-docs] “Tap to Pay. Turn compatible smartphones or tablets into Tap to Pay checkouts. No extra hardware required.”

   proof ↗⚑ flag

Tipping

1. merchant-ops userConfigure tipping prompts (percentages, smart amounts, custom tips) collected on the reader or terminal

   weight 2 · round drawn
   Square~partialclaimed6/10

   Square's Terminal API explicitly documents tip collection with a separate tip screen and custom tip amounts on the reader/terminal (square-docs-26), which directly supports the story's core need. However, evidence is developer-API-focused rather than showing merchant-ops-friendly configuration (e.g., no direct mention of preset percentage options or 'smart tip amounts' UI, nor Dashboard-level tipping settings). missing for 10: explicit smart/percentage tip presets configuration, merchant-facing Dashboard UI evidence, and independent/hands-on confirmation of the tipping prompt experience.

   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed6/10

   Adyen docs confirm tipping is supported via terminal/POS app/receipt, and that a tip amount can be suggested by the POS app for the customer to accept, change, or decline on the terminal (adyen-pos-docs-26, adyen-pos-docs-30, adyen-pos-docs-9). However, the evidence never details merchant-ops-configurable smart-tip percentage tiers or custom-amount prompt configuration UI—only that tip amounts are set in the payment request. Missing for 10: explicit documentation of percentage-based smart tipping configuration, custom tip entry flows, and merchant-ops-facing configuration tools (vs. developer-set tip amounts).

   • [claimed-docs] “There are various ways to implement tipping ('gratuity').”
   • [claimed-docs] “you add a tip amount to the payment request that you send from your POS app. The customer then accepts, changes, or declines the suggested t…”
   • [claimed-docs] “There are various ways to implement tipping ('gratuity'). These are your options: Tipping from the POS app... Tipping from the terminal... T…”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   Square✓fullprobed9/10

   Square hosts a working llms.txt at developer.squareup.com/llms.txt (HTTP 200, confirmed by probe) and an llms-full.txt with detailed doc content, directly enabling agents to consume agent-oriented docs. Missing for 10: no independent/community confirmation of agents actually using it, and openapi/docs.md alternatives return 404.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.squareup.com/llms.txt # Square Developer Platform > Square APIs and SDKs for accepting paymen…”
   • [claimed-docs] “Nested modifiers let one selection reveal the next, so the buyer answers a sequence of questions instead of reading o”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullprobed9/10

   Probe evidence confirms a live llms.txt at docs.adyen.com/llms.txt (HTTP 200) plus .md-formatted agent-friendly docs (e.g. point-of-sale.md returning 200), directly satisfying the story of pointing an agent at llms.txt/agent-oriented docs; there's also a documented MCP server as further agentic tooling. Missing for 10: independent third-party confirmation of an agent successfully consuming these docs in practice.

   • [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/point-of-sale.md --- title: "In-person payments" description: "Accept payments at the poin…”
   • [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] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round to Square
   Square~partialclaimed6/10

   Square exposes a full REST API with official SDKs (e.g., Node/TypeScript client) that let developers create payments, manage catalog/inventory/orders programmatically, and a dedicated Sandbox environment for testing outside the Dashboard UI — all of which support scripted/automated, non-interactive use suitable for CI pipelines. However, there is no explicit documentation of CI/CD integration, GitHub Actions examples, or headless deployment guidance. missing for 10: explicit CI/CD or headless automation documentation, examples of running SDK calls in an automated pipeline.

   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “You probably want to just use one of the clients that are pre-built in a language of your choice”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed4/10

   Adyen's Terminal/Management APIs are JSON/HTTP based and programmatic, and a basic testing system exists to simulate transactions for integration testing without live hardware, which could support scripted/automated pipelines. However there is no explicit documentation of running the product headlessly in CI, no CLI, and the core product still relies on physical terminals for real transactions. Missing for 10: explicit CI/headless automation guidance, a documented CLI or SDK for scripted runs, and evidence of automated test suites beyond manual simulation.

   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “We provide a basic testing system to simulate transaction scenarios and functionalities.”
   • [claimed-docs] “We provide a basic testing system to simulate transaction scenarios and functionalities. You can use this system to ensure your test integra…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Square✓fullprobed8/10

   Square documents an official 'Square Model Context Protocol Server' with dedicated docs, and this is independently confirmed by a probe hitting that URL directly. Missing for 10: independent/hands-on community corroboration of the MCP server working in practice and deeper docs detail on setup/capabilities.

   • [claimed-docs] “Square Model Context Protocol Server”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullprobed8/10

   Adyen documents an official MCP server that lets developers/agents interact with Adyen's platform using natural language via an LLM client, confirmed both in docs and a dedicated probe. Missing for 10: independent/hands-on community corroboration of the MCP server's real-world reliability and integration depth.

   • [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] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Square—none0/10

   No evidence in the pack mentions an official Square CLI; the docs reference SDKs, APIs, sandbox, and an MCP server but nothing about a command-line tool for developers or AI-native workflows.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   Adyen is a payments platform; the evidence shows an MCP server, APIs, and OpenAPI spec but no mention of an official CLI tool for AI-native or any workflow. This axis applies (a payments platform could plausibly ship a CLI) but no evidence supports it.

   ⚑ flag

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

   weight 3 · round drawn
   Square✓fullprobed8/10

   Square provides an extensive, well-documented public REST API with catalog, inventory, orders, payments, webhooks, sandbox testing, and official SDKs (e.g., TypeScript SDK), plus an llms.txt for AI discoverability and even a dedicated MCP server for agentic access. This clearly enables AI-native users to programmatically drive the product. Missing for 10: a publicly discoverable OpenAPI/swagger spec (probe returned 404s) and independent hands-on developer corroboration beyond official docs.

   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Build eCommerce applications to help sellers manage key aspects of their business.”
   • [claimed-docs] “Design a Catalog”
   • [claimed-docs] “Inventory API”
   • [claimed-docs] “Create Orders”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “Square Model Context Protocol Server”
   • [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…”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullprobed8/10

   Adyen documents a full public Terminal API and Management API using JSON messages, provides an official OpenAPI specification repository (adyen-pos-gh-1), and ships an MCP server enabling natural-language/AI-native interaction with the platform (adyen-pos-docs-13, adyen-pos-docs-20, adyen-pos-probe-4). Extensive docs cover payments, refunds, webhooks, disputes, and testing, all API-driven. Missing for 10: a discoverable machine-readable OpenAPI endpoint directly under docs.adyen.com (probe found 404s) and independent hands-on confirmation beyond one dated negative community anecdote about a legacy integration path.

   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [github] “This repository contains Adyen API definition files, represented in the OpenAPI Specification standard”
   • [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] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”
   • [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

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

   weight 2 · round drawn
   Square—none0/10

   The evidence pack documents Square's APIs, SDKs, sandbox testing, and an MCP server, but contains no mention of OAuth scopes, restricted/scoped API keys, or any mechanism for issuing least-privilege credentials specifically for an AI agent. This axis is fair for an API platform like Square, but no evidence supports it.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   No evidence of scoped/least-privilege API credential issuance for agents; docs mention general API keys, Customer Area management, and an MCP server for natural-language access, but nothing about granular/scoped credential minting or per-agent permission scoping.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square provides official SDKs across multiple languages (e.g., TypeScript/Node.js SDK on GitHub) with documented usage examples, plus a broad developer platform with sandbox testing and multiple pre-built client libraries referenced in official docs. Missing for 10: independent third-party validation of SDK quality/reliability beyond GitHub repo, and broader multi-language SDK evidence (only TypeScript repo cited explicitly).

   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “You probably want to just use one of the clients that are pre-built in a language of your choice”
   • [claimed-docs] “The Connect Examples are working sample applications that you can copy from to build your own.”
   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “Mobile Payments SDK”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence shows only an OpenAPI spec repo (adyen-openapi) and JSON-based Terminal/Management APIs; one doc even states integration works 'without the need for libraries,' and no official language SDKs (Java, Node, Python, etc.) are documented for AI-native building. Missing for 10: explicit official SDK libraries, SDK docs/quickstarts, and any AI-native SDK tooling beyond the separate MCP server.

   • [claimed-docs] “This communicates using JSON messages, without the need for libraries, making integrating quicker and simpler than a traditional point-of-sa…”
   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [github] “This repository contains Adyen API definition files, represented in the OpenAPI Specification standard”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square Webhooks documentation ([square-docs-12]) provides an official subscription mechanism for events (payments, orders, disputes, etc.), and sandbox testing support ([square-docs-13]) exists for validating webhook subscriptions. missing for 10: independent/hands-on corroboration of webhook reliability and no explicit mention of event filtering/retry semantics in the evidence pack.

   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullclaimed7/10

   Adyen documents webhooks explicitly for asynchronous status updates, letting integrators subscribe to events instead of polling, which applies to POS/payment outcomes. Missing for 10: POS-specific webhook event catalog/payload examples and independent/community confirmation of webhook reliability in POS context.

   • [claimed-docs] “Webhooks solve this by sending you a message with the final outcome as soon as it is available.”
   • [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

Agentic features

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

   weight 2 · round drawn
   Square—none0/10

   Evidence shows Square as a payments/commerce platform with APIs, dashboards, and an MCP server for developer integration, but nothing indicates Square itself surfaces AI-generated insights or suggestions from a seller's data inside its product. missing for 10: any documentation of built-in AI analytics, insight dashboards, or suggestion features within Square's product surface.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   Evidence covers payment terminal integration, refunds, tipping, offline payments, and an MCP server for developers to build with natural language—but nothing shows AI-generated insights or suggestions surfaced from merchant transaction/sales data inside the product itself.

   ⚑ flag

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

   weight 2 · round to Square
   Square~partialprobed3/10

   Square exposes webhooks and an MCP server that could let an AI agent trigger or observe events and act autonomously, but there's no documented native 'automation builder' or scheduled/background workflow feature in Square itself — it only provides raw APIs/events for developers to wire up their own automations. Missing for 10: evidence of a first-party automation/workflow engine, scheduling or trigger-action system, and confirmation that MCP server actions can run unattended in the background.

   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Square Model Context Protocol Server”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   Adyen POS is a payments API/terminal platform; there is no evidence of a feature allowing autonomous background automations to run (e.g. scheduled or event-triggered agent workflows). Webhooks and MCP server enable integration/event notification, but nothing describes autonomous background automation setup as a product capability. Missing for full/partial: any documented automation builder, scheduler, or autonomous-agent workflow feature.

   ⚑ flag

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

   weight 3 · round drawn
   Square—none0/10

   Evidence shows Square offers an MCP server for external AI agents to call Square APIs (square-docs-14, square-probe-4), but this is the reverse of the story—no evidence of a built-in AI assistant inside Square's own product (Dashboard/POS) that users can delegate tasks to.

   • [claimed-docs] “Square Model Context Protocol Server”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   Adyen's evidence only shows an MCP server that lets external LLM clients connect to Adyen's platform via natural language (docs-13, docs-20, probe-4) — this is the reverse of a built-in assistant embedded in the product for task delegation. No evidence of an in-product AI assistant that users can delegate tasks to.

   • [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] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round to Adyen In-Person Payments
   Square~partialprobed4/10

   Square documents an official MCP server (square-docs-14, square-probe-4), which would let AI agents interact with Square's APIs via natural-language-driven tool calls, but there is no detailed documentation of the NL command set, no first-party or independent evidence of it working end-to-end, and no mention of a native chat/NL interface for merchants themselves. missing for 10: detailed MCP tool/command documentation, hands-on or independent verification of NL operation, evidence of a built-in conversational interface beyond the MCP server stub.

   • [claimed-docs] “Square Model Context Protocol Server”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialprobed5/10

   Adyen documents an official MCP server that lets developers 'use natural language with your chosen LLM client' to connect to Adyen's platform and build payment solutions faster, which supports agentic/natural-language interaction with Adyen's APIs (including POS-related endpoints). However, this is scoped to development/integration tasks rather than an end-user natural-language interface for operating in-person payments (terminals, transactions, refunds) directly. Missing for 10: evidence of natural-language control over live POS operations (transactions, terminal management, refunds) rather than just developer-side API/documentation querying, and any independent/hands-on validation of the MCP server's real-world use.

   • [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] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Square
   Square~partialprobed4/10

   Square provides a developer sandbox for testing API calls (square-docs-13) and 'Connect Examples' working sample apps (square-docs-29), plus SDKs with code snippets (square-gh-2), which give some runnable-example experience, but there is no evidence of an interactive API reference (e.g., Swagger/OpenAPI explorer) — probes show openapi.json/swagger.json all 404 (square-probe-3) and no docs.md (square-probe-2). missing for 10: a true interactive API explorer with live try-it-now requests, OpenAPI spec exposure, in-browser runnable examples tied directly to reference docs.

   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “The Connect Examples are working sample applications that you can copy from to build your own.”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [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”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   Evidence shows only static docs, an OpenAPI spec repo, and an MCP server, but no interactive API reference with runnable/try-it examples; probes for openapi.json/swagger explorer endpoints returned 404. Missing for 10: any evidence of an interactive 'try it' console or runnable code sandbox in the docs.

   • [github] “This repository contains Adyen API definition files, represented in the OpenAPI Specification standard”
   • [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] “This allows developers to use natural language to connect with Adyen's platform more easily and build new payment solutions faster.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square~partialprobed6/10

   Square maintains a public 'connect-api-specification' repo whose README explicitly discusses the API specification used to generate SDKs, implying a machine-readable spec is available for download, and the docs reference pre-built clients derived from it. However, direct probes of developer.squareup.com show no openapi.json/swagger.json endpoint (404s), so the spec isn't served in an obviously discoverable machine-readable format from the docs site itself. Missing for 10: a directly linked/downloadable OpenAPI file on the docs domain, and independent confirmation that the GitHub spec is kept current and complete.

   • [claimed-docs] “You probably want to just use one of the clients that are pre-built in a language of your choice”
   • [claimed-docs] “The Connect Examples are working sample applications that you can copy from to build your own.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialprobed6/10

   Adyen maintains an official GitHub repo of OpenAPI Specification files for its APIs (adyen-pos-gh-1), which is machine-readable and downloadable, but a live probe of the docs site found no standard hosted openapi.json/swagger.json endpoint (adyen-pos-probe-3), meaning access requires going to GitHub rather than a first-class docs-site download link. Missing for 10: a directly hosted/downloadable spec endpoint on docs.adyen.com, and explicit confirmation the GitHub spec covers the Terminal/POS API specifically.

   • [github] “This repository contains Adyen API definition files, represented in the OpenAPI Specification standard”
   • [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 Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”

   proof ↗⚑ flag

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

   weight 1 · round to Square
   Square✓fullclaimed8/10

   Square provides a dedicated Sandbox environment for testing APIs without touching production data, documented directly in developer docs [square-docs-13], plus SDKs/examples that support pointing to sandbox credentials/environment [square-gh-1][square-docs-19]. Missing for 10: independent hands-on confirmation of sandbox fidelity and no explicit mention of sandbox data reset/isolation guarantees.

   • [claimed-docs] “Test in Sandbox”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “You probably want to just use one of the clients that are pre-built in a language of your choice”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullclaimed7/10

   Adyen documents a dedicated test Customer Area with test cards and a 'basic testing system to simulate transaction scenarios' before switching to a live integration, explicitly separating sandbox from production data/transactions. Missing for 10: no independent/hands-on confirmation of sandbox fidelity or explicit data-isolation guarantees, and no AI-specific sandbox tooling beyond generic docs.

   • [claimed-docs] “Using the Adyen test card, you can: Test different card brands. Test different CVMs. Test declined payments.”
   • [claimed-docs] “You can order an Adyen test card from your test Customer Area... Using the Adyen test card, you can: Test different card brands. Test differ…”
   • [claimed-docs] “We provide a basic testing system to simulate transaction scenarios and functionalities.”
   • [claimed-docs] “We provide a basic testing system to simulate transaction scenarios and functionalities. You can use this system to ensure your test integra…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square—none0/10

   The evidence pack contains no documentation of API versioning scheme (e.g., Square-Version header) or a deprecation policy—only general API/SDK docs, sandbox testing, and webhooks are covered. Missing for 10: explicit versioning documentation, deprecation/EOL policy, changelog or migration guides.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence pack shows Adyen has OpenAPI definitions and extensive docs, but nowhere does it mention API version numbers or a documented deprecation/sunset policy for the Terminal API or Management API. Missing for 10: explicit versioning scheme documentation, deprecation/sunset policy, migration guides between API versions.

   • [github] “This repository contains Adyen API definition files, represented in the OpenAPI Specification standard”
   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square—none0/10

   The evidence shows Square's Catalog, Inventory, and Orders APIs exist, but nothing in the pack documents batch/bulk endpoints (e.g., bulk catalog upsert, bulk inventory adjustment) or any AI-native bulk-action tooling. Missing for 10: explicit bulk/batch API documentation, evidence of bulk operations across items, and any hands-on confirmation of such functionality.

   • [claimed-docs] “Design a Catalog”
   • [claimed-docs] “Inventory API”
   • [claimed-docs] “Create Orders”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence covers individual terminal/payment API operations (single refunds, single terminal orders, single transactions) but nowhere mentions batch/bulk endpoints for processing many items at once (e.g., bulk refunds, bulk terminal provisioning, batch transaction imports). This is a fair question for a payments/POS platform but no supporting evidence exists.

   ⚑ flag

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

   weight 3 · round to Square
   Square~partialclaimed5/10

   Square offers webhooks for event notification (square-docs-12) which could be paired with external automation tools to trigger actions on events, but there is no evidence of a native rules engine or built-in conditional automation ('when X happens, do Y') within Square itself. missing for 10: a documented native automation/rules builder, examples of event-triggered actions configured directly in Square, and independent confirmation of such workflows in practice.

   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed3/10

   Adyen provides webhooks that notify external systems of payment events, which developers can use to build their own automation, but there is no evidence of a native rules engine or UI where users define conditional triggers/actions within Adyen itself. Missing for 10: a documented rules/automation engine, conditional logic builder, or no-code trigger-action configuration; independent evidence of end-to-end automated workflows.

   • [claimed-docs] “Webhooks solve this by sending you a message with the final outcome as soon as it is available.”
   • [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

Receipts

1. merchant-ops userIssue digital (email/SMS) or printed receipts that meet card-network requirements

   weight 1 · round to Square
   Square~partialclaimed6/10

   Square's Locations API supports custom receipt text fields, and Terminal/Payments APIs are documented to generate digital receipts as part of transaction flows, indicating receipt issuance capability tied to card-network-compliant transactions. However, there is no explicit documentation confirming email/SMS receipt delivery mechanics or explicit card-network compliance requirements for receipt content. missing for 10: explicit docs on email/SMS receipt delivery flow, explicit statement of card-network receipt compliance requirements, independent/hands-on confirmation of receipt issuance working as described.

   • [claimed-docs] “A seller can customize the receipts issued for a location with two text fields. The `custom_receipt_text` field holds custom text that is pr…”
   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [claimed-docs] “Learn how to use a Square API to update and retrieve location information for a Square seller.”
   • [claimed-docs] “Sellers can review and edit location information in the Square Dashboard”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence pack covers POS integration, tipping, refunds, testing, and terminals but contains no mention of issuing digital (email/SMS) or printed receipts, nor any reference to card-network receipt requirements. Receipt generation is a standard POS capability, so this axis applies, but no evidence shows Adyen delivering it.

   ⚑ flag

Custom checkout

1. developerEmbed in-person payments into my own iOS or Android app with official mobile SDKs

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square documents a Mobile Payments SDK for iOS/Android plus Tap to Pay on iPhone and offline payments support, directly enabling developers to embed in-person payments into native mobile apps. missing for 10: independent third-party hands-on validation of the mobile SDK integration and Android-specific Tap to Pay parity details.

   • [claimed-docs] “Tap to Pay on iPhone”
   • [claimed-docs] “Mobile Payments SDK”
   • [claimed-docs] “Offline Payments”
   • [claimed-docs] “Accept contactless cards, Apple Pay, and other digital wallets in person with Tap to Pay on iPhone.”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed5/10

   Adyen documents a Tap to Pay on iPhone solution for embedding contactless in-person payments directly into an iOS app, but there is no evidence of an equivalent official Android SDK for in-app card-present payments — the pack only shows generic Terminal API/POS integration docs. missing for 10: official Android SDK/Tap to Pay for Android evidence, and independent developer corroboration of ease-of-integration for either platform.

   • [claimed-docs] “With our Tap to Pay on iPhone solution you can accept contactless in-person payments using an iPhone as the payment interface, and process t…”
   • [claimed-docs] “Tap to Pay. Turn compatible smartphones or tablets into Tap to Pay checkouts. No extra hardware required.”

   proof ↗⚑ flag

2. developerBuild a custom point-of-sale checkout that drives the terminal from my backend through a documented server-driven API

   weight 3 · round to Square
   Square✓fullprobed8/10

   Square's Terminal API is explicitly documented for driving Square hardware terminals from a backend (tip collection, signature screens, custom tip amounts), alongside the broader server-driven APIs (Orders, Payments, Catalog, Sandbox testing, webhooks) needed to build a custom checkout flow. Official SDKs (e.g., Node.js) further support server-driven integration. Missing for 10: no independent/hands-on developer report validating real-world Terminal API integration experience, and no public OpenAPI spec was found via probe.

   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Create Orders”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”
   • [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…”

   proof ↗⚑ flag

   Adyen In-Person Payments!disputedcontradicted6/10

   Adyen's docs clearly describe a server-driven Terminal API using JSON messages to make payments, refunds, tipping, and testing (adyen-pos-docs-17, -1, -9, -10, -12), which matches the story. However, a hands-on community report describes being forced into an older COM-based integration rather than the promised JSON-only flow, costing hundreds of hours before abandoning Adyen, directly contradicting the simplicity claim for at least some POS hardware/integration paths (adyen-pos-comm-1). missing for 10: independent corroboration that the JSON Terminal API works smoothly in practice across common POS hardware, and resolution of the COM-vs-JSON discrepancy.

   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [claimed-docs] “This communicates using JSON messages, without the need for libraries, making integrating quicker and simpler than a traditional point-of-sa…”
   • [claimed-docs] “There are various ways to implement tipping ('gratuity').”
   • [claimed-docs] “We offer two refund types: Referenced refund... Unreferenced refund...”
   • [claimed-docs] “Using the Adyen test card, you can: Test different card brands. Test different CVMs. Test declined payments.”
   • [community] “Adyen had a better story for omni-channel commerce with card present, but they made us integrate with COM. COM! Apparently they have card pr…”

   proof ↗⚑ flag

Payment events

1. developerSubscribe to payment lifecycle events (authorized, captured, refunded, disputed) via webhooks to drive downstream automations

   weight 2 · round drawn
   Square~partialclaimed6/10

   Square has documented webhooks (square-docs-12) and a dedicated Disputes API (square-docs-11), suggesting lifecycle events like disputes and payments can be subscribed to; sandbox testing is also documented (square-docs-13). However, evidence doesn't explicitly enumerate specific webhook event types (authorized, captured, refunded, disputed) or show sample payloads/subscription config details. missing for 10: explicit list of supported webhook event types, payload examples, independent/hands-on confirmation of reliability.

   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Process Disputes”
   • [claimed-docs] “Test in Sandbox”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed6/10

   Adyen's docs confirm webhooks exist to notify on asynchronous payment outcomes (avoiding polling) and a separate Disputes API lets you retrieve/manage dispute events, which together cover the core of this story. However, the evidence pack doesn't show the specific webhook event types (AUTHORISATION, CAPTURE, REFUND, DISPUTE) or subscription/configuration details for POS-specific transactions. Missing for 10: explicit list of supported webhook event types for POS transactions, configuration/subscription docs, and independent/hands-on confirmation that dispute or refund webhooks fire reliably in production.

   • [claimed-docs] “Webhooks solve this by sending you a message with the final outcome as soon as it is available.”
   • [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] “You can retrieve dispute information, defend or accept disputes, and upload defense documents.”

   proof ↗⚑ flag

Testing

1. developerTest my in-person integration end-to-end with a simulated reader or test card environment before going live

   weight 2 · round to Adyen In-Person Payments
   Square~partialclaimed5/10

   Square documents a general Sandbox for testing API calls (square-docs-13) and a Terminal API for in-person checkout flows like tip collection (square-docs-26), implying some pre-production testing path, but the evidence never explicitly describes a simulated card reader or test-card environment tailored to the in-person/Terminal API flow. missing for 10: explicit documentation of Terminal API sandbox/test reader behavior, sample test card numbers for in-person transactions, and independent developer confirmation that end-to-end in-person testing works before going live.

   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [claimed-docs] “Mobile Payments SDK”

   proof ↗⚑ flag

   Adyen In-Person Payments✓fullclaimed8/10

   Adyen docs explicitly describe a dedicated testing system for POS integrations with test cards to simulate card brands, CVMs, and declined payments, allowing developers to validate their integration before going live. This is well documented across multiple doc pages with clear intent (pre-production validation). Missing for 10: no independent/hands-on developer report confirming the simulator's fidelity or ease of use, and no detail on a fully simulated virtual reader (only physical test cards/terminals are described).

   • [claimed-docs] “Using the Adyen test card, you can: Test different card brands. Test different CVMs. Test declined payments.”
   • [claimed-docs] “You can order an Adyen test card from your test Customer Area... Using the Adyen test card, you can: Test different card brands. Test differ…”
   • [claimed-docs] “We provide a basic testing system to simulate transaction scenarios and functionalities.”
   • [claimed-docs] “We provide a basic testing system to simulate transaction scenarios and functionalities. You can use this system to ensure your test integra…”

   proof ↗⚑ flag

Disputes

1. ai-native userHave an agent monitor dispute deadlines via API or webhooks and draft evidence responses for my review

   weight 3 · round to Square
   Square~partialclaimed6/10

   Square's Disputes API and Webhooks docs (square-docs-11, square-docs-12) provide the building blocks for an agent to monitor dispute status/deadlines and submit evidence programmatically, and Square also documents an official MCP server (square-docs-14) that could expose these to an AI agent. However, there's no evidence of deadline-specific webhook events, evidence-drafting assistance, or any AI-native workflow purpose-built for this use case. Missing for 10: explicit deadline/expiration fields or events in the Disputes API, any documented AI-assisted evidence drafting feature, and independent confirmation of agents using this workflow.

   • [claimed-docs] “Process Disputes”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Square Model Context Protocol Server”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed5/10

   Adyen provides a Disputes API to retrieve dispute information, defend/accept disputes, and upload defense documents, plus general webhook infrastructure for async status changes, which an agent could poll or subscribe to for building dispute workflows. However, there's no evidence of dispute-deadline-specific webhook events, deadline tracking, or any AI-assisted evidence-drafting capability. missing for 10: dispute-deadline webhook events, automated evidence-response drafting/generation feature, explicit deadline field/tracking in the API.

   • [claimed-docs] “You can retrieve dispute information, defend or accept disputes, and upload defense documents.”
   • [claimed-docs] “Webhooks solve this by sending you a message with the final outcome as soon as it is available.”
   • [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

2. merchant-ops userGet notified of chargebacks and submit dispute evidence before the deadline

   weight 2 · round drawn
   Square~partialclaimed6/10

   Square has a dedicated Disputes API (square-docs-11) for retrieving dispute details and submitting evidence, and Webhooks (square-docs-12) that can notify merchants of new disputes/chargebacks. However, evidence lacks detail on deadline tracking/reminders or Dashboard-native notification workflows, and there's no independent confirmation of the evidence-submission UX working end-to-end. Missing for 10: explicit deadline-reminder mechanism, Dashboard notification UI details, hands-on/independent validation of the dispute submission flow.

   • [claimed-docs] “Process Disputes”
   • [claimed-docs] “Square Webhooks”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed6/10

   Adyen's Disputes API explicitly supports retrieving dispute information, defending or accepting disputes, and uploading defense documents, which covers the core dispute-evidence submission workflow. However, evidence does not confirm merchant-ops notification mechanisms (e.g., dashboard alerts or automated deadline reminders) specific to chargebacks, though generic webhooks exist that could plausibly relay dispute events. missing for 10: explicit documentation of chargeback notification/alerting to merchant-ops users, deadline-tracking UI, and independent/hands-on confirmation of the dispute workflow in practice.

   • [claimed-docs] “You can retrieve dispute information, defend or accept disputes, and upload defense documents.”
   • [claimed-docs] “Webhooks solve this by sending you a message with the final outcome as soon as it is available.”
   • [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

Refunds

1. merchant-ops userIssue full or partial refunds back to the original card from the point of sale, dashboard, or API

   weight 2 · round to Adyen In-Person Payments
   Square—none0/10

   The evidence pack covers payments creation, disputes, catalog, inventory, and other APIs but contains no documentation or reference to a Refunds API, POS refund flow, or dashboard refund capability. Since Square is a payments platform, refund support is a plausible and expected axis, but no evidence in the pack confirms it.

   ⚑ flag

   Adyen In-Person Payments✓fullclaimed8/10

   Docs confirm refunds via Terminal API (referenced and unreferenced refunds to original card), via Customer Area dashboard, and via API integration, covering POS, dashboard, and API channels for full/partial amounts. missing for 10: no independent/hands-on corroboration of refund success, and no explicit confirmation that partial refund amounts are supported (only 'any amount' language for unreferenced refunds).

   • [claimed-docs] “We offer two refund types: Referenced refund... Unreferenced refund...”
   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [claimed-docs] “You can also issue refunds from your Customer Area”
   • [claimed-docs] “We offer two refund types: Referenced refund... Unreferenced refund... Unreferenced refunds let you return any amount to any card presented …”

   proof ↗⚑ flag

Ai fleet ops

1. ai-native userHave an agent provision a new location end-to-end via API — creating the location and registering its readers

   weight 3 · round drawn
   Square~partialclaimed4/10

   Square's Locations API supports creating new locations programmatically (square-docs-9, square-docs-24), and there's a broad API/SDK ecosystem (square-gh-1, square-docs-3) an agent could drive. However, no evidence in the pack shows an API for registering/provisioning physical readers (e.g., a Devices API or reader pairing endpoint) — Terminal API only covers checkout flows on already-paired devices (square-docs-26). Missing for 10: reader/device registration API documentation, end-to-end example combining location creation with reader provisioning, and any hands-on confirmation of this workflow.

   • [claimed-docs] “Learn how to use a Square API to update and retrieve location information for a Square seller.”
   • [claimed-docs] “Newly created accounts only have this single location, but more locations can be created.”
   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed4/10

   Adyen's Management API explicitly supports ordering/registering terminals via API calls instead of the Customer Area (adyen-pos-docs-11), which covers the reader-registration half of the story, and general API-first architecture is documented (adyen-pos-docs-1, adyen-pos-docs-2). However, no evidence describes an API endpoint or workflow for creating/provisioning a new physical 'location' object itself — location management is only shown via the Customer Area UI (adyen-pos-docs-3), not agent-drivable API. missing for 10: explicit API endpoint/documentation for creating a location object, end-to-end example combining location creation + reader registration in one automated flow.

   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”
   • [claimed-docs] “This communicates using JSON messages, without the need for libraries, making integrating quicker and simpler than a traditional point-of-sa…”
   • [claimed-docs] “You can integrate using the same architecture as your existing POS system, whether this communicates over a local network, or over the cloud…”

   proof ↗⚑ flag

Fleet api

1. developerManage a fleet of readers and terminals via API — register devices, monitor status, and update configuration remotely

   weight 3 · round to Adyen In-Person Payments
   Square—none0/10

   The pack shows Square has physical hardware (Terminal API for payments, Tap to Pay) but no evidence of a device-fleet management API for registering devices, monitoring status, or remotely updating terminal/reader configuration — the only terminal-related doc (square-docs-26) covers payment/tip flows, not fleet administration.

   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed3/10

   Adyen docs mention a Management API for ordering terminals via API (adyen-pos-docs-11) and a unified Customer Area for managing terminals (adyen-pos-docs-3), which touches part of the fleet-management story, but there is no evidence of API-based device registration, status monitoring, or remote configuration updates. missing for 10: API endpoints for registering devices, retrieving/monitoring device status, and remotely updating terminal configuration; independent/hands-on confirmation of these capabilities.

   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”

   proof ↗⚑ flag

Multi location

1. merchant-ops userRun multiple locations with per-location devices, settings, and reporting

   weight 2 · round drawn
   Square~partialclaimed6/10

   Square's Locations API confirms merchants can create and manage multiple locations, each with its own settings (e.g., custom receipt text) editable via the Dashboard or API, and location data can be retrieved/updated per-location. However, there's no explicit evidence of per-location device fleet management or per-location reporting dashboards beyond the basic Locations API. missing for 10: dedicated per-location device provisioning/management docs, per-location reporting/analytics evidence.

   • [claimed-docs] “Learn how to use a Square API to update and retrieve location information for a Square seller.”
   • [claimed-docs] “Sellers can review and edit location information in the Square Dashboard”
   • [claimed-docs] “Newly created accounts only have this single location, but more locations can be created.”
   • [claimed-docs] “A seller can customize the receipts issued for a location with two text fields. The `custom_receipt_text` field holds custom text that is pr…”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed6/10

   Adyen's docs show fleet-friendly capabilities: a unified Customer Area to manage terminals and transactions across sites, a Management API to order terminals for delivery to specific locations, and per-merchant-account payout settings, which together support multi-location device management. However, there is no explicit documentation of per-location reporting dashboards or location-specific configuration granularity beyond terminal ordering and merchant-account-level settings. missing for 10: explicit per-location reporting/analytics views, granular per-location settings management beyond account-level payout config, and independent/hands-on validation of multi-site operations at scale.

   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”
   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “you have the option to change how you get paid for each of your merchant accounts”
   • [claimed-docs] “Lets you choose from a wide range of fully-certified and PCI-compliant Adyen payment terminals.”

   proof ↗⚑ flag

Readers

1. merchant-ops userPair a card reader with the POS app or register it to my account and take a payment within minutes

   weight 2 · round to Square
   Square~partialcommunity6/10

   Square documents multiple ways to accept in-person payments (Tap to Pay on iPhone, Terminal API for hardware readers, general 'process payments on Square hardware' claims) and community comments corroborate that Square's card-reader hardware (magstripe/audio-jack, later Terminal) enables fast in-person checkout. However, there is no explicit evidence pack content describing the actual pairing/registration flow (Bluetooth pairing, account registration steps, time-to-first-payment) for a physical reader with the POS app. Missing for 10: explicit reader pairing/setup documentation, hands-on time-to-payment confirmation, and independent verification of ease of registering a reader to an account.

   • [claimed-docs] “Accept contactless cards, Apple Pay, and other digital wallets in person with Tap to Pay on iPhone.”
   • [claimed-docs] “Tap to Pay on iPhone”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [community] “And they say innovation is dead in the U.S. Using the audio jack to read credit cards, brilliant.”
   • [community] “The hardware is almost a gimmick to push what is otherwise a potentially powerful service. Individuals are now empowered to take credit card…”
   • [community] “Faster, which is not a trivial thing at all if you've got a line of potential customers... there's additional data on the magstripe that pro…”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialcommunity4/10

   Docs describe ordering/managing terminals via Customer Area or Management API, standalone terminal setup, and Terminal API integration for POS apps, implying setup is possible, but there is no evidence of an actual quick-pairing/registration flow or a documented 'minutes to first payment' onboarding experience; a community anecdote also describes hundreds of hours spent integrating card-present readers before abandoning Adyen. missing for 10: concrete pairing/registration UX steps, time-to-first-payment evidence, independent hands-on confirmation that setup is fast, and resolution of the contradicting community integration-pain report.

   • [claimed-docs] “If you do not need a fully featured API integration, and want the quickest way to accept in-person payments, we also offer a standalone term…”
   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”
   • [claimed-docs] “Lets you choose from a wide range of fully-certified and PCI-compliant Adyen payment terminals.”
   • [community] “Adyen had a better story for omni-channel commerce with card present, but they made us integrate with COM. COM! Apparently they have card pr…”

   proof ↗⚑ flag

Offline

1. merchant-ops userKeep taking card payments when the internet drops, with transactions stored and forwarded when connectivity returns

   weight 2 · round to Adyen In-Person Payments
   Square~partialclaimed5/10

   Square's Mobile Payments SDK documents an explicit 'Offline Payments' feature for Android that stores transactions locally and forwards them when connectivity returns, directly matching the story; however this is documented only for the Android SDK path, not confirmed for the core POS app/hardware terminals broadly, and there's no independent/hands-on corroboration of reliability in practice. missing for 10: confirmation offline mode applies across Square's main POS app/hardware (not just Android SDK integrations), details on transaction limits/risk holds during offline queuing, and independent verification of real-world behavior.

   • [claimed-docs] “Offline Payments”
   • [claimed-docs] “Mobile Payments SDK”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed6/10

   Adyen's docs explicitly confirm offline payment support ('when there is a temporary loss of internet connectivity, you can continue making point-of-sale payments if offline payments have been enabled') and marketing claims terminals 'stay up and running, even when the internet is down.' However, evidence lacks detail on store-and-forward mechanics, limits/risk controls during offline mode, or independent hands-on confirmation of reliability. missing for 10: technical detail on transaction queuing/forwarding limits, risk/fraud handling for offline auth, and independent verification of real-world offline resilience.

   • [claimed-docs] “When there is a temporary loss of internet connectivity, you can continue making point-of-sale payments if offline payments have been enable…”
   • [claimed-docs] “Get started fast with a full range of PCI PTS 6 certified terminals. They stay up and running, even when the internet is down.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square~partialclaimed6/10

   Square exposes extensive APIs for payments, catalog, inventory, orders, locations, disputes, payouts, webhooks, and team management (square-docs-3,6,7,8,9,10,11,12,17,25), suggesting broad API/UI parity, but there is no explicit statement or independent audit confirming that every UI feature (e.g., dashboard customization, marketing/engagement tools, reporting views) is fully mirrored via API. missing for 10: explicit parity claim or audit, coverage of marketing/engagement and reporting UI features, independent verification of completeness.

   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Build eCommerce applications to help sellers manage key aspects of their business.”
   • [claimed-docs] “Design a Catalog”
   • [claimed-docs] “Inventory API”
   • [claimed-docs] “Learn how to use a Square API to update and retrieve location information for a Square seller.”
   • [claimed-docs] “Create Orders”
   • [claimed-docs] “Process Disputes”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Enable team management with scheduling, timecards, and payro”
   • [claimed-docs] “List Payouts”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialcommunity6/10

   Adyen documents strong API coverage for core in-person payment actions (Terminal API for payments/refunds/tipping, Management API for ordering terminals 'instead of the Customer Area', Disputes API for dispute management) plus an official MCP server for natural-language/agent access, showing broad but not exhaustive UI-API parity. However, some functions (e.g., unified Customer Area terminal/transaction management, some refund flows) are explicitly still done via UI, and a community report describes friction requiring non-JSON integration work, undercutting a claim of full parity. Missing for 10: explicit vendor statement of complete UI/API feature parity, independent verification that every Customer Area action has an API equivalent.

   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”
   • [claimed-docs] “The Management API lets you order terminals and accessories for delivery to a location of your choice using API requests instead of the Cust…”
   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [claimed-docs] “You can retrieve dispute information, defend or accept disputes, and upload defense documents.”
   • [claimed-docs] “You can also issue refunds from your Customer Area”
   • [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] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [community] “Adyen had a better story for omni-channel commerce with card present, but they made us integrate with COM. COM! Apparently they have card pr…”

   proof ↗⚑ flag

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

   weight 3 · round to Square
   Square~partialclaimed4/10

   Square exposes JSON-based APIs for catalog, inventory, orders, locations, and payouts data (square-docs-7,8,9,10,25), which technically allows a user to programmatically extract much of their business data in an open format, but there is no documented single 'export all my data and leave' feature, no bulk account-export tool, and no GDPR-style full data dump mentioned anywhere in the evidence. Missing for 10: a dedicated full-account data export tool, explicit open-format bulk export (e.g., CSV/JSON dump of entire account), and confirmation that all data types (customer engagement, team/payroll, disputes) are exportable via API.

   • [claimed-docs] “Design a Catalog”
   • [claimed-docs] “Inventory API”
   • [claimed-docs] “Learn how to use a Square API to update and retrieve location information for a Square seller.”
   • [claimed-docs] “Create Orders”
   • [claimed-docs] “List Payouts”
   • [claimed-docs] “Manage customer data securely and keep customers coming back with engagement programs.”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   No evidence of a data export feature or open-format data portability for merchants leaving Adyen; documentation covers APIs, terminals, tipping, refunds, MCP server, but nothing about exporting transaction/customer data in open formats or account offboarding processes.

   ⚑ flag

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

   weight 2 · round drawn
   Square—none0/10

   Square is a closed-source SaaS payments platform; only thin client SDK wrappers (e.g., square-nodejs-sdk) are open source on GitHub, not the actual product/service source code. No evidence indicates the core platform, backend, or application logic is available under any open license.

   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “You probably want to just use one of the clients that are pre-built in a language of your choice”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   Adyen In-Person Payments is a closed commercial payments platform; the only public repo cited (adyen-openapi) contains API definition files, not the product's actual source code, and no evidence indicates any open-license release of the underlying software.

   • [github] “This repository contains Adyen API definition files, represented in the OpenAPI Specification standard”

   proof ↗⚑ flag

Payouts

1. founderSee when each payout lands and speed it up (next-day or instant) when I need the cash

   weight 2 · round to Square
   Square~partialclaimed4/10

   Square's Payouts API (list-payouts) lets a business see payout records, and 'Manage your cash flow' hints at cash-flow visibility, but the evidence pack has no documentation of an instant or next-day payout acceleration option that a founder could trigger. Missing for 10: explicit instant/next-day payout feature docs, UI/dashboard evidence of speeding up a payout, and any confirmation of fees/timing for expedited payouts.

   • [claimed-docs] “List Payouts”
   • [claimed-docs] “Manage your cash flow”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence pack only vaguely mentions that merchants can 'change how you get paid' (adyen-pos-docs-22), with no documentation of payout timing visibility, payout status tracking, or an option to expedite payouts to next-day/instant. No dashboard, API, or docs evidence describes seeing payout schedules or triggering faster payouts.

   • [claimed-docs] “you have the option to change how you get paid for each of your merchant accounts”

   proof ↗⚑ flag

Reconciliation

1. ai-native userHave an agent pull transactions and payouts via API and reconcile daily takings into my ledger

   weight 3 · round to Square
   Square✓fullprobed7/10

   Square documents a Payouts API (list-payouts) and Payments/Orders APIs accessible via SDKs, plus webhooks for transaction events and a sandbox for testing, all of which an agent could use to pull transactions/payouts. Square also ships an official MCP server, letting an AI agent programmatically query these APIs, directly supporting agent-driven reconciliation workflows. Missing for 10: explicit dedicated 'transactions' endpoint documentation, a built-in reconciliation/ledger feature, and independent hands-on evidence of an agent actually performing daily reconciliation.

   • [claimed-docs] “List Payouts”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “Square Model Context Protocol Server”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialprobed4/10

   Adyen exposes APIs for terminal payments, refunds, disputes, and a getting-paid/payout settings endpoint, plus webhooks and an MCP server that could let an agent pull transaction data via natural language, but there is no documented payouts/transactions reporting API or reconciliation report endpoint (e.g. Balance Platform/Reporting API) evidenced here, and no example of an agent actually reconciling daily takings into a ledger. missing for 10: dedicated payouts/settlement reporting API evidence, reconciliation report/ledger-matching documentation, and a concrete example of an agent workflow pulling transactions+payouts and reconciling them.

   • [claimed-docs] “you have the option to change how you get paid for each of your merchant accounts”
   • [claimed-docs] “You can retrieve dispute information, defend or accept disputes, and upload defense documents.”
   • [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] “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”

   proof ↗⚑ flag

2. merchant-ops userReconcile daily takings against payouts with itemized transaction and fee reports

   weight 2 · round to Square
   Square~partialclaimed5/10

   Square provides a Payouts API (List Payouts) and dashboard-level cash flow management, giving a starting point for reconciling payouts, but there is no evidence of itemized fee breakdowns, transaction-to-payout matching reports, or a dedicated reconciliation report tool. missing for 10: itemized fee reporting API/docs, dashboard reconciliation report walkthrough, independent/hands-on confirmation of reconciling takings vs payouts.

   • [claimed-docs] “List Payouts”
   • [claimed-docs] “Manage your cash flow”

   proof ↗⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence pack shows only payout-method configuration (docs-22) and dispute handling (docs-23), but nothing about itemized transaction/fee reports or a reconciliation workflow tying daily takings to payouts. Missing for 10: settlement/reconciliation reports, itemized fee breakdowns, payout-to-transaction matching tools or reports API evidence.

   • [claimed-docs] “you have the option to change how you get paid for each of your merchant accounts”
   • [claimed-docs] “You can retrieve dispute information, defend or accept disputes, and upload defense documents.”

   proof ↗⚑ flag

Pci

1. developerKeep my PCI scope minimal because card data is captured end-to-end by certified readers and vendor systems, with vendor guidance on my remaining obligations

   weight 2 · round to Adyen In-Person Payments
   Square~partialclaimed5/10

   Square's SDK uses tokenized sourceId (never raw card numbers) in payment creation calls, and certified hardware/Tap to Pay readers capture card data directly, both of which structurally reduce a developer's PCI exposure. However, the evidence pack contains no explicit PCI-DSS documentation, SAQ level guidance, or statement of the developer's remaining compliance obligations. Missing for 10: explicit PCI compliance/SAQ documentation, vendor statements on residual merchant obligations, and any certification details (e.g., PCI-validated P2PE) tied to the readers.

   • [claimed-docs] “Accept contactless cards, Apple Pay, and other digital wallets in person with Tap to Pay on iPhone.”
   • [claimed-docs] “Tap to Pay on iPhone”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “Mobile Payments SDK”

   proof ↗⚑ flag

   Adyen In-Person Payments~partialclaimed6/10

   Docs confirm Adyen terminals are PCI PTS/PCI-compliant certified and capture card data via the Terminal API, supporting reduced PCI scope for card-present integrations, but there is no explicit vendor guidance document addressing the developer's residual PCI-DSS obligations (e.g., SAQ type, cardholder-data handling responsibilities) beyond terminal certification. missing for 10: explicit documentation of remaining PCI-DSS obligations/SAQ guidance for the integrating developer, independent audit confirmation of scope reduction.

   • [claimed-docs] “Get started fast with a full range of PCI PTS 6 certified terminals. They stay up and running, even when the internet is down.”
   • [claimed-docs] “Lets you choose from a wide range of fully-certified and PCI-compliant Adyen payment terminals.”
   • [claimed-docs] “The Adyen Terminal API lets you make payments, issue refunds, collect shopper information, and perform other shopper-terminal interactions u…”
   • [claimed-docs] “Lets you manage your payment terminals and transactions from our unified Customer Area.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square—none0/10

   No evidence pack items mention data residency, region selection, or storage location options for Square merchant/customer data; all evidence concerns payments, catalog, inventory, and MCP features. Missing for 10: any documentation of regional data centers, data residency controls, or storage location choice.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   No evidence in the pack discusses data residency, regional data storage options, or configurable region controls for Adyen's payment/data processing; the docs cover POS features, terminals, refunds, and MCP but not residency choices.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Square—none0/10

   No evidence in the pack addresses AI training data usage, opt-out controls, or privacy policy language about model training for Square products; this is an applicable axis for any data-handling platform but no supporting documentation exists.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   No evidence in the pack addresses AI training data usage or opt-out controls for Adyen In-Person Payments; the documentation focuses on POS integration, payments, and an MCP server, not AI model training data policies.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Square—none0/10

   No evidence pack items address data retention policies, deletion controls, or AI-native data lifecycle management; docs focus on payments, catalog, inventory, and MCP server access but not privacy/retention controls.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   The evidence pack covers POS integration, terminals, refunds, tipping, testing, and MCP server for natural-language API access, but contains no mention of data retention controls, deletion policies, or privacy/data lifecycle management features for an AI-native user. Missing for 10: any documentation of data retention settings, deletion APIs/workflows, or privacy controls relevant to AI agent usage.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Square—none0/10

   No evidence in the pack addresses telemetry opt-out or usage tracking controls for AI-native users; the documentation covers payments, APIs, and MCP server but nothing about privacy/telemetry settings. Missing for 10: any telemetry disclosure, opt-out mechanism, or privacy policy documentation addressing AI usage tracking.

   ⚑ flag

   Adyen In-Person Payments—none0/10

   Adyen In-Person Payments is a payment terminal/API product; there is no mention anywhere in the evidence of a telemetry/usage-tracking opt-out mechanism for AI-native or any users, despite the axis being plausible for a developer platform with docs, SDKs, and an MCP server.

   ⚑ flag