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

   Docs confirm hardware ordering and reader registration/configuration directly from the Dashboard (docs-32, docs-5, docs-20, docs-44) and no-code acceptance options (docs-21, docs-26, docs-31), supporting a founder's ability to get set up for in-person payments quickly. However, there is no evidence describing the account signup/approval process, approval timelines, or shipping/delivery speed for hardware, so the 'same week' claim is unverified. missing for 10: evidence of signup/approval flow and timeline, hardware shipping/delivery speed, independent confirmation of onboarding speed.

   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”
   • [claimed-docs] “You can register smart readers in one of three ways: Registration code, Serial number, Order number”
   • [claimed-docs] “Use no-code options: Accept payments without building a custom POS integration.”
   • [claimed-docs] “Accept in-person payments on a compatible reader using Stripe's no-code solution.”

   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 to Stripe Terminal
   Stripe Terminal✓fullcommunity9/10

   Docs explicitly confirm chip/contactless card reader support, Tap to Pay on iPhone and Android contactless via SDK, and Apple Pay/Google Pay via Stripe's payment methods on Terminal-compatible readers/devices, plus real-world community validation of the API-based in-person integration. Missing for 10: independent hands-on confirmation specifically of Apple Pay/Google Pay wallet taps on readers (evidence focuses more on contactless generally) and no dispute found.

   • [claimed-docs] “Use Tap to Pay on iPhone to accept in-person contactless payments with a compatible iPhone.”
   • [claimed-docs] “Accept contactless payments using a compatible iPhone or Android device with the Stripe Terminal SDK.”
   • [claimed-docs] “Terminal supports an API-based integration in addition to SDKs for Android, iOS, JavaScript, and React Native.”
   • [claimed-docs] “Accept in-person payments on a compatible reader using Stripe's no-code solution.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”
   • [community] “I am working with a company that has small physical stores processing hundreds of payments every day... having to rely on all the existing c…”

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

   No evidence in the pack describes split-tender functionality (splitting one sale across multiple payment methods or payers); documentation covers tipping, refunds, receipts, offline payments, and fleet management but nothing about multi-tender or split payment splitting at checkout.

   ⚑ 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 to Stripe Terminal
   Stripe Terminal✓fullclaimed9/10

   Stripe Terminal explicitly documents Tap to Pay on iPhone (and Android) for accepting contactless payments on a compatible off-the-shelf phone without a separate physical reader, directly matching the story. Missing for 10: independent/hands-on confirmation of the Tap to Pay experience specifically (community evidence covers general Terminal use, not Tap to Pay directly).

   • [claimed-docs] “Use Tap to Pay on iPhone to accept in-person contactless payments with a compatible iPhone.”
   • [claimed-docs] “Accept contactless payments using a compatible iPhone or Android device with the Stripe Terminal SDK.”
   • [claimed-docs] “Terminal supports an API-based integration in addition to SDKs for Android, iOS, JavaScript, and React Native.”

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

   Docs explicitly describe on-reader tipping with suggested tip prompts before payment collection, plus on-receipt tipping as an alternative, directly matching the story's percentage/smart-amount/custom-tip prompt configuration on the terminal. Missing for 10: no explicit documentation of configuring specific percentage values or 'smart amount' algorithms, nor independent/hands-on merchant confirmation of the tipping UX.

   • [claimed-docs] “On-reader tipping: The card reader suggests tips to customers before collecting payment.”
   • [claimed-docs] “Use Terminal to collect tips from your customer before or after authorizing a payment.”
   • [claimed-docs] “You can collect voluntary tips in two ways: On-receipt tipping ... On-reader tipping: The card reader suggests tips to customers before coll…”
   • [claimed-docs] “The card reader suggests tips to customers before collecting payment.”

   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
   Stripe Terminal✓fullprobed9/10

   Stripe's documentation confirms an llms.txt is live (HTTP 200) and individual docs pages are available as .md files (e.g., terminal.md), confirmed by direct probes, letting an agent be pointed at agent-oriented docs. Missing for 10: no independent/community confirmation that agents actually consume this successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/terminal.md # Terminal Use Stripe Terminal to accept in-person payments. Stripe Termina…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”

   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 drawn
   Stripe Terminal~partialclaimed4/10

   Stripe Terminal SDKs ship a built-in simulated card reader so developers can build/test integrations without physical hardware (docs-9), and the Stripe CLI (docs-37) supports scripting Stripe integrations, which together enable some automated/CI-style testing. However, there's no explicit documentation of running Terminal itself headlessly in CI pipelines, GitHub Actions examples, or automated end-to-end payment flows without human/device interaction, since the product's core function requires physical readers for real transactions. missing for 10: explicit CI/automation docs or examples (GitHub Actions, headless test harness), confirmation that simulated-reader testing can run fully unattended in CI, and evidence of production-grade headless orchestration beyond manual SDK/CLI use.

   • [claimed-docs] “Stripe Terminal SDKs and server-driven integration come with a built-in simulated card reader, so you can develop and test your app without …”
   • [claimed-docs] “The Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal.”

   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 to Adyen In-Person Payments
   Stripe Terminal~partialprobed6/10

   Stripe (the parent platform) documents an official MCP server that lets AI agents interact with 'the Stripe API' and search Stripe's knowledge base, and this is corroborated by a probe confirming the live docs page; since Stripe Terminal is exposed via the Stripe API, this MCP server plausibly covers Terminal use cases, but no evidence explicitly names Terminal-specific tools or endpoints within the MCP server. missing for 10: explicit documentation that the MCP server exposes Terminal-specific actions (e.g., reader registration, payment collection) rather than generic Stripe API access, and independent/hands-on confirmation of Terminal agent workflows via MCP.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”

   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 to Stripe Terminal
   Stripe Terminal✓fullprobed8/10

   Stripe provides an official CLI ('Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal'), which applies to Stripe's platform including Terminal integrations, and this is corroborated by a dedicated docs probe confirming its existence. missing for 10: no evidence of Terminal-specific CLI subcommands or independent hands-on validation of CLI usage for Terminal workflows specifically.

   • [claimed-docs] “The Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ 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 to Stripe Terminal
   Stripe Terminal✓fullprobed9/10

   Stripe Terminal is documented as an API-based integration with SDKs, and Stripe provides a public OpenAPI spec repo, CLI, and webhooks, giving AI-native users a fully documented programmatic surface to drive the product; community evidence corroborates deep API-level integration in production use. Missing for 10: a dedicated OpenAPI endpoint hosted directly under docs.stripe.com (probe found 404s) and independent hands-on AI-agent usage evidence specific to Terminal.

   • [claimed-docs] “Build a custom POS integration tailored to your business. Terminal supports an API-based integration in addition to SDKs for Android, iOS, J…”
   • [claimed-docs] “Terminal supports an API-based integration in addition to SDKs for Android, iOS, JavaScript, and React Native.”
   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”
   • [claimed-docs] “The Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal.”
   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

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

   The evidence pack covers Terminal's POS/hardware features, MCP server availability, and general agent commerce framing, but contains no mention of restricted/scoped API keys, granular permissions, or any mechanism for issuing least-privilege credentials specifically for an AI agent using Terminal's API.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Stripe Terminal
   Stripe Terminal✓fullprobed8/10

   Stripe Terminal ships official SDKs for Android, iOS, JavaScript (with a public GitHub repo), and React Native plus a server-driven API integration, backed by an OpenAPI spec and CLI for tooling — all first-party documented and corroborated by a hands-on developer report praising the API-level integration power for building custom terminals. Missing for 10: independent third-party benchmarking/reviews of the SDKs' developer experience specifically for AI-native/agentic workflows beyond the general MCP/agents docs.

   • [claimed-docs] “Build a custom POS integration tailored to your business. Terminal supports an API-based integration in addition to SDKs for Android, iOS, J…”
   • [claimed-docs] “Terminal supports an API-based integration in addition to SDKs for Android, iOS, JavaScript, and React Native.”
   • [github] “Use the Terminal JS SDK as an ES module.”
   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”
   • [claimed-docs] “The Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/terminal.md # Terminal Use Stripe Terminal to accept in-person payments. Stripe Termina…”

   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 drawn
   Stripe Terminal✓fullclaimed7/10

   Stripe's platform-wide webhooks system (registering HTTPS endpoints, receiving real-time event pushes to trigger automated reactions) is documented and applies to Terminal-generated events like payment_intent updates. missing for 10: Terminal-specific webhook event documentation and independent/hands-on confirmation that Terminal transactions reliably trigger these webhooks.

   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”

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

   No evidence that Stripe Terminal surfaces AI-generated insights or suggestions from transaction/business data inside its dashboard or SDKs. The MCP server and agent tooling references (docs-35, docs-36) enable external AI agents to call the Stripe API, but that is not the same as the product itself generating insights/suggestions from a user's data.

   ⚑ 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 Stripe Terminal
   Stripe Terminal~partialclaimed4/10

   Stripe's broader platform offers building blocks for background automation—webhooks that trigger automatic reactions to events (e.g., completed Terminal payments), Smart Disputes that automate evidence collection, and an MCP server letting AI agents call the Stripe API—but none of this is a dedicated 'set up an autonomous background automation' feature specific to Terminal itself; it requires the developer to wire up webhook listeners or agent integrations themselves. Missing for 10: a first-party Terminal-specific automation/workflow engine, evidence of autonomous scheduled/triggered Terminal actions, and independent confirmation that these pieces compose into hands-off background automations.

   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [claimed-docs] “To help you submit the best possible response for each dispute, Stripe guides you through the process in the Dashboard. Use Smart Disputes t…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”

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

   Evidence shows Stripe offers an MCP server so external AI agents can call the Stripe API, and general 'Agents and AI on Stripe' agent-first tooling, but nothing indicates Stripe Terminal itself embeds a built-in AI assistant that a user can delegate tasks to within the product.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”
   • [probe] “official MCP server documented at https://docs.stripe.com/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
   Stripe Terminal~partialprobed3/10

   Stripe (the parent platform) documents an official MCP server that lets AI agents interact with 'the Stripe API' and search documentation, which could in principle route Terminal-related API calls through natural-language agent commands, but there is no Terminal-specific evidence of natural-language control of readers, payments, or fleet management. missing for 10: Terminal-specific natural-language command support, agent-driven reader/payment control examples, independent corroboration of MCP-driven Terminal operations.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”

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

   The evidence pack shows extensive Terminal docs, SDKs, and an OpenAPI spec repo, but nothing describes an interactive API reference with runnable/executable examples (e.g., a live 'try it' console); a probe even shows openapi.json endpoints returning 404 at the docs site, suggesting no readily discoverable interactive spec integration.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/terminal.md # Terminal Use Stripe Terminal to accept in-person payments. Stripe Termina…”

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

   Stripe publishes a public OpenAPI specification repository for its API (stripe/openapi) which underlies Terminal's API-based integration, giving AI-native users a machine-readable spec to consume; probe attempts at docs.stripe.com-hosted openapi.json paths 404 but the canonical GitHub-hosted spec is well documented. missing for 10: no direct download link from Terminal-specific docs pages, and probe could not confirm a docs.stripe.com-hosted openapi.json endpoint.

   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   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 drawn
   Stripe Terminal✓fullclaimed7/10

   Stripe Terminal SDKs include a built-in simulated card reader for developing and testing without physical hardware, and Stripe broadly supports test mode (sandbox) separate from live/production data. missing for 10: explicit mention of full sandbox parity (test API keys/test mode) specific to Terminal payments beyond the simulated reader, and independent hands-on confirmation of sandbox isolation.

   • [claimed-docs] “Stripe Terminal SDKs and server-driven integration come with a built-in simulated card reader, so you can develop and test your app without …”

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

   The evidence pack includes general Terminal docs, SDKs, CLI, and MCP references, but nothing documents API versioning conventions or a deprecation policy for the Stripe API/Terminal endpoints (e.g. no mention of API version headers, changelogs, or sunset timelines). The OpenAPI spec repo (stripe-terminal-docs-41) only points to spec files, not a versioning/deprecation policy.

   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”

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

   Stripe Terminal docs describe managing multiple readers via locations/zones and registering readers individually, but there is no evidence of a bulk/batch API (e.g., batch payment processing, bulk reader configuration, or bulk refunds) that an AI agent could invoke to operate on many items in a single call. missing for 10: batch/bulk API endpoints for Terminal, evidence of programmatic bulk operations on payments or readers, AI-agent-oriented bulk automation examples.

   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”

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

   Stripe provides generic webhook infrastructure ("Listen for events from Stripe... so your integration can automatically trigger reactions") which lets developers build event-driven automation on top of Terminal transactions, and Smart Disputes shows some automated action-on-event behavior. However, there is no Terminal-specific rules engine or no-code trigger/action builder — automation still requires custom webhook-handling code rather than user-defined rules. Missing for 10: a declarative rules/trigger UI or API specific to Terminal events, and evidence of AI-native users defining conditional automations without writing webhook handlers.

   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [claimed-docs] “To help you submit the best possible response for each dispute, Stripe guides you through the process in the Dashboard. Use Smart Disputes t…”

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

   Stripe Terminal docs explicitly state merchants must offer physical or email receipts, prebuilt email receipts include all card-network-required fields, and receipts can be customized while retaining required information. This directly matches the story of issuing digital/printed receipts meeting card-network requirements. Missing for 10: independent/hands-on verification of receipt compliance and no explicit mention of SMS receipts (only email/print).

   • [claimed-docs] “You can use Stripe’s prebuilt email receipts, or use receipt data from the Stripe API and your Terminal integration to generate on-brand cus…”
   • [claimed-docs] “If you accept payments using Stripe Terminal, you must provide customers with the option to receive a physical or email receipt.”
   • [claimed-docs] “Prebuilt email receipts already include all card network-required fields.”
   • [claimed-docs] “You can also customize receipts to include any design and content you want—as long as you list required information.”
   • [claimed-docs] “Stripe provides everything you need to start offering receipts with your first transaction.”

   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 Stripe Terminal
   Stripe Terminal✓fullcommunity8/10

   Docs explicitly confirm official Terminal SDKs for iOS and Android (plus JS/React Native) for building custom in-person payment integrations, with support for Tap to Pay on iPhone, offline payment storage, tipping, receipts, and built-in simulated readers for testing without hardware. Community evidence corroborates real-world developers building custom POS apps on top of the Terminal SDK/API, reinforcing that this is a viable, used integration path. Missing for 10: independent hands-on review of the actual mobile SDK integration experience (vs. docs only) and more detail on SDK API specifics/version history.

   • [claimed-docs] “Build a custom POS integration tailored to your business. Terminal supports an API-based integration in addition to SDKs for Android, iOS, J…”
   • [claimed-docs] “Terminal supports an API-based integration in addition to SDKs for Android, iOS, JavaScript, and React Native.”
   • [claimed-docs] “Accept contactless payments using a compatible iPhone or Android device with the Stripe Terminal SDK.”
   • [claimed-docs] “Use Tap to Pay on iPhone to accept in-person contactless payments with a compatible iPhone.”
   • [claimed-docs] “Stripe Terminal SDKs and server-driven integration come with a built-in simulated card reader, so you can develop and test your app without …”
   • [claimed-docs] “Deploy your Android POS app to Stripe smart readers.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”

   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 Stripe Terminal
   Stripe Terminal✓fullcommunity9/10

   Docs explicitly confirm an API-based, server-driven integration path (in addition to SDKs) for building a custom POS, with supporting infrastructure like reader registration, locations/zones, offline payment storage, and a simulated reader for testing without hardware; a hands-on developer account corroborates building a fully custom terminal integration via the API. missing for 10: no independent third-party benchmark of the raw REST/server-driven API surface itself (only docs + one anecdotal HN account).

   • [claimed-docs] “Build a custom POS integration tailored to your business. Terminal supports an API-based integration in addition to SDKs for Android, iOS, J…”
   • [claimed-docs] “Terminal supports an API-based integration in addition to SDKs for Android, iOS, JavaScript, and React Native.”
   • [claimed-docs] “Build a custom POS integration”
   • [claimed-docs] “Stripe Terminal SDKs and server-driven integration come with a built-in simulated card reader, so you can develop and test your app without …”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”

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

   Stripe's general webhook system is well documented (docs-38: register an HTTPS endpoint and receive real-time events), and Terminal payments flow through core Stripe objects (PaymentIntents, Refunds, Disputes) that are webhook-eligible, with dispute (docs-40) and refund (docs-24, docs-28) API/dashboard support shown. However, the evidence never explicitly enumerates Terminal-specific webhook event types (e.g., terminal.reader.action_succeeded, payment_intent.succeeded for in-person) or shows a Terminal webhook integration example. Missing for 10: explicit list of Terminal-triggered webhook event names, a Terminal-specific webhook code sample, and independent developer confirmation that lifecycle events (authorized/captured/refunded/disputed) fire reliably for in-person transactions.

   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [claimed-docs] “To refund a payment using the Dashboard: 1. Find the payment you want to refund in the Payments page. 2. Click the overflow menu (⋯) ... the…”
   • [claimed-docs] “You can issue refunds by using the Refunds API or the Dashboard.”
   • [claimed-docs] “To help you submit the best possible response for each dispute, Stripe guides you through the process in the Dashboard. Use Smart Disputes t…”

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

   Docs explicitly state Terminal SDKs and server-driven integration include a built-in simulated card reader for developing/testing without physical hardware, and the Stripe CLI supports building/testing integrations. missing for 10: no independent/hands-on developer account confirming the simulated reader workflow end-to-end, and no detail on test card numbers specific to Terminal.

   • [claimed-docs] “Stripe Terminal SDKs and server-driven integration come with a built-in simulated card reader, so you can develop and test your app without …”
   • [claimed-docs] “The Stripe CLI helps you build, test, and manage your Stripe integration right from the terminal.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   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
   Stripe Terminal~partialclaimed4/10

   Stripe provides webhooks and API access to dispute data plus a Smart Disputes feature to automate evidence collection/submission, and an MCP server that could let agents interact with the Stripe API — but there is no evidence of an agent-specific workflow that monitors dispute deadlines and drafts evidence responses for human review; this is inferred by combining generic webhook/dispute docs. missing for 10: explicit documentation of agent-driven deadline monitoring, evidence-drafting workflow tailored for AI agents, and confirmation that Smart Disputes integrates with the MCP/agent tooling rather than being a Dashboard-only automation.

   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [claimed-docs] “To help you submit the best possible response for each dispute, Stripe guides you through the process in the Dashboard. Use Smart Disputes t…”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”

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

   Stripe (the broader platform) documents a dispute workflow in the Dashboard, guiding merchants through evidence submission and offering 'Smart Disputes' to automate evidence collection for eligible disputes, which covers the core of this story. However, this evidence is generic Stripe platform documentation, not specific to Stripe Terminal or in-person/card-present disputes, and there's no explicit mention of chargeback notification mechanisms (e.g., webhook events for disputes) tied to Terminal transactions. Missing for 10: Terminal-specific dispute handling details, explicit notification/webhook triggers for disputes, deadline tracking specifics, and any hands-on/independent corroboration of the dispute workflow.

   • [claimed-docs] “To help you submit the best possible response for each dispute, Stripe guides you through the process in the Dashboard. Use Smart Disputes t…”
   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”

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

   Docs confirm refunds can be issued via Dashboard (docs-24) or Refunds API (docs-28), covering original card refunds initiated from dashboard/API; Terminal's unified in-person/online payment management (docs-10, docs-17) implies POS-originated payments are refundable through these same channels. Missing for 10: explicit documentation of partial refund support and a POS/reader-native refund flow (as opposed to only dashboard/API) plus independent hands-on confirmation.

   • [claimed-docs] “To refund a payment using the Dashboard: 1. Find the payment you want to refund in the Payments page. 2. Click the overflow menu (⋯) ... the…”
   • [claimed-docs] “You can issue refunds by using the Refunds API or the Dashboard.”
   • [claimed-docs] “You can manage both in-person payments and online payments in a unified system in the Dashboard.”
   • [claimed-docs] “you can accept in-person payments and manage them alongside your online payments in Stripe”

   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 Stripe Terminal
   Stripe Terminal✓fullprobed7/10

   Stripe Terminal's docs explicitly describe API-based management of locations/zones and reader registration (by serial number, registration code, or order number), and require readers be registered to a location before use — all doable via API calls without physical device access, which an agent could drive end-to-end. Stripe also has a general MCP server for agents to interact with the Stripe API. Missing for 10: no explicit example or confirmation that the MCP server's toolset covers Terminal locations/readers specifically, and no hands-on/independent evidence of an agent actually performing this end-to-end flow.

   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You must register your reader to a location to accept payments.”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”
   • [claimed-docs] “You can register smart readers in one of three ways: Registration code, Serial number, Order number”
   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   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 Stripe Terminal
   Stripe Terminal✓fullcommunity8/10

   Stripe Terminal docs explicitly cover fleet management via API: registering readers by serial number/registration code/order number, organizing devices with locations and zones across sites, and 'order, register, configure, and monitor readers from the Dashboard' with an equivalent API-based integration path. Community evidence corroborates that API-level control over terminals/hardware fleet is a key strength of the product. Missing for 10: independent hands-on confirmation of remote configuration updates specifically via API (docs emphasize Dashboard for monitor/configure) and no direct code sample of a fleet-status API call.

   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You must register your reader to a location to accept payments.”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”
   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”

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

   Docs explicitly support a fleet model: readers are grouped into 'locations and zones' to manage multiple physical sites, registered to a specific location, and can be ordered/configured/monitored from the Dashboard (stripe-terminal-docs-4, -5, -13, -20, -32, -44). However, evidence does not show per-location reporting breakdowns or per-location configurable settings (e.g., distinct tipping/receipt/tax rules per site) beyond the general reader/location grouping. missing for 10: explicit per-location reporting/analytics in the Dashboard, per-location settings customization (receipts, tipping, tax), and independent/hands-on confirmation of multi-location fleet operations at scale.

   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You must register your reader to a location to accept payments.”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”
   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”
   • [claimed-docs] “You can register smart readers in one of three ways: Registration code, Serial number, Order number”

   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 Stripe Terminal
   Stripe Terminal✓fullcommunity8/10

   Docs detail multiple quick registration paths (serial number usable immediately after unboxing, registration code, order number), no-code acceptance, and Dashboard-based reader/location management, directly matching the 'pair and take a payment within minutes' story. Community accounts corroborate that Terminal's hardware/API integration is powerful and solves real in-store pain points for merchants moving off legacy POS hardware. Missing for 10: independent hands-on timing evidence explicitly confirming a 'within minutes' setup experience.

   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”
   • [claimed-docs] “You must register your reader to a location to accept payments.”
   • [claimed-docs] “Use no-code options: Accept payments without building a custom POS integration.”
   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”
   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”
   • [community] “I am working with a company that has small physical stores processing hundreds of payments every day... having to rely on all the existing c…”

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

   Stripe's docs explicitly describe offline payment storage on POS device/smart reader with automatic forwarding once connectivity resumes, directly matching the story. Missing for 10: independent/hands-on merchant evidence corroborating real-world offline behavior and details on limits/timeouts of offline storage.

   • [claimed-docs] “If you have internet connectivity issues, Stripe Terminal allows you to store payments locally on your POS device or smart reader. When a ne…”
   • [claimed-docs] “If you have internet connectivity issues, Stripe Terminal allows you to store payments locally on your POS device or smart reader.”
   • [claimed-docs] “Stripe Terminal allows you to store payments locally on your POS device or smart reader. When a network connection is restored, the SDK or s…”
   • [claimed-docs] “Stripe Terminal allows you to store payments locally on your POS device or smart reader.”

   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 Stripe Terminal
   Stripe Terminal~partialcommunity7/10

   Stripe Terminal documents a full API-based integration path (reader registration/config via API, offline payment storage, receipts generated from API data, tips, refunds via API or Dashboard) and independent commentary confirms deep API-level control over terminal hardware, suggesting most Dashboard actions are API-accessible. However, some Dashboard-centric features (e.g., Smart Disputes automation, fleet monitoring dashboards) aren't explicitly confirmed as fully API-equivalent. Missing for 10: explicit API parity for dispute management/analytics dashboards, and stronger independent verification that every UI action has a documented API equivalent.

   • [claimed-docs] “Build a custom POS integration tailored to your business. Terminal supports an API-based integration in addition to SDKs for Android, iOS, J…”
   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [claimed-docs] “You can register readers using their serial number. This method doesn’t require someone to physically have the reader to register it, so you…”
   • [claimed-docs] “You can use Stripe’s prebuilt email receipts, or use receipt data from the Stripe API and your Terminal integration to generate on-brand cus…”
   • [claimed-docs] “You can register smart readers in one of three ways: - Registration code - Serial number - Order number”
   • [claimed-docs] “You can issue refunds by using the Refunds API or the Dashboard.”
   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”
   • [community] “We spent a lot of time building a terminal at Sidestep on top of Stripe (and a few other processors). The hardest part wasn't managing devic…”

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

   Stripe Terminal's evidence pack covers payments, hardware, receipts, offline mode, and Connect integration, but contains no mention of bulk data export in open formats (e.g., CSV/JSON exports of transaction/customer data) or any facility for a user to extract all their data and migrate away from the platform.

   ⚑ 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 to Stripe Terminal
   Stripe Terminal~partialclaimed3/10

   Stripe publishes open client SDK source (e.g., the Terminal JS SDK repo) and the OpenAPI spec repo, but the core Stripe Terminal service/backend and hardware firmware are proprietary and not available under an open license. missing for 10: no open-source license for the core Terminal service/backend, no evidence of an open license file on the SDK repos, no independent confirmation of full source availability beyond a thin client library.

   • [github] “Use the Terminal JS SDK as an ES module.”
   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”

   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 Stripe Terminal
   Stripe Terminal~partialclaimed4/10

   Stripe's general payouts docs confirm funds move from available balance to bank account and that Instant Payouts can be triggered anytime with funds landing in ~30 minutes, which would apply to Terminal-collected funds as well. However, this is generic Stripe platform documentation, not Terminal-specific, and there's no evidence of a dashboard view for tracking individual payout status/timing or an explicit next-day payout toggle description tied to in-person transactions. Missing for 10: Terminal-specific payout scheduling/dashboard visibility, explicit next-day payout option details, and any reconciliation UI tying Terminal transactions to payout batches.

   • [claimed-docs] “Stripe sends funds from your available balance to your bank account as payouts. With Instant Payouts you can send payouts any time, includin…”

   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 Stripe Terminal
   Stripe Terminal~partialprobed6/10

   Stripe's platform (which Terminal sits within) exposes a Payouts API, webhooks for real-time transaction events, and an official MCP server that lets AI agents call the Stripe API directly, which together could support an agent pulling transactions/payouts data programmatically. However, there is no Terminal-specific documentation or example of an agent-driven reconciliation workflow, ledger-matching, or 'daily takings' summary feature. Missing for 10: explicit reconciliation/ledger-matching tooling, a documented end-to-end example of an agent pulling Terminal transactions+payouts and reconciling them, and independent/hands-on evidence of this working in practice.

   • [claimed-docs] “The Stripe Model Context Protocol (MCP) server provides tools that AI agents can use to interact with the Stripe API and search Stripe’s kno…”
   • [claimed-docs] “Stripe sends funds from your available balance to your bank account as payouts. With Instant Payouts you can send payouts any time, includin…”
   • [claimed-docs] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [claimed-docs] “You can issue refunds by using the Refunds API or the Dashboard.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   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 Stripe Terminal
   Stripe Terminal~partialclaimed4/10

   Stripe docs confirm payouts (funds sent to bank accounts) and a unified Dashboard showing in-person and online payments together, which supports basic reconciliation, but there is no evidence of a dedicated itemized transaction/fee report or reconciliation tool tailored to Terminal payouts. missing for 10: itemized fee-report documentation, explicit payout-to-transaction reconciliation feature, and any reporting API/export evidence specific to Terminal.

   • [claimed-docs] “Stripe sends funds from your available balance to your bank account as payouts. With Instant Payouts you can send payouts any time, includin…”
   • [claimed-docs] “You can manage both in-person payments and online payments in a unified system in the Dashboard.”
   • [claimed-docs] “you can accept in-person payments and manage them alongside your online payments in Stripe”
   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”

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

   The evidence pack describes Stripe Terminal's SDKs, readers, offline handling, receipts, and fleet management, but nowhere does it mention PCI DSS, PCI scope, certified reader compliance guidance, or vendor documentation on the developer's remaining compliance obligations. missing for 10: any documentation of PCI DSS certification for Terminal readers, explicit vendor guidance on developer PCI scope reduction, and confirmation that card data never touches developer servers/code.

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

   No evidence anywhere in the pack addresses data residency, region selection, or data storage location controls for Stripe Terminal; the docs cover payments, receipts, offline storage of transactions, and fleet management but never data residency options.

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

   No evidence describes data retention controls, deletion mechanisms, or privacy-posture settings for Stripe Terminal data; evidence pack covers payments, hardware, receipts, and unrelated compliance/dispute topics only. Missing for 10: any documentation of data retention policy, customer data deletion API/process, or configurable retention windows.

   ⚑ 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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

   No evidence in the pack mentions telemetry opt-out or usage-tracking controls for Stripe Terminal; the docs cover payments, hardware, receipts, and MCP/agent tooling but nothing about disabling analytics/telemetry collection.

   ⚑ 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