Checkout.com vs Mollie

Agent access

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

   weight 2 · round to Mollie
   Checkout.com✓fullprobed8/10

   Checkout.com hosts a live llms.txt at both www.checkout.com/llms.txt and docs.checkout.com/llms.txt, confirmed via probe returning HTTP 200 with structured content, plus multiple docs entries derived from that file listing agent-readable summaries of products/APIs. This directly satisfies pointing an agent at llms.txt. missing for 10: independent third-party confirmation of an agent successfully consuming the file end-to-end, and a docs.md/markdown mirror (docs.md returned 404).

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.checkout.com/llms.txt # Checkout.com: High-performance global payments platform for enterprise and s…”
   • [claimed-docs] “Unified Payments API: Connect to all payment methods through a single API integration.”
   • [claimed-docs] “Request a payment using a token, a network token, a payment instrument, or the full card details.”
   • [claimed-docs] “Use your Checkout Business Account to efficiently manage your funds across our product suite.”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.checkout.com/docs.md”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Mollie
   Checkout.com~partialclaimed7/10

   Checkout.com is API-first with SDKs (e.g. Node.js), OAuth2 client-credentials auth, idempotent retries, webhooks, and a full sandbox/test-account environment with test cards — all of which support scripted, headless use in CI/test pipelines. However there is no dedicated CLI or explicit CI/CD pipeline documentation/tutorials for automation. Missing for 10: dedicated CLI tool, explicit CI/CD integration guide or example pipeline.

   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”
   • [claimed-docs] “Two documented server-side authentication forms — "Access keys (OAuth 2.0)" (client-credentials flow) and "Secret keys" — plus public keys f…”
   • [claimed-docs] “A dedicated test-account environment with per-scenario testing docs: payments testing, test cards, disputes testing, fraud-detection testing…”
   • [github] “The official Node.js SDK for Checkout.com payment gateway.”
   • [claimed-docs] “Test cards”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Checkout.com✓fullprobed9/10

   Checkout.com documents an official, hosted MCP server (sandbox and production endpoints, OAuth via Dashboard account) with concrete setup instructions (e.g., adding it to Claude Code) and documented capabilities like querying payments, issuing refunds, managing payment links, and knowledge-base search — directly fulfilling the story. Missing for 10: independent/third-party corroboration of real-world usage beyond vendor docs, and it's explicitly marked Beta.

   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”
   • [claimed-docs] “The Checkout.com Model Context Protocol (MCP) Server enables you to search through our knowledge base and manage payment operations directly…”
   • [probe] “official MCP server documented at https://www.checkout.com/docs/developer-resources/checkout-com-mcp-server”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Checkout.com—none0/10

   Evidence shows SDKs (Node.js), a Dashboard, an MCP server, and agentic-commerce protocol integrations, but no mention of an official CLI tool for developers. Payment platforms commonly ship CLIs (e.g., for testing webhooks, managing keys), so the axis applies, but no such capability is documented anywhere in this evidence pack.

   • [github] “The official Node.js SDK for Checkout.com payment gateway.”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.checkout.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.checkout.com/openapi.json, https://www.checkout.com/swagger.json, https://www.checkout.c…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Checkout.com
   Checkout.com✓fullprobed9/10

   Checkout.com documents a comprehensive public REST/Unified Payments API with OAuth2/API-key auth, idempotency, rate limits, webhooks, SDKs (Node.js), and a full testing sandbox, plus explicit agentic-commerce integrations (ChatGPT, Google AI) and an official MCP server for AI-agent operation — strongly supporting AI-native programmatic control. Missing for 10: a discoverable OpenAPI/swagger spec (probe found 404s) and independent third-party corroboration beyond vendor docs.

   • [claimed-docs] “Unified Payments API: Connect to all payment methods through a single API integration.”
   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”
   • [claimed-docs] “Two documented server-side authentication forms — "Access keys (OAuth 2.0)" (client-credentials flow) and "Secret keys" — plus public keys f…”
   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “A dedicated test-account environment with per-scenario testing docs: payments testing, test cards, disputes testing, fraud-detection testing…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”
   • [claimed-docs] “"With agentic commerce, your customers can discover and pay for products through an AI chat interface, instead of visiting your website. The…”
   • [github] “The official Node.js SDK for Checkout.com payment gateway.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.checkout.com/openapi.json, https://www.checkout.com/swagger.json, https://www.checkout.c…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Mollie
   Checkout.com~partialclaimed5/10

   Checkout.com documents OAuth 2.0 client-credentials flow and 'access keys' alongside secret keys, letting integrations obtain scoped, non-static credentials per processing channel — a real least-privilege mechanism. However, the MCP server (the actual agent-facing surface) authenticates via a full Dashboard account login rather than a dedicated scoped/agent-specific credential, so there's no documented way to mint a narrowly-scoped key specifically for an autonomous agent. Missing for 10: explicit agent-scoped OAuth scopes/roles for the MCP server, granular permission docs tied to agent use cases, and independent confirmation that access-key scopes can be limited to agent-safe operations only.

   • [claimed-docs] “Two documented server-side authentication forms — "Access keys (OAuth 2.0)" (client-credentials flow) and "Secret keys" — plus public keys f…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Checkout.com
   Checkout.com~partialprobed6/10

   Checkout.com documents an official Node.js SDK on GitHub, a native Mobile SDK for iOS/Android, plugins for ecommerce platforms, and machine-readable docs (llms.txt) plus an MCP server that let AI agents build against its API. However, evidence only names one language SDK explicitly and no broader SDK catalog (e.g., Python, PHP, Java, .NET) or independent hands-on validation is shown. Missing for 10: multi-language official SDK coverage, independent/community corroboration of SDK quality, and a public OpenAPI spec (probes show openapi.json 404).

   • [github] “The official Node.js SDK for Checkout.com payment gateway.”
   • [claimed-docs] “Mobile SDK: Build native mobile checkout experiences for iOS and Android.”
   • [claimed-docs] “Plugins: Integrate Checkout.com into existing ecommerce platforms via pre-built plugins.”
   • [claimed-docs] “Unified Payments API: Connect to all payment methods through a single API integration.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.checkout.com/llms.txt # Checkout.com: High-performance global payments platform for enterprise and s…”
   • [claimed-docs] “The Checkout.com Model Context Protocol (MCP) Server enables you to search through our knowledge base and manage payment operations directly…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Checkout.com
   Checkout.com✓fullclaimed9/10

   Checkout.com has robust, well-documented webhooks: event notifications with HMAC signature verification, configuration via Dashboard or API, resending webhooks, and integration with Amazon EventBridge for event streaming — directly enabling programmatic/agentic subscription to payment lifecycle events. Missing for 10: independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “Receive webhooks”
   • [claimed-docs] “Resend webhooks”
   • [claimed-docs] “Manage webhooks in the Dashboard”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round to Checkout.com
   Checkout.com~partialclaimed3/10

   Checkout.com references a general 'AI-driven solution' to optimize payment acceptance rates and mentions 'advanced analytics' on transaction-level data, which gestures at AI working on the merchant's own data, but there is no documented dashboard AI-insights/copilot feature that surfaces suggestions or narrative insights to the user. Missing for 10: a named in-product AI insights/analytics feature, evidence of generated recommendations shown to users, and any hands-on/independent corroboration beyond marketing copy.

   • [claimed-docs] “Automatically optimize payments to increase your acceptance rate with our powerful AI-driven solution.”
   • [claimed-docs] “Transaction-level data you can use to do more. Go beyond approvals and declines and experience our advanced analytics.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Mollie
   Checkout.com~partialclaimed4/10

   Checkout.com offers building blocks that support background automation — webhooks trigger server-side actions on payment lifecycle events, and the MCP server lets an AI agent query statuses, issue refunds, and manage payment links — plus agentic commerce protocols (ChatGPT, Google AI) letting an AI complete transactions on a user's behalf. However, none of this constitutes a dedicated 'set up an automation that runs autonomously in the background' capability (e.g., scheduled jobs, persistent agent workflows); the MCP server is described as an IDE-session tool, not an unattended background process. Missing for 10: a documented scheduler/background-job or persistent autonomous-agent workflow feature, and independent evidence of such automations running unattended.

   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “"With agentic commerce, your customers can discover and pay for products through an AI chat interface, instead of visiting your website. The…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Checkout.com—none0/10

   Checkout.com offers an MCP server so external AI agents/IDEs can query its API, and supports agentic-commerce protocols so third-party AI agents (ChatGPT, Google AI) can transact with merchants — but there is no evidence of a built-in AI assistant embedded inside the Checkout.com product/dashboard itself that a user can delegate tasks to. The MCP 'Guide tool' and AI-driven acceptance optimization are external-agent or backend features, not an in-product assistant.

   • [claimed-docs] “The Checkout.com Model Context Protocol (MCP) Server enables you to search through our knowledge base and manage payment operations directly…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “"With agentic commerce, your customers can discover and pay for products through an AI chat interface, instead of visiting your website. The…”
   • [claimed-docs] “Automatically optimize payments to increase your acceptance rate with our powerful AI-driven solution.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Checkout.com
   Checkout.com✓fullprobed8/10

   Checkout.com ships an official MCP Server that lets users query payment statuses, issue refunds, void payments, and manage payment links via natural-language requests to an AI agent, plus guided onboarding through a 'Guide tool' — directly matching the story. This is corroborated by concrete endpoint/setup details (OAuth, sandbox/production URLs, `claude mcp add` command) rather than just marketing copy. Missing for 10: independent/hands-on user reports of the NL commands working (server is labeled Beta) and no evidence beyond vendor docs of reliability at scale.

   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”
   • [claimed-docs] “The Checkout.com Model Context Protocol (MCP) Server enables you to search through our knowledge base and manage payment operations directly…”
   • [probe] “official MCP server documented at https://www.checkout.com/docs/developer-resources/checkout-com-mcp-server”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   Checkout.com—none0/10

   The evidence pack shows extensive documentation pages, an llms.txt feed, and an MCP server for AI agents, but no evidence of an interactive API reference with runnable/live code examples (e.g., a 'try it' console or embedded sandbox). The OpenAPI probe explicitly found all candidate spec paths returning 404, suggesting no machine-readable spec is exposed for such tooling.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.checkout.com/openapi.json, https://www.checkout.com/swagger.json, https://www.checkout.c…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.checkout.com/docs.md”
   • [claimed-docs] “Request a payment using a token, a network token, a payment instrument, or the full card details.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Checkout.com—none0/10

   The evidence pack shows an llms.txt (LLM-friendly documentation index) but explicit probes for OpenAPI/Swagger specs at common paths (openapi.json, swagger.json, .well-known/openapi.json) all returned 404, and no other citation references a downloadable OpenAPI or equivalent machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.checkout.com/openapi.json, https://www.checkout.com/swagger.json, https://www.checkout.c…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.checkout.com/llms.txt # Checkout.com: High-performance global payments platform for enterprise and s…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.checkout.com/docs.md”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Checkout.com✓fullclaimed8/10

   Checkout.com documents a dedicated sandbox/test-account environment (test cards, disputes testing, fraud/payouts testing, and a public 'get test account' signup) separate from production, and the MCP server itself is explicitly split into a sandbox endpoint (checkout.mcp.sbox.cko.tech) versus production (mcp.checkout.com), letting AI-native integrations test agentic operations without touching live data. Missing for 10: independent/hands-on confirmation that the sandbox fully mirrors production behavior and more detail on data isolation guarantees.

   • [claimed-docs] “A dedicated test-account environment with per-scenario testing docs: payments testing, test cards, disputes testing, fraud-detection testing…”
   • [claimed-docs] “Test cards”
   • [claimed-docs] “Disputes testing”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Checkout.com—none0/10

   The evidence pack covers idempotency, rate limits, auth, webhooks, and testing, but contains no mention of API version headers, a changelog, or a documented deprecation/sunset policy; probes for an OpenAPI spec even returned 404s, suggesting no discoverable versioning artifact.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Checkout.com—none0/10

   The evidence pack covers single-resource operations (payments, refunds, payment links, webhooks) and idempotent retries for individual requests, but there is no documentation of a batch/bulk API, bulk refund/payout endpoints, or MCP tooling that operates across many items at once. Reconciliation and reporting are read-only aggregate views, not bulk write operations.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Checkout.com~partialclaimed4/10

   Checkout.com supports webhooks that notify external systems on payment lifecycle events, and documented 'risk rules and lists' that automatically trigger fraud-prevention actions based on transaction conditions — both are forms of event-triggered automation. However, there is no evidence of a general-purpose, user-defined rules/automation engine (e.g., 'if X event then Y action' workflow builder) spanning arbitrary events beyond fraud, so it only partially satisfies the story. Missing for 10: a native no-code/low-code rules engine for arbitrary event-triggered actions, documented conditional logic builder, and evidence of automation beyond fraud rules and webhook delivery.

   • [claimed-docs] “Create risk rules and lists”
   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “Receive webhooks”
   • [claimed-docs] “Retrieve fraud reports”

   proof ↗⚑ flag

   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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Mollie
   Checkout.com—none0/10

   The evidence pack documents payment processing, webhooks, MCP-driven operations, and reconciliation reports, but nowhere describes recurring/scheduled job or workflow automation (e.g., subscription billing, cron-like scheduling, recurring payment automation) that an AI-native user could set up. No mention of scheduling, recurring billing, or workflow orchestration exists in the pack.

   ⚑ flag

   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

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 drawn
   Checkout.com~partialclaimed4/10

   Checkout.com provides the raw building blocks an agent could use — webhooks for payment lifecycle events (including failures), idempotent retry-safe API endpoints, and an MCP server that can query payment statuses and manage payment operations from an AI agent — but there is no documented dunning/retry-campaign feature or subscription-billing failed-payment workflow (no mention of automatic retry scheduling, dunning emails, or a 'monitor failed payments and drive outreach' capability). missing for 10: dedicated dunning/retry-campaign automation, evidence of subscription/recurring billing failure handling, and any documented agent workflow specifically for failed-payment monitoring/outreach.

   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”
   • [claimed-docs] “Receive webhooks”
   • [claimed-docs] “Resend webhooks”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Checkout.com~partialclaimed4/10

   Checkout.com documents API-driven Payment Link creation (docs-19/56) and an MCP server that can be used from an AI-assisted IDE to 'create and manage payment links' (cko-supp-mcp-server), so an agent could plausibly create a payment link in one session via API/MCP. However, there is no evidence of a discrete 'product' or 'price' catalog object/API (unlike a full product-catalog model) — Checkout.com's docs only reference amount/currency fields on payment links, not reusable Product/Price entities. missing for 10: a documented Products API and Prices API (or catalog object model) that an agent could provision alongside a payment link, and any hands-on/independent confirmation of an agent completing product+price+link creation end-to-end in one session.

   • [claimed-docs] “Create a Payment Link”
   • [claimed-docs] “Create a Payment Link - Docs”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”

   proof ↗⚑ flag

   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

Subscriptions

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

   weight 2 · round drawn
   Checkout.com—none0/10

   The evidence pack shows Checkout.com as a payments/acquiring platform with API idempotency (for network retries, not subscription dunning), webhooks, refunds, and platforms/marketplace features, but there is no documented subscription billing product, dunning logic, automatic retry scheduling for failed recurring payments, or recovery email capability. This axis is plausible for a payments platform, but no evidence supports it being delivered.

   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”
   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “The Platforms solution enables marketplaces, payment facilitators (Payfacs), and other platform-based businesses to onboard sub-entities and…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Mollie
   Checkout.com—none0/10

   Checkout.com is a payments/acquiring platform (payment processing, links, hosted pages, platforms/marketplaces, issuing) but the evidence pack contains no mention of subscription/recurring billing objects such as plans, trial periods, proration, or plan upgrades/downgrades — these are billing-engine concepts (like Stripe Billing/Chargebee) not documented here.

   ⚑ flag

   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

Card acceptance

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

   weight 3 · round drawn
   Checkout.com~partialclaimed6/10

   Checkout.com explicitly markets a Hosted Payment Page you can get 'fully branded... in less than a day' and offers self-serve test accounts, payment links, and low-code Flow for fast integration, suggesting a founder could technically wire up a checkout quickly. However, the pricing model is explicitly sales-led with 'no self-serve rate card' and merchants must 'get in touch with our team' to create a plan, implying an onboarding/underwriting step before going live with real payments that isn't addressed in the evidence. Missing for 10: evidence of self-serve signup-to-live-payment flow without sales contact, KYC/merchant approval timelines, and confirmation that a brand-new account can process a live card charge within 24 hours.

   • [claimed-docs] “Get a fully branded checkout page in less than a day. No heavy lifting or confusing compliance. Just one integration, and you're ready to ta…”
   • [claimed-docs] “A dedicated test-account environment with per-scenario testing docs: payments testing, test cards, disputes testing, fraud-detection testing…”
   • [claimed-docs] “Pricing is sales-led and unpublished: a tailored "Fully Flat-Rate" plan ("We price based on your business profile and risk category, nothing…”
   • [claimed-docs] “Create a Payment Link”
   • [claimed-docs] “Flow is a clever bit of code that helps you boost conversions, stay compliant, and enter new markets fast. Accept payments using customizabl…”

   proof ↗⚑ flag

   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

Checkout surfaces

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

   weight 3 · round to Mollie
   Checkout.com✓fullclaimed7/10

   Checkout.com's Flow product is explicitly documented as embeddable, customizable payment components in a single integration rather than a redirect ('Accept payments using customizable components – all through one simple integration'), alongside Mobile SDKs for native embedded checkout. missing for 10: hands-on/independent verification of the embedded component customization (theming depth, framework support), and a code sample showing actual component embedding rather than marketing copy.

   • [claimed-docs] “Flow is a clever bit of code that helps you boost conversions, stay compliant, and enter new markets fast. Accept payments using customizabl…”
   • [claimed-docs] “Get started with low-code Flow”
   • [claimed-docs] “Take charge of your mobile checkout with Flow for Mobile. Available via iOS and Android Mobile SDKs.”
   • [claimed-docs] “Mobile SDK: Build native mobile checkout experiences for iOS and Android.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Mollie
   Checkout.com✓fullclaimed8/10

   Checkout.com documents a dedicated Hosted Payments Page product ('Get a fully branded checkout page in less than a day... one integration') with low-code deployment and customization docs, plus a related Payment Links option for no-code hosted checkout flows. This directly matches the story of redirecting to a vendor-hosted, conversion-optimized checkout page without building custom payment UI. Missing for 10: independent/third-party conversion benchmarks or hands-on merchant testimonials validating the 'conversion-optimized' claim beyond vendor copy.

   • [claimed-docs] “Get a fully branded checkout page in less than a day. No heavy lifting or confusing compliance. Just one integration, and you're ready to ta…”
   • [claimed-docs] “Customize your Hosted Payments Page”
   • [claimed-docs] “Hosted Payment Page: Deploy a pre-built, low-code payment page integration.”
   • [claimed-docs] “Create a Payment Link”
   • [claimed-docs] “Send secure Payment Links over email, SMS, social, and more – without any need for coding – and open up more revenue opportunities, no matte…”
   • [claimed-docs] “Flow is a clever bit of code that helps you boost conversions, stay compliant, and enter new markets fast. Accept payments using customizabl…”

   proof ↗⚑ flag

   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

No code selling

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

   weight 2 · round drawn
   Checkout.com~partialclaimed6/10

   Checkout.com explicitly documents no-code Payment Links that can be sent via email/SMS/social to accept payments without coding (checkout-com-docs-5, -19, -41, -56), which directly matches the story. However, the account/pricing evidence indicates a sales-led, KYC-gated onboarding model rather than instant self-serve signup ('get in touch with our team' — cko-supp-pricing), undercutting the 'start selling immediately' claim for a new founder. Missing for 10: evidence of an instant self-serve dashboard signup (no sales call) and independent/hands-on confirmation that a first-time user can generate a link within minutes.

   • [claimed-docs] “Payment Links: Accept payments on any channel using shareable payment links.”
   • [claimed-docs] “Create a Payment Link”
   • [claimed-docs] “Send secure Payment Links over email, SMS, social, and more – without any need for coding – and open up more revenue opportunities, no matte…”
   • [claimed-docs] “Create a Payment Link - Docs”
   • [claimed-docs] “Pricing is sales-led and unpublished: a tailored "Fully Flat-Rate" plan ("We price based on your business profile and risk category, nothing…”

   proof ↗⚑ flag

   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

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 Checkout.com
   Checkout.com✓fullclaimed8/10

   Checkout.com documents a unified payments API and Flow/Hosted Payment Page integrations that give access to digital wallets, local payment methods, and global card schemes via a single integration (checkout-com-docs-45, checkout-com-docs-2, checkout-com-docs-38, checkout-com-docs-43), explicitly covering local currencies and regional payment strategies. Missing for 10: no explicit line-item confirmation of BNPL providers or bank redirect method names, and no independent/hands-on corroboration of wallet coverage breadth.

   • [claimed-docs] “Get instant access to all the local payment methods, digital wallets, and global card schemes you need for smarter regional strategies and h…”
   • [claimed-docs] “Unified Payments API: Connect to all payment methods through a single API integration.”
   • [claimed-docs] “Flow is a clever bit of code that helps you boost conversions, stay compliant, and enter new markets fast. Accept payments using customizabl…”
   • [claimed-docs] “Take complete control of the entire payment lifecycle from a single API. Upgrade, expand, and adapt your payment experiences with a flexible…”
   • [claimed-docs] “Accept payments like a local business globally. Get paid in local currencies, settle funds fast, and gain valuable insights.”
   • [claimed-docs] “Process worldwide in 150+ currencies. Plus domestic coverage in 45+ countries and counting.”

   proof ↗⚑ flag

   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

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
   Checkout.com~partialclaimed6/10

   Checkout.com offers hosted payment pages, Flow, mobile SDKs, and payment links that are explicitly marketed as reducing compliance burden ('no confusing compliance'), and also supports tokens/network tokens/payment instruments as an alternative to raw card data, all of which are standard mechanisms for keeping card data off merchant servers and reducing PCI scope. However, no evidence explicitly names PCI DSS, SAQ levels, or describes tokenization architecture/vaulting in detail, and the API also documents accepting 'full card details' directly, meaning scope reduction depends on which integration path a developer chooses. Missing for 10: explicit PCI DSS compliance/SAQ-A scope-reduction documentation, dedicated tokenization/vaulting API docs, and independent confirmation of scope-reduction claims.

   • [claimed-docs] “Request a payment using a token, a network token, a payment instrument, or the full card details.”
   • [claimed-docs] “Flow is a clever bit of code that helps you boost conversions, stay compliant, and enter new markets fast. Accept payments using customizabl…”
   • [claimed-docs] “Get a fully branded checkout page in less than a day. No heavy lifting or confusing compliance. Just one integration, and you're ready to ta…”
   • [claimed-docs] “Take charge of your mobile checkout with Flow for Mobile. Available via iOS and Android Mobile SDKs.”
   • [claimed-docs] “Send secure Payment Links over email, SMS, social, and more – without any need for coding – and open up more revenue opportunities, no matte…”
   • [claimed-docs] “Customize your Hosted Payments Page”

   proof ↗⚑ flag

   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

Integration reliability

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

   weight 2 · round drawn
   Checkout.com✓fullclaimed9/10

   Checkout.com's docs explicitly document idempotency support via the Cko-Idempotency-Key header across payments, authorizations, captures, refunds, cancellations, voids, and transfers endpoints, caching results of 2xx responses to safely retry without duplicate charges, with a configurable idempotency window. Missing for 10: independent/hands-on developer corroboration of real-world retry behavior beyond vendor docs.

   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”
   • [claimed-docs] “Occasionally, you may need to retry a request due to a disrupted API call. For example, if you encounter a network error or timeout.”
   • [claimed-docs] “Idempotency - Docs”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Checkout.com
   Checkout.com~partialclaimed6/10

   Checkout.com documents HMAC-signed webhooks, dashboard/API-based webhook configuration, and a dedicated 'Resend webhooks' capability for replay, satisfying the signing and replay parts of the story. However, evidence does not confirm automatic system-driven retries of failed webhook deliveries (only manual resend) or a dedicated event log/audit trail view for webhook history. Missing for 10: documented automatic retry policy for undelivered webhooks, explicit event log/audit UI, independent confirmation of retry behavior.

   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “Receive webhooks”
   • [claimed-docs] “Resend webhooks”
   • [claimed-docs] “Manage webhooks in the Dashboard”

   proof ↗⚑ flag

   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

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 drawn
   Checkout.com~partialprobed5/10

   Checkout.com's docs support several low-code paths (Hosted Payment Page explicitly marketed as 'less than a day', Flow, Payment Links, plugins) and there's a Unified Payments API plus a public Node.js SDK on GitHub, suggesting a developer could get a basic flow running quickly. However, the pack shows only one language SDK (Node.js) with no evidence of multi-language copy-paste snippets in the docs themselves, and openapi/reference-doc probes returned 404s, weakening confidence that a full in-docs multi-language integration experience exists. missing for 10: multi-language code samples embedded in docs, other official SDKs (Python/Java/PHP/Ruby), independent hands-on confirmation of 'under a day' integration.

   • [claimed-docs] “Get a fully branded checkout page in less than a day. No heavy lifting or confusing compliance. Just one integration, and you're ready to ta…”
   • [claimed-docs] “Flow is a clever bit of code that helps you boost conversions, stay compliant, and enter new markets fast. Accept payments using customizabl…”
   • [claimed-docs] “Take complete control of the entire payment lifecycle from a single API. Upgrade, expand, and adapt your payment experiences with a flexible…”
   • [github] “The official Node.js SDK for Checkout.com payment gateway.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.checkout.com/openapi.json, https://www.checkout.com/swagger.json, https://www.checkout.c…”
   • [claimed-docs] “Customize your Hosted Payments Page”

   proof ↗⚑ flag

   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

Sandbox fidelity

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

   weight 3 · round to Checkout.com
   Checkout.com✓fullclaimed8/10

   Checkout.com documents a dedicated test-account environment with a public 'Get test account' signup, plus per-scenario testing docs covering payments testing, test cards, disputes testing, fraud-detection testing, and bank payouts testing — directly matching the story's requirement for a sandbox mirroring production with test cards for declines and disputes. Missing for 10: independent/hands-on developer corroboration that the sandbox truly mirrors production behavior end-to-end, and more detail on how comprehensive the decline-scenario coverage is beyond the docs listing.

   • [claimed-docs] “A dedicated test-account environment with per-scenario testing docs: payments testing, test cards, disputes testing, fraud-detection testing…”
   • [claimed-docs] “Test cards”
   • [claimed-docs] “Disputes testing”

   proof ↗⚑ flag

   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

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
   Checkout.com—none0/10

   Checkout.com's docs cover general dispute management topics (manage-disputes, disputes testing, preventing fraudulent disputes) but there's no evidence of an API endpoint for retrieving disputes or submitting evidence, and the documented MCP server's capabilities explicitly list only payment status queries, refunds, voids, and payment links — dispute handling is not among them. No evidence shows an agent can retrieve a dispute, assemble evidence, and submit a response end-to-end via API or MCP.

   • [claimed-docs] “Preventing fraudulent disputes”
   • [claimed-docs] “Disputes testing”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”

   proof ↗⚑ flag

   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

Disputes

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

   weight 3 · round to Checkout.com
   Checkout.com~partialclaimed4/10

   Checkout.com documents a disputes management area ("Preventing fraudulent disputes"), dedicated disputes testing scenarios, and webhook events that report "progress on disputes," showing the platform supports dispute lifecycle tracking. However, there is no evidence of the actual structured-evidence submission workflow (e.g., uploading proof documents, dispute reason codes, response deadlines) or a documented end-to-end resolution tracking UI/API. Missing for 10: documentation of evidence submission fields/API, dispute status states and resolution outcomes, and any dashboard/API walkthrough of responding to a chargeback.

   • [claimed-docs] “Preventing fraudulent disputes”
   • [claimed-docs] “Disputes testing”
   • [claimed-docs] “Create risk rules and lists”
   • [claimed-docs] “Retrieve fraud reports”
   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”

   proof ↗⚑ flag

   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

Fraud prevention

1. finance-ops userScreen transactions with machine-learning fraud scores and write custom block, review, and allow rules

   weight 3 · round to Checkout.com
   Checkout.com~partialclaimed6/10

   Checkout.com's docs explicitly cover 'Create risk rules and lists' and 'Retrieve fraud reports' under Prevent Fraud, giving finance-ops the ability to write custom block/review/allow-style rules, and it separately touts an 'AI-driven solution' for optimizing acceptance. However, the evidence never names a machine-learning fraud score, a scoring model, or how scores feed into rule conditions, nor a review-queue UI. Missing for 10: explicit ML fraud-score documentation, rule-to-score integration details, and hands-on/independent confirmation of the scoring engine's accuracy or usability.

   • [claimed-docs] “Create risk rules and lists”
   • [claimed-docs] “Retrieve fraud reports”
   • [claimed-docs] “Preventing fraudulent disputes”
   • [claimed-docs] “Automatically optimize payments to increase your acceptance rate with our powerful AI-driven solution.”

   proof ↗⚑ flag

   Mollie—none0/10

   Evidence covers chargebacks retrieval, webhooks, idempotency, and testing, but there is no mention of ML-based fraud scoring or a rules engine for block/review/allow decisions on transactions.

   ⚑ flag

Refunds

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

   weight 3 · round drawn
   Checkout.com✓fullclaimed8/10

   Docs explicitly cover refunding a payment via API with or without a reference (checkout-com-docs-21, checkout-com-docs-55), implying support for full/partial refunds through the payments/{id}/refunds endpoint (also listed as idempotent, cko-supp-idempotency). Dashboard-based refund management is implied by broader webhook/dashboard management patterns but not explicitly documented with a dedicated dashboard refund walkthrough. Missing for 10: explicit dashboard UI screenshot/walkthrough for issuing refunds, and independent/hands-on confirmation of partial refund amounts being configurable.

   • [claimed-docs] “Refund a payment without a reference”
   • [claimed-docs] “Refund a payment with a reference”
   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”

   proof ↗⚑ flag

   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

Multi currency

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

   weight 2 · round to Checkout.com
   Checkout.com~partialclaimed6/10

   Checkout.com clearly supports charging in local currencies (150+ currencies, local acquiring, FX rates API for acquiring/payouts) and provides settlement reporting and a documented FX rate fee for reconciliation, which supports the founder's need to settle in their own currency. However, evidence does not show a clear, transparent published FX markup/rate table or a self-serve explanation of exactly how conversion and settlement currency selection works — pricing and FX fees are sales-led/unpublished, undercutting the 'transparent' claim. Missing for 10: a documented transparent FX rate/markup disclosure mechanism, self-serve settlement currency selection docs, and independent verification of actual FX transparency in practice.

   • [claimed-docs] “Use the FX rates API to retrieve the indicative foreign exchange (FX) rates that Checkout.com uses for acquiring and card payouts.”
   • [claimed-docs] “Process worldwide in 150+ currencies. Plus domestic coverage in 45+ countries and counting.”
   • [claimed-docs] “Accept payments like a local business globally. Get paid in local currencies, settle funds fast, and gain valuable insights.”
   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”
   • [claimed-docs] “Exchange (FX) rate fee”
   • [claimed-docs] “Pricing is sales-led and unpublished: a tailored "Fully Flat-Rate" plan ("We price based on your business profile and risk category, nothing…”
   • [claimed-docs] “Settlement Breakdown Report”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Mollie
   Checkout.com~partialprobed6/10

   Checkout.com's core payment lifecycle (payments, refunds, voids, payment links, webhooks, reconciliation, platforms/sub-entities, FX) is fully API-driven per docs, and the API is treated as the primary integration surface rather than the UI. However, some Dashboard-only or UI-centric functions (e.g., some fraud rule configuration, risk list management, business account setup, certain reporting views) are only shown via Dashboard screenshots/flows without confirmed API parity, and no OpenAPI spec was discoverable (404s on probes) to verify full API surface coverage. missing for 10: confirmed API parity for all Dashboard-configurable settings (risk rules, fraud lists, business account management), a public/complete OpenAPI spec, and independent evidence confirming no UI-only features exist.

   • [claimed-docs] “Unified Payments API: Connect to all payment methods through a single API integration.”
   • [claimed-docs] “Idempotent retries are first-class: "The following endpoints from our API support idempotent requests, so you can safely retry them without …”
   • [claimed-docs] “Two documented server-side authentication forms — "Access keys (OAuth 2.0)" (client-credentials flow) and "Secret keys" — plus public keys f…”
   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”
   • [claimed-docs] “"The Platforms solution enables marketplaces, payment facilitators (Payfacs), and other platform-based businesses to onboard sub-entities an…”
   • [claimed-docs] “Create risk rules and lists”
   • [claimed-docs] “Retrieve fraud reports”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.checkout.com/openapi.json, https://www.checkout.com/swagger.json, https://www.checkout.c…”
   • [claimed-docs] “Refund a payment without a reference”
   • [claimed-docs] “Refund a payment with a reference”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Checkout.com
   Checkout.com~partialclaimed3/10

   Checkout.com documents various financial reports (Settlement Breakdown, Balance, Payouts, Reconciliation) accessible via Dashboard/API, which implies some data export capability, but there is no explicit documentation of a comprehensive 'export all your data in open formats and leave' capability, no data portability policy, and no mention of open-format guarantees or full account data export upon departure. missing for 10: explicit full-data export tooling, open-format (CSV/JSON) export guarantees, documented data portability/account closure export process, and independent confirmation of completeness.

   • [claimed-docs] “Reconciliation is a crucial part of your business's bookkeeping process. You can reconcile your balances, fee categories, financial actions,…”
   • [claimed-docs] “Settlement Breakdown Report”
   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”

   proof ↗⚑ flag

   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

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 Checkout.com
   Checkout.com✓fullclaimed8/10

   Checkout.com documents a report suite explicitly designed for reconciling payouts to underlying financial actions (Balance Breakdown, Balance, Financial Actions by Date Range/Payout ID, Payouts, Settlement Breakdown, Settlement Statement reports), and these are exposed via API alongside a documented MCP server and OAuth2/API-key auth suitable for agent-driven automation. Missing for 10: no explicit end-to-end example showing an agent script pulling payout+balance-transaction endpoints and matching them to charges, and no independent/hands-on confirmation of this reconciliation workflow being done via an agent.

   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”
   • [claimed-docs] “Reconciliation is a crucial part of your business's bookkeeping process. You can reconcile your balances, fee categories, financial actions,…”
   • [claimed-docs] “Settlement Breakdown Report”
   • [claimed-docs] “Two documented server-side authentication forms — "Access keys (OAuth 2.0)" (client-credentials flow) and "Secret keys" — plus public keys f…”
   • [claimed-docs] “The Checkout.com MCP Server (Beta) "enables you to search through our knowledge base and manage payment operations directly from your AI-ass…”
   • [claimed-docs] “The MCP server is hosted with documented per-environment endpoints — "Sandbox: https://checkout.mcp.sbox.cko.tech Production: https://mcp.ch…”

   proof ↗⚑ flag

   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

Payouts

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

   weight 2 · round drawn
   Checkout.com~partialclaimed6/10

   Checkout.com documents a strong reconciliation report suite mapping payouts to their underlying financial actions — the 'Financial Actions by Payout ID Report', 'Payouts Report', 'Settlement Breakdown Report', and 'Balance' reports explicitly let finance-ops trace charges, fees, and refunds composing a payout, plus FX fee visibility. However, there is no evidence of the 'control the payout schedule' half of the story (e.g., configuring payout frequency/cadence or triggering ad hoc payouts) anywhere in the pack. Missing for 10: documentation of payout schedule/frequency configuration, self-serve payout timing controls.

   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”
   • [claimed-docs] “Settlement Breakdown Report”
   • [claimed-docs] “Exchange (FX) rate fee”
   • [claimed-docs] “Reconciliation is a crucial part of your business's bookkeeping process. You can reconcile your balances, fee categories, financial actions,…”

   proof ↗⚑ flag

   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

Reconciliation

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

   weight 3 · round to Checkout.com
   Checkout.com✓fullclaimed8/10

   Checkout.com documents a dedicated reconciliation report suite (Balance Breakdown, Balance Report, Financial Actions by Date Range/Payout ID, Payouts Report, Settlement Breakdown Report, Settlement Statement) explicitly mapping settlements to underlying financial actions including fee categories, and separate refund/dispute docs cover those transaction types. Missing for 10: independent/third-party corroboration (e.g. finance-ops user reviews) that reconciliation reports itemize chargebacks specifically and match to bank deposits in practice, and no sample report output shown.

   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”
   • [claimed-docs] “Reconciliation is a crucial part of your business's bookkeeping process. You can reconcile your balances, fee categories, financial actions,…”
   • [claimed-docs] “Settlement Breakdown Report”
   • [claimed-docs] “"Webhooks are automated messages that Checkout.com sends your server when events related to your account occur. For example, payment lifecyc…”
   • [claimed-docs] “Refund a payment without a reference”
   • [claimed-docs] “Refund a payment with a reference”
   • [claimed-docs] “Preventing fraudulent disputes”
   • [claimed-docs] “Exchange (FX) rate fee”

   proof ↗⚑ flag

   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

Marketplace

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

   weight 2 · round drawn
   Checkout.com✓fullclaimed8/10

   Checkout.com has a dedicated 'Platforms' product explicitly for marketplaces/payfacs that documents onboarding sub-entities, splitting funds between platform and sub-entities, and paying out sub-entities in their local currency/preferred method, backed by reconciliation and settlement reporting to track those splits and payouts. missing for 10: independent/hands-on validation of the onboarding flow, detailed KYC/sub-entity API reference specifics, and public case studies of marketplaces running this in production.

   • [claimed-docs] “"The Platforms solution enables marketplaces, payment facilitators (Payfacs), and other platform-based businesses to onboard sub-entities an…”
   • [claimed-docs] “The Platforms solution enables marketplaces, payment facilitators (Payfacs), and other platform-based businesses to onboard sub-entities and…”
   • [claimed-docs] “Split funds between your platform and sub-entities according to your business model.”
   • [claimed-docs] “Make payouts to your sub-entities in their local currency and preferred payment method.”
   • [claimed-docs] “"You can reconcile your balances, fee categories, financial actions, invoices, and settlements with Checkout.com using the following reports…”
   • [claimed-docs] “Settlement Breakdown Report”

   proof ↗⚑ flag

   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