SumUp 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 Adyen In-Person Payments
   SumUp—none0/10

   The evidence pack is entirely developer-API documentation (checkouts, SDKs, MCP servers, cloud API, refunds) and pricing claims; it contains no evidence about the merchant signup/approval workflow or ordering hardware from a dashboard, which is the core of this founder-onboarding story.

   ⚑ 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
   SumUp✓fullclaimed8/10

   SumUp's docs explicitly describe in-person acceptance of card payments via physical readers (chip/contactless via Solo/Go readers, Cloud API) and Tap to Pay for direct contactless acceptance on a compatible phone, covering chip, contactless, and mobile-wallet-capable in-person flows. Missing for 10: explicit named confirmation of Apple Pay/Google Pay wallet support specifically (only 'contactless' and 'mobile-wallet' terminals generically referenced) and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Tap to Pay lets merchants accept in-person contactless payments directly on a compatible phone without carrying a separate card reader.”
   • [claimed-docs] “SumUp's in-person payment products let you accept card payments face-to-face using physical card readers or Tap to Pay on a mobile device.”
   • [claimed-docs] “The Cloud API lets you start a transaction from a Point of Sale (POS) running on any platform (Windows, iOS, Linux, Android, Web-based, etc.…”
   • [claimed-docs] “Trigger and manage payments on Solo or Go readers via HTTPS requests.”
   • [claimed-docs] “Embed payment acceptance directly in your Android or iOS app. Your app controls the reader over Bluetooth or uses Tap to Pay.”

   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
   SumUp—none0/10

   No evidence anywhere in the docs describes splitting a single sale across multiple payment methods or multiple payers — checkouts, refunds, terminal payments, and offline flows are all described as single-payer/single-method transactions. This is a plausible axis for a payments product but SumUp's evidence pack shows no split-tender or split-payment capability.

   ⚑ 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
   SumUp✓fullclaimed8/10

   SumUp's docs explicitly describe Tap to Pay: accepting in-person contactless payments directly on a compatible phone without a separate card reader, embedded in the merchant's app. Missing for 10: independent hands-on confirmation of the founder-facing app experience and specifics on supported phone models/onboarding steps.

   • [claimed-docs] “Tap to Pay lets merchants accept in-person contactless payments directly on a compatible phone without carrying a separate card reader.”
   • [claimed-docs] “SumUp's in-person payment products let you accept card payments face-to-face using physical card readers or Tap to Pay on a mobile device.”
   • [claimed-docs] “Embed payment acceptance directly in your Android or iOS app. Your app controls the reader over Bluetooth or uses Tap to Pay.”

   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 to Adyen In-Person Payments
   SumUp—none0/10

   The evidence pack covers checkout creation, terminal payment integrations, refunds, webhooks, offline transactions, and MCP/agent tooling, but nowhere mentions tipping prompts, tip percentages, smart tip amounts, or custom tip configuration on readers/terminals. This is a plausible feature for a payments platform's reader/terminal product, so the axis applies, but there is no supporting evidence at all.

   ⚑ 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
   SumUp✓fullprobed9/10

   SumUp explicitly publishes llms.txt/llms-small.txt (verified live by probe) plus a dedicated agent-oriented docs section describing Markdown-accessible docs, an MCP server, and an Agent Toolkit for LangChain/AI SDK/OpenAI Agents SDK, directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: independent/community confirmation of an agent actually consuming llms.txt successfully.

   • [claimed-docs] “You can access all of our documentation as plain text Markdown files by adding index.md to the end of any URL.”
   • [claimed-docs] “Give coding assistants current SumUp documentation and tools.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.sumup.com/llms.txt # SumUp Developer ## Documentation Sets - [Abridged documentation](https:…”
   • [claimed-docs] “Use the SumUp MCP server to connect MCP-compatible clients and AI assistants to SumUp APIs and documentation tools.”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”

   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 SumUp
   SumUp~partialclaimed5/10

   SumUp provides a Node.js SDK (works in headless runtimes like Node 18+, Cloudflare Workers), static API keys for programmatic access, and sandbox accounts with test cards to simulate payment flows—together enabling scripted, non-interactive automation suitable for CI-like testing. However, there is no explicit CI/CD documentation, headless test runner, or automation pipeline example, and webhooks are limited to checkout status only, limiting full automation of end-to-end flows. Missing for 10: explicit CI/CD integration guide, documented automated test suite/harness, broader event webhooks beyond checkout status.

   • [claimed-docs] “SumUp provides sandbox merchant accounts and a comprehensive set of test cards to simulate various payment scenarios, including different 3D…”
   • [claimed-docs] “The @sumup/sdk package wraps SumUp API, ships TypeScript declarations, and works in modern JavaScript runtimes and platforms”
   • [claimed-docs] “API keys are static credentials that let your application act on behalf of the merchant account that created the key.”
   • [claimed-docs] “The `@sumup/sdk` package wraps SumUp API, ships TypeScript declarations, and works in modern JavaScript runtimes and platforms, including No…”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”

   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
   SumUp✓fullprobed8/10

   SumUp documents an official managed MCP server at https://mcp.sumup.com/mcp that lets MCP clients manage accounts, create checkouts, and process payments, corroborated by an independent probe confirming the docs page. Missing for 10: independent hands-on third-party test of the MCP server actually working, and details on auth/setup limitations.

   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “Use the SumUp MCP server to connect MCP-compatible clients and AI assistants to SumUp APIs and documentation tools.”
   • [claimed-docs] “This endpoint allows your MCP client to interact with SumUp APIs to manage your account, create checkouts, or process payments using Cloud A…”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [probe] “official MCP server documented at https://developer.sumup.com/tools/llms/mcp-server”

   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 userDrive the product through a documented public API

   weight 3 · round drawn
   SumUp✓fullprobed8/10

   SumUp publishes extensive developer documentation covering checkout creation, refunds, webhooks, terminal Cloud API, and JS/TS SDKs, with sandbox testing support and API-key auth, and an independent developer confirms building on the public API in production. This clearly satisfies a documented, drivable public API for AI-native or programmatic use. missing for 10: a formal machine-readable OpenAPI/Swagger spec (probe shows 404s for standard OpenAPI endpoints), broader independent hands-on confirmation beyond one anecdote.

   • [claimed-docs] “Create and verify a checkout with a sandbox merchant account.”
   • [claimed-docs] “const checkout = await client.checkouts.create({ amount: 2500, checkout_reference: "ORDER-1001", currency: "EUR"”
   • [claimed-docs] “API keys are static credentials that let your application act on behalf of the merchant account that created the key.”
   • [claimed-docs] “SumUp provides sandbox merchant accounts and a comprehensive set of test cards to simulate various payment scenarios, including different 3D…”
   • [claimed-docs] “The @sumup/sdk package wraps SumUp API, ships TypeScript declarations, and works in modern JavaScript runtimes and platforms”
   • [claimed-docs] “In this guide, you will learn how to refund a transaction... Option A: Make a full refund... Option B: Make a partial refund”
   • [community] “Developer built low-cost receipt printer integration for SumUp by hacking the system through SumUp's public API rather than communicating wi…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.sumup.com/openapi.json, https://developer.sumup.com/swagger.json, https://develope…”

   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

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

   weight 2 · round drawn
   SumUp—none0/10

   SumUp docs describe API keys as static, account-wide credentials ('act on behalf of the merchant account that created the key') with no mention of scopes, permissions, or least-privilege options for agents or sub-credentials. No evidence of OAuth scopes, restricted-permission keys, or agent-specific credential issuance.

   • [claimed-docs] “API keys are static credentials that let your application act on behalf of the merchant account that created the key.”

   proof ↗⚑ 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

6. ai-native userBuild against official SDKs

   weight 2 · round to SumUp
   SumUp✓fullprobed8/10

   SumUp offers an official JavaScript SDK (@sumup/sdk) with TypeScript declarations for modern runtimes, plus an official Agent Toolkit adding SumUp tools to LangChain, AI SDK, OpenAI Agents SDK, and MCP, and a managed MCP server for AI clients. This directly supports building against official SDKs in an AI-native/agentic context. Missing for 10: independent/hands-on developer corroboration of the SDK or agent toolkit in practice, and broader multi-language SDK coverage beyond JavaScript.

   • [claimed-docs] “The @sumup/sdk package wraps SumUp API, ships TypeScript declarations, and works in modern JavaScript runtimes and platforms”
   • [claimed-docs] “The `@sumup/sdk` package wraps SumUp API, ships TypeScript declarations, and works in modern JavaScript runtimes and platforms, including No…”
   • [claimed-docs] “The SumUp Agent Toolkit adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Conte…”
   • [claimed-docs] “adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Context Protocol (MCP)”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [probe] “official MCP server documented at https://developer.sumup.com/tools/llms/mcp-server”

   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

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Adyen In-Person Payments
   SumUp~partialclaimed4/10

   SumUp documents a narrow webhook mechanism: a `return_url` parameter set at checkout creation lets you get notified only about checkout status changes, not a general event subscription/webhook system covering other event types. missing for 10: broader event catalog beyond checkout status, a dedicated webhook subscription/management API, and any signature-verification or delivery-retry docs.

   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout.”
   • [claimed-docs] “our system only allows you to get notified about a status change for a checkout”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”

   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 userSet up automations that run autonomously in the background

   weight 2 · round drawn
   SumUp—none0/10

   SumUp is a payments API/platform with webhooks, an MCP server, and an agent toolkit for building agentic integrations, but there is no evidence of a native automation/workflow feature that runs autonomously in the background (e.g., scheduled jobs, triggers, rules engine) within SumUp itself — it only exposes APIs/tools that a third party would need to orchestrate.

   ⚑ 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

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

   weight 3 · round drawn
   SumUp—none0/10

   SumUp's evidence only shows it exposes an MCP server and Agent Toolkit so that external AI agents/coding assistants can call SumUp APIs — this is SumUp acting as a tool provider for other agents, not a built-in AI assistant embedded in the SumUp product itself that a user can delegate tasks to.

   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “The SumUp Agent Toolkit adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Conte…”
   • [claimed-docs] “Use the SumUp MCP server to connect MCP-compatible clients and AI assistants to SumUp APIs and documentation tools.”
   • [claimed-docs] “adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Context Protocol (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

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

   weight 2 · round to SumUp
   SumUp~partialprobed7/10

   SumUp exposes a managed MCP server and an Agent Toolkit that let MCP-compatible AI assistants create checkouts, manage accounts, and process payments via natural-language-driven agents (sumup-docs-11, sumup-docs-25, sumup-docs-12, sumup-docs-43). This is first-party documentation only, with no independent or hands-on report confirming smooth natural-language operation in practice. Missing for 10: independent/hands-on corroboration of the MCP server's natural-language workflows, and any evidence of a native NL command interface outside the MCP/agent-toolkit integration path.

   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “Use the SumUp MCP server to connect MCP-compatible clients and AI assistants to SumUp APIs and documentation tools.”
   • [claimed-docs] “The SumUp Agent Toolkit adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Conte…”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [probe] “official MCP server documented at https://developer.sumup.com/tools/llms/mcp-server”

   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 drawn
   SumUp—none0/10

   Docs include code snippets (e.g., sumup-docs-13) and markdown-based documentation, but there is no evidence of an interactive, runnable API reference (like Swagger/OpenAPI explorer or Postman console); a direct probe for OpenAPI/Swagger specs returned 404s (sumup-probe-2), indicating no such interactive reference exists.

   • [claimed-docs] “const checkout = await client.checkouts.create({ amount: 2500, checkout_reference: "ORDER-1001", currency: "EUR"”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.sumup.com/openapi.json, https://developer.sumup.com/swagger.json, https://develope…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.sumup.com/llms.txt # SumUp Developer ## Documentation Sets - [Abridged documentation](https:…”

   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 to Adyen In-Person Payments
   SumUp—none0/10

   A direct probe for OpenAPI/Swagger specs at all standard candidate paths returned 404, and no evidence pack item points to a downloadable machine-readable API spec; the documentation instead offers Markdown/llms.txt files and an MCP server, not an OpenAPI spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.sumup.com/openapi.json, https://developer.sumup.com/swagger.json, https://develope…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.sumup.com/llms.txt # SumUp Developer ## Documentation Sets - [Abridged documentation](https:…”

   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 SumUp
   SumUp✓fullclaimed8/10

   SumUp docs explicitly provide sandbox merchant accounts, test cards, and 3D Secure simulation for testing payment flows without touching production data, plus a Virtual Solo option for terminal testing before switching to a physical reader. This covers the AI-native testing need well, though missing for 10: explicit guidance on using sandbox specifically via the MCP server/agent toolkit, and independent hands-on confirmation of sandbox fidelity.

   • [claimed-docs] “SumUp provides sandbox merchant accounts and a comprehensive set of test cards to simulate various payment scenarios, including different 3D…”
   • [claimed-docs] “Create and verify a checkout with a sandbox merchant account.”
   • [claimed-docs] “Use Virtual Solo together with a sandbox merchant account to test the pairing and checkout flow first, then switch to a physical reader late…”
   • [claimed-docs] “Exercise successful, failed, and 3D Secure payment flows.”
   • [claimed-docs] “Prepare a merchant account, device, and integration for testing.”

   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
   SumUp—none0/10

   No evidence pack item mentions API versioning scheme or any documented deprecation policy; probes even show OpenAPI spec URLs returning 404, and no changelog/versioning docs are referenced.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.sumup.com/openapi.json, https://developer.sumup.com/swagger.json, https://develope…”

   proof ↗⚑ 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 to SumUp
   SumUp~partialclaimed3/10

   The docs mention the Cloud API can run simultaneous transactions across multiple paired Solo readers, which is the only hint of parallel/batch-like operation, but there is no evidence of a genuine bulk API (e.g., batch checkout creation, bulk refunds, or list-based operations) that an AI agent could invoke to act on many items in one call. Missing for 10: bulk/batch endpoints for checkouts or refunds, documented multi-item request payloads, and confirmation that MCP/Agent Toolkit tools support batch calls rather than one-at-a-time operations.

   • [claimed-docs] “Ability to process simultaneous transactions on multiple Solo card readers at once - No distance limitation between your POS device and the …”
   • [claimed-docs] “Ability to process simultaneous transactions on multiple Solo card readers at once”
   • [claimed-docs] “Pairing multiple Solo card readers with any SumUp account - Naming each Solo card reader as desired to streamline checkout”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “The SumUp Agent Toolkit adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Conte…”

   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 Adyen In-Person Payments
   SumUp—none0/10

   SumUp's docs show only basic webhook notifications for checkout status changes (via return_url), not a rules engine allowing users to define custom conditions/actions across events; no evidence of any automation/rules builder.

   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout.”
   • [claimed-docs] “our system only allows you to get notified about a status change for a checkout”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”

   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 drawn
   SumUp—none0/10

   The evidence pack contains no documentation of a native email/SMS or printed receipt feature, nor any mention of card-network receipt compliance. The only related item is a community post describing a developer having to hack a receipt-printer integration via the public API because SumUp's app didn't natively support it, which suggests the absence of a first-party receipt-issuance capability rather than confirming one.

   • [community] “Developer built low-cost receipt printer integration for SumUp by hacking the system through SumUp's public API rather than communicating wi…”

   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 SumUp
   SumUp✓fullclaimed7/10

   SumUp docs explicitly describe embedding payment acceptance directly in iOS/Android apps via Reader SDKs, controlling the reader over Bluetooth or using Tap to Pay, and offline transactions support, covering the core of the story. missing for 10: explicit named SDK package/repo links for iOS/Android (e.g. CocoaPods/Gradle artifacts), independent developer corroboration of SDK integration experience, and detailed API reference docs beyond high-level descriptions.

   • [claimed-docs] “There are three ways to integrate SumUp in-person payments: | | Cloud API | Reader SDKs | Payment Switch |”
   • [claimed-docs] “Embed payment acceptance directly in your Android or iOS app.”
   • [claimed-docs] “Embed payment acceptance directly in your Android or iOS app. Your app controls the reader over Bluetooth or uses Tap to Pay.”
   • [claimed-docs] “SumUp's in-person payment products let you accept card payments face-to-face using physical card readers or Tap to Pay on a mobile device.”
   • [claimed-docs] “Offline Transactions let merchants continue accepting card payments when internet connectivity is unavailable or unreliable.”
   • [claimed-docs] “Offline Transactions let merchants continue accepting card payments when internet connectivity is unavailable or unreliable. In this store-a…”

   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 SumUp
   SumUp✓fullprobed8/10

   SumUp's Cloud API explicitly lets a POS on any platform drive Solo/Go readers via HTTPS requests from the backend, with docs covering pairing, multi-reader support, sandbox/virtual testing, and offline transactions, plus community evidence of a real developer building a custom integration against the public API. Missing for 10: a public OpenAPI/swagger spec (probe found only 404s) and more independent hands-on validation beyond one HN anecdote.

   • [claimed-docs] “There are three ways to integrate SumUp in-person payments: | | Cloud API | Reader SDKs | Payment Switch |”
   • [claimed-docs] “Trigger and manage payments on Solo or Go readers via HTTPS requests.”
   • [claimed-docs] “Ability to process simultaneous transactions on multiple Solo card readers at once - No distance limitation between your POS device and the …”
   • [claimed-docs] “Use Virtual Solo together with a sandbox merchant account to test the pairing and checkout flow first, then switch to a physical reader late…”
   • [claimed-docs] “The Cloud API lets you start a transaction from a Point of Sale (POS) running on any platform (Windows, iOS, Linux, Android, Web-based, etc.…”
   • [claimed-docs] “Offline Transactions let merchants continue accepting card payments when internet connectivity is unavailable or unreliable. In this store-a…”
   • [community] “Developer built low-cost receipt printer integration for SumUp by hacking the system through SumUp's public API rather than communicating wi…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.sumup.com/openapi.json, https://developer.sumup.com/swagger.json, https://develope…”

   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 to Adyen In-Person Payments
   SumUp~partialclaimed4/10

   SumUp docs confirm webhooks exist but explicitly state the system 'only allows you to get notified about a status change for a checkout' — a single generic event type, not the granular authorized/captured/refunded/disputed lifecycle events the story requests. Refunds are documented as a separate API-driven action, not as a distinct webhook event, and disputes are not mentioned at all in the webhook docs. missing for 10: distinct webhook events for authorization, capture, dispute; documented dispute webhook; independent/hands-on confirmation of webhook reliability.

   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout.”
   • [claimed-docs] “our system only allows you to get notified about a status change for a checkout”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”
   • [claimed-docs] “When you complete these steps, the payment you have previously processed through SumUp will be refunded either partially or in full.”
   • [claimed-docs] “In this guide, you will learn how to refund a transaction... Option A: Make a full refund... Option B: Make a partial refund”

   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 drawn
   SumUp✓fullclaimed8/10

   SumUp docs explicitly describe sandbox merchant accounts, test cards, and simulated 3D Secure flows for testing before going live, plus a Virtual Solo reader that can be paired with a sandbox account to test checkout flow prior to using a physical device. This directly covers both simulated-reader and test-card scenarios for in-person integration. Missing for 10: independent/hands-on developer confirmation of the sandbox/test-card workflow in practice beyond vendor docs.

   • [claimed-docs] “SumUp provides sandbox merchant accounts and a comprehensive set of test cards to simulate various payment scenarios, including different 3D…”
   • [claimed-docs] “Use Virtual Solo together with a sandbox merchant account to test the pairing and checkout flow first, then switch to a physical reader late…”
   • [claimed-docs] “Create and verify a checkout with a sandbox merchant account.”
   • [claimed-docs] “Exercise successful, failed, and 3D Secure payment flows.”

   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 Adyen In-Person Payments
   SumUp—none0/10

   SumUp's docs cover checkouts, refunds, webhooks for checkout status, and MCP/agent tooling, but there is no evidence of a disputes/chargebacks API, dispute deadline data, or evidence-submission endpoints that an agent could monitor or draft responses against.

   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout.”
   • [claimed-docs] “our system only allows you to get notified about a status change for a checkout”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”
   • [claimed-docs] “When you complete these steps, the payment you have previously processed through SumUp will be refunded either partially or in full.”
   • [claimed-docs] “the payment you have previously processed through SumUp will be refunded either partially or in full”

   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 to Adyen In-Person Payments
   SumUp—none0/10

   Evidence shows webhooks only notify on checkout status changes and refund guides, with no mention of chargeback notifications or a dispute-evidence submission workflow/deadline tracking anywhere in the docs.

   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout.”
   • [claimed-docs] “our system only allows you to get notified about a status change for a checkout”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”
   • [claimed-docs] “When you complete these steps, the payment you have previously processed through SumUp will be refunded either partially or in full.”
   • [claimed-docs] “In this guide, you will learn how to refund a transaction... Option A: Make a full refund... Option B: Make a partial refund”

   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
   SumUp~partialclaimed6/10

   SumUp's developer docs explicitly describe both full and partial refunds for a previously processed payment via the API (sumup-docs-16, -23, -40), covering the API leg of the story clearly. However, there is no evidence in the pack describing refund initiation from the point-of-sale device or the merchant dashboard UI, so only one of the three channels is substantiated. missing for 10: dashboard-based refund flow, POS/terminal refund flow, independent/hands-on confirmation of refund completion.

   • [claimed-docs] “When you complete these steps, the payment you have previously processed through SumUp will be refunded either partially or in full.”
   • [claimed-docs] “the payment you have previously processed through SumUp will be refunded either partially or in full”
   • [claimed-docs] “In this guide, you will learn how to refund a transaction... Option A: Make a full refund... Option B: Make a partial refund”

   proof ↗⚑ 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 to Adyen In-Person Payments
   SumUp—none0/10

   Evidence shows reader pairing/naming and Cloud API triggering payments, but there is no documented API for creating a 'location' entity or registering readers to a location end-to-end — no location resource, no provisioning workflow evidenced. missing for 10: location creation API, reader-to-location registration endpoint, any end-to-end provisioning example.

   • [claimed-docs] “Ability to process simultaneous transactions on multiple Solo card readers at once - No distance limitation between your POS device and the …”
   • [claimed-docs] “Pairing multiple Solo card readers with any SumUp account - Naming each Solo card reader as desired to streamline checkout”
   • [claimed-docs] “The Cloud API lets you start a transaction from a Point of Sale (POS) running on any platform (Windows, iOS, Linux, Android, Web-based, etc.…”

   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 drawn
   SumUp~partialclaimed3/10

   SumUp's Cloud API supports pairing and naming multiple Solo readers and triggering payments via HTTPS, which is a thin form of device registration, but there is no evidence of true fleet management — no API for monitoring device status/health or remotely updating reader configuration. Missing for 10: device status/health monitoring endpoints, remote configuration/firmware update API, fleet-wide management dashboard or bulk operations.

   • [claimed-docs] “Ability to process simultaneous transactions on multiple Solo card readers at once - No distance limitation between your POS device and the …”
   • [claimed-docs] “Pairing multiple Solo card readers with any SumUp account - Naming each Solo card reader as desired to streamline checkout”
   • [claimed-docs] “The Cloud API lets you start a transaction from a Point of Sale (POS) running on any platform (Windows, iOS, Linux, Android, Web-based, etc.…”
   • [claimed-docs] “Trigger and manage payments on Solo or Go readers via HTTPS requests.”

   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 to Adyen In-Person Payments
   SumUp—none0/10

   Evidence covers payment API/reader integrations, MCP tools, and pricing tiers, but there is no mention of multi-location management, per-location settings, or per-location reporting/dashboards for merchant-ops. Multiple readers can be paired/named but nothing ties this to a location-based hierarchy or reporting.

   ⚑ 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 SumUp
   SumUp~partialclaimed6/10

   SumUp's docs describe pairing Solo/Go readers with an account (docs-45), naming readers for streamlined checkout, and using a Virtual Solo to test the pairing flow before switching to a physical reader (docs-8), plus Cloud API triggering payments over HTTPS (docs-6) and Tap to Pay as a no-reader option (docs-9). However there's no explicit first-party or hands-on evidence of the end-to-end time-to-first-payment ('within minutes') claim, and no independent corroboration of the pairing UX itself. Missing for 10: explicit speed/time claim for pairing-to-payment, independent/hands-on account of the pairing experience.

   • [claimed-docs] “Pairing multiple Solo card readers with any SumUp account - Naming each Solo card reader as desired to streamline checkout”
   • [claimed-docs] “Use Virtual Solo together with a sandbox merchant account to test the pairing and checkout flow first, then switch to a physical reader late…”
   • [claimed-docs] “Trigger and manage payments on Solo or Go readers via HTTPS requests.”
   • [claimed-docs] “Tap to Pay lets merchants accept in-person contactless payments directly on a compatible phone without carrying a separate card reader.”
   • [claimed-docs] “The Cloud API lets you start a transaction from a Point of Sale (POS) running on any platform (Windows, iOS, Linux, Android, Web-based, etc.…”

   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 SumUp
   SumUp✓fullclaimed8/10

   SumUp documents a dedicated Offline Transactions feature for terminal SDKs explicitly describing a store-and-forward flow where card data is captured and cached securely on-device and uploaded later for processing when connectivity returns. This directly matches the story; missing for 10: independent/hands-on confirmation of reliability in real outage scenarios and details on limits (e.g., risk caps, duration offline).

   • [claimed-docs] “Offline Transactions let merchants continue accepting card payments when internet connectivity is unavailable or unreliable.”
   • [claimed-docs] “Offline Transactions let merchants continue accepting card payments when internet connectivity is unavailable or unreliable. In this store-a…”

   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 to Adyen In-Person Payments
   SumUp~partialprobed5/10

   SumUp's docs show broad API/SDK coverage for core payment operations—checkouts, refunds, terminal/reader management, webhooks—and even an MCP server/agent toolkit for AI-driven use, but webhooks are explicitly limited ('only allows notified about a status change') and no evidence shows API parity for account settings, reporting, disputes, or other dashboard/UI-only features found on a typical SumUp merchant account. missing for 10: evidence of full account/reporting/dispute management parity via API, explicit statement of 1:1 UI-API feature parity, and independent confirmation beyond vendor docs.

   • [claimed-docs] “const checkout = await client.checkouts.create({ amount: 2500, checkout_reference: "ORDER-1001", currency: "EUR"”
   • [claimed-docs] “When you complete these steps, the payment you have previously processed through SumUp will be refunded either partially or in full.”
   • [claimed-docs] “our system only allows you to get notified about a status change for a checkout”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout. To subscribe to an event, specify a `return_ur…”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “Use the SumUp MCP server to connect MCP-compatible clients and AI assistants to SumUp APIs and documentation tools.”
   • [probe] “official MCP server documented at https://developer.sumup.com/tools/llms/mcp-server”

   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 drawn
   SumUp—none0/10

   SumUp is a payments platform holding transaction/merchant data, and the evidence pack has no mention of any data export feature (open formats like CSV/JSON export of transactions, merchant data, or account closure/data portability tooling); it covers payment APIs, MCP/agent tooling, and checkout flows but nothing about exporting user data and leaving.

   ⚑ 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
   SumUp—none0/10

   SumUp is a closed-source commercial payments platform; no evidence of any open-source license or public source repository for the core product, only API docs and SDK wrappers.

   ⚑ 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 drawn
   SumUp—none0/10

   No evidence pack item mentions payout timing, payout schedules, next-day/instant payout options, or any mechanism to view or accelerate payouts; the docs focus on checkouts, terminal payments, refunds, webhooks, and MCP/agent tooling.

   ⚑ 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 drawn
   SumUp~partialclaimed4/10

   SumUp exposes API access (SDK, MCP server, Agent Toolkit) that could let an agent create checkouts and manage payments, and webhooks/refund guides show some transaction-status visibility, but there is no evidence of a payouts endpoint or a documented transactions/payouts listing API for reconciliation into a ledger. missing for 10: dedicated payouts API/endpoint, transaction history/list API, ledger/reconciliation-specific documentation or examples, independent confirmation of agent-driven reconciliation workflows.

   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”
   • [claimed-docs] “The SumUp Agent Toolkit adds SumUp API tools to agentic applications built with LangChain, AI SDK, the OpenAI Agents SDK, or the Model Conte…”
   • [claimed-docs] “API keys are static credentials that let your application act on behalf of the merchant account that created the key.”
   • [claimed-docs] “At this time our system only allows you to get notified about a status change for a checkout.”
   • [claimed-docs] “The @sumup/sdk package wraps SumUp API, ships TypeScript declarations, and works in modern JavaScript runtimes and platforms”
   • [claimed-docs] “SumUp runs a managed MCP server at https://mcp.sumup.com/mcp. This endpoint allows your MCP client to interact with SumUp APIs to manage you…”

   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 drawn
   SumUp—none0/10

   Evidence covers checkout, terminal payments, refunds, webhooks, and pricing pages, but there is no mention of reconciliation reports, payout statements, itemized fee breakdowns, or any dashboard/export feature for matching daily takings to payouts.

   ⚑ 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
   SumUp~partialclaimed5/10

   SumUp's architecture (hosted Checkout, embedded Payment Widget, certified Solo/Go readers over Bluetooth/HTTPS, offline transactions with secure on-device caching) is consistent with minimizing merchant PCI scope, since card data is captured/processed by SumUp-certified hardware or hosted pages rather than the merchant's own systems (sumup-docs-35, sumup-docs-36, sumup-docs-9, sumup-docs-44, sumup-docs-6). However, there is no explicit vendor documentation cited that discusses PCI DSS scope reduction, SAQ eligibility, or guidance on the developer's remaining compliance obligations. Missing for 10: explicit PCI DSS/SAQ guidance pages, statements of PCI certification levels for readers, and any developer-facing compliance checklist.

   • [claimed-docs] “Hosted Checkout is the fastest path to launch. SumUp hosts the payment page, while your integration creates the checkout and redirects the c…”
   • [claimed-docs] “For an embedded checkout on your own site, use the [Payment Widget]. It only requires adding a single script to your payment page.”
   • [claimed-docs] “Tap to Pay lets merchants accept in-person contactless payments directly on a compatible phone without carrying a separate card reader.”
   • [claimed-docs] “Offline Transactions let merchants continue accepting card payments when internet connectivity is unavailable or unreliable. In this store-a…”
   • [claimed-docs] “Trigger and manage payments on Solo or Go readers via HTTPS requests.”
   • [claimed-docs] “Embed payment acceptance directly in your Android or iOS app.”

   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
   SumUp—none0/10

   SumUp is a payments platform and no evidence pack item mentions data residency, region selection, or data storage location controls; the docs focus on payments, checkout, MCP tools, and pricing without any data residency configuration.

   ⚑ 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 userControl data retention and deletion

   weight 2 · round drawn
   SumUp—none0/10

   No evidence of any data retention/deletion controls, privacy dashboard, or GDPR-style data export/delete APIs in the SumUp docs pack; the evidence focuses on payments, SDKs, and MCP tooling with no mention of user data lifecycle management.

   ⚑ 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