Stripe Terminal vs SumUp

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

   Docs confirm hardware can be ordered, registered, and configured directly from the Dashboard (docs-32, docs-5, docs-20, docs-44) and that no-code options let a business start accepting payments immediately without building an integration (docs-21, docs-26, docs-31, docs-46). However, there is no evidence in the pack about the account sign-up/approval flow, KYC/underwriting timelines, or shipping speed that would substantiate 'approved and taking payments the same week.' missing for 10: evidence on account approval/underwriting turnaround, hardware shipping/delivery timelines, and independent confirmation of a same-week setup experience.

   • [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.”
   • [claimed-docs] “Accept in-person payments on a compatible reader using Stripe’s no-code solution.”
   • [claimed-docs] “you can use Terminal with no-code options, a custom point-of-sale (POS) integration, or supported third-party POS and gateway integrations”

   proof ↗⚑ flag

   SumUp—none0/10

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

   ⚑ flag

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 confirm chip/contactless via smart readers and Tap to Pay on iPhone (Apple Pay/Google Pay/contactless), SDKs across platforms, no-code options, and independent HN commentary corroborates real-world card-present integration usage. missing for 10: independent hands-on review confirming mobile-wallet (Apple/Google Pay) acceptance specifically, and no explicit third-party verification of chip transaction success.

   • [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] “Use Tap to Pay on iPhone to accept in-person contactless payments with a compatible iPhone”
   • [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] “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

   SumUp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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 addresses splitting a single sale across multiple payment methods or multiple payers (e.g., split tender). Stripe Terminal docs cover reader management, tipping, receipts, refunds, offline payments, and Connect integration, but none mention split-tender or multi-payer sale functionality.

   ⚑ flag

   SumUp—none0/10

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

   ⚑ flag

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 with no separate reader hardware required, including a no-code Dashboard mobile app option for founders who don't want to build custom integrations. Missing for 10: independent hands-on confirmation specifically of Tap to Pay (community evidence in the pack is about the physical reader hardware/API rather than the phone-only Tap to Pay flow).

   • [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] “Use Tap to Pay on iPhone to accept in-person contactless payments with a compatible iPhone”
   • [claimed-docs] “Looking for a no-code solution? Accept payments from the Stripe Dashboard mobile app.”
   • [claimed-docs] “Use no-code options: Accept payments without building a custom POS integration.”

   proof ↗⚑ flag

   SumUp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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 detail on-reader tipping (reader suggests tip percentages/amounts before payment) and on-receipt tipping, collected before or after authorizing a payment, directly matching the merchant-ops tipping configuration story. Missing for 10: no independent/hands-on confirmation of configuring specific percentage/smart-amount/custom-tip values in the Dashboard, and no evidence of granular UI screenshots or API parameter details for tip customization.

   • [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

   SumUp—none0/10

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

   ⚑ flag

Agent access

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

   weight 2 · round drawn
   Stripe Terminal✓fullprobed9/10

   Stripe hosts a live llms.txt at docs.stripe.com/llms.txt (HTTP 200) and provides machine-readable .md versions of docs pages (e.g., terminal.md), confirmed by direct probes, plus explicit agent-oriented documentation pages (agents.md, mcp.md) referencing AI-native workflows. Missing for 10: independent/hands-on confirmation that an agent successfully consumed llms.txt end-to-end rather than just the file's existence.

   • [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] “Agents and AI on Stripe: Build with agent-first developer tools, and sell agent-enabled products and services. Build your integration with a…”
   • [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…”

   proof ↗⚑ flag

   SumUp✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to SumUp
   Stripe Terminal~partialclaimed4/10

   Terminal provides a simulated card reader and API-based/server-driven integration so developers can test without physical hardware (stripe-terminal-docs-9, stripe-terminal-docs-48), which could support headless automated testing, and Stripe CLI can be scripted (stripe-terminal-docs-37). However, there is no explicit documentation of running Terminal integrations in CI pipelines or fully headless automated workflows beyond dev testing. missing for 10: explicit CI/automation pipeline documentation, evidence of unattended/headless production runs, independent confirmation of CI usage.

   • [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] “Before ordering a reader, test your integration with the reader simulator.”
   • [claimed-docs] “The Stripe CLI helps you build, test, and manage your Stripe integration right from the 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…”

   proof ↗⚑ flag

   SumUp~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to SumUp
   Stripe Terminal~partialprobed6/10

   Stripe (the parent platform that Terminal is built on) documents an official MCP server enabling AI agents to interact with the Stripe API and knowledge base, and this is confirmed live at docs.stripe.com/mcp. However, the evidence doesn't specify that Terminal-specific in-person payment/reader operations are exposed as MCP tools, so it's unclear how much of Terminal's functionality is agent-accessible via this server. Missing for 10: explicit confirmation that Terminal-specific APIs (readers, locations, offline payments) are covered by the MCP tool set, and independent/hands-on corroboration of agent usage against Terminal endpoints.

   • [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

   SumUp✓fullprobed8/10

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

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

   proof ↗⚑ flag

4. 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

   SumUp✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

   The evidence pack documents Stripe's general API access (CLI, OpenAPI spec, MCP server for agents) but contains no mention of scoped or restricted API keys, permission scoping, or least-privilege credential issuance mechanisms for agents. Missing for 10: any documentation of restricted API keys, role-based permissions, or scoped credential issuance for AI agents interacting with Stripe Terminal.

   ⚑ flag

   SumUp—none0/10

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

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

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stripe Terminal✓fullclaimed8/10

   Stripe Terminal ships official SDKs for Android, iOS, JavaScript, and React Native alongside an API-based integration path, with a public GitHub repo for the JS SDK confirming real developer tooling exists beyond just docs. Missing for 10: independent/hands-on developer corroboration for the iOS/Android SDKs and no AI-agent-specific SDK extension (the general MCP server is a separate, adjacent capability).

   • [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] “Deploy your Android POS app to Stripe smart readers.”

   proof ↗⚑ flag

   SumUp✓fullprobed8/10

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

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

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Stripe Terminal
   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

   SumUp~partialclaimed4/10

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

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

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Stripe Terminal
   Stripe Terminal~partialclaimed4/10

   Stripe Terminal integrations can react automatically to events via webhooks and offline payments auto-forward when connectivity resumes, and Stripe's broader platform offers agent-first tools (MCP server, agents.md) that could be used to build autonomous workflows. However, none of this evidence describes a dedicated 'set up an automation that runs autonomously in the background' capability specific to Terminal itself (e.g., scheduled jobs, agent-driven POS automation). Missing for 10: Terminal-specific automation/orchestration features, documented autonomous agent workflows tied to in-person payment flows, and independent confirmation of such automations working end-to-end.

   • [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] “Listen for events from Stripe on your webhook endpoint so your integration can automatically trigger reactions. You can create an HTTPS webh…”
   • [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…”
   • [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] “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

   SumUp—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   Stripe Terminal—none0/10

   The evidence pack shows Stripe has agent-facing tooling (MCP server, agent commerce docs) for AI agents to call Stripe's API, but nothing describes a built-in AI assistant inside Stripe Terminal that a user can delegate tasks to (e.g., a chat-based assistant in the Dashboard or POS app). This is a fair question for a Dashboard-based product, but no such capability is documented.

   • [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

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to SumUp
   Stripe Terminal~partialprobed3/10

   Stripe's platform-wide MCP server lets AI agents call the general Stripe API and search docs, and Stripe advertises 'agent-first developer tools,' but no evidence specifically shows natural-language control of Terminal (in-person payment/reader) operations rather than generic Stripe API usage. Missing for 10: Terminal-specific MCP tools or docs showing an agent issuing NL commands to readers, and hands-on/community confirmation that Terminal actions (charge, refund, reader management) can be driven conversationally.

   • [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

   SumUp~partialprobed7/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

   The evidence pack lists Stripe's OpenAPI spec repo and various docs, but nothing in the pack confirms an interactive API reference with runnable/try-it code examples for Terminal; a probe for openapi.json/swagger.json endpoints even returned 404s, and no docs entry describes an interactive reference explorer.

   • [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

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

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

   Stripe publishes an official OpenAPI specification repository for its API (which Terminal is built on) at github.com/stripe/openapi, machine-readable and maintained, though direct probe attempts at docs.stripe.com/openapi.json returned 404s, indicating it's hosted separately rather than at a predictable docs endpoint. Missing for 10: a direct discoverable link from Terminal-specific docs to the spec, and confirmation the spec covers Terminal endpoints specifically.

   • [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

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

   weight 1 · round to SumUp
   Stripe Terminal~partialclaimed6/10

   Stripe Terminal docs confirm a built-in simulated card reader and reader simulator for developing/testing without physical hardware, and Stripe's broader test-mode/sandbox concept (API keys, test data) is implied but not explicitly detailed for Terminal beyond hardware simulation. missing for 10: explicit documentation of a full sandbox/test-mode environment covering data isolation (test vs live API keys), independent hands-on confirmation of sandbox fidelity for AI-driven testing, and any AI-native tooling specifically validating sandbox 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] “Before ordering a reader, test your integration with the reader simulator.”

   proof ↗⚑ flag

   SumUp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Terminal
   Stripe Terminal~partialclaimed4/10

   Evidence shows Stripe Terminal SDKs are versioned (a documented v5.0.0 migration guide) and a public OpenAPI spec repo exists, implying some API versioning discipline, but there is no explicit documented deprecation policy, versioning cadence, or sunset timeline provided in the evidence pack. missing for 10: explicit deprecation policy documentation, API version lifecycle/support timeline, sunset notices for older Terminal API versions.

   • [claimed-docs] “Learn how to migrate to version 5.0.0 of the Stripe Terminal SDK.”
   • [claimed-docs] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”

   proof ↗⚑ flag

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to SumUp
   Stripe Terminal—none0/10

   Stripe Terminal's docs describe fleet management (registering/monitoring multiple readers via locations and zones) and API-based integration, but there is no evidence of a bulk/batch API for processing many payments, refunds, or reader operations in a single call as an AI agent would need. missing for 10: batch/bulk API endpoints, documented multi-item operation examples, evidence of programmatic bulk processing.

   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [claimed-docs] “Reader management: Order, register, configure, and monitor readers from the Dashboard.”
   • [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…”

   proof ↗⚑ flag

   SumUp~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Terminal
   Stripe Terminal~partialclaimed5/10

   Stripe's webhooks documentation explicitly supports automatic reactions to events (docs-38), and Smart Disputes automates part of the dispute workflow (docs-40), giving a basic event-triggered automation capability. However, this is a raw webhook/event system requiring custom code rather than a declarative rules engine an AI-native user could configure directly, and there's no Terminal-specific rules/automation builder. Missing for 10: a no-code or declarative rule-definition interface, Terminal-specific event-trigger examples, and independent/hands-on evidence of automation reliability.

   • [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

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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 customers a physical or email receipt, provide prebuilt email receipts that already include all card-network-required fields, and allow custom-branded receipts that still list required information—directly matching the story. Missing for 10: independent/hands-on verification of receipt compliance and details on printed receipt formatting beyond the API/customization docs.

   • [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

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

   Official docs confirm dedicated iOS and Android SDKs for Terminal, alongside JS/React Native, enabling developers to embed custom in-person payment flows including reader management, offline support, tipping, and testing simulators. Community evidence corroborates real-world use of the API-based integration for building custom POS apps on Stripe's stack. Missing for 10: independent hands-on verification specifically of the iOS/Android SDK integration experience (most community evidence discusses the broader Terminal API/hardware rather than the mobile SDKs specifically).

   • [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] “Deploy your Android POS app to Stripe smart readers.”
   • [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] “If you have internet connectivity issues, Stripe Terminal allows you to store payments locally on your POS device or smart reader. When a ne…”
   • [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

   SumUp✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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 describe API-based custom POS integration (server-driven, no SDK required) alongside SDKs for Android/iOS/JS/React Native, plus built-in reader simulator for testing without hardware, and community evidence (Sidestep) confirms real-world developers built custom terminal integrations directly on Stripe's API. missing for 10: no independent hands-on report specifically validating the server-driven (SDK-less) API path in production.

   • [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 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 use Terminal with no-code options, a custom point-of-sale (POS) integration, or supported third-party POS and gateway integrations”
   • [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

   SumUp✓fullprobed8/10

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

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

   proof ↗⚑ flag

Payment events

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

   weight 2 · round to Stripe Terminal
   Stripe Terminal~partialclaimed6/10

   Stripe's general webhook system (docs-38) lets developers subscribe to real-time events, and Stripe documents refunds (docs-24/28) and disputes (docs-40) as distinct API/dashboard flows that would generate corresponding events; since Terminal payments use the core PaymentIntent/Charge objects, these lifecycle events apply to it. However, the evidence never explicitly enumerates Terminal-specific webhook event names (e.g., a documented list of 'authorized', 'captured', 'refunded', 'disputed' events for terminal reader payments) or shows an example webhook payload tied to Terminal transactions. Missing for 10: explicit Terminal-context webhook event list/examples, confirmation of 'authorized' and 'captured' as distinct fired events for in-person payments, and independent developer corroboration of using webhooks specifically with 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…”
   • [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

   SumUp~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   Docs explicitly state Terminal SDKs and server-driven integration come with a built-in simulated card reader for development/testing without physical hardware, and recommend testing with the reader simulator before ordering a physical reader. Missing for 10: independent/hands-on developer corroboration of the simulator workflow and details on simulated test card scenarios (e.g., specific decline/edge-case simulation coverage).

   • [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] “Before ordering a reader, test your integration with the reader simulator.”

   proof ↗⚑ flag

   SumUp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   Stripe (the platform Terminal sits on) exposes a Disputes object/API, webhook events for real-time notifications, and even 'Smart Disputes' to automate evidence collection, plus an official MCP server letting AI agents call the Stripe API — together these could support an agent watching dispute deadlines and preparing evidence. But nothing describes deadline-specific webhook triggers, an agent drafting evidence for human review (Smart Disputes is described as automating submission, not human-reviewed drafts), and none of this is Terminal-specific functionality. Missing for 10: explicit dispute-deadline webhook/event documentation, agent-drafted-evidence-for-review workflow, and Terminal-specific dispute handling.

   • [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…”
   • [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] “You can issue refunds by using the Refunds API or the Dashboard.”

   proof ↗⚑ flag

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Terminal
   Stripe Terminal~partialclaimed5/10

   Stripe's platform docs describe a Dashboard-guided dispute process and 'Smart Disputes' automation for evidence collection/submission (docs-40), which would apply to Terminal-processed payments as part of the broader Stripe account. However, the evidence is generic Stripe documentation (not Terminal-specific) and never details chargeback notification mechanisms, deadline tracking, or how disputes surface for in-person transactions specifically. missing for 10: explicit notification/alerting for new disputes, deadline visibility, Terminal-specific dispute workflow details, independent/hands-on confirmation.

   • [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

   SumUp—none0/10

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

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

   proof ↗⚑ flag

Refunds

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

   weight 2 · round to Stripe Terminal
   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

   SumUp~partialclaimed6/10

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

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

   proof ↗⚑ flag

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✓fullcommunity7/10

   Stripe's docs explicitly describe an API-based approach to managing multiple locations and registering readers (via serial number, registration code, or order number), and require reader-to-location registration for payments—covering both halves of the story. Community evidence (stripe-terminal-comm-1) corroborates that full API-level integration for terminal/location management is a real, valued capability. Missing for 10: a concrete end-to-end code/agent example combining location creation + reader registration in one API workflow, and no direct evidence of an AI agent performing this specific provisioning flow (the MCP server exists but isn't shown driving Terminal fleet setup).

   • [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”
   • [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…”
   • [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…”

   proof ↗⚑ flag

   SumUp—none0/10

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

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

   proof ↗⚑ flag

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

   SumUp~partialclaimed3/10

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

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

   proof ↗⚑ flag

Multi location

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

   weight 2 · round to Stripe Terminal
   Stripe Terminal~partialclaimed6/10

   Docs confirm locations/zones for managing readers across multiple physical sites, reader registration tied to a location, and unified Dashboard reporting for in-person and online payments, which supports multi-location fleet management. However, there is no explicit evidence of per-location settings customization (e.g., location-specific tax, receipt, or tipping configs) or per-location reporting breakdowns beyond the general unified Dashboard. missing for 10: explicit per-location settings/config differentiation, per-location reporting/analytics breakdown, independent hands-on validation of multi-location fleet workflows at scale.

   • [claimed-docs] “You can streamline the management of multiple readers across different physical sites by using locations and zones.”
   • [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 manage both in-person payments and online payments in a unified system in the Dashboard.”
   • [claimed-docs] “You can manage both in-person payments and online payments in a unified system in the Dashboard”

   proof ↗⚑ flag

   SumUp—none0/10

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

   ⚑ flag

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 registration methods (serial number, registration code, order number) that work immediately after unboxing, plus no-code Dashboard app and Tap to Pay options for taking a payment quickly, and fleet management via locations/zones. Community evidence corroborates real-world use for in-store payment acceptance. Missing for 10: independent hands-on account of actual pairing time/setup friction and no direct evidence of 'within minutes' onboarding speed claims being verified by third parties.

   • [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] “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] “Accept in-person payments on a compatible reader using Stripe's no-code solution.”
   • [claimed-docs] “Looking for a no-code solution? Accept payments from the Stripe Dashboard mobile app.”
   • [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

   SumUp~partialclaimed6/10

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

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

   proof ↗⚑ flag

Offline

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

   weight 2 · round drawn
   Stripe Terminal✓fullclaimed8/10

   Stripe's docs explicitly describe the offline-reliability capability: payments are stored locally on the POS device or smart reader when connectivity drops and automatically forwarded once the network is restored, matching the story closely. Missing for 10: independent/hands-on confirmation of this specific offline-and-forward behavior beyond first-party docs, and details on limits (e.g., how long/how many transactions can be queued offline).

   • [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

   SumUp✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Terminal
   Stripe Terminal~partialclaimed7/10

   Stripe Terminal exposes a broad API surface (custom POS integration, reader registration via serial/registration/order number, locations/zones fleet management, tips, receipts, refunds via Refunds API) that mirrors most Dashboard/UI capabilities, and Stripe's own OpenAPI spec exists for programmatic access. However, some flows (e.g., ordering readers, Smart Disputes automation, reader monitoring/configuration UI) are described as Dashboard-centric without explicit API equivalents, and no-code options are positioned as UI-first rather than API-parity features. Missing for 10: explicit API equivalents for reader ordering/monitoring dashboard actions, confirmation that Smart Disputes and other dashboard-only workflows are fully API-accessible, and independent hands-on verification of full parity.

   • [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 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.”
   • [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] “Stripe's OpenAPI Specification: This repository contains OpenAPI specifications for Stripe's API.”

   proof ↗⚑ flag

   SumUp~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Terminal—none0/10

   The evidence pack covers Stripe Terminal's hardware, SDKs, offline payments, receipts, and API access, but contains no mention of bulk data export tools, open-format export of transaction/customer data, or any data-portability/exit guarantee for merchants using Terminal.

   ⚑ flag

   SumUp—none0/10

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

   ⚑ flag

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

   SumUp—none0/10

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

   ⚑ flag

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 docs confirm Instant Payouts (funds within ~30 minutes, including weekends/holidays) as an accelerated payout option [stripe-terminal-docs-39], but there is no evidence of a dashboard view showing exact payout landing times/schedules or an explicit next-day payout toggle. missing for 10: dashboard payout-timing visibility, next-day payout details, independent confirmation of speed.

   • [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

   SumUp—none0/10

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

   ⚑ flag

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

   SumUp~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   SumUp—none0/10

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

   ⚑ flag

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

   Stripe Terminal's architecture — certified smart readers/Tap to Pay/SDKs that capture card data directly on the device rather than passing it through the merchant's own systems (docs-1, docs-18, docs-19, docs-26, docs-46) — inherently supports minimized PCI scope, and this is the standard value proposition of a certified terminal solution. However, the evidence pack contains no explicit vendor documentation mentioning PCI DSS, SAQ levels, or specific guidance on the developer's remaining compliance obligations. Missing for 10: explicit PCI compliance/SAQ documentation, statement of certified reader PCI validation, and guidance on merchant's residual PCI responsibilities.

   • [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] “Accept contactless payments using a compatible iPhone or Android device with the Stripe Terminal SDK.”
   • [claimed-docs] “Accept in-person payments on a compatible reader using Stripe's no-code solution.”
   • [claimed-docs] “you can use Terminal with no-code options, a custom point-of-sale (POS) integration, or supported third-party POS and gateway integrations”
   • [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

   SumUp~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

   No evidence in the pack mentions data residency, regional data storage, or any control over where Stripe Terminal data is stored; the axis is applicable to a payments platform handling customer/transaction data, but nothing addresses it.

   ⚑ flag

   SumUp—none0/10

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

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Terminal—none0/10

   The evidence pack covers payment processing, receipts, refunds, disputes, and MCP/agent tooling, but contains no documentation about data retention policies, deletion controls, or privacy/data lifecycle management for Terminal transaction or customer data. Missing for 10: data retention policy docs, data deletion/export API or dashboard controls, GDPR/CCPA compliance mechanisms specific to Terminal data.

   ⚑ flag

   SumUp—none0/10

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

   ⚑ flag