Adyen vs Polar

Agent access

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

   weight 2 · round to Adyen
   Adyen✓fullprobed10/10

   Adyen has a live, probed llms.txt (HTTP 200) plus markdown-renderable docs pages (append .md), a documented full-docs ZIP mirror explicitly for feeding AI agents/code assistants, and an OpenAPI spec repo positioned as LLM context — this is direct, independently-probed confirmation of agent-oriented docs.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.adyen.com/online-payments.md --- title: "Online payments" description: "Accept payments with cards, …”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”

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

   Adyen's core integration is a server-to-server REST API (docs-1, docs-2) that can be called entirely headlessly with no UI dependency, supports idempotency keys for safe automated retries (adyen-docs-4, adyen-docs-25), and provides a dedicated test environment with test credentials explicitly meant for pre-production integration testing (adyen-docs-6, adyen-docs-18). Scoped, multiple API credentials support automated/service-account style access (adyen-docs-26, adyen-supp-api-credential-scoping). However, there is no explicit CI/CD pipeline documentation, no CLI/SDK testing harness, and the MCP server is documented as running locally via npx rather than as a CI-oriented headless service. Missing for 10: explicit CI/CD integration guides, automated test-suite/SDK tooling, and confirmation of non-interactive credential provisioning for pipelines.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Your server makes three Checkout API requests: /paymentMethods, /payments, and /payments/details.”
   • [claimed-docs] “To submit a request for idempotent processing, send a request with the `idempotency-key:` in the header.”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”
   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Test the different types of transactions with Adyen that your integration handles using test credentials.”
   • [claimed-docs] “You can also create multiple API credentials to improve security and control access.”
   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”

   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 to Polar
   Adyen✓fullprobed8/10

   Adyen documents and ships an official MCP server (github.com/Adyen/adyen-mcp) that lets LLM clients call Checkout, payment links, modifications, and Management API tools via natural language, with clear setup (npx install), scoped API-key auth, and role-based permissions. Missing for 10: independent/hands-on third-party verification of the MCP server working in practice (only vendor docs and a live-probe confirming the doc page exists, no community usage reports) and clarity on production-readiness given its 'Alpha' status.

   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [claimed-docs] “This allows developers to use natural language to connect with Adyen's platform more easily and build new payment solutions faster.”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “MCP access rides on Adyen's standard scoped credentials: "To authenticate the requests you will make using the MCP, generate an API key. Mak…”

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

   Evidence covers an MCP server, OpenAPI specs, docs tooling, and agentic-commerce protocols, but there is no mention of an official Adyen CLI for AI-native workflows anywhere in the pack.

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

   Adyen ships extensive documented public REST APIs (Checkout, Management, Platforms, Payouts, Agentic Commerce, etc.), an OpenAPI spec repo as 'single source of truth' for client generation, idempotency keys, scoped API credentials, webhooks, and machine-readable docs (llms.txt, .md pages, full docs mirror) explicitly aimed at AI tooling. Probes independently confirm llms.txt and .md doc endpoints return 200. Missing for 10: a live discoverable OpenAPI/swagger endpoint directly under docs.adyen.com (probe found 404s on standard paths) and independent third-party corroboration of API usability beyond vendor docs.

   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”
   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.adyen.com/online-payments.md --- title: "Online payments" description: "Accept payments with cards, …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”

   proof ↗⚑ flag

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

   Adyen documents scoped, role-based API credentials (roles define exactly what a credential can do, e.g. limiting to initiating vs capturing payments, per-merchant-account scoping) and explicitly recommends creating multiple credentials for finer-grained access control — and the MCP server docs instruct assigning a dedicated API credential with only the specific roles needed for agent use, plus a --tools flag to limit which MCP tools are exposed. This directly supports least-privilege credential issuance for an AI agent. missing for 10: no independent/hands-on verification of least-privilege enforcement in practice, and no explicit per-agent short-lived/ephemeral credential mechanism beyond static role-scoped API keys.

   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”
   • [claimed-docs] “MCP access rides on Adyen's standard scoped credentials: "To authenticate the requests you will make using the MCP, generate an API key. Mak…”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “You can also create multiple API credentials to improve security and control access.”

   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 to Polar
   Adyen~partialprobed6/10

   Adyen documents official SDKs for web/iOS/Android/React Native/Flutter and a public OpenAPI spec repo as the 'single source of truth' usable to generate client libraries, which supports SDK-based building; however, the OpenAPI/spec endpoint probes returned 404s and there's no independent/hands-on corroboration of SDK quality or completeness for AI-native workflows specifically. missing for 10: independent verification of official SDK repos/quality, working OpenAPI spec endpoint (probe returned 404s), hands-on developer confirmation of SDK-based agentic integration.

   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”

   proof ↗⚑ flag

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

   Adyen provides first-party webhook subscriptions to avoid polling, with event logs visible in the Customer Area, and MCP tools to list/get/test webhooks, plus agentic-commerce flows that explicitly send webhook payment outcomes to merchant servers — showing webhooks are usable both directly and via AI-native/agent tooling. missing for 10: no independent/hands-on developer confirmation of webhook subscription setup via API or MCP, and no detail on webhook event types/payload schema management through natural-language/agentic tooling.

   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Google Agentic Commerce integration: "Use this integration for processing Google Pay payments through Adyen, when Google agents (Google AI M…”

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

   Adyen Uplift is documented as an AI layer that analyzes payment data and 'gives you recommendations that are tailored for your business' to optimize conversion, risk, and cost, and risk management includes ML-powered fraud detection using global transaction data. This matches the spirit of AI-generated insights/suggestions from account data, but it's narrowly scoped to payment-funnel optimization and fraud, not a general-purpose 'insights' feature across reporting/dashboards, and there's no independent/hands-on corroboration of how these suggestions surface in the UI. Missing for 10: broader AI-generated insights across reporting/analytics (not just Uplift/fraud), and third-party or hands-on evidence of the insights UX.

   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”
   • [claimed-docs] “Adyen Uplift helps you strike a balance between conversion, risk and cost. You get recommendations that are tailored for your business”
   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”

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

   Adyen supports several background/event-driven automations — webhooks that eliminate manual polling for async status changes, Uplift's AI-driven payment-funnel optimization experiments that can be started/evaluated/stopped autonomously, and risk-management rules/ML fraud detection that run continuously — but these are fixed platform features rather than a general-purpose mechanism for an AI-native user to author custom autonomous background automations. Missing for 10: a user-configurable automation/workflow builder or scheduler that an AI-native user can set up to run arbitrary agentic tasks unattended, and independent evidence of such automations running reliably in production.

   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”
   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”

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

   Adyen documents an MCP server (for external LLM clients to call Adyen's APIs) and 'Uplift' (automated AI-driven payment optimization), but no evidence of a built-in AI assistant/copilot inside the Adyen product itself that a user can converse with or delegate tasks to interactively.

   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Adyen Uplift is the platform's AI optimization layer: "Adyen Uplift helps you strike a balance between conversion, risk and cost. You get re…”

   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
   Adyen~partialprobed7/10

   Adyen ships an official MCP server (adyen-mcp) that explicitly lets users 'use natural language with your chosen LLM client' to interact with Adyen APIs (create sessions, payment links, refunds, management API), with documented scoped-credential setup — a genuine natural-language operation surface for AI-native users. However, the MCP server is explicitly marked 'Alpha', runs only locally via npx, and only exposes a documented subset of tools rather than full product coverage. Missing for 10: production-grade/GA status, independent hands-on validation of the NL interface actually working reliably, and broader coverage beyond the documented tool subset.

   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”
   • [claimed-docs] “This allows developers to use natural language to connect with Adyen's platform more easily and build new payment solutions faster.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “MCP access rides on Adyen's standard scoped credentials: "To authenticate the requests you will make using the MCP, generate an API key. Mak…”
   • [probe] “official MCP server documented at https://docs.adyen.com/development-resources/mcp-server”

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

   The evidence describes OpenAPI specs (usable to generate Postman collections or client libraries), markdown-rendered docs, and an MCP server for natural-language API access, but there is no evidence of an actual interactive API reference/console embedded in Adyen's docs where a user can run live example requests. A probe for a standard OpenAPI/Swagger endpoint also returned 404s, and no 'try it' console or embedded runnable code examples are documented.

   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”

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

   Adyen documents a dedicated OpenAPI specification repository (github.com/Adyen/adyen-openapi) covering 'every public API Adyen offers' as the 'single source of truth,' explicitly positioned for machine consumption (client-library generation, Postman collections, and LLM/agent context). This is reinforced by llms.txt, markdown-renderable docs, and a full docs mirror ZIP for AI tooling. missing for 10: independent/hands-on confirmation that the OpenAPI repo is current and complete, and a direct in-docs discoverable openapi.json endpoint (probe found only 404s for openapi.json-style paths on the docs domain itself).

   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.adyen.com/llms.txt # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen f…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”

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

   Adyen documents a dedicated test environment for the full integration (client- and server-side) using test credentials before going live, and this test environment is explicitly wired into AI-native workflows via the Adyen MCP server which runs with `--env=TEST` (or LIVE with a live prefix), letting an AI agent exercise Checkout, payment links, and modification tools against sandbox data. Missing for 10: no independent/hands-on confirmation that sandbox test data is fully isolated from production, and no detail on seeding/resetting sandbox state for repeatable AI-driven test runs.

   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Test the different types of transactions with Adyen that your integration handles using test credentials.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Our Model Context Protocol (MCP) server lets you use natural language with your chosen Large Language Model (LLM) client.”

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

   The evidence pack covers API idempotency, webhooks, credentials, OpenAPI specs, and agentic commerce integrations, but contains no documentation of API versioning scheme or a deprecation policy for older API versions. Versioning/deprecation policy is a standard and fair axis for a payments API platform, so absence of evidence yields 'none'.

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

   Adyen documents concrete bulk operations in its agentic Product Feed API — batch ingest of up to 200 items per call and batch delete of up to 200 products per call — which is genuine 'many items at once' functionality for AI-platform inventory sync. However, evidence of bulk operations elsewhere in the platform (e.g., bulk payouts, bulk refunds/modifications, bulk reporting exports, or MCP tools operating on many resources at once) is absent; the MCP tool list is single-item oriented (create one session, one payment link, one refund). Missing for 10: bulk support evidenced across other core domains (payments, payouts, platforms/onboarding) and bulk-capable MCP tools, not just the product feed.

   • [claimed-docs] “You can upload batches of information about your inventory to Adyen, and we will synchronize it with AI platforms.”
   • [claimed-docs] “The Adyen Product Feed API is "a centralized product knowledge hub that synchronizes your inventory with AI platforms" via asynchronous batc…”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”

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

   Adyen documents a genuine rules mechanism — the risk management rule builder lets you 'create, backtest, and label custom rules' that automatically trigger block/allow/review actions on each transaction event (adyen-docs-20, adyen-docs-28, adyen-docs-48), and webhooks notify on async status-change events (adyen-docs-3/17). This satisfies the core 'rule triggers action on event' pattern, but only within the fraud/risk-decisioning domain, not as a general-purpose automation/workflow engine, and there's no evidence of AI-native rule authoring (e.g., via the MCP server or natural language) for these rules. Missing for 10: general cross-domain event-action automation beyond fraud rules, AI/LLM-driven rule creation or triggering, and independent evidence of real-world use of the rule builder.

   • [claimed-docs] “Create, backtest, and label custom rules with a rule builder interface | Machine learning powered fraud detection using global transaction d…”
   • [claimed-docs] “Machine learning powered fraud detection using global transaction data | | | Create, backtest, and label custom rules with a rule builder in…”
   • [claimed-docs] “Each payment goes through a risk evaluation. The risk evaluation reaches a decision that results in an action to block, allow, or review the…”
   • [claimed-docs] “You can detect, monitor, and mitigate fraud using Protect, Adyen's risk management system.”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”

   proof ↗⚑ flag

   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

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

   Adyen provides the raw building blocks an agent could use—webhooks for status changes (adyen-docs-3/17/45), refusal-reason detail on failed payments (adyen-docs-7), idempotent retries (adyen-docs-4/25), and an MCP server exposing webhook list/get/test and payment tools (adyen-supp-mcp-tools)—but there is no documented dunning/subscription-retry feature, automated outreach mechanism, or agent workflow specifically for failed-payment recovery. Missing for 10: native dunning/retry orchestration, recurring-billing failed-payment workflow, and evidence of an agent actually driving retries/outreach rather than just monitoring raw webhook/API data.

   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”

   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 to Polar
   Adyen—none0/10

   Adyen's API and MCP server cover payments, payment links, checkout sessions, and payouts, but there is no evidence of any 'product' or 'price' resource concept (billing/catalog objects like Stripe's Products/Prices) that an agent could provision alongside a payment link — Adyen is a payments processor, not a billing/invoicing product catalog system. The only 'product' references are to inventory feeds for agentic commerce (syncing existing catalog to AI platforms), not creating new products/prices via API. missing for 10: evidence of a Products/Prices API or equivalent billing object model, evidence of a single-session workflow that creates a product+price+payment link together, any documentation of provisioning billing entities (not just payment links) via API or MCP.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Offer payment links.”
   • [claimed-docs] “The Adyen Product Feed API is "a centralized product knowledge hub that synchronizes your inventory with AI platforms" via asynchronous batc…”

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

   Adyen's evidence covers payment links, checkout, platforms, payouts, and agentic commerce, but there is no mention of a hosted invoicing product, invoice generation, or automatic payment reminders anywhere in the pack — only generic 'payment links' (adyen-docs-24) which is a different capability.

   • [claimed-docs] “Offer payment links.”

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

   The evidence pack covers payments, payouts, webhooks, idempotency, risk management, platforms/marketplace payouts, and agentic commerce, but contains no mention of subscription billing, dunning management, automatic retry logic for failed recurring payments, or recovery emails. This is a plausible axis for a payments platform, but nothing in the docs or community evidence shows Adyen offering smart dunning/recovery workflows.

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

   Adyen's evidence pack covers payments, payouts, platforms, risk, reporting, and agentic commerce, but there is no mention of subscription/recurring billing constructs like plans, trial periods, upgrades/downgrades, or proration—these are the domain of a billing/subscription-management layer (e.g. Adyen has separate tooling or partners for this) not documented here.

   ⚑ 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
   Adyen!disputedcontradicted4/10

   Adyen's docs describe a fast technical integration (single /sessions call, test-then-go-live flow, no setup fees) that could suggest same-day acceptance, but independent community reports concretely contradict a founder's ability to just sign up and start accepting payments quickly: Adyen reportedly refuses small clients ('under the million'), requires large reserves for subscription businesses, and one user describes a multi-hundred-hour integration effort before abandoning it. These are hands-on, specific counter-examples, not generic skepticism, so the 'within a day' claim is disputed rather than simply partial. Missing for 10: any evidence of Adyen actually onboarding a small/new founder-level merchant same-day, or a rebuttal to the reserve/minimum-volume gating reports.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Pay per transaction, with no setup or monthly fees.”
   • [community] “Adyen refuses small clients, under the million :/”
   • [community] “One of the bigger drawbacks of Adyen vs Stripe... they require a crazy reserve (in the millions) if your model is subscription based, to be …”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”
   • [community] “Adyen's pricing model looks much more attractive on paper, but the integration complexity and minimum processing volumes usually keep early-…”

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

   Adyen's Web/mobile Drop-in and Components let developers embed sessions-based payment UI directly in their own site/app (web, iOS, Android, React Native, Flutter) with customizable styling and localization, rather than redirecting to a hosted page. This is a core, well-documented capability with sample flows (create session, mount Components) and cross-platform SDK support. Missing for 10: independent hands-on confirmation of embedding ease (community feedback is mixed/critical on integration complexity), and no detailed code-level customization examples in the pack.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [claimed-docs] “Customize the styling of your checkout.”
   • [claimed-docs] “Customize the styling of your checkout. Present your payment form in the local language of your shoppers with our localization support.”
   • [claimed-docs] “With the client key, you have: A single key for all your allowed origins in an environment.”
   • [community] “I implemented Adyen for a company I was consulting for. I liked it. Their integration was not as terrible as many here make it seem. It allo…”

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

   Adyen explicitly offers hosted 'payment links' that developers can generate and redirect customers to without building payment UI (adyen-docs-24), and the MCP tool surface confirms this as a first-class API capability (create/get/expire payment links) (adyen-supp-mcp-tools). However, Adyen's primary integration path emphasized in the docs is the Sessions/Components client-side flow which requires building or embedding UI (adyen-docs-1), and there is no detailed documentation on conversion-optimization specifics of the hosted page itself. Missing for 10: dedicated documentation describing the hosted checkout page's design/conversion features, independent evidence of its effectiveness, and clarity on it being the recommended 'no-code UI' path rather than a secondary option.

   • [claimed-docs] “Offer payment links.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”

   proof ↗⚑ 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
   Adyen!disputedcontradicted4/10

   Adyen's docs confirm a payment-links feature exists ("Offer payment links" - adyen-docs-24) and a Customer Area dashboard for managing transactions (adyen-docs-16), but there is no evidence of a self-serve, no-code flow a founder can use to instantly start selling. Community reports concretely contradict the 'start immediately' premise for founders: Adyen is described as refusing small clients ('Adyen refuses small clients, under the million' - adyen-comm-1) and requiring underwriting/minimum volumes that keep early-stage startups away ('integration complexity and minimum processing volumes usually keep early-stage startups on Stripe' - adyen-comm-11), unlike a turnkey signup-and-sell experience. missing for 10: documented self-serve onboarding flow for small merchants, step-by-step dashboard payment-link creation, evidence that a founder can go live without a sales/underwriting process.

   • [claimed-docs] “Offer payment links.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [community] “Adyen refuses small clients, under the million :/”
   • [community] “Adyen's pricing model looks much more attractive on paper, but the integration complexity and minimum processing volumes usually keep early-…”

   proof ↗⚑ 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 Adyen
   Adyen✓fullcommunity8/10

   Adyen docs explicitly promise 'one integration' covering all preferred payment methods (wallets, local methods, BNPL) via a single Checkout API/sessions flow, with community corroboration that it supports native local methods like iDEAL and Sofort. Missing for 10: an explicit itemized list of Apple Pay/Google Pay/BNPL support and independent hands-on confirmation of wallet/BNPL specifically (only general local-method corroboration exists), plus some community friction reports on integration complexity.

   • [claimed-docs] “Offer your customers all their preferred payment methods with a single integration.”
   • [claimed-docs] “One integration Offer your customers all their preferred payment methods with a single integration.”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Your server makes three Checkout API requests: /paymentMethods, /payments, and /payments/details.”
   • [community] “I implemented Adyen for a company I was consulting for. I liked it. Their integration was not as terrible as many here make it seem. It allo…”

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

   Adyen's Checkout API/sessions flow shows card data handled client-side and passed via Adyen's hosted fields/client key rather than touching the merchant's server (adyen-docs-1, adyen-docs-44), which implies the tokenization pattern developers rely on for reduced PCI scope. However, none of the evidence explicitly discusses PCI DSS, SAQ levels, or scope-reduction guidance, so the compliance benefit is only inferable from the technical integration pattern, not documented directly. missing for 10: explicit PCI DSS scope-reduction documentation, SAQ-A eligibility guidance, independent compliance certification evidence.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “With the client key, you have: A single key for all your allowed origins in an environment.”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”

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

   Adyen explicitly documents idempotency-key headers for retrying API requests without duplicate side-effects (adyen-docs-4, adyen-docs-25), directly matching the story. Missing for 10: independent/hands-on developer confirmation of idempotency behavior in production and detail on key expiration/edge cases.

   • [claimed-docs] “To submit a request for idempotent processing, send a request with the `idempotency-key:` in the header.”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”

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

   Adyen documents webhook event logs in the Customer Area (adyen-docs-45) and general webhook mechanics to avoid polling (adyen-docs-3/17), plus an MCP tool to 'test' webhooks (adyen-supp-mcp-tools) that hints at replay tooling. However, the evidence pack never explicitly documents HMAC/signature verification for webhook payloads, an automatic retry policy for failed webhook deliveries, or a dedicated replay mechanism. Missing for 10: explicit signed-webhook (HMAC) verification docs, documented automatic retry/backoff schedule for webhook delivery, and a concrete replay/redeliver feature beyond the vague MCP 'test' tool.

   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process, or for…”
   • [claimed-docs] “With webhooks, you can avoid having to continuously poll an API endpoint, waiting for a change in status for an asynchronous process”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “To submit a request for idempotent processing, send a request with the `idempotency-key:` in the header.”
   • [claimed-docs] “The Adyen API supports idempotency, allowing you to retry a request multiple times while only performing the action once.”

   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
   Adyen!disputedcontradicted4/10

   Adyen's docs describe a clear-looking integration path (single /sessions call or paymentMethods/payments/payments/details flow, testing, webhooks) and multi-platform SDK support (web, iOS, Android, React Native, Flutter), but no evidence pack item actually shows copy-paste code samples per language, and independent hands-on reports directly contradict the 'under a day' claim: one integrator says 'after hundreds of hours invested, we ditched Adyen' and another states 'Stripe beats Adyen on ease of integration... hands down,' while a third calls it 'much more bare metal' than turnkey competitors. A counter-report says the integration 'was not as terrible as many here make it seem,' so the picture is mixed rather than uniformly negative. missing for 10: actual copy-paste language-specific code samples in the evidence, a documented time-to-first-payment benchmark, and independent confirmation that integration is fast rather than the reported multi-hundred-hour effort.

   • [claimed-docs] “Your server makes a single Checkout API request to the /sessions endpoint. Adyen sends payment data from our server to your client-side appl…”
   • [claimed-docs] “Your server makes three Checkout API requests: /paymentMethods, /payments, and /payments/details.”
   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Support online payments for web, iOS, Android, React Native, or Flutter.”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”
   • [community] “I implemented Adyen for a company I was consulting for. I liked it. Their integration was not as terrible as many here make it seem. It allo…”
   • [community] “Adyen is much more 'bare metal.' Think more like a modern Authorize.net. Nobody comes close to Stripe's turnkey developer-friendliness.”
   • [community] “Adyen's pricing model looks much more attractive on paper, but the integration complexity and minimum processing volumes usually keep early-…”

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

   Adyen documents a dedicated test environment with test credentials for exercising different transaction types (adyen-docs-18), recommends testing the full client+server integration before going live (adyen-docs-6), and documents refusal reasons/result codes for simulating declines (adyen-docs-7). However, the pack lacks explicit documentation of test cards for disputes/chargebacks specifically, or a catalog of scenario-specific test cards, and community evidence notes real-world integration friction (adyen-comm-9) though not specifically about sandbox fidelity. Missing for 10: explicit dispute/chargeback simulation test cards, a documented full test-card matrix, and independent hands-on confirmation that sandbox mirrors production behavior.

   • [claimed-docs] “We recommend testing your full integration, including the client-side and server-side parts, in your test environment before accepting live …”
   • [claimed-docs] “Test the different types of transactions with Adyen that your integration handles using test credentials.”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”

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

   The evidence pack contains no mention of a Disputes API, chargeback evidence submission, or any agent/MCP workflow for handling disputes end-to-end—only risk/fraud detection (Protect), refusal reasons, and unrelated agentic-commerce checkout flows are documented. The MCP server's tool list (sessions, payment links, modifications, management API) explicitly does not include dispute retrieval or evidence submission.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “You can detect, monitor, and mitigate fraud using Protect, Adyen's risk management system.”
   • [claimed-docs] “Each payment goes through a risk evaluation. The risk evaluation reaches a decision that results in an action to block, allow, or review the…”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”

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

   The evidence pack covers Adyen's risk/fraud tooling (Protect, rule builder, ML fraud detection) but contains no documentation of a chargeback/dispute management API, structured evidence submission, or dispute lifecycle tracking/status workflow. A vague community comment says Stripe beats Adyen on chargebacks 'hands down' but gives no concrete detail to substantiate a documented-capability failure, so it doesn't rise to a disputed claim — it simply reinforces the absence of positive evidence.

   ⚑ 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 Polar
   Adyen~partialclaimed5/10

   Evidence confirms API-level refund capability (Adyen's Management/Checkout 'modifications' API allows refunding a captured payment, and the MCP tool set explicitly includes 'refund a captured payment') and dashboard access to transaction management via the Customer Area, but no citation explicitly confirms partial-refund amount support or a documented dashboard refund button/workflow. missing for 10: explicit documentation of partial refund support (specifying an amount less than the captured total), explicit dashboard refund action screenshot/flow, and any independent/hands-on confirmation that refunds work as described.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “When the payment or modification request is unsuccessful, the `resultCode`, `refusalReason`, and `refusalReasonCode` describe the issue.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “In your Customer Area, you can find a log of all webhook events sent to your server.”

   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 to Adyen
   Adyen~partialclaimed7/10

   Adyen documents accepting local payment methods/currencies, configuring multiple payout currencies per merchant account, and both local (no SWIFT fee) and cross-border (SWIFT) settlement options, plus flexible payout timing/currency choice — directly supporting charge-local/settle-in-own-currency workflows. However, there's no explicit documentation of FX rate transparency (e.g., disclosed markup, real-time rate reporting) beyond the currency/payout mechanics themselves. Missing for 10: explicit FX rate/markup transparency documentation, independent confirmation of settlement FX handling in practice.

   • [claimed-docs] “Local payouts are faster and avoid SWIFT fees. You need a local bank account in a country that uses that specific currency as the legal tend…”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “This means you have the option to change how you get paid for each of your merchant accounts.”

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

   Adyen's evidence pack is entirely about payment processing, payouts, platforms, risk management, and agentic-commerce integrations — nothing addresses tax calculation, VAT/GST determination, tax collection, or tax compliance/remittance features. This axis applies since a payments platform could plausibly integrate tax calculation, but no evidence shows Adyen offers this.

   ⚑ 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 to Polar
   Adyen~partialprobed5/10

   Adyen exposes extensive Management/Checkout/Platforms APIs covering payments, onboarding, payouts, webhooks, credentials, terminals, and even an MCP server wrapping many of these APIs, suggesting broad API/UI parity for core payment operations. However, some UI-only surfaces (Customer Area account/transaction overview, visual reporting dashboards) are described only as UI features with no explicit statement that every dashboard/report/action is also API-accessible, and no full OpenAPI spec was reachable at standard docs endpoints (404s), only a separate GitHub repo. Missing for 10: explicit parity claim or evidence that all Customer Area/reporting/dashboard actions have API equivalents, and a verified complete OpenAPI coverage confirmation.

   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “You can also create multiple API credentials to improve security and control access.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “Adyen API credentials are scoped by construction: each credential carries "Roles: Permissions that define what the credential is allowed to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.adyen.com/openapi.json, https://docs.adyen.com/swagger.json, https://docs.adyen.com/api…”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”

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

   The evidence pack shows reporting dashboards and general documentation transparency (llms.txt, markdown docs, OpenAPI specs) but nothing about a merchant being able to export their own transactional/account data in open formats or close their account and leave without lock-in. Reporting is described as visual dashboards (adyen-docs-10), not bulk open-format export, and no data-portability/account-closure mechanism is documented.

   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [community] “Longtime Stripe user did about a year-long stint with Adyen. Stripe beats Adyen on ease of integration, ease of using the back office, charg…”

   proof ↗⚑ 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
   Adyen~partialclaimed3/10

   Adyen's core payment-processing platform is closed, proprietary SaaS with no evidence of the underlying service source being published under any license. However, evidence shows genuinely open-source ancillary components: the Adyen MCP server (github.com/Adyen/adyen-mcp) and the OpenAPI specification repo (github.com/Adyen/adyen-openapi) described as 'the single source of truth for our APIs,' both publicly viewable on GitHub. Missing for 10: any open license on the actual platform/service code, no stated license type for the repos, no independent confirmation of license terms, and no indication the core product itself is inspectable beyond API specs and a thin MCP client tool.

   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”
   • [claimed-docs] “The Adyen OpenAPI Specification repository (github.com/Adyen/adyen-openapi) "contains OpenAPI specifications for every public API Adyen offe…”
   • [claimed-docs] “"Adyen makes documentation accessible to developers as well as the software and AI tools they create." Documented agent-docs surface: llms.t…”

   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 to Polar
   Adyen—none0/10

   The evidence pack describes payouts, payout frequency, currencies, and a dashboard 'visual representation' of balances/payouts (adyen-docs-9,10,12,30,43), but nowhere documents an API for pulling balance/transaction-level data or a reconciliation workflow that an agent could invoke — the MCP tool list (adyen-supp-mcp-tools) covers checkout, payment links, and management API objects (merchants, terminals, webhooks, credentials) with no balance-transaction or reconciliation tools. Missing for 10: documented Balance/Transaction API endpoints, evidence of agent/MCP access to payout reconciliation data, and any reconciliation workflow example.

   • [claimed-docs] “Adyen supports paying out to cards instantly, and immediately returns the result of the payout attempt.”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”
   • [claimed-docs] “The Adyen MCP server (github.com/Adyen/adyen-mcp, Alpha) runs locally via `npx -y @adyen/mcp --env=TEST` (or `--env=LIVE --livePrefix=YOUR_P…”

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

   Docs clearly support configuring payout frequency, currency, and timing per merchant account (adyen-docs-12, adyen-docs-30, adyen-docs-50, adyen-docs-22) and note local vs cross-border payout mechanics (adyen-docs-13, adyen-docs-43). Reporting is mentioned as giving a 'visual representation of balances, sales, and payouts' (adyen-docs-10) and the Customer Area gives an overview of payment channels (adyen-docs-16), but there is no explicit evidence of a line-item payout reconciliation report breaking down which specific charges, fees, and refunds compose each payout. Missing for 10: detailed payout reconciliation report/API showing per-payout transaction breakdown, fee itemization, and refund matching.

   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “This means you have the option to change how you get paid for each of your merchant accounts.”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “Local payouts are faster and avoid SWIFT fees. You need a local bank account in a country that uses that specific currency as the legal tend…”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”

   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 Adyen
   Adyen~partialclaimed3/10

   Adyen's reporting docs mention a dashboard 'visual representation of your balances, sales, and payouts' and configurable payout frequency/currency, implying some settlement reporting exists, but nothing in the evidence describes itemized reconciliation reports that break out fees, refunds, and chargebacks against bank deposits. Missing for 10: documented settlement/reconciliation report format, explicit fee/refund/chargeback itemization, and any bank-deposit matching workflow or independent confirmation it works as needed.

   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Manage your account and transactions from our Customer Area, which shows an overview of all your payment channels.”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “Flexible payouts Choose when and in which currency you want to settle.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”

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

   Adyen for Platforms is explicitly documented to onboard sellers/contractors with verification (adyen-docs-11, adyen-docs-31, adyen-docs-36), split payments between parties and hold funds until payout (adyen-docs-21, adyen-docs-37), and configure flexible payout frequency/currency/local vs cross-border payouts (adyen-docs-12, adyen-docs-13, adyen-docs-22, adyen-docs-43, adyen-docs-50). Reporting/dashboards and risk management further round out the marketplace platform story (adyen-docs-10, adyen-docs-8). missing for 10: independent/hands-on developer account of building a full marketplace integration end-to-end, and more granular API-level detail (e.g., specific split-payment API request/response schemas) beyond docs summaries.

   • [claimed-docs] “Onboard sellers, service providers, or contractors on to your platform, and let Adyen verify them before paying out.”
   • [claimed-docs] “Process payments: accept payments on behalf of your users using Adyen's payment processing platform. You can split the payments between one …”
   • [claimed-docs] “Onboard sellers, service providers, or contractors on to your platform, and let Adyen verify them before paying out. Adyen informs you of th…”
   • [claimed-docs] “Onboard and verify your users: onboard sellers, service providers, or contractors on to your platform, and let Adyen verify them before payi…”
   • [claimed-docs] “You can split the payments between one or more users, deduct costs as needed, and hold funds until payout.”
   • [claimed-docs] “You can configure the payout frequency for each of your merchant accounts.”
   • [claimed-docs] “Local payouts are faster and avoid SWIFT fees. You need a local bank account in a country that uses that specific currency as the legal tend…”
   • [claimed-docs] “You can configure multiple payout currencies for each merchant account.”
   • [claimed-docs] “You can receive payouts in two ways: Local payout ... Cross-border payout: We send funds through SWIFT.”
   • [claimed-docs] “Allow your users to easily sign up, sell, and receive payments all within one solution.”
   • [claimed-docs] “This means you have the option to change how you get paid for each of your merchant accounts.”
   • [claimed-docs] “Get a visual representation of your balances, sales, and payouts.”

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

   Adyen's evidence pack covers payments, payouts, risk management, and agentic commerce integrations, but there is no documentation on data retention policies, data deletion requests, or user/API-level controls to manage how long payment or transaction data is stored or how to purge it. This is a fair axis for a payments platform handling PII/PCI data, but no evidence addresses it.

   ⚑ 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

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

   weight 2 · round drawn
   Adyen—none0/10

   Adyen ships AI-native tooling (an MCP server, docs-for-LLMs surface, agentic commerce APIs) so a privacy-posture question about telemetry/usage-tracking opt-out is a fair axis to ask, but no evidence in the pack describes any telemetry collection by these tools or any opt-out mechanism for it.

   ⚑ flag

   Polar—none0/10

   No evidence in the pack addresses telemetry/usage-tracking opt-out; Polar's docs focus on billing, checkout, MCP, webhooks, and merchant-of-record features with no mention of a privacy/telemetry setting.

   ⚑ flag