Mollie vs Polar

Agent access

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

   weight 2 · round drawn
   Mollie✓fullprobed9/10

   Mollie publishes a live llms.txt index (verified by probe returning HTTP 200) and documents the markdown-mirror convention (append .md to any doc page) so agents can systematically discover and fetch docs; this is corroborated by an independent probe hit, not just vendor claims. missing for 10: no independent third-party (non-Mollie) report of an agent actually using llms.txt successfully in practice.

   • [claimed-docs] “docs.mollie.com publishes a full llms.txt page index and documents the markdown mirror convention on every page: "Fetch the complete documen…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mollie.com/llms.txt # Mollie Documentation Documentation > Easily integrate online and point-of-sa…”

   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 Mollie
   Mollie✓fullclaimed7/10

   Mollie is a REST API-based payment platform designed for headless/server-side integration: API keys, idempotency keys, webhooks, and test mode all support fully automated, non-interactive/CI-driven operation without a UI. Missing for 10: no explicit CI/CD pipeline examples, SDK/CLI tooling for automated test suites, or independent hands-on reports of running Mollie flows inside a CI pipeline.

   • [claimed-docs] “Test mode is a first-class switch: "You can access the `test` mode of the Mollie API in two ways: by using the Test API key, or... by provid…”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”
   • [claimed-docs] “Four documented authentication methods — API keys ("default API access for a specific payment profile"), Advanced access tokens ("advanced A…”
   • [claimed-docs] “The Payments API is at the heart of the Mollie API. It allows you to create and manage payments.”
   • [claimed-docs] “Webhooks are used to process real-time status updates, for example when a payment is paid.”

   proof ↗⚑ flag

   Polar~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Mollie✓fullprobed9/10

   Mollie documents an official hosted MCP server at https://mcp.mollie.com/mcp acting as a proxy for its public API, with documented API coverage (Payments, Balances, Subscriptions, Webhooks, etc.), scoped access tokens, and setup instructions for Claude Desktop, Cursor, and VS Code. Missing for 10: independent/hands-on third-party corroboration beyond vendor docs and probe confirmation.

   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [probe] “official MCP server documented at https://docs.mollie.com/docs/mollie-mcp-server”

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

   Mollie is a payments API/platform; while it offers an MCP server, llms.txt index, and REST API/SDKs, no evidence pack item describes an official CLI tool for managing Mollie resources or workflows. Absence of evidence for this applicable capability yields 'none'.

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

   Mollie exposes a comprehensive, well-documented public REST API (Payments, Subscriptions, Balances, Webhooks, etc.), plus auth schemes, idempotency headers, test mode, and an llms.txt documentation index explicitly designed for AI agent discovery, alongside an official MCP server proxying the public API for AI tools like Claude/Cursor. Missing for 10: no discoverable OpenAPI/Swagger spec (probe returned 404s) and no independent hands-on corroboration beyond vendor docs.

   • [claimed-docs] “The Payments API is at the heart of the Mollie API. It allows you to create and manage payments.”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”
   • [claimed-docs] “Test mode is a first-class switch: "You can access the `test` mode of the Mollie API in two ways: by using the Test API key, or... by provid…”
   • [claimed-docs] “Four documented authentication methods — API keys ("default API access for a specific payment profile"), Advanced access tokens ("advanced A…”
   • [claimed-docs] “docs.mollie.com publishes a full llms.txt page index and documents the markdown mirror convention on every page: "Fetch the complete documen…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mollie.com/llms.txt # Mollie Documentation Documentation > Easily integrate online and point-of-sa…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.mollie.com/openapi.json, https://docs.mollie.com/swagger.json, https://docs.mollie.com/…”
   • [probe] “official MCP server documented at https://docs.mollie.com/docs/mollie-mcp-server”

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

   Mollie documents scoped credential mechanisms applicable to agent use: Advanced access tokens can be scoped to a specific mode or profile, API keys are scoped per payment profile with granular permissions grouped by business area/API, and the MCP server explicitly requires profile.read plus optional per-API scopes to enable individual tools. This shows a real least-privilege model usable when provisioning an agent, but there's no dedicated 'agent credential' concept, no fine-grained per-action/per-amount limits, and no independent evidence of this being used in practice for agent scoping. Missing for 10: agent-specific credential issuance workflow, granular per-action/spend-limit scoping beyond API/profile level, independent/hands-on confirmation of least-privilege enforcement in an agentic context.

   • [claimed-docs] “Four documented authentication methods — API keys ("default API access for a specific payment profile"), Advanced access tokens ("advanced A…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”

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

   The evidence pack documents Mollie's REST API references, webhooks, testing mode, and an MCP server for AI agents, but never mentions official client SDKs/libraries (e.g., PHP, Node, Python, Java clients) that developers or AI agents could build against. Since SDK availability is a standard axis for a payments API platform, its absence here is a gap rather than a category mismatch.

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

   Mollie's next-gen Webhooks API explicitly supports permanent subscriptions to specific event types (replacing one-off payment webhooks), backed by a Webhook Events API for auditing past events and documented HMAC signature verification for security. This directly satisfies event-driven subscription via webhooks for programmatic/agentic consumption. Missing for 10: independent/hands-on verification of webhook delivery reliability and broader real-world event-type coverage beyond docs.

   • [claimed-docs] “Next-gen webhooks add a subscription model and an audit API: "Updated Webhooks API allowing you to permanently subscribe to specific event t…”
   • [claimed-docs] “Webhooks are used to process real-time status updates, for example when a payment is paid.”
   • [claimed-docs] “To verify HMAC signature for a webhook, follow these steps: 1. Retrieve the signature from the request header (X-Mollie-Signature)...”
   • [claimed-docs] “New event types to offer a broader context for your business processes (e.g. payment creation, invoice creation, onboarding status changes e…”
   • [claimed-docs] “To verify HMAC signature for a webhook, follow these steps: Retrieve the signature from the request header (X-Mollie-Signature) and obtain t…”

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

   Mollie's AI-related evidence covers an MCP server that lets external AI tools create/manage payment resources via natural language, but there is no evidence of the product itself generating insights, analytics, or suggestions from a merchant's data within Mollie's own interface or reports.

   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”

   proof ↗⚑ flag

   Polar—none0/10

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

   ⚑ flag

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

   weight 2 · round to Mollie
   Mollie~partialclaimed6/10

   Mollie ships genuine background automation primitives — Subscriptions/Recurring Payments run autonomously after initial setup ('happen in the background', 'we automatically create recurring payments for you at the interval you specified') and webhooks push real-time async updates — and its MCP server lets AI tools like Claude Desktop/Cursor create these resources via natural language. However, the automation scope is narrow (payment-related resources only) and the MCP server is documented for one-off resource creation/queries, not for orchestrating persistent autonomous agent workflows. Missing for 10: evidence of AI agents scheduling/monitoring ongoing automations themselves (vs. one-time setup), and any broader workflow/automation-builder beyond payments primitives.

   • [claimed-docs] “Recurring payments happen in the background. The customer goes through the payment steps only once, for the first payment.”
   • [claimed-docs] “The Subscriptions API provides an easy way to schedule recurring payments at regular intervals. When using this API, we automatically create…”
   • [claimed-docs] “When using this API, we automatically create recurring payments for you at the interval you specified.”
   • [claimed-docs] “Webhooks are used to process real-time status updates, for example when a payment is paid.”
   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [claimed-docs] “Next-gen webhooks add a subscription model and an audit API: "Updated Webhooks API allowing you to permanently subscribe to specific event t…”

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

   Mollie's evidence describes an MCP server that lets external AI tools (Claude Desktop, Cursor, VS Code) call Mollie's APIs via natural language — this is Mollie acting as a tool/backend for other assistants, not a built-in AI assistant inside Mollie's own product that users delegate tasks to. No dashboard chatbot, in-app assistant, or similar built-in AI feature is documented.

   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [probe] “official MCP server documented at https://docs.mollie.com/docs/mollie-mcp-server”

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

   Mollie ships an official MCP server (hosted at mcp.mollie.com/mcp) explicitly documented as enabling merchants to use natural language via AI tools like Claude Desktop and Cursor AI to create resources in their Mollie account, with scoped OAuth access and documented client configs. Missing for 10: independent/hands-on user reports confirming reliability, and broader coverage details (only a subset of APIs are exposed via MCP, e.g. no Payments creation confirmation beyond listed APIs).

   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [probe] “official MCP server documented at https://docs.mollie.com/docs/mollie-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
   Mollie—none0/10

   Evidence covers static markdown documentation, an llms.txt index, and reference pages, but there is no mention of an interactive API console, 'try it' runnable examples, or Postman/OpenAPI-based playground; a probe for OpenAPI/swagger specs returned 404s, suggesting no such interactive reference exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.mollie.com/openapi.json, https://docs.mollie.com/swagger.json, https://docs.mollie.com/…”
   • [claimed-docs] “docs.mollie.com publishes a full llms.txt page index and documents the markdown mirror convention on every page: "Fetch the complete documen…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mollie.com/llms.txt # Mollie Documentation Documentation > Easily integrate online and point-of-sa…”

   proof ↗⚑ flag

   Polar~partialprobed5/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Polar
   Mollie—none0/10

   Probes for standard OpenAPI/Swagger spec locations on Mollie's docs site all returned 404, and no evidence pack item shows a published, downloadable OpenAPI/Swagger spec; the llms.txt index and markdown mirrors are documentation aids, not a machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.mollie.com/openapi.json, https://docs.mollie.com/swagger.json, https://docs.mollie.com/…”
   • [claimed-docs] “docs.mollie.com publishes a full llms.txt page index and documents the markdown mirror convention on every page: "Fetch the complete documen…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mollie.com/llms.txt # Mollie Documentation Documentation > Easily integrate online and point-of-sa…”

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

   Mollie documents a first-class test mode that isolates test resources from live data, supports test API keys or a testmode parameter, replaces hosted checkout with a simulated flow, and even allows simulating refunds/chargebacks via changePaymentState — directly matching the sandbox-without-production-data story. missing for 10: no independent/hands-on third-party confirmation of sandbox behavior beyond vendor docs, and no explicit mention of sandbox support specifically for the MCP/AI-agent workflow (only general API test mode is documented).

   • [claimed-docs] “Any payments or other resources you create in test mode are completely isolated from your live mode data.”
   • [claimed-docs] “Test mode is a first-class switch: "You can access the `test` mode of the Mollie API in two ways: by using the Test API key, or... by provid…”

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

   The evidence shows Mollie has a v2 API (mollie-docs-12) but nothing documents a versioning scheme, deprecation policy, changelog, or sunset timeline for older API versions/endpoints. Missing for 10: explicit API versioning documentation, deprecation/sunset policy, changelog or migration guide evidence.

   • [claimed-docs] “Mollie enables you to accept payments in currencies beyond EUR through its v2 APIs, allowing international customers to transact in their pr…”

   proof ↗⚑ flag

   Polar~partialprobed4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Mollie—none0/10

   Mollie's documented APIs (Payments, Refunds, Subscriptions, Balances, MCP server, etc.) are all single-resource endpoints; there is no evidence of a batch/bulk API, bulk payment creation, or bulk refund/webhook management across many items at once. The MCP server description explicitly frames it as creating individual resources via natural language, not bulk operations.

   • [claimed-docs] “The Mollie MCP server enables merchants to use various AI tools like Claude Desktop and Cursor AI to utilize natural language for creating d…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [claimed-docs] “The Payments API is at the heart of the Mollie API. It allows you to create and manage payments.”
   • [claimed-docs] “Next to the API endpoint, you can also create refunds manually via the Mollie Web app.”

   proof ↗⚑ flag

   Polar—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   Mollie~partialclaimed4/10

   Mollie provides event-driven building blocks — webhooks that fire on payment status changes, subscriptions that auto-create recurring payments, and application fees that auto-collect on every payment — but these are fixed, pre-built automations, not a general rules engine where a user defines arbitrary 'if event X then action Y' logic. Actual custom rule logic must be built externally by consuming webhooks in the merchant's own system. Missing for 10: a native rules/automation builder, conditional trigger-action configuration UI or API, and evidence of user-defined (vs. Mollie-predefined) automated actions.

   • [claimed-docs] “Webhooks are used to process real-time status updates, for example when a payment is paid.”
   • [claimed-docs] “Next-gen webhooks add a subscription model and an audit API: "Updated Webhooks API allowing you to permanently subscribe to specific event t…”
   • [claimed-docs] “The Subscriptions API provides an easy way to schedule recurring payments at regular intervals. When using this API, we automatically create…”
   • [claimed-docs] “Application Fees allow your platform to collect a fee on every payment you process on behalf of a connected account. You define the amount, …”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”

   proof ↗⚑ flag

   Polar~partialclaimed4/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Mollie
   Mollie~partialclaimed6/10

   Mollie's Subscriptions API automatically creates recurring payments at specified intervals without further manual action, which is a genuine recurring-job capability, but it is scoped strictly to payment charges rather than general workflow/job scheduling. Missing for 10: any general-purpose task/workflow scheduler, cron-like triggers beyond billing, or orchestration hooks usable outside payments.

   • [claimed-docs] “When using this API, we automatically create recurring payments for you at the interval you specified.”
   • [claimed-docs] “The Subscriptions API provides an easy way to schedule recurring payments at regular intervals. When using this API, we automatically create…”
   • [claimed-docs] “Recurring payments can be used to charge customers on a regular basis or to offer automatic top-ups with credits-based services.”
   • [claimed-docs] “Recurring payments happen in the background. The customer goes through the payment steps only once, for the first payment.”

   proof ↗⚑ flag

   Polar—none0/10

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

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

   proof ↗⚑ flag

Ai billing ops

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

   weight 3 · round to Polar
   Mollie~partialclaimed4/10

   Mollie exposes webhooks with real-time payment status updates (including failures) and a Subscriptions/Payments API that an agent could poll or subscribe to via the MCP server, giving raw building blocks for monitoring failed payments programmatically. However, there is no documented dunning/retry-management feature, automated retry scheduling, or outreach tooling — an agent would have to build all retry/dunning logic itself on top of raw webhook events and API calls. Missing for 10: native dunning/retry automation, documented failed-payment recovery workflow, and evidence of an agent orchestrating retries end-to-end.

   • [claimed-docs] “Webhooks are used to process real-time status updates, for example when a payment is paid.”
   • [claimed-docs] “Next-gen webhooks add a subscription model and an audit API: "Updated Webhooks API allowing you to permanently subscribe to specific event t…”
   • [claimed-docs] “The Subscriptions API provides an easy way to schedule recurring payments at regular intervals. When using this API, we automatically create…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [claimed-docs] “Webhooks are used to process real-time status updates, for example when a payment is paid. It is a URL Mollie will call with the ID of the u…”

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

   Mollie's MCP server (mollie-supp-mcp-server) lets an agent create resources including Payment Links via natural language in one session, and the Payment Links API supports generating a shareable payment link directly from an amount/description (mollie-docs-5, mollie-docs-23). However, Mollie has no documented 'Product' or 'Price' catalog objects (unlike Stripe-style billing) — the MCP tool coverage list (Balances, Captures, Customers, Invoices, Mandates, Methods, Payments, Payment Links, Settlements, Subscriptions, Terminals, Webhooks) never mentions Products or Prices APIs, so the exact three-step workflow described isn't evidenced. Missing for 10: a Products/Prices API or equivalent catalog resource, an end-to-end documented/independent example of an agent chaining product+price+link creation in one session.

   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”
   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer... shared via email or chat applications.”
   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer. The payment link can for example be attached to an u…”
   • [claimed-docs] “The Payments API is at the heart of the Mollie API. It allows you to create and manage payments.”

   proof ↗⚑ flag

   Polar~partialclaimed7/10

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

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

   proof ↗⚑ flag

Invoicing

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

   weight 2 · round to Mollie
   Mollie~partialclaimed3/10

   Mollie's Payment Links can be attached to an unpaid invoice and shared via email/chat, giving a hosted payment option for invoices, and an 'Invoices API' is listed among MCP-server-exposed APIs, but there is no documentation of generating/sending actual hosted invoice documents or of automatic payment reminders. missing for 10: dedicated hosted-invoice creation/send flow, automatic reminder scheduling, and any invoice-status/reminder API details.

   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer... shared via email or chat applications.”
   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer. The payment link can for example be attached to an u…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”

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

   Mollie's docs cover Subscriptions API, recurring payments, webhooks, and idempotency, but none of the evidence describes automatic retry logic for failed subscription payments, dunning schedules, or recovery emails to customers — this is a distinct capability not documented anywhere in the pack.

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

   Mollie's Subscriptions API automates recurring payments at set intervals, which covers basic recurring billing, but the evidence shows no concept of 'plans' as reusable templates, no trial period support, no subscription upgrade/downgrade mechanism, and no proration logic — these are core parts of the story. missing for 10: plan/catalog abstraction, trial period support, upgrade/downgrade workflows, proration calculation, and any documented example of managing subscription lifecycle changes.

   • [claimed-docs] “When using this API, we automatically create recurring payments for you at the interval you specified.”
   • [claimed-docs] “The Subscriptions API provides an easy way to schedule recurring payments at regular intervals. When using this API, we automatically create…”
   • [claimed-docs] “Recurring payments happen in the background. The customer goes through the payment steps only once, for the first payment.”
   • [claimed-docs] “Recurring payments can be used to charge customers on a regular basis or to offer automatic top-ups with credits-based services.”

   proof ↗⚑ flag

   Polar✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Card acceptance

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

   weight 3 · round to Polar
   Mollie~partialclaimed6/10

   Mollie offers multiple fast paths to accept a card payment—hosted checkout, plug-and-play e-commerce plugins (Shopify/WooCommerce/Magento), and no-code Payment Links shareable via email/chat—all of which could plausibly go live quickly after signup. However, there is no explicit evidence about account verification/KYC turnaround time or a documented 'go live same day' onboarding flow, which is the crux of the founder's story. Missing for 10: explicit onboarding/KYC approval timeline evidence, first-party or independent confirmation that a new merchant can complete verification and accept a live payment within 24 hours.

   • [claimed-docs] “we provide integrations for all common e-commerce platforms, such as Shopify, WooCommerce, and Magento. Simply installing the Mollie module …”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”
   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer... shared via email or chat applications.”
   • [claimed-docs] “Mollie provides a hosted checkout environment dubbed Mollie Checkout. These hosted payment pages allow your customer to select their payment…”
   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer. The payment link can for example be attached to an u…”

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

   Mollie Components (Mollie JS) let developers embed PCI-DSS-compliant card fields directly in their own checkout UI rather than redirecting to a hosted page, and docs explicitly outline build-your-own-checkout via the Payments API as an alternative to hosted checkout. This covers the core story of embeddable, customizable payment components. Missing for 10: independent/hands-on developer corroboration of styling customization depth and broader component coverage beyond card fields.

   • [claimed-docs] “If, however, you are keen on building your own checkout experience, below we offer a way to implement it.”
   • [claimed-docs] “Mollie JS is a set of Javascript APIs that allow you to add the fields needed for credit card holder data to your own checkout, in a way tha…”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”

   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 drawn
   Mollie✓fullclaimed9/10

   Mollie's hosted checkout is explicitly documented as a Mollie-hosted, device-optimized payment page that lets developers redirect customers without building their own UI, with e-commerce platform plugins and Payments API integration for redirect flows. missing for 10: independent/hands-on conversion-optimization evidence beyond vendor docs.

   • [claimed-docs] “Mollie provides a hosted checkout environment dubbed Mollie Checkout. These hosted payment pages allow your customer to select their payment…”
   • [claimed-docs] “Mollie's hosted payment pages have been optimized for devices of all common brands and sizes, including phones and tablets.”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”
   • [claimed-docs] “we provide integrations for all common e-commerce platforms, such as Shopify, WooCommerce, and Magento. Simply installing the Mollie module …”
   • [claimed-docs] “The Payments API is at the heart of the Mollie API. It allows you to create and manage payments.”

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

   Mollie's docs confirm a no-code Payment Links capability that lets founders generate a shareable link (email/chat) without building a full checkout, and it's explicitly called out as a 'no-code' option alongside hosted/API checkouts [mollie-docs-5, mollie-docs-23, mollie-supp-hosted-checkout]. However, the evidence never explicitly shows the dashboard UI flow for creating a payment link (it frames it as an API), so it's unclear if a founder can do this purely by clicking in the dashboard with zero technical setup. Missing for 10: explicit dashboard UI screenshots/steps for generating a payment link with no code, and confirmation that no account/API key setup is needed before selling.

   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer... shared via email or chat applications.”
   • [claimed-docs] “With the Payment Links API you can generate a payment link to share with your customer. The payment link can for example be attached to an u…”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”

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

   Mollie's hosted checkout is documented as a single integration where 'customer can select their payment method of choice' (mollie-docs-21), and Apple Pay is explicitly called out as a checkout button option (mollie-docs-35), supporting the core 'one integration, many methods' claim. However, the evidence pack never explicitly names Google Pay, bank redirects (iDEAL/SEPA/Bancontact), or BNPL options (Klarna/Riverty) as available methods within this single integration. Missing for 10: explicit documentation of Google Pay support, bank redirect methods, and BNPL options within the same checkout integration.

   • [claimed-docs] “Mollie provides a hosted checkout environment dubbed Mollie Checkout. These hosted payment pages allow your customer to select their payment…”
   • [claimed-docs] “Display the Apple Pay button on your cart, checkout, and product pages... to speed up checkout.”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”
   • [claimed-docs] “Mollie's hosted payment pages have been optimized for devices of all common brands and sizes, including phones and tablets.”

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

   Mollie offers hosted checkout, Payment Links, and Mollie Components explicitly documented as 'fully PCI-DSS SAQ-A compliant', keeping card data off the merchant's own servers via tokenized/embedded fields or redirect, which minimizes PCI scope. missing for 10: no independent third-party audit or compliance certificate evidence, and no explicit statement of merchant SAQ-A eligibility requirements/limitations.

   • [claimed-docs] “Mollie JS is a set of Javascript APIs that allow you to add the fields needed for credit card holder data to your own checkout, in a way tha…”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”
   • [claimed-docs] “Mollie's hosted payment pages have been optimized for devices of all common brands and sizes, including phones and tablets.”
   • [claimed-docs] “Mollie provides a hosted checkout environment dubbed Mollie Checkout. These hosted payment pages allow your customer to select their payment…”

   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 Mollie
   Mollie✓fullclaimed9/10

   Mollie documents the Idempotency-Key header explicitly for safe retries and even calls out the exact danger scenarios (double charges on recurring payments/subscriptions, duplicate partial refunds) that it prevents. missing for 10: independent/hands-on developer confirmation of idempotency behavior in production beyond vendor docs.

   • [claimed-docs] “you can send a unique value with every API request via the Idempotency-Key header. If two requests come in with the same value, the second r…”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”
   • [claimed-docs] “In the Mollie API, these sorts of problems can be solved in two ways... you can actively i[dentify requests with an idempotency key]”

   proof ↗⚑ flag

   Polar—none0/10

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

   ⚑ flag

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

   weight 3 · round drawn
   Mollie~partialclaimed5/10

   Mollie documents signed webhooks via HMAC verification (X-Mollie-Signature) and a next-gen Webhook Events API that lets developers 'retroactively inspect past events' and retrieve detailed info per triggered event, giving an audit/event-log capability. However, there is no documented automatic retry mechanism for webhook delivery, and no explicit 'replay' feature to resend a webhook event to reprocess it — idempotency keys only cover client-side API request retries, not Mollie's own webhook delivery retries. missing for 10: documented automatic webhook delivery retry policy, explicit replay/resend capability for webhook events, independent/hands-on confirmation of retry behavior.

   • [claimed-docs] “To verify HMAC signature for a webhook, follow these steps: 1. Retrieve the signature from the request header (X-Mollie-Signature)...”
   • [claimed-docs] “To verify HMAC signature for a webhook, follow these steps: Retrieve the signature from the request header (X-Mollie-Signature) and obtain t…”
   • [claimed-docs] “Next-gen webhooks add a subscription model and an audit API: "Updated Webhooks API allowing you to permanently subscribe to specific event t…”
   • [claimed-docs] “New event types to offer a broader context for your business processes (e.g. payment creation, invoice creation, onboarding status changes e…”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”

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

   Mollie's docs give a clear, well-structured path (hosted checkout, Payments API, webhooks, test mode, idempotency) that a developer could follow to build a working payment flow, and llms.txt/markdown mirrors make the docs easily consumable. However, the evidence pack never shows actual copy-paste code snippets in a specific programming language (e.g. PHP/Node/Python SDK examples) or confirms a 'under a day' end-to-end tutorial — only conceptual/API-reference descriptions are present. missing for 10: language-specific copy-paste code samples/SDK quickstarts, an explicit fast end-to-end tutorial timeline, independent developer corroboration of setup speed

   • [claimed-docs] “If, however, you are keen on building your own checkout experience, below we offer a way to implement it.”
   • [claimed-docs] “Mollie provides a hosted checkout environment dubbed Mollie Checkout. These hosted payment pages allow your customer to select their payment…”
   • [claimed-docs] “The Payments API is at the heart of the Mollie API. It allows you to create and manage payments.”
   • [claimed-docs] “Three documented integration depths: hosted checkout (Mollie-hosted payment pages), Mollie Components (embeddable card components for PCI sc…”
   • [claimed-docs] “Test mode is a first-class switch: "You can access the `test` mode of the Mollie API in two ways: by using the Test API key, or... by provid…”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”
   • [claimed-docs] “docs.mollie.com publishes a full llms.txt page index and documents the markdown mirror convention on every page: "Fetch the complete documen…”

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

   Mollie documents a genuine test mode that isolates test data from production, replaces hosted checkout with a walkthrough screen, and exposes a changePaymentState URL to simulate refunds and chargebacks (mollie-supp-testing, mollie-docs-18). However, the evidence never mentions specific test card numbers or a documented list of decline/failure scenarios by card, which the story explicitly calls for. Missing for 10: documented test card numbers per scenario (success, decline, insufficient funds, etc.), and independent/hands-on confirmation that test mode fully mirrors all production payment method behaviors.

   • [claimed-docs] “Test mode is a first-class switch: "You can access the `test` mode of the Mollie API in two ways: by using the Test API key, or... by provid…”
   • [claimed-docs] “Any payments or other resources you create in test mode are completely isolated from your live mode data.”

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

   Mollie's Chargebacks API only supports retrieving chargeback details (mollie-docs-9); there is no documented capability for assembling evidence or submitting a dispute response via the API, and the MCP server's supported API list does not even include Chargebacks (mollie-supp-mcp-server). No evidence supports the 'submitting the response' half of this story.

   • [claimed-docs] “The Chargebacks API then allows you to retrieve details of the chargebacks that took place on your account.”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a p…”

   proof ↗⚑ flag

   Polar—none0/10

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

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

   proof ↗⚑ flag

Disputes

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

   weight 3 · round to Mollie
   Mollie~partialclaimed3/10

   Mollie's Chargebacks API only lets merchants retrieve details of chargebacks that occurred on their account (mollie-docs-9); there is no documented capability to submit structured evidence in response to a dispute or to track a dispute lifecycle through stages to resolution. Settlement reports and balances APIs (mollie-docs-10, mollie-docs-11) help reconcile chargeback deductions financially, but this is reconciliation, not dispute-response workflow. missing for 10: evidence-submission/response mechanism for chargebacks, dispute status/lifecycle states, resolution outcome tracking, any UI or API for contesting a chargeback.

   • [claimed-docs] “The Chargebacks API then allows you to retrieve details of the chargebacks that took place on your account.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”

   proof ↗⚑ flag

   Polar—none0/10

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

   ⚑ flag

Refunds

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

   weight 3 · round to Mollie
   Mollie✓fullclaimed8/10

   Docs confirm refunds can be created via the API endpoint and manually via the Mollie Web app (dashboard), and the idempotency docs explicitly reference 'partial refunds' as a supported operation, confirming both full and partial refund support across both surfaces. Missing for 10: no dedicated Refunds API reference doc explicitly listing full vs partial refund parameters, and no independent/hands-on confirmation beyond first-party docs.

   • [claimed-docs] “you can also create refunds manually via the Mollie Web app.”
   • [claimed-docs] “Next to the API endpoint, you can also create refunds manually via the Mollie Web app.”
   • [claimed-docs] “Idempotent retries via a documented header: "you can send a unique value with every API request via the `Idempotency-Key` header. If two req…”

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

   Mollie documents accepting payments in currencies beyond EUR via its v2 APIs [mollie-docs-12], and provides Settlement Reports and Balances API for reconciling payouts [mollie-docs-10, mollie-docs-27, mollie-docs-11, mollie-docs-28], which supports part of the founder's need. However, there is no evidence detailing FX conversion rates, markup/fee transparency, or explicit confirmation that funds settle to the merchant's bank account in their own currency after conversion. Missing for 10: explicit FX rate/markup disclosure, settlement-currency selection/conversion mechanics, and independent confirmation of how multi-currency payments reconcile to a single bank currency.

   • [claimed-docs] “Mollie enables you to accept payments in currencies beyond EUR through its v2 APIs, allowing international customers to transact in their pr…”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”

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

   Mollie is a payment processing platform (checkout, payments, subscriptions, payouts, connect/marketplace splits) with no evidence of tax/VAT/GST calculation, rate lookup, or automated tax collection features anywhere in the evidence pack.

   ⚑ flag

   Polar✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Mollie~partialclaimed7/10

   Mollie's API surface is extensive and mirrors most Dashboard functionality: payments, refunds (explicitly noted as available both via API and manually in the 'Mollie Web app'), subscriptions, balances, settlement reports, chargebacks, webhooks, and Connect split-payments/application-fees are all API-accessible. However, no evidence explicitly asserts full 1:1 API/UI parity across every dashboard feature (e.g., account settings, onboarding flows, reporting UI extras), and the MCP server itself only proxies a subset of APIs (missing Refunds, Chargebacks, Orders), leaving some UI-only gaps unconfirmed either way. Missing for 10: explicit parity statement, independent confirmation that every dashboard action has an API equivalent, and coverage of admin/config UI features not mentioned in docs.

   • [claimed-docs] “you can also create refunds manually via the Mollie Web app.”
   • [claimed-docs] “Next to the API endpoint, you can also create refunds manually via the Mollie Web app.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Chargebacks API then allows you to retrieve details of the chargebacks that took place on your account.”
   • [claimed-docs] “Marketplace money movement is documented under Mollie Connect: "Split payments let marketplaces distribute funds across multiple sellers in …”
   • [claimed-docs] “Test mode is a first-class switch: "You can access the `test` mode of the Mollie API in two ways: by using the Test API key, or... by provid…”
   • [claimed-docs] “Four documented authentication methods — API keys ("default API access for a specific payment profile"), Advanced access tokens ("advanced A…”

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

   Mollie's docs show only piecemeal transaction-reporting APIs (Settlement Report, Balances API) for reconciliation, not a comprehensive account data export or account-closure/portability feature; there's no evidence of a full data export in open formats or a documented way to close an account and take all data with you.

   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”

   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

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

   Mollie documents a Balances API for real-time/historical balance data and a Settlement Report that breaks down transactions, fees, and deductions per payout for reconciliation, both accessible via API and exposed through the Mollie MCP server (Balances, Settlements listed as covered APIs). However, evidence doesn't show a documented API endpoint for retrieving the underlying settlement/payout line items programmatically beyond the Settlements API listing itself, nor concrete agent-driven examples of matching balance transactions to charges. missing for 10: explicit documented Settlements API line-item/transactions endpoint schema, worked example of an agent reconciling deposits to charges end-to-end, and independent/hands-on confirmation of this reconciliation workflow via API or MCP.

   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”
   • [claimed-docs] “The Mollie MCP server is hosted at a documented endpoint: "You can find Mollie MCP server at `https://mcp.mollie.com/mcp`, which acts as a 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 Mollie
   Mollie~partialclaimed6/10

   Mollie's Settlement Report gives a full breakdown of transactions, fees, and deductions per payout, and the Balances API exposes real-time/historical balance data useful for reconciliation, directly supporting the 'see what makes up each payout' half of the story. However, there is no evidence of finance-ops controls to set or change the payout schedule (e.g., daily/weekly/custom payout frequency settings) — the docs only describe reporting/retrieval APIs, not schedule configuration. missing for 10: documented payout schedule/frequency controls, UI or API to set payout timing, confirmation that fees/refunds/chargebacks are itemized per payout beyond settlement report summary.

   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”

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

   Mollie's Settlement Report explicitly gives a breakdown of a payout showing 'all transactions, fees and deductions,' and the Balances API supports bookkeeping reconciliation, while separate Chargebacks and Refunds APIs let finance-ops retrieve those items — together covering the core of the story. However, no evidence shows a single itemized report combining fees, refunds, and chargebacks in one reconciliation view, nor any bank-deposit matching feature or independent/hands-on validation of the reconciliation workflow. Missing for 10: unified itemized settlement report explicitly breaking out refunds/chargebacks line-by-line, bank-deposit matching capability, and independent user corroboration.

   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout... helping you reconcile your transactions.”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance.”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”
   • [claimed-docs] “The Chargebacks API then allows you to retrieve details of the chargebacks that took place on your account.”
   • [claimed-docs] “you can also create refunds manually via the Mollie Web app.”

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

   Mollie Connect explicitly supports onboarding connected merchants, escrow-like holding of funds, split payments to multiple sellers, and application fees/commission retention for the platform, backed by documented onboarding, reporting, and payout mechanisms (settlement reports, balances API). missing for 10: independent/hands-on developer case studies building a full marketplace end-to-end, and more detail on seller onboarding KYC flow specifics beyond doc mentions.

   • [claimed-docs] “Mollie Connect lets software platforms and marketplaces offer payment and money management capabilities to their merchants under their own b…”
   • [claimed-docs] “Split payments let marketplaces distribute funds across multiple sellers in a single transaction.”
   • [claimed-docs] “Application Fees allow your platform to collect a fee on every payment you process on behalf of a connected account.”
   • [claimed-docs] “Marketplace money movement is documented under Mollie Connect: "Split payments let marketplaces distribute funds across multiple sellers in …”
   • [claimed-docs] “Settlement Report gives you a complete breakdown of the data included in a specific payout. It shows all transactions, fees and deductions t…”
   • [claimed-docs] “The Balances API allows you to retrieve real-time as well as historical information about your Mollie balance. This may be useful to for exa…”
   • [claimed-docs] “Application Fees allow your platform to collect a fee on every payment you process on behalf of a connected account. You define the amount, …”

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

   Mollie is a payments API/platform; no evidence in the pack addresses data retention policies, data deletion controls, or export/erasure mechanisms for AI-native users. The evidence covers payments, checkout, webhooks, Connect, and MCP server capabilities but nothing about privacy/data lifecycle controls.

   ⚑ 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