Stripe Terminal vs Square

Onboarding

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

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

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

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

   proof ↗⚑ flag

   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

Payment methods

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

   weight 3 · round to Stripe Terminal
   Stripe Terminal✓fullcommunity9/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

   ⚑ flag

   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

Tap to pay

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

   weight 3 · round to Stripe Terminal
   Stripe Terminal✓fullclaimed9/10

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

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

   proof ↗⚑ flag

   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

Tipping

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

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

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

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

   proof ↗⚑ flag

   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

Agent access

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

   weight 2 · round drawn
   Stripe Terminal✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

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

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

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

   proof ↗⚑ flag

   Square—none0/10

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

   ⚑ flag

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

   weight 3 · round to Stripe Terminal
   Stripe Terminal✓fullprobed9/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

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

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stripe Terminal✓fullprobed8/10

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

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

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

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

   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

Agentic features

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

   ⚑ flag

   Square—none0/10

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

   ⚑ flag

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

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

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Stripe Terminal—none0/10

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

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

   proof ↗⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   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

Api quality

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

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

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

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

   proof ↗⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   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

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

   weight 1 · round to Square
   Stripe Terminal✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

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

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Stripe Terminal~partialclaimed5/10

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

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

   proof ↗⚑ flag

   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

Receipts

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

   weight 1 · round to Stripe Terminal
   Stripe Terminal✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

Custom checkout

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

   weight 2 · round drawn
   Stripe Terminal✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round to Stripe Terminal
   Stripe Terminal✓fullcommunity9/10

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

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

   proof ↗⚑ flag

   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

Payment events

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

   weight 2 · round drawn
   Stripe Terminal~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

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

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

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

   proof ↗⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   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

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

   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

Ai fleet ops

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

   weight 3 · round to Stripe Terminal
   Stripe Terminal✓fullprobed7/10

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

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

   proof ↗⚑ flag

   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

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

   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

Multi location

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

   weight 2 · round drawn
   Stripe Terminal~partialclaimed6/10

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

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

   proof ↗⚑ flag

   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

Readers

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

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

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

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

   proof ↗⚑ flag

   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

Offline

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

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

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

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

   proof ↗⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   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

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

   weight 3 · round to Square
   Stripe Terminal—none0/10

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

   ⚑ flag

   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

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

   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

Payouts

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

   weight 2 · round drawn
   Stripe Terminal~partialclaimed4/10

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

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

   proof ↗⚑ flag

   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

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

   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

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

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

   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

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

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

   ⚑ flag

   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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

   ⚑ flag

   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

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

   ⚑ flag

   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

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

   weight 2 · round drawn
   Stripe Terminal—none0/10

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

   ⚑ flag

   Square—none0/10

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

   ⚑ flag