Square 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 Square
   Square~partialcommunity4/10

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

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

   proof ↗⚑ flag

   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 drawn
   Square✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Build eCommerce applications to help sellers manage key aspects of their business.”
   • [claimed-docs] “Design a Catalog”
   • [claimed-docs] “Inventory API”
   • [claimed-docs] “Create Orders”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “Square Model Context Protocol Server”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.squareup.com/llms.txt # Square Developer Platform > Square APIs and SDKs for accepting paymen…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 Square
   Square~partialprobed3/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Square~partialprobed4/10

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

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

   proof ↗⚑ flag

   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 to Square
   Square~partialprobed4/10

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

   • [claimed-docs] “Test in Sandbox”
   • [claimed-docs] “The Connect Examples are working sample applications that you can copy from to build your own.”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”
   • [probe] “PROBE docs-md: HTTP 404 at https://developer.squareup.com/docs.md”

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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

Catalog

1. merchant-ops userManage an item catalog with inventory counts that stay in sync across registers and channels

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square documents a dedicated Catalog API for item/modifier management and an Inventory API explicitly for tracking counts, plus multi-location support (Locations API) and marketing copy touting 'Track inventory' across the business, implying sync across registers/channels. missing for 10: no explicit hands-on/independent verification that inventory sync across multiple registers/channels works reliably in practice, and no detail on conflict resolution or real-time sync guarantees.

   • [claimed-docs] “Design a Catalog”
   • [claimed-docs] “Inventory API”
   • [claimed-docs] “Learn how to use a Square API to update and retrieve location information for a Square seller.”
   • [claimed-docs] “Newly created accounts only have this single location, but more locations can be created.”
   • [claimed-docs] “Track inventory”
   • [claimed-docs] “Create Orders”

   proof ↗⚑ flag

   SumUp—none0/10

   Evidence covers payment processing, checkout, terminal readers, refunds, webhooks, and SDKs, but nothing describes an item/product catalog with inventory counts synced across registers and channels — a core POS/inventory feature is absent from all provided documentation.

   ⚑ flag

Receipts

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

   weight 1 · round to Square
   Square~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   • [claimed-docs] “Tip money: Collect tips as money at checkout. Supports showing a separate tip input screen before getting a buyer's signature and allowing c…”
   • [claimed-docs] “Process payments on Square hardware or online using any Internet-connected device.”
   • [claimed-docs] “Create Orders”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Test in Sandbox”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.squareup.com/llms.txt # Square Developer Platform > Square APIs and SDKs for accepting paymen…”

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 drawn
   Square~partialcommunity6/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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 to Square
   Square~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

   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