Square vs Polar

Agent access

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

   weight 2 · round drawn
   Square✓fullprobed9/10

   Square publishes a live, verified llms.txt (probe confirms HTTP 200) explicitly designed for AI agents, with agent-specific guidance on idempotency keys, pagination, and instructions to fetch llms-full.txt or per-page .md files instead of loading the whole corpus; docs pages also render as raw markdown. This is corroborated by an independent probe hit. missing for 10: no independent third-party (non-vendor) confirmation that agents successfully consume this file in practice, and the docs.md/openapi fallback endpoints 404 rather than existing.

   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [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 docs-md: HTTP 404 at https://developer.squareup.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”

   proof ↗⚑ flag

   Polar✓fullprobed9/10

   Polar publishes an llms.txt at /docs/llms.txt (also live-probed at /llms.txt returning HTTP 200) with .md siblings for every doc page and versioned OpenAPI specs, explicitly designed for agent legibility; this is corroborated by a direct probe hit. Missing for 10: independent third-party confirmation that AI agents actually consume these docs successfully in practice (only first-party docs and probes provided), and the root-level docs.md probe returned 404, showing coverage isn't perfectly uniform across all URL patterns.

   • [claimed-docs] “Migrate to Polar: Get set up on Polar in minutes from an existing store”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://polar.sh/llms.txt # Polar > Payments & Billing with 6 lines of code. Open Source & Global Merchant of R…”
   • [probe] “PROBE docs-md: HTTP 404 at https://polar.sh/docs.md”

   proof ↗⚑ flag

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

   weight 2 · round to Square
   Square~partialclaimed6/10

   Square's platform is fundamentally API/SDK-driven (Node.js SDK, REST/GraphQL APIs, idempotency keys) and ships a dedicated Sandbox environment explicitly for testing automation, plus a local MCP server mode (`npx square-mcp-server start`) with env-var controls like SANDBOX=true and DISALLOW_WRITES=true that suit scripted/CI use. However, there is no explicit CI/CD pipeline documentation, GitHub Actions integration, or hands-on evidence of running Square headlessly in an actual CI pipeline. Missing for 10: explicit CI/pipeline integration guides, documented headless automation examples beyond sandbox testing, independent confirmation of CI usage.

   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Square Sandbox”
   • [claimed-docs] “Idempotency”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [github] “const client = new SquareClient({ token: "YOUR_TOKEN" });”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar exposes a full API/SDKs (Python, TypeScript), a CLI (`polar listen` for webhook forwarding) and an isolated sandbox environment for testing without live money, all of which could be scripted into CI pipelines, and its OpenAPI/llms.txt makes it machine-legible for automation. However there is no explicit documentation of running Polar itself headlessly or CI/CD integration guidance (e.g., GitHub Actions examples, automated test suites against sandbox). missing for 10: explicit CI/CD pipeline documentation or examples, statement of headless/automation mode, independent evidence of running the CLI/SDKs unattended in a build pipeline.

   • [claimed-docs] “polar listen http://localhost:3000/”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Square✓fullprobed9/10

   Square documents an official hosted remote MCP server (mcp.squareup.com/mcp) with OAuth-based scoped auth plus an open-source local server, both exposing the full Square API platform, and provides setup guidance for Claude, Cursor, Windsurf, Goose. This is well-documented first-party evidence with a public GitHub repo, though independent hands-on user validation is limited. Missing for 10: independent/community confirmation of real-world agent usage beyond vendor docs.

   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “npx square-mcp-server start”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “The remote MCP is recommended as it uses OAuth authentication, allowing you to log in with your Square account directly without having to cr…”
   • [probe] “official MCP server documented at https://developer.squareup.com/docs/mcp”

   proof ↗⚑ flag

   Polar✓fullprobed9/10

   Polar (a SaaS billing platform, not itself an agent) documents an official remote MCP server with production and sandbox endpoints, OAuth-based auth, and setup instructions for Cursor, Claude Code, ChatGPT, and Claude Desktop, letting agents securely act on the organization's data. Missing for 10: independent/community hands-on confirmation beyond vendor docs and probes.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Polar
   Square—none0/10

   Square's evidence shows an MCP server, SDKs, GraphQL, and API Explorer, but no dedicated official CLI tool (e.g., a 'square' command-line utility for managing resources, testing APIs, or agentic workflows) is documented anywhere in the pack. The `npx square-mcp-server start` command is for launching an MCP server, not a general-purpose CLI.

   • [claimed-docs] “npx square-mcp-server start”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs.”

   proof ↗⚑ flag

   Polar~partialclaimed4/10

   The docs show a single CLI invocation, `polar listen http://localhost:3000/`, implying an official Polar CLI for local webhook forwarding/testing, but there's no dedicated CLI reference page, installation instructions, or list of subcommands beyond this one snippet. missing for 10: CLI installation/setup docs, full command reference, independent confirmation of broader CLI usage.

   • [claimed-docs] “polar listen http://localhost:3000/”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Square✓fullprobed9/10

   Square publishes an extensive documented public REST API (payments, refunds, disputes, subscriptions, invoices, webhooks) plus GraphQL, SDKs (e.g. square-nodejs-sdk), API Explorer, sandbox testing, OAuth scopes, and an explicit llms.txt/llms-full.txt agent-consumption index with agent-specific guidance (idempotency keys, pagination) — directly supporting AI-native, agentic driving of the product. Missing for 10: no public OpenAPI/swagger spec discoverable (probe returned 404s), and no independent third-party corroboration beyond vendor docs.

   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”
   • [claimed-docs] “Square access is scope-controlled: "Access tokens are credentials that allow applications to securely interact with Square APIs. An access t…”
   • [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…”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”

   proof ↗⚑ flag

   Polar✓fullprobed9/10

   Polar publishes a documented, versioned OpenAPI 3.1 spec, official typed SDKs (TypeScript/Python), webhooks, and llms.txt/agent-legible docs, giving AI-native users a fully documented public API surface to drive the product programmatically. missing for 10: independent third-party corroboration of the API's stability/completeness beyond first-party docs, and the probe showing openapi.json not reachable at the root domain (spec is only under /docs).

   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://polar.sh/llms.txt # Polar > Payments & Billing with 6 lines of code. Open Source & Global Merchant of R…”

   proof ↗⚑ flag

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

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square supports OAuth with per-permission scopes for granular access control, and its remote MCP server explicitly uses OAuth login to 'authorize only the scopes your application needs' for agent connections; the local MCP server also supports a DISALLOW_WRITES read-only mode and SANDBOX flag for least-privilege agent setups. Missing for 10: no independent/hands-on verification of scope granularity in practice, and no explicit documentation of fine-grained scope lists specifically tailored for agent use cases beyond general OAuth scopes.

   • [claimed-docs] “Square access is scope-controlled: "Access tokens are credentials that allow applications to securely interact with Square APIs. An access t…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”
   • [claimed-docs] “The remote MCP is recommended as it uses OAuth authentication, allowing you to log in with your Square account directly without having to cr…”

   proof ↗⚑ flag

   Polar~partialprobed5/10

   Polar's MCP server uses OAuth so agents authorize access to an organization via browser rather than embedding a raw API key, which is a step toward safer agent credentialing, but the docs describe org-level authorization only, not fine-grained/least-privilege scopes (e.g., read-only vs write, per-resource permissions) for issuing agent-specific credentials. Missing for 10: documented scope/permission granularity for API keys or OAuth tokens, ability to restrict an agent to specific resources/actions, and any explicit 'least privilege' credential-issuance workflow.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Square✓fullclaimed8/10

   Square ships official, first-party SDKs (e.g. square-nodejs-sdk/TypeScript library) with documented code examples for payments, versioning, and client setup, plus broader API coverage (REST, GraphQL, OAuth, webhooks, sandbox) that AI-native developers can build against, reinforced by an explicit llms.txt/agent-guidance file and an official MCP server for programmatic AI tool access. Missing for 10: independent/hands-on developer corroboration of SDK quality beyond GitHub README snippets, and broader multi-language SDK evidence beyond Node/TypeScript.

   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [github] “await client.payments.create(..., { version: "2024-05-04" // override the version used })”
   • [github] “const client = new SquareClient({ token: "YOUR_TOKEN" });”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar documents official TypeScript and Python SDKs with full type safety, fully typed sync/async clients, framework adapters, versioned OpenAPI specs, and machine-legible llms.txt docs—clear support for AI-native developers building against official SDKs. missing for 10: independent third-party corroboration of SDK quality/coverage beyond vendor docs, and the openapi probe found no public root-level spec (though versioned specs are documented within docs).

   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Framework adapters make it dead simple to add Polar checkouts and webhooks to your stack.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Our TypeScript & Python SDKs come with a built-in helper function to easily validate and parse the webhook event”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Polar
   Square✓fullclaimed8/10

   Square provides a documented Webhooks system with subscribing to event notifications, verifying/validating events, sandbox testing, and event logs — a standard webhook mechanism usable by any AI-native integration (including via its MCP server/API access). missing for 10: no explicit example of an AI agent programmatically subscribing to webhooks, and no independent hands-on corroboration beyond first-party docs.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “[Verify and Validate an Event Notification](/docs/webhooks/step3validate)”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

   Polar provides comprehensive webhook subscription support: documented endpoint configuration, async event notifications instead of polling, Standard Webhooks spec compliance, typed payloads, signature validation SDK helpers, local testing via `polar listen`, and CRUD API for webhook endpoints — directly enabling event-driven/agentic integration patterns. missing for 10: independent third-party corroboration of webhook reliability at scale beyond vendor docs.

   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Our TypeScript & Python SDKs come with a built-in helper function to easily validate and parse the webhook event”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates... our webhooks offer built-in support for Slack & …”
   • [claimed-docs] “polar listen http://localhost:3000/”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “Customer State is a concept allowing you to query for the current state of a customer, including their active subscriptions and granted bene…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square AI (Beta) is a first-party in-product assistant that answers natural-language questions over the seller's own sales/inventory data, surfaces proactive insights, and even pulls in web data (weather, events, reviews), with seller testimonials confirming real use for sales analysis. Missing for 10: independent/third-party validation beyond vendor testimonials and more detail on breadth/accuracy of suggestions across all data types.

   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”
   • [claimed-docs] “Square AI | Unlock Growth with AI-Powered Insights”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's evidence covers billing, checkout, usage metering, webhooks, and an MCP server for external agent access, but nothing describes the product itself generating AI insights, suggestions, or analytics narratives from customer/revenue data for the user inside the dashboard.

   ⚑ flag

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

   weight 2 · round to Polar
   Square~partialclaimed4/10

   Square provides building blocks (Webhooks for event-driven triggers, Subscriptions API for recurring billing, and an MCP server letting AI tools call the API) that a developer could wire into an autonomous background automation, but there is no evidence of a native workflow/automation engine or scheduled-agent feature that runs independently without custom integration work. Square AI is described as an on-demand insight assistant, not an autonomous background automation runner. Missing for 10: a documented no-code/low-code automation or workflow builder, evidence of scheduled/triggered autonomous agent execution, and confirmation that MCP-driven agents can run unattended in the background rather than only via an interactive AI client.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “Subscriptions API”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar ships genuine autonomous background automations — automated dunning/payment retries on a fixed schedule, automatic subscription renewal and proration, async webhooks instead of polling, and usage meters that compute continuously — and its MCP server lets AI agents take actions on the account. However, none of this is presented as a user-configurable 'automation builder' or agent-driven workflow scheduler; the autonomy is built into Polar's own billing engine rather than something the AI-native user 'sets up' themselves. Missing for 10: evidence of user-defined trigger/action automation rules, scheduled/cron-like agent workflows, or any explicit 'automation' feature beyond fixed billing/dunning logic.

   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “Polar renews it automatically. At the end of each billing period, Polar advances the subscription to the next cycle and creates a new order”
   • [claimed-docs] “You pick the proration behavior either at the organization level (as the default) or per API call.”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Polar has a powerful Usage Based Billing infrastructure that allows you to charge your customers based on the usage of your application.”

   proof ↗⚑ flag

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

   weight 3 · round to Square
   Square✓fullclaimed7/10

   Square AI (Beta) is documented as an in-product assistant built into seller tools that answers natural-language questions over sales/inventory data, handles routine tasks, and pulls in web data, with seller testimonials of real usage. Missing for 10: independent/hands-on verification beyond vendor testimonials, and detail on the breadth of tasks it can autonomously execute versus just answer questions.

   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”
   • [claimed-docs] “Square AI | Unlock Growth with AI-Powered Insights”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's evidence shows an MCP server that lets external AI agents connect to Polar's data/actions (polar-docs-24, polar-supp-mcp), which is the reverse of the story — it's Polar being used as a tool by outside agents, not a built-in assistant inside Polar's own product that a user can delegate tasks to. No evidence of any in-product chat/assistant UI exists in the pack.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Square~partialclaimed7/10

   Square ships a first-party beta 'Square AI' seller assistant for natural-language queries over sales/inventory data, and a documented MCP server (local + hosted, OAuth-scoped) that lets AI agents like Claude/Cursor issue natural-language-driven API calls (payments, orders, catalog, etc.) via discovery tools. This gives real NL-command operability, but it's split across a beta insights assistant (limited to analysis/reporting) and third-party agent integration (MCP) rather than a single native NL control surface for all product actions. Missing for 10: evidence that Square AI itself can execute broad write/operational commands (not just analysis), and independent/hands-on validation of MCP agent workflows beyond vendor docs.

   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “Square AI | Unlock Growth with AI-Powered Insights”

   proof ↗⚑ flag

   Polar✓fullprobed8/10

   Polar ships a documented remote MCP server (OAuth-secured) that lets AI agents look up data and take actions across products, customers, subscriptions, orders, and benefits, with explicit setup for Claude Code, Cursor, ChatGPT, and Claude Desktop — enabling natural-language operation of the product via an agent client. Missing for 10: independent/hands-on validation of the MCP server working in practice and concrete examples of successful natural-language command execution beyond vendor docs.

   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [probe] “official MCP server documented at https://polar.sh/docs/integrate/mcp”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Square
   Square✓fullprobed8/10

   Square documents a genuine interactive API Explorer that builds/sends real HTTP requests against Sandbox or production resources (customers, orders, catalog), plus a GraphQL Explorer for runnable queries, giving developers a hands-on interactive reference. Missing for 10: no independent/third-party corroboration of the API Explorer's usability and no discoverable OpenAPI spec (probe confirms 404s), so tooling depth is documented only by the vendor.

   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”
   • [claimed-docs] “API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs.”
   • [claimed-docs] “API Explorer lets you test your requests using actual Sandbox or production resources in your account such as customers, orders, and catalog…”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.squareup.com/openapi.json, https://developer.squareup.com/swagger.json, https://de…”

   proof ↗⚑ flag

   Polar~partialprobed5/10

   Polar publishes versioned OpenAPI specs and machine-readable docs (llms.txt/.md pages) plus a sandbox environment for testing API calls with test cards, which supports API exploration, but there is no evidence of an actual interactive API reference UI (e.g., a Swagger/Redoc-style console) with embedded runnable examples directly in the docs. Missing for 10: an in-docs interactive 'try it' console, embedded runnable code examples per endpoint, and independent confirmation the OpenAPI spec renders as an explorable reference.

   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Square—none0/10

   No documentation page or probe in the evidence pack shows a downloadable OpenAPI/Swagger spec; explicit probes for common OpenAPI paths (openapi.json, swagger.json, etc.) all returned 404, and no docs page links to a machine-readable spec file (only an interactive API Explorer, GraphQL schema, and SDKs are mentioned).

   • [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”
   • [claimed-docs] “API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs.”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

   Polar✓fullprobed7/10

   Polar's docs explicitly state it serves versioned OpenAPI 3.1.0 specs (2026-04.openapi.json, 2026-10.openapi.json) directly from the docs site alongside llms.txt and per-page .md files, giving AI-native users machine-readable spec access. However, probes only tested root-domain paths (polar.sh/openapi.json etc., all 404) rather than the actual documented docs-site paths, so there's no independent confirmation of a successful direct download. Missing for 10: independent verification of the exact documented OpenAPI URL resolving successfully, and no mention of spec discoverability via standard well-known paths.

   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://polar.sh/llms.txt # Polar > Payments & Billing with 6 lines of code. Open Source & Global Merchant of R…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 1 · round to Polar
   Square✓fullclaimed8/10

   Square documents a dedicated Sandbox environment (square-docs-21, square-docs-40) with sandbox testing for disputes/payments, and the API Explorer and MCP server explicitly support running against Sandbox resources instead of production (square-docs-48, square-supp-api-explorer, square-supp-mcp-remote with 'run a local instance configured to access a seller's Sandbox environment', and SANDBOX=true env var in square-supp-mcp-tools). This directly enables AI-native agents to test without touching production data. Missing for 10: independent/hands-on confirmation that sandbox parity with production is complete and that MCP sandbox mode is broadly validated by third-party users rather than only vendor docs.

   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Square Sandbox”
   • [claimed-docs] “API Explorer lets you test your requests using actual Sandbox or production resources in your account such as customers, orders, and catalog…”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

   Polar documents a fully isolated sandbox environment (separate server, unlimited test accounts/orgs) that supports end-to-end testing including checkout with Stripe test cards, explicitly to avoid touching production data or money — and a dedicated sandbox MCP endpoint further supports AI-agent testing workflows. missing for 10: independent/hands-on third-party confirmation beyond vendor docs.

   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [claimed-docs] “To test Polar or work on your integration without worrying about actual money processing or breaking your live organization, you can use our…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”

   proof ↗⚑ flag

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

   weight 2 · round to Square
   Square~partialclaimed5/10

   Square's API clearly supports date-based versioning — SDK calls can override the API version ("version: '2024-05-04'") and the MCP tool documents a SQUARE_VERSION pinning control — showing a live, explicit versioning scheme. However, no evidence in the pack shows a documented deprecation policy (timelines, sunset notices, migration guides) that would let an AI-native user reliably plan around version lifecycle changes. Missing for 10: an explicit deprecation/sunset policy document, version changelog, or migration guidance referenced anywhere in the evidence.

   • [github] “await client.payments.create(..., { version: "2024-05-04" // override the version used })”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Idempotency”

   proof ↗⚑ flag

   Polar~partialprobed4/10

   Evidence shows Polar publishes dated, versioned OpenAPI specs (2026-04.openapi.json and 2026-10.openapi.json) alongside machine-readable docs (llms.txt), indicating an API versioning scheme exists. However, no evidence describes an explicit deprecation policy, sunset timelines, or migration guidance between API versions; probes for a root-level openapi.json also 404 outside the documented docs-site paths. Missing for 10: documented deprecation/sunset policy, version lifecycle timelines, migration guides between dated API versions, independent confirmation of long-term version support.

   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square—none0/10

   The evidence pack shows GraphQL reducing multiple API calls into one query (square-docs-41/square-supp-graphql) and a generic MCP `make_api_request` tool, but no documentation or example of true bulk/batch operations (e.g., batch-upserting catalog items, bulk inventory adjustments, or bulk order processing) that would let an AI-native user act across many items in one call.

   • [claimed-docs] “One GraphQL query can retrieve data that requires multiple Square API calls.”
   • [claimed-docs] “Square ships a GraphQL API alongside REST: "GraphQL queries can improve performance and reduce development time by letting you request exact…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's docs describe individual resource APIs, webhooks, SDKs, and an MCP server for agents to look up/take actions, but nothing in the evidence pack describes batch or bulk endpoints (e.g., bulk refunds, bulk customer/product updates, batch import) that would let an AI-native user act on many items in one call.

   ⚑ flag

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

   weight 3 · round drawn
   Square~partialclaimed4/10

   Square exposes webhooks/event notifications that let a developer wire custom code to react to events (square-docs-19, square-docs-39) and has narrow built-in 'custom rules and alerts' for fraud/risk management (square-docs-28), but there is no general-purpose, user-definable rules/automation engine ('if event X then action Y') across the platform's business events. Missing for 10: a documented no-code/low-code rule builder, broader event-trigger coverage beyond payments/fraud, and evidence of the AI-native user directly authoring such rules (vs. developers writing webhook handlers).

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “Prevent loss online. Get insights into payment fraud patterns, and set custom rules and alerts to manage risk.”
   • [claimed-docs] “[Verify and Validate an Event Notification](/docs/webhooks/step3validate)”

   proof ↗⚑ flag

   Polar~partialclaimed4/10

   Polar ships built-in automated behaviors for specific billing events (auto-renewal, dunning/retry schedules, proration) and webhooks that notify external systems asynchronously when events occur, which a user can wire up to trigger their own actions. However, there is no evidence of a native rule-definition engine (e.g., 'if event X then do Y' conditions/workflows) inside Polar itself — automation requires building a webhook consumer outside the product. Missing for 10: a first-party rules/workflow builder, conditional logic on events, and any evidence of user-authored automation rules beyond webhook delivery.

   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates... our webhooks offer built-in support for Slack & …”
   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”
   • [claimed-docs] “polar listen http://localhost:3000/”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Square
   Square~partialclaimed4/10

   Square's Subscriptions API and Invoices API let sellers configure recurring billing plans, which is a form of scheduled recurring workflow accessible via the platform's API/MCP surface, but there is no evidence of a general-purpose job/task scheduler or cron-like automation mechanism that an AI agent could use to schedule arbitrary recurring workflows beyond billing. missing for 10: a generic scheduling/automation API (cron, timers, recurring task triggers) independent of payments/subscriptions, evidence of MCP tools exposing scheduling controls, and any hands-on confirmation of recurring workflow automation working end-to-end.

   • [claimed-docs] “Subscriptions API”
   • [claimed-docs] “Invoices API”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's automation is limited to internal billing mechanics (auto-renewing subscriptions, fixed dunning retry schedules, meter aggregation) rather than a general-purpose job/workflow scheduler that an AI-native user or agent could configure for arbitrary recurring tasks. The MCP server lets agents take one-off actions on billing data, but there is no evidence of scheduling recurring jobs or workflows via API, MCP, or dashboard.

   • [claimed-docs] “Polar renews it automatically. At the end of each billing period, Polar advances the subscription to the next cycle and creates a new order”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “Events are sent to Polar using the Events Ingestion API and are stored in our database.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”

   proof ↗⚑ flag

Ai billing ops

1. ai-native userHave an agent monitor failed payments via API and webhooks and drive retries and dunning outreach

   weight 3 · round to Polar
   Square—none0/10

   Square documents webhooks, a Subscriptions API, and Payments API, but the evidence pack has no mention of failed-payment monitoring, automated retry logic, or dunning outreach features/APIs; the community note even flags subscriptions as a historical gap. An agent could theoretically be built on top of webhooks, but no first-party capability or workflow for this specific story is evidenced.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “Subscriptions API”
   • [community] “Does square have a way to handle subscriptions yet? Seems to be the only thing they are missing”

   proof ↗⚑ flag

   Polar~partialclaimed6/10

   Polar documents automated dunning (fixed retry schedule 2/5/7/7 days, past_due state, customer emails) plus webhooks for async notifications and an official MCP server letting agents 'look up data and take actions' across subscriptions/orders — enough for an agent to monitor failed payments and dunning state via API/webhooks. However, dunning/retries are built-in automatic Polar behavior rather than agent-driven; there's no documented API/webhook event specifically for failed-charge notification or an endpoint for an agent to manually trigger a retry or custom outreach message. Missing for 10: explicit failed-payment webhook event schema, an API to trigger/override retry attempts, and evidence of agent-customized dunning outreach beyond Polar's built-in emails.

   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “Polar then retries the charge on a fixed schedule, starting from the time of the first failure”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Polar lets you run these off-session charges against a customer's saved payment method, without the customer being present.”

   proof ↗⚑ flag

2. ai-native userHave an agent provision a new product, price, and payment link via the API in a single session

   weight 3 · round drawn
   Square~partialclaimed7/10

   Square's remote/local MCP server (square-mcp-server) exposes a discovery-oriented `make_api_request` tool spanning Catalog, Checkout, and Payments services, and Square's llms.txt explicitly frames the API as agent-consumable with idempotency-key guidance for writes — together these support an agent creating a catalog item (product), its price, and a payment link (via Checkout/Payment Links API) in one session using a single access token/OAuth session. However, no evidence pack item shows an actual end-to-end worked example or transcript of an agent doing product+price+payment-link creation in one session, and Payment Links API itself is not separately documented in the pack (only Checkout/Catalog mentioned generically). missing for 10: an explicit end-to-end tutorial/example chaining catalog item + price + payment link creation, and independent/hands-on confirmation the MCP tool can complete this multi-step flow in a single session.

   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “Learn how to nest modifier lists under modifiers with the Catalog API to build multi-step customization flows”

   proof ↗⚑ flag

   Polar~partialclaimed7/10

   Polar documents a remote MCP server giving agents OAuth-secured access to 'take actions across your products, customers, subscriptions, orders, benefits, and more,' plus a full API/SDK stack (Checkout Session API, versioned OpenAPI specs, llms.txt) that would let an agent create a product, price, and payment link programmatically in one session. However, there's no first-party walkthrough or hands-on example explicitly chaining product+price+payment-link creation via MCP or API in a single session. Missing for 10: an explicit documented example/tutorial showing an agent creating product, price, and checkout link together in one session, and independent confirmation the MCP tool schema exposes create-product/create-price actions (not just 'look up' access).

   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”

   proof ↗⚑ flag

Invoicing

1. finance-ops userSend hosted invoices with online payment and automatic reminders

   weight 2 · round to Square
   Square~partialclaimed5/10

   Square has a documented Invoices API confirming hosted invoicing exists, but the evidence pack lacks detail on automatic reminders, online payment collection specifics within invoices, or hosted invoice pages. Missing for 10: documentation on automatic reminder scheduling, hosted payment page details, and independent/hands-on confirmation of the invoicing workflow.

   • [claimed-docs] “Invoices API”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's documented feature set covers checkout links/sessions, subscriptions, usage-based billing, and payment-failure dunning (retry emails when a subscription charge fails), but there is no evidence of a distinct 'invoice' object — i.e., a finance-ops workflow to issue a one-off hosted invoice with a due date and automatic reminders for an unpaid bill. The dunning flow (polar-supp-dunning) only fires after a failed subscription charge, not as a general invoicing/reminder tool.

   ⚑ flag

Subscriptions

1. finance-ops userAutomatically retry failed subscription payments with smart dunning and recovery emails

   weight 2 · round to Polar
   Square—none0/10

   Square documents a Subscriptions API and general payments/invoicing capabilities, but no evidence describes automated retry logic, smart dunning, or recovery emails for failed subscription payments; a community comment even questions whether Square's subscription handling is mature.

   • [claimed-docs] “Subscriptions API”
   • [community] “Does square have a way to handle subscriptions yet? Seems to be the only thing they are missing”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar documents automated dunning explicitly: failed charges move the subscription to past_due, trigger a fixed retry schedule (2,5,7,7 days up to 21 days), stamp next_payment_attempt_at, and send the customer a recovery email with a Customer Portal link to update payment method rather than canceling immediately. This directly matches the story's core ask of automatic retries with recovery emails. Missing for 10: no evidence of customizable dunning schedules, multi-channel (SMS/in-app) recovery notifications, or independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “Polar then retries the charge on a fixed schedule, starting from the time of the first failure”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “The Customer Portal is a hosted, self-service page where your customers can manage everything related to their relationship with your busine…”

   proof ↗⚑ flag

2. developerSet up recurring subscription billing with plans, trials, upgrades, and proration

   weight 3 · round to Polar
   Square~partialcommunity5/10

   Square documents a dedicated Subscriptions API (square-docs-23), confirming recurring billing support, but the evidence pack gives no detail on plan configuration, trial periods, upgrade/downgrade flows, or proration logic. An old community comment (square-comm-1) also shows subscriptions were historically seen as a gap, though this predates the current API's existence. Missing for 10: documented support for trials, plan upgrades/downgrades, and proration calculations; independent/hands-on confirmation these work as expected.

   • [claimed-docs] “Subscriptions API”
   • [community] “Does square have a way to handle subscriptions yet? Seems to be the only thing they are missing”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

   Polar documents recurring subscriptions with automatic renewal, plan upgrades/downgrades with immediate rate changes, configurable proration behavior (org-level or per-call), trials are implied via subscription lifecycle, and dunning/failed-payment retry schedules; seat-based proration is also documented. Missing for 10: explicit first-party documentation of trial period configuration (only inferred, not directly cited) and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “Polar renews it automatically. At the end of each billing period, Polar advances the subscription to the next cycle and creates a new order”
   • [claimed-docs] “You pick the proration behavior either at the organization level (as the default) or per API call.”
   • [claimed-docs] “You can switch between plans anytime, and your rate adjusts immediately.”
   • [claimed-docs] “Polar then retries the charge on a fixed schedule, starting from the time of the first failure”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “Add, remove and prorate seats automatically.”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”

   proof ↗⚑ flag

Card acceptance

1. founderAccept an online card payment within a day of signing up

   weight 3 · round to Polar
   Square✓fullclaimed7/10

   Square documents self-serve signup with a Web Payments SDK, Card Payments API, and prebuilt eCommerce integrations that 'can be completed in just a few clicks,' plus a Sandbox for immediate testing—consistent with a founder going from signup to live online card acceptance quickly without sales calls. Missing for 10: explicit 'time-to-first-payment' documentation or independent/hands-on account of actual signup-to-live timing.

   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “Square has prebuilt online payment solutions with top eCommerce providers. Most connections can be completed in just a few clicks.”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Take payments in person and online. Securely save recurring payment methods. Easily sync sales, inventory, and customer data with your Squ…”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar documents fast onboarding ('minutes from an existing store'), no-code Checkout Links you can 'share the URL anywhere,' embedded checkout, and a Merchant-of-Record model that lets founders accept international card payments without setting up separate processors — plus a sandbox to test cards before going live. This directly supports going from signup to accepting a real card payment within a day. Missing for 10: independent/hands-on account confirming actual time-to-first-live-payment (all evidence is vendor docs) and no explicit account approval/KYC timeline that could delay live payments.

   • [claimed-docs] “Migrate to Polar: Get set up on Polar in minutes from an existing store”
   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “As the Merchant of Record, Polar takes care of charging customers, so Stripe Payments doesn't need to be available in your country.”

   proof ↗⚑ flag

Checkout surfaces

1. developerEmbed customizable payment components directly in my own site or app instead of redirecting to a hosted page

   weight 3 · round drawn
   Square✓fullclaimed8/10

   Square's Web Payments SDK is explicitly documented for embedding customizable card/ACH/Cash App/Afterpay payment components directly into a developer's own site rather than redirecting to a hosted checkout page, and this is backed by a full Payments API, Node SDK, and sandbox testing tools. missing for 10: no independent/hands-on developer report confirming ease of customization or styling flexibility beyond first-party docs.

   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “[ACH Bank Transfer Payment](/docs/payments-api/take-payments/ach-payments)”
   • [claimed-docs] “[Afterpay and Clearpay Payments](/docs/payments-api/take-payments/afterpay-payments)”
   • [claimed-docs] “[Cash App Payments](/docs/payments-api/take-payments/cash-app-payments)”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Take payments in person and online. Securely save recurring payment methods. Easily sync sales, inventory, and customer data with your Squ…”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar documents an embedded checkout explicitly designed to avoid redirecting users off-site, plus a Checkout Session API for deeper custom integration, alongside the simpler hosted checkout links option — directly matching the story's ask for embeddable, customizable in-app payment components. Missing for 10: independent/hands-on confirmation of embed customization depth (styling, component-level control) beyond first-party docs.

   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”

   proof ↗⚑ flag

2. developerRedirect customers to a vendor-hosted, conversion-optimized checkout page without building my own payment UI

   weight 3 · round to Polar
   Square—none0/10

   The evidence pack covers Square's Payments API, Web Payments SDK (embeddable UI), Invoices, and various backend APIs, but never mentions a vendor-hosted, conversion-optimized checkout page (e.g., a Checkout API or Payment Links) that a developer could redirect customers to without building payment UI. Web Payments SDK (square-docs-31) actually requires building your own UI, the opposite of this story.

   ⚑ flag

   Polar✓fullclaimed9/10

   Polar documents no-code Checkout Links that developers configure once and redirect to (share URL anywhere, hosted, Polar handles the rest), plus a Checkout Session API for deeper redirect flows, and a sandbox to test the full checkout funnel end-to-end — directly matching a vendor-hosted redirect checkout without building custom payment UI. missing for 10: independent third-party review of checkout conversion/UX quality beyond vendor docs.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”

   proof ↗⚑ flag

No code selling

1. founderCreate a shareable payment link from the dashboard with no code and start selling immediately

   weight 2 · round to Polar
   Square—none0/10

   The evidence pack focuses almost entirely on Square's developer APIs, SDKs, and MCP/AI tooling for building payment integrations, not on the no-code merchant dashboard feature of generating a shareable payment link. No citation mentions 'Payment Links' or a dashboard flow for founders to create a link without coding.

   ⚑ flag

   Polar✓fullclaimed8/10

   Polar explicitly documents no-code Checkout Links: 'Configure once in the dashboard, share the URL anywhere... and Polar handles the rest,' as one of three checkout surfaces alongside embedded and API-driven flows, and Polar acts as Merchant of Record so a founder can sell immediately without separate tax/payment setup. Missing for 10: independent/hands-on confirmation of the dashboard link-creation flow beyond vendor docs, and no third-party account of actual end-to-end usage.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Migrate to Polar: Get set up on Polar in minutes from an existing store”

   proof ↗⚑ flag

Payment methods

1. founderOffer digital wallets and local payment methods (Apple Pay, Google Pay, bank redirects, BNPL) from the same integration

   weight 2 · round to Square
   Square~partialclaimed6/10

   Square's Payments API and Web Payments SDK docs confirm ACH bank transfers, Afterpay/Clearpay (BNPL), Cash App, and card payments in one integration, but the evidence never explicitly documents Apple Pay or Google Pay wallet support alongside these, nor generic 'bank redirect' methods beyond ACH. missing for 10: explicit Apple Pay/Google Pay digital wallet docs, broader local bank-redirect methods (iDEAL, etc.), and independent confirmation that all these methods coexist in a single unified checkout flow.

   • [claimed-docs] “[ACH Bank Transfer Payment](/docs/payments-api/take-payments/ach-payments)”
   • [claimed-docs] “[Afterpay and Clearpay Payments](/docs/payments-api/take-payments/afterpay-payments)”
   • [claimed-docs] “[Cash App Payments](/docs/payments-api/take-payments/cash-app-payments)”
   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “ACH Bank Transfer Payment”
   • [claimed-docs] “Afterpay and Clearpay Payments”
   • [claimed-docs] “Cash App Payments”

   proof ↗⚑ flag

   Polar—none0/10

   The evidence pack extensively documents Polar's checkout flows (links, embedded, API-driven), merchant-of-record tax handling, subscriptions, and payments infrastructure, but nowhere mentions specific payment method support such as Apple Pay, Google Pay, bank redirects, or BNPL options. Sandbox testing is documented only via Stripe test card numbers, not wallet/local payment coverage.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”

   proof ↗⚑ flag

Pci compliance

1. developerKeep my systems out of most of PCI DSS scope because card data is tokenized and never touches my servers

   weight 2 · round to Polar
   Square~partialclaimed5/10

   Square's Web Payments SDK and Card Payments API use client-side tokenization (e.g., sourceId/ccof: tokens in the SDK, 'Save Card on File') so raw card numbers are handled by Square's SDK rather than the developer's server, which is the standard architecture for reducing PCI scope. However, the evidence pack contains no explicit statement about PCI DSS compliance level, SAQ A eligibility, or scope-reduction guidance from Square itself. Missing for 10: an explicit PCI DSS/SAQ-A scope statement, documentation of compliance certifications, and independent confirmation that using these SDKs actually reduces a merchant's PCI scope.

   • [claimed-docs] “Web Payments SDK”
   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [claimed-docs] “[Save Card on File](/docs/terminal-api/advanced-features/save-card-on-file)”

   proof ↗⚑ flag

   Polar~partialclaimed6/10

   Polar's checkout is hosted/embedded (never redirecting raw card data to the developer's own servers) and it acts as Merchant of Record, handling payment processing, tax and compliance obligations, which strongly implies card data tokenization keeps most PCI scope off the developer's infrastructure (polar-docs-7, polar-docs-8, polar-docs-9, polar-supp-checkout-links, polar-docs-40, polar-docs-26). However, the evidence pack never explicitly states a PCI DSS compliance certification or scope-reduction claim, and off-session/saved-card charges (polar-docs-13) aren't tied to any documented tokenization/PCI statement. Missing for 10: an explicit PCI DSS SAQ-A or compliance statement, documentation of card tokenization mechanics, and independent/third-party confirmation of reduced PCI scope.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “As the Merchant of Record, Polar takes care of charging customers, so Stripe Payments doesn't need to be available in your country.”
   • [claimed-docs] “Polar lets you run these off-session charges against a customer's saved payment method, without the customer being present.”

   proof ↗⚑ flag

Integration reliability

1. developerSafely retry any API request using idempotency keys so network failures never create duplicate charges

   weight 2 · round to Square
   Square✓fullclaimed8/10

   Square has a dedicated 'Idempotency' documentation page and its agent-facing llms.txt explicitly states 'every write endpoint accepts an idempotency key' to prevent duplicate charges from retries. This directly matches the story's core requirement. Missing for 10: independent/hands-on developer confirmation of idempotency behavior under real network-failure retries, and more detail on key expiration/scope beyond the doc title.

   • [claimed-docs] “Idempotency”
   • [claimed-docs] “Square's developer llms.txt declares the platform "Designed to be consumable by both human developers and AI agents" and ships explicit agen…”

   proof ↗⚑ flag

   Polar—none0/10

   The evidence pack covers checkout, subscriptions, webhooks, SDKs, and dunning/retry logic for failed payments, but nowhere mentions idempotency keys or a documented mechanism for safely retrying API requests to prevent duplicate charges. This is a standard, fair expectation for a payments API, so its absence is 'none' rather than 'na'.

   ⚑ flag

2. developerRely on signed webhook deliveries with automatic retries, event logs, and replay to keep my system consistent with payment state

   weight 3 · round drawn
   Square~partialclaimed5/10

   Square documents webhook subscriptions and signature verification/validation of event notifications, plus mentions of webhook event logs in the dev tools, which covers signed delivery and basic observability. However, the evidence pack contains no explicit documentation of automatic retry behavior or an event replay mechanism, which are core parts of the story. missing for 10: documented automatic retry policy for failed webhook deliveries, explicit event replay/resend capability, independent confirmation of retry/replay behavior.

   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”
   • [claimed-docs] “[Verify and Validate an Event Notification](/docs/webhooks/step3validate)”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar's webhooks are signed per the Standard Webhooks spec with SDK-side signature validation, typed payloads, and a Webhook Events API for endpoint management, plus delivery monitoring and Slack/Discord alerts. However, the evidence does not document automatic retry behavior for webhook deliveries specifically, nor event logs of delivery attempts, nor a replay/redeliver mechanism — the retry/dunning schedule cited is for failed payment charges, not webhook redelivery. missing for 10: explicit webhook delivery retry policy, delivery attempt/event log UI, and a replay/resend mechanism for missed webhooks.

   • [claimed-docs] “Webhooks follow the Standard Webhooks spec: "Secrets generated on or after 8 September 2026, 00:00 UTC follow Standard Webhooks. Older secre…”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates”
   • [claimed-docs] “Our TypeScript & Python SDKs come with a built-in helper function to easily validate and parse the webhook event”
   • [claimed-docs] “Get notifications asynchronously when events occur instead of having to poll for updates... our webhooks offer built-in support for Slack & …”
   • [claimed-docs] “polar listen http://localhost:3000/”

   proof ↗⚑ flag

Onboarding dx

1. developerIntegrate a working payment flow from the docs alone in under a day, with copy-paste examples in my language

   weight 2 · round to Polar
   Square~partialclaimed6/10

   Square provides extensive first-party docs for card, ACH, Cash App, Afterpay payments, plus sandbox testing and idempotency guidance, and the Node.js/TypeScript SDK shows concrete copy-paste code (client.payments.create). This supports fast integration, but the evidence pack shows only one language's SDK example, no explicit 'under a day' quickstart guide, and no cross-language parity proof (Python, Java, PHP, etc.) or independent developer testimony confirming a same-day integration timeline. missing for 10: multi-language copy-paste examples, an explicit time-to-integrate quickstart, independent hands-on confirmation of a sub-day integration.

   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Idempotency”
   • [github] “await client.payments.create({ sourceId: "ccof:GaJGNaZa8x4OgDJn4GB",”
   • [github] “const client = new SquareClient({ token: "YOUR_TOKEN" });”
   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “Square Sandbox”

   proof ↗⚑ flag

   Polar✓fullclaimed7/10

   Polar's docs provide copy-paste checkout flows (links, embed, session API), official TypeScript & Python SDKs, framework adapters, a full sandbox with test cards, local webhook testing CLI, and an explicit '6 lines of code' quick-start claim—together covering a realistic under-a-day integration path. Missing for 10: independent/hands-on confirmation of the 'under a day' timeline, broader language SDK coverage beyond TS/Python/adapters, and corroboration beyond first-party docs.

   • [claimed-docs] “Configure once in the dashboard, share the URL anywhere (your website, social media, email, a button in your app), and Polar handles the res…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Framework adapters make it dead simple to add Polar checkouts and webhooks to your stack.”
   • [claimed-docs] “polar listen http://localhost:3000/”
   • [claimed-docs] “Payments & Billing with 6 lines of code. Open Source & Global Merchant of Record.”

   proof ↗⚑ flag

Sandbox fidelity

1. developerBuild and test the entire payment flow in a sandbox or test mode that mirrors production, with test cards for every scenario including declines and disputes

   weight 3 · round to Square
   Square✓fullclaimed7/10

   Square documents a dedicated Sandbox environment (square-docs-21, square-docs-40) with Sandbox Payments docs, sandbox-specific dispute testing (square-docs-16), and an API Explorer that lets developers run requests against actual Sandbox or production resources (square-docs-48, square-supp-api-explorer), covering the core sandbox/test-mode workflow for payments and disputes. missing for 10: explicit enumeration of test card numbers for every decline/dispute scenario and independent developer corroboration that the sandbox fully mirrors production edge cases.

   • [claimed-docs] “[Sandbox Payments](/docs/devtools/sandbox/payments)”
   • [claimed-docs] “Square Sandbox”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”
   • [claimed-docs] “API Explorer lets you test your requests using actual Sandbox or production resources in your account such as customers, orders, and catalog…”
   • [claimed-docs] “"API Explorer is an interactive web application you can use to build, view, and send HTTP requests that call Square APIs. API Explorer lets …”

   proof ↗⚑ flag

   Polar~partialclaimed6/10

   Polar documents a dedicated, isolated sandbox environment that mirrors the full checkout/customer funnel and supports Stripe test card numbers (e.g., 4242...), letting developers test payment flows without real money. However, evidence does not confirm dedicated test cards for every scenario (e.g., specific decline codes, dispute/chargeback simulation) — it relies on generic Stripe test cards with no documented list of scenario-specific cards or dispute-simulation tooling. missing for 10: explicit test-card matrix for various decline reasons, documented way to simulate disputes/chargebacks in sandbox, independent/hands-on confirmation of sandbox fidelity.

   • [claimed-docs] “The sandbox environment allows you to experience the complete customer funnel, including checkout. You can perform test payments using Strip…”
   • [claimed-docs] “A fully isolated test environment rather than a test-mode flag: "you can use our sandbox environment. It's a dedicated server, completely is…”
   • [claimed-docs] “To test Polar or work on your integration without worrying about actual money processing or breaking your live organization, you can use our…”

   proof ↗⚑ flag

Ai disputes

1. ai-native userHave an agent handle a dispute end-to-end, retrieving it, assembling evidence, and submitting the response via the API

   weight 3 · round to Square
   Square~partialclaimed5/10

   Square publishes a Disputes API (retrieve disputes, process them, sandbox testing) and its MCP server's service catalog explicitly includes 'disputes' alongside a generic make_api_request tool, so an agent could plausibly retrieve a dispute and call dispute-related endpoints programmatically. However, there is no documented evidence-assembly workflow (e.g., specific evidence-submission endpoint, required evidence fields) or any hands-on/community example of an agent completing a dispute end-to-end via the API or MCP. missing for 10: explicit evidence-submission API details, a demonstrated end-to-end agent workflow, and independent confirmation the MCP disputes tools work as claimed.

   • [claimed-docs] “[Process Disputes](/docs/disputes-api/process-disputes)”
   • [claimed-docs] “Disputes API”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”

   proof ↗⚑ flag

   Polar—none0/10

   The evidence pack contains no mention of a disputes/chargebacks feature, API, or workflow at all — only refunds, failed payments/dunning, and payouts are documented. As a Merchant of Record, dispute handling is a plausible expected capability, but nothing shows Polar exposes dispute retrieval, evidence assembly, or response submission via API for an agent to act on end-to-end.

   • [claimed-docs] “No matter what refund policy you offer to customers, Polar makes it easy to issue both full and partial refunds”
   • [claimed-docs] “Automated dunning with a published schedule: "If that charge fails, the subscription moves to `past_due` and enters Polar's automated paymen…”
   • [claimed-docs] “If that charge fails, the subscription moves to past_due and enters Polar's automated payment recovery (dunning) flow instead of being cance…”

   proof ↗⚑ flag

Disputes

1. finance-ops userRespond to a chargeback with structured evidence and track the dispute lifecycle to resolution

   weight 3 · round to Square
   Square~partialclaimed6/10

   Square documents a dedicated Disputes API with a 'Process Disputes' guide and sandbox testing support, indicating sellers/developers can submit evidence and interact with dispute records programmatically. However, the evidence pack lacks detail on structured evidence-submission fields, dispute status/lifecycle event types, or webhook notifications specific to dispute state changes, and marketing copy suggests Square often manages the dispute process on the seller's behalf rather than the user actively tracking it end-to-end. Missing for 10: detailed evidence-field schema, dispute status/lifecycle event documentation, and independent confirmation of end-to-end resolution tracking.

   • [claimed-docs] “[Process Disputes](/docs/disputes-api/process-disputes)”
   • [claimed-docs] “[Test in the Sandbox](/docs/disputes-api/sandbox-testing)”
   • [claimed-docs] “Disputes API”
   • [claimed-docs] “With no chargeback fees, we save you money and time by managing the credit card dispute process for you.”

   proof ↗⚑ flag

   Polar—none0/10

   The evidence pack covers refunds, failed payments/dunning, payouts, checkout, and usage billing extensively, but contains no mention of chargebacks, dispute evidence submission, or a dispute lifecycle tracking feature anywhere in the docs or probes.

   ⚑ flag

Refunds

1. finance-ops userIssue full or partial refunds from both the dashboard and the API

   weight 3 · round to Square
   Square~partialclaimed7/10

   Square documents a dedicated Refunds API supporting both linked and unlinked refunds (full/partial refunds for existing or off-platform payments), which covers the API side, and the dashboard is implied via the broader Square seller product but not explicitly documented for refund issuance in the evidence pack. missing for 10: explicit dashboard UI documentation/screenshots showing refund issuance from the Seller Dashboard, and confirmation of partial-amount refund support in docs text.

   • [claimed-docs] “[Refund Payments](/docs/payments-api/refund-payments)”
   • [claimed-docs] “[Process an Unlinked Refund](/docs/refunds-api/unlinked-refunds)”
   • [claimed-docs] “Refund Payments”

   proof ↗⚑ flag

   Polar~partialclaimed6/10

   Polar's docs explicitly state that full and partial refunds can be issued regardless of refund policy (polar-docs-25), and the product exposes a general typed API/SDK for all resources (polar-docs-23), implying refund actions are API-accessible. However, no evidence explicitly confirms a dedicated refunds API endpoint or dashboard refund UI walkthrough — missing for 10: explicit refunds API endpoint documentation, dashboard UI screenshot/flow evidence, and independent confirmation that partial refund amounts can be specified via API.

   • [claimed-docs] “No matter what refund policy you offer to customers, Polar makes it easy to issue both full and partial refunds”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”

   proof ↗⚑ flag

Multi currency

1. founderCharge customers in their local currencies and settle to my bank in mine with transparent FX handling

   weight 2 · round drawn
   Square—none0/10

   The evidence pack contains no mention of multi-currency charging, FX conversion, or cross-currency settlement anywhere in Square's docs, GraphQL/REST APIs, MCP server, or payments pages — all payment method docs (cards, ACH, Afterpay, Cash App) are silent on currency handling. This is a fair axis for a payments platform, so absence of evidence yields none rather than na.

   • [claimed-docs] “[Card Payments](/docs/payments-api/take-payments/card-payments)”
   • [claimed-docs] “[ACH Bank Transfer Payment](/docs/payments-api/take-payments/ach-payments)”
   • [claimed-docs] “[Afterpay and Clearpay Payments](/docs/payments-api/take-payments/afterpay-payments)”
   • [claimed-docs] “[Cash App Payments](/docs/payments-api/take-payments/cash-app-payments)”
   • [claimed-docs] “Payouts API”
   • [claimed-docs] “Take payments in person and online. Securely save recurring payment methods. Easily sync sales, inventory, and customer data with your Squ…”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's docs cover MoR tax handling, payouts, and pricing plans, but none of the evidence describes charging customers in their local currency or explains FX conversion/settlement transparency — payouts are described only in terms of a single 'account currency' threshold, with no mention of multi-currency checkout or FX rate disclosure.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Polar is the merchant of record ("We take on the liability of international sales taxes globally for you") with public, self-serve pricing: …”

   proof ↗⚑ flag

Tax

1. finance-ops userCalculate and collect the correct sales tax, VAT, or GST on every transaction automatically

   weight 3 · round to Polar
   Square—none0/10

   The evidence pack covers payments, refunds, disputes, webhooks, invoices, and MCP tooling but contains no mention of tax calculation, tax rates, VAT/GST handling, or automated tax collection features.

   ⚑ flag

   Polar✓fullclaimed8/10

   Polar acts as Merchant of Record and documents that it calculates, collects, and remits sales tax/VAT/GST worldwide, taking on international tax liability so sellers don't need to manage it, plus configurable tax-inclusive pricing controls. missing for 10: no independent/hands-on corroboration of actual tax calculation accuracy across jurisdictions, and no detail on specific tax rate/rule coverage per country.

   • [claimed-docs] “As your Merchant of Record, we handle all international tax compliance. We calculate, collect, and remit taxes worldwide.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Polar gives you fine-grained control over this behavior at both the organization level and on individual product prices.”
   • [claimed-docs] “Polar is the merchant of record ("We take on the liability of international sales taxes globally for you") with public, self-serve pricing: …”
   • [claimed-docs] “As the Merchant of Record, Polar takes care of charging customers, so Stripe Payments doesn't need to be available in your country.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Square~partialclaimed7/10

   Square's developer platform exposes an extensive set of APIs (payments, refunds, disputes, invoices, subscriptions, payouts, webhooks, OAuth, GraphQL, catalog/customers/orders/inventory/labor) plus an MCP server giving 'programmatic access to everything the APIs offer', suggesting broad UI/API parity for core commerce and back-office functions. However, some UI-only surfaces (e.g., the in-product Square AI seller assistant, POS idle-screen customization, dashboard reporting UI) are not shown to have full API equivalents, and there is no explicit vendor or independent claim of 100% UI-API parity. missing for 10: an explicit parity statement or audit confirming every UI feature (e.g., Square AI insights, POS-specific dashboard views) is fully API-accessible, and independent/hands-on verification of edge-case coverage.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “Invoices API”
   • [claimed-docs] “Subscriptions API”
   • [claimed-docs] “Disputes API”
   • [claimed-docs] “Square Webhooks”
   • [claimed-docs] “One GraphQL query can retrieve data that requires multiple Square API calls.”
   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”
   • [claimed-docs] “The Square MCP server connects your AI tools directly to the full Square API platform, giving you programmatic access to everything the APIs…”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “Square AI (Beta) is an in-product assistant for sellers: "Square AI is built into your everyday tools to pull game-changing insights from yo…”

   proof ↗⚑ flag

   Polar~partialprobed7/10

   Polar documents a broad, versioned API/SDK surface covering checkout, subscriptions, meters/usage billing, customer state, webhooks, refunds, and payouts, plus an official MCP server letting agents 'look up data and take actions across your products, customers, subscriptions, orders, benefits, and more' without needing the UI, and agent-legible docs (llms.txt, OpenAPI specs). However, no explicit vendor statement guarantees 1:1 UI/API parity, some dashboard-only mentions (e.g., 'create and manage your meters from the dashboard') aren't cross-confirmed with an API equivalent in the pack, and root-level openapi.json probes 404'd (spec is only reachable via versioned docs paths). Missing for 10: an explicit parity claim/audit, confirmation every dashboard action (e.g., payouts, balance views) has a documented API call, and independent corroboration of full API/UI equivalence.

   • [claimed-docs] “Customer State is a concept allowing you to query for the current state of a customer, including their active subscriptions and granted bene…”
   • [claimed-docs] “If you want to integrate more deeply the checkout process with your website or application, you can use our dedicated API.”
   • [claimed-docs] “Our embedded checkout allows you to provide a seamless purchasing experience without redirecting users away from your site.”
   • [claimed-docs] “Three documented checkout surfaces: no-code Checkout Links, embedded checkout (embed.md — drop-in on your own site, including an embedded pa…”
   • [claimed-docs] “"Polar has a powerful Usage Based Billing infrastructure that allows you to charge your customers based on the usage of your application. Th…”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://polar.sh/openapi.json, https://polar.sh/swagger.json, https://polar.sh/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Square—none0/10

   Square's docs describe extensive APIs to create/read individual objects (payments, customers, orders, catalog) and even an MCP/GraphQL layer, but there is no evidence of a bulk data-export feature, standard open-format export (CSV/JSON dump), or documented account-closure/data-portability process letting a user take all their data and leave.

   ⚑ flag

   Polar—none0/10

   Polar is a merchant-of-record billing/payments platform; the evidence pack covers API access, webhooks, MCP, and OpenAPI specs for developers to integrate with, but there is no mention of a data export feature letting a user (customer or merchant) export all of their own data (orders, subscriptions, customer records, transaction history) in an open, portable format for the purpose of leaving the platform. Having an API is not the same as a documented bulk data-export/portability capability.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Polar
   Square—none0/10

   Square is a closed-source SaaS payments platform; the evidence only shows open-source client SDKs (square-nodejs-sdk) and an MCP server wrapper on GitHub, not the core product/platform source under an open license. No documentation states Square's actual service code is open-sourced or licensed for public reading.

   • [github] “The Square TypeScript library provides convenient access to the Square APIs from TypeScript.”
   • [claimed-docs] “npx square-mcp-server start”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”

   proof ↗⚑ flag

   Polar✓fullclaimed8/10

   Polar's own repo (github.com/polarsource/polar) is documented as open source under Apache-2.0 with 10k+ stars, meaning the product's source is publicly readable under a permissive OSI license, and this is reinforced by docs/site language positioning Polar as 'Open Source & Global Merchant of Record.' missing for 10: no independent third-party audit of license file contents or contribution history beyond the single citation.

   • [claimed-docs] “Polar is open source: the platform itself is developed in the open at github.com/polarsource/polar (Apache-2.0, 10k+ stars), positioning its…”
   • [claimed-docs] “Payments & Billing with 6 lines of code. Open Source & Global Merchant of Record.”

   proof ↗⚑ flag

Ai reconciliation

1. ai-native userHave an agent pull payout and balance-transaction data via the API and reconcile each bank deposit to its underlying charges

   weight 3 · round drawn
   Square~partialclaimed5/10

   Square has a documented Payouts API and API access (via SDK, MCP server, GraphQL, webhooks) that an agent could use to pull payout and balance-transaction data programmatically, and payments/refunds/disputes APIs provide the underlying charge data needed for reconciliation. However, there is no direct evidence of a balance-transactions endpoint equivalent to Stripe's, nor documentation showing how payout line items map to underlying charges/fees for reconciliation workflows. missing for 10: explicit balance-transaction/payout-entries API detail, worked reconciliation example or docs linking deposits to charges, independent/hands-on confirmation of this specific workflow.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “The Square MCP server (github.com/square/square-mcp-server, Beta) uses a discovery-oriented tool design — `get_service_info` ("Discover meth…”
   • [claimed-docs] “"The Square remote MCP server is hosted at: https://mcp.squareup.com/mcp... Square recommends using the remote MCP server, which supports OA…”
   • [claimed-docs] “One GraphQL query can retrieve data that requires multiple Square API calls.”
   • [claimed-docs] “[Subscribe to Event Notifications](/docs/webhooks/step2subscribe)”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar documents payout thresholds and balance visibility (polar-docs-14, polar-docs-15), a full typed API/SDK (polar-docs-23, polar-docs-38), webhooks, and a remote MCP server letting agents access 'products, customers, subscriptions, orders, benefits' (polar-supp-mcp). However, there is no explicit documentation of a balance-transaction/ledger API endpoint, nor confirmation that the MCP server or SDK exposes payout/balance data specifically (the MCP scope list omits payouts/balance), so reconciling deposits to charges via an agent is only indirectly supported. Missing for 10: explicit balance-transaction API endpoint docs, MCP/agent access to payout and balance data, and any documented reconciliation workflow or example.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “Call the Polar API with full type safety using one of our official SDKs.”
   • [claimed-docs] “"Use Polar's remote Model Context Protocol (MCP) server to give AI agents secure access to your Polar organization. Agents can look up data …”
   • [claimed-docs] “The official Python SDK provides fully typed synchronous and asynchronous clients for the Polar API.”
   • [claimed-docs] “Agent-legible docs and machine specs: polar.sh/docs publishes llms.txt with `.md` siblings for every page, and serves versioned OpenAPI spec…”

   proof ↗⚑ flag

Payouts

1. finance-ops userControl the payout schedule and see exactly which charges, fees, and refunds make up each payout

   weight 2 · round to Polar
   Square~partialclaimed4/10

   Square exposes a Payouts API (square-docs-17) which presumably supports payout schedule and reconciliation data, but the evidence pack gives no detail on schedule controls (e.g., daily/weekly/manual), nor on how payouts break down into constituent charges, fees, and refunds. missing for 10: documentation of payout schedule configuration options, payout entries/line-item breakdown by charge/fee/refund, and any independent/hands-on confirmation of reconciliation accuracy.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “[Refund Payments](/docs/payments-api/refund-payments)”
   • [claimed-docs] “[Process an Unlinked Refund](/docs/refunds-api/unlinked-refunds)”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

   Polar documents balance visibility and a manual withdrawal/payout mechanism gated by a minimum threshold, plus refunds and order/charge tracking, giving finance-ops some reconciliation ability. However, there's no evidence of a configurable payout schedule (e.g., automatic weekly/monthly payout cadence) or a consolidated payout report itemizing which specific charges, fees, and refunds roll up into a given payout. missing for 10: documented payout scheduling/cadence controls, a per-payout itemized breakdown of constituent charges/fees/refunds, and any reconciliation report or export tying payouts to transactions.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “No matter what refund policy you offer to customers, Polar makes it easy to issue both full and partial refunds”
   • [claimed-docs] “Polar is the merchant of record ("We take on the liability of international sales taxes globally for you") with public, self-serve pricing: …”

   proof ↗⚑ flag

Reconciliation

1. finance-ops userReconcile settlements to bank deposits with itemized reports covering fees, refunds, and chargebacks

   weight 3 · round to Square
   Square~partialclaimed5/10

   Square provides a Payouts API for settlement data and separate Refunds and Disputes APIs, plus marketing copy about seeing 'all your sales in one report' to reduce reconciliation effort, but there's no dedicated documentation showing an itemized report that ties bank deposits to fees, refunds, and chargebacks in one place. missing for 10: explicit itemized payout/settlement report schema breaking down fees, refunds, chargebacks; documentation linking payout amounts directly to bank deposit records; independent confirmation from finance-ops users that reconciliation works end-to-end.

   • [claimed-docs] “Payouts API”
   • [claimed-docs] “[Refund Payments](/docs/payments-api/refund-payments)”
   • [claimed-docs] “[Process Disputes](/docs/disputes-api/process-disputes)”
   • [claimed-docs] “See all your sales in one report. Spend less time reconciling data across payment systems and more time optimizing sales based on your real-…”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's docs cover payouts, balance tracking, and refunds, but there is no evidence of itemized reconciliation reports matching settlements to bank deposits, nor any mention of chargeback handling or reporting at all.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “No matter what refund policy you offer to customers, Polar makes it easy to issue both full and partial refunds”

   proof ↗⚑ flag

Marketplace

1. developerBuild a marketplace or platform that onboards sellers, splits payments between parties, and pays out to each seller

   weight 2 · round to Square
   Square~partialclaimed6/10

   Square provides the core building blocks for a marketplace: OAuth to onboard sellers to their own Square accounts (square-docs-42, square-docs-51), the OAuth access-token scope model (square-supp-oauth-scopes), Payments API with 'Collect Application Fees' for platform fee splitting (square-docs-37), and a Payouts API for disbursing funds to sellers (square-docs-17). However, the evidence never documents a unified 'split payment across multiple parties in one transaction' primitive or destination-account payout routing akin to Stripe Connect transfers—application fees and payouts appear as separate mechanisms rather than an integrated marketplace split-and-payout flow, and there's no dedicated marketplace/platform guide or case study. missing for 10: explicit multi-party split-payment/transfer API documentation, an end-to-end marketplace onboarding+split+payout guide, and independent/hands-on validation that this pattern works in production.

   • [claimed-docs] “Use the OAuth API to connect your application to a seller's account using OAuth.”
   • [claimed-docs] “multi-tenant applications that serve multiple sellers should use OAuth access tokens”
   • [claimed-docs] “Square access is scope-controlled: "Access tokens are credentials that allow applications to securely interact with Square APIs. An access t…”
   • [claimed-docs] “Collect Application Fees”
   • [claimed-docs] “Payouts API”
   • [claimed-docs] “For custom integrations that only access your own Square account, personal access tokens are suitable for production use.”

   proof ↗⚑ flag

   Polar—none0/10

   Polar's evidence describes single-organization merchant-of-record billing, payouts, and balances for one seller, but nothing about onboarding multiple sellers/sub-accounts, splitting a single transaction's proceeds between parties, or a Connect-like marketplace primitive. The axis is plausible for a payments platform, but no evidence supports multi-seller marketplace functionality.

   • [claimed-docs] “You can issue a withdrawal — also called a payout — once your balance meets the minimum threshold for your account currency.”
   • [claimed-docs] “You can see your available balance for payout at any time under your Finance page.”
   • [claimed-docs] “We take on the liability of international sales taxes globally for you. So you can focus on growing your business vs. accounting bills.”
   • [claimed-docs] “Polar is the merchant of record ("We take on the liability of international sales taxes globally for you") with public, self-serve pricing: …”

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Square—none0/10

   No evidence in the pack addresses data retention policies, data deletion capabilities, or privacy controls for AI/MCP interactions with Square data. While OAuth scopes and access-token controls are documented, nothing speaks to retaining or deleting data collected via AI tools or the MCP server.

   ⚑ flag

   Polar—none0/10

   The evidence pack covers billing, checkout, subscriptions, webhooks, MCP integration, and merchant-of-record tax handling, but contains no mention of data retention policies, customer data deletion, GDPR/right-to-be-forgotten controls, or any user-facing mechanism to purge or manage stored data. As a platform that stores customer and transaction data, this is a fair question, but no capability is documented.

   ⚑ flag