Autumn vs Mollie

Agent access

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

   weight 2 · round to Mollie
   Autumn✓fullprobed8/10

   A probe confirms llms.txt is live at docs.useautumn.com/llms.txt returning HTTP 200 with structured doc links, directly satisfying the ability to point an agent at agent-oriented docs; this is reinforced by an official MCP server for AI assistants. Missing for 10: no independent/community confirmation of an agent successfully consuming llms.txt in practice, and no openapi.json fallback.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.useautumn.com/llms.txt # Autumn - [Welcome to Autumn](https://docs.useautumn.com/welcome.md): Drop…”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”

   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
   Autumn~partialprobed5/10

   Autumn ships an `atmn` CLI that syncs pricing configs (`autumn.config.ts`) with a single command and supports non-interactive actions like `preview` and `pull`, which are scriptable and could run in CI, plus SDK calls (`check`, `track`) that are inherently headless. However, there's no explicit documentation or example of running Autumn in a CI/CD pipeline, no mention of non-interactive auth/token flags for automated environments, and no community confirmation of headless CI usage. Missing for 10: explicit CI/CD pipeline examples, non-interactive authentication guidance, and independent confirmation of automated/headless runs.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

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

   Autumn is a billing/entitlements SaaS platform (not itself an agent), and it documents an official MCP server that connects AI assistants to its billing, customer, plan, balance, and log tools, confirmed by both docs and probe. Missing for 10: independent hands-on confirmation of the MCP server working and more detail on its tool coverage/setup.

   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”

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

   Autumn ships an official `atmn` CLI documented in first-party docs, supporting config-as-code (autumn.config.ts), pushing/syncing plans, previewing changes (bunx atmn preview), and pulling existing dashboard products (atmn pull) — clearly enabling AI-native, code-first workflows. Missing for 10: independent/hands-on community verification of the CLI itself (community evidence covers billing/security topics, not CLI usage) and no evidence of scripting/automation-specific features beyond basic commands.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

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

   Autumn ships a documented public API with clear reference pages (check, track, attach) and code examples, webhooks, and an API-reference section, letting an AI-native user drive billing/entitlements programmatically. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe found only 404s at expected paths), and independent hands-on confirmation of API robustness beyond docs.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “You can also [check and reserve] balance in a single, atomic API call for concurrent events.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”

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

   Autumn's docs describe customerId-based check/track/attach calls and an MCP server for billing tools, but there is no evidence of an API-key or credential system that lets an AI-native user mint scoped, least-privilege credentials for an agent. Community reports even describe unauthenticated server actions and customer_id spoofing (IDOR), the opposite of least-privilege access control.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [community] “Commenters criticized Autumn's 'backendless billing' approach as reinventing JWTs poorly: "Your encrypted customer ID has the exact same sem…”
   • [community] “Security concern raised: Autumn's server actions were public, unauthenticated routes, meaning "a simple curl request with a different custom…”

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

   Docs consistently show official SDK code (autumn.check, autumn.track, autumn.attach) across many endpoints, plus a companion CLI (atmn) for config sync, indicating a first-party SDK for building AI-native billing integrations. Missing for 10: explicit multi-language SDK coverage/package registry links and independent developer corroboration of SDK usage beyond docs.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

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

   Autumn documents webhooks fired on plan/subscription changes (autumn-docs-8), giving basic event subscription capability, but evidence doesn't cover a broad event catalog (e.g. usage/track events), payload schemas, signing/verification, or subscription management API — missing for 10: full webhook event catalog, payload/signature docs, subscription management endpoints, independent hands-on confirmation.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”

   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 userOperate the product with natural-language commands

   weight 2 · round to Mollie
   Autumn~partialprobed5/10

   Autumn ships an official MCP server that 'connects AI assistants to Autumn's billing, customer, plan, balance, and log tools,' enabling AI-native/natural-language operation indirectly through an MCP-connected assistant rather than a built-in chat interface. There's no first-party or community evidence of actual natural-language command usage in practice, and the product is fundamentally a CLI/API/dashboard tool otherwise. Missing for 10: direct natural-language command interface (not just MCP passthrough), hands-on demonstration of NL commands working, independent user corroboration.

   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”

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

   Autumn's docs include static code snippets for API endpoints (e.g. check, attach) but there is no evidence of an interactive, runnable API console—probes for openapi/swagger specs all 404'd, indicating no interactive reference tooling exists.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”

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

   There's an api-reference section implying documented endpoints, but a direct probe for OpenAPI/Swagger specs at standard paths returned 404s with no alternate machine-readable spec found or linked anywhere in the docs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”

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

   Autumn is a billing/entitlements layer where sandbox/test-mode testing is a reasonable ask (similar to Stripe test mode), but the evidence pack has no mention of a dedicated sandbox/test environment separate from production—only 'atmn preview' for previewing pricing plan changes before pushing config, which is not the same as isolating test transactions/customers from production data.

   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”

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

   No evidence of API versioning scheme or documented deprecation policy; changelog entries show ongoing changes but no version numbers or deprecation guarantees, and OpenAPI/spec probes 404. missing for 10: versioned API endpoints/headers, explicit deprecation policy documentation, migration guides for breaking changes.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.useautumn.com/openapi.json, https://docs.useautumn.com/swagger.json, https://docs.useau…”
   • [claimed-docs] “Usage alerts gain a `basis` field that defines what 100% means: the full `balance` (the default, unchanged), the plan’s `included` grants, `…”
   • [claimed-docs] “Catalog plans now accept a `processors` object so Autumn can reuse your existing Stripe catalog instead of minting new objects.”

   proof ↗⚑ 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
   Autumn—none0/10

   Autumn's docs show only single-item operations (check, track, attach for one customer/feature at a time) and CLI commands (pull/preview/push) that sync a single config, but no batch/bulk API for operating across many customers, features, or items at once. missing for 10: bulk/batch API endpoints, documentation of batch customer or feature updates, evidence of any multi-item transaction support.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”

   proof ↗⚑ 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
   Autumn~partialclaimed4/10

   Autumn supports event-driven mechanisms like webhooks fired on plan changes and usage alerts with configurable thresholds (basis field), which act as simple automated triggers tied to billing state. However, there is no evidence of a general-purpose rule engine where users can define custom trigger→action logic across arbitrary events; the automation is scoped narrowly to billing/entitlement events. Missing for 10: a documented rules/automation DSL or workflow builder, support for arbitrary custom triggers/actions beyond billing events, and evidence of chaining multiple actions per rule.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [claimed-docs] “Usage alerts gain a `basis` field that defines what 100% means: the full `balance` (the default, unchanged), the plan’s `included` grants, `…”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “You can also [check and reserve] balance in a single, atomic API call for concurrent events.”

   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

Ai billing ops

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

   weight 3 · round to Mollie
   Autumn—none0/10

   Evidence shows Autumn webhooks fire only on plan changes (new subscriptions, upgrades, downgrades) and covers usage/credit tracking, but there is no mention of failed-payment events, retry logic, or dunning outreach workflows anywhere in the docs, changelog, or community threads. This is a fair axis for a billing product (Stripe-based dunning is a common billing capability) but no evidence supports Autumn delivering it.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Usage alerts gain a `basis` field that defines what 100% means: the full `balance` (the default, unchanged), the plan’s `included` grants, `…”

   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 to Autumn
   Autumn~partialprobed5/10

   Autumn's API/CLI supports creating products/plans (attach, config.ts, atmn CLI) and MCP server exposes billing/plan/customer tools to AI assistants, suggesting an agent could provision products and prices programmatically, but there is no direct evidence of generating a 'payment link' via API or of a documented single-session workflow combining product+price+payment link creation. missing for 10: explicit payment-link creation endpoint/API, end-to-end example of an agent provisioning product+price+payment link in one session, independent verification of this workflow.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

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

   Autumn's evidence covers metering, entitlements, plan attachment, and Stripe catalog sync, but there is no mention of dunning, retry logic for failed payments, or recovery emails anywhere in the docs, changelog, or community discussion.

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

   Autumn's docs explicitly cover defining plans (autumn.config.ts + atmn CLI), attaching plans to customers with automatic handling of new subscriptions, upgrades, and downgrades, usage-based/pay-per-use pricing with proration-like billing period logic, and webhooks firing on plan changes (new subscriptions, upgrades, downgrades). Community feedback corroborates real-world use for billing/entitlements and notes Autumn's team handling of annual/monthly billing transitions and race conditions. Missing for 10: explicit first-party documentation of free trials and detailed proration mechanics, plus independent hands-on verification of trial/upgrade billing flows.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”
   • [claimed-docs] “Pay-per-use (usage-based) pricing charges customers based on how much of a feature they actually consume, billed at the end of each billing …”
   • [claimed-docs] “Catalog plans now accept a `processors` object so Autumn can reuse your existing Stripe catalog instead of minting new objects.”
   • [community] “Autumn combines billing, metering, and entitlements into a single state, unlike Lago which only handles billing—users must sync permissions …”
   • [community] “"love this as someone who's been fixing the same billing bugs over and over and who sometimes finds stripe more complex than it should be." …”

   proof ↗⚑ 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 to Mollie
   Autumn~partialcommunity4/10

   Autumn is a billing/metering layer built on top of Stripe, with an `attach` API that handles new subscriptions/upgrades/downgrades and a CLI that syncs pricing plans in a single command, suggesting reasonably fast setup. However, there's no direct evidence of a turnkey checkout page or explicit same-day payment acceptance flow, and the product only works atop Stripe (comm-4), meaning a founder still needs a separate Stripe account/setup for actual card processing. Missing for 10: an end-to-end checkout UI or hosted payment page, explicit time-to-first-payment claims, and independent confirmation of same-day integration speed.

   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [community] “Concern raised that Autumn is only built on Stripe, with no support for other payment providers like Paystack, which is needed for regions l…”

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

   Autumn's evidence describes a billing/metering/entitlements API, CLI, and MCP integration built on top of Stripe, but nothing in the pack mentions embeddable payment/checkout UI components as an alternative to hosted checkout pages—attach/billing calls appear to route through Stripe's own flows.

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

   The evidence pack covers Autumn's metering, entitlements, CLI, MCP, and plan-attach APIs, but nowhere describes a vendor-hosted, conversion-optimized checkout page that a developer can redirect customers to; 'attach' only documents subscription state changes, not a hosted checkout flow.

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

   Autumn is a code-first billing/entitlements layer requiring SDK calls, an autumn.config.ts file, or CLI (atmn) to define and attach plans—there is no evidence of a no-code, dashboard-generated shareable payment link feature for founders to start selling immediately.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [claimed-docs] “Pay-per-use (usage-based) pricing charges customers based on how much of a feature they actually consume, billed at the end of each billing …”

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

   Autumn is a billing/entitlement/metering layer built on top of Stripe (confirmed by autumn-comm-4, which notes it lacks support for other payment providers like Paystack), but the evidence pack contains no mention of Autumn configuring or exposing digital wallets, local payment methods, bank redirects, or BNPL options in checkout. Missing for 10: any documentation of wallet/BNPL/local payment method support, checkout configuration options, or evidence Autumn surfaces Stripe's payment-method capabilities to founders.

   • [community] “Concern raised that Autumn is only built on Stripe, with no support for other payment providers like Paystack, which is needed for regions l…”

   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

Integration reliability

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

   weight 2 · round to Mollie
   Autumn—none0/10

   No evidence pack item mentions idempotency keys or request-retry safety mechanisms anywhere in Autumn's docs, changelog, or community discussion; the API examples shown (check, track, attach) don't reference idempotency handling.

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

   Docs mention webhooks are fired for plan changes, but there is no evidence of signed payloads, automatic retries, event logs, or replay functionality for webhook deliveries; the evidence pack shows only a single event type description with no delivery guarantees.

   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”

   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 to Autumn
   Autumn~partialcommunity6/10

   Docs provide multiple copy-paste TypeScript/JS snippets (check, track, attach, gating) and a CLI/config flow that suggest a fast path to a working payment flow, and community comments (comm-2, comm-5) reflect developers finding it appealing to integrate quickly. However all examples are JS/TS only (no other languages), there's no explicit hands-on confirmation of a 'under a day' integration timeline, and separate security reports (comm-6/7) show at least one integration built from the docs' approach ended up with an IDOR vulnerability, suggesting the docs alone may not guarantee a fully working/secure flow without extra care. Missing for 10: multi-language code samples, an independent hands-on report confirming rapid end-to-end integration, and evidence the documented flow is secure by default.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”
   • [community] “"I've suffered so much with all the pricing changes I've been experimenting with (early stage solo founder)... I'm going to integrate autumn…”
   • [community] “"love this as someone who's been fixing the same billing bugs over and over and who sometimes finds stripe more complex than it should be." …”
   • [community] “Security concern raised: Autumn's server actions were public, unauthenticated routes, meaning "a simple curl request with a different custom…”

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

   No evidence in the pack mentions a sandbox/test mode, test cards, or simulated decline/dispute scenarios; Autumn's docs cover CLI, config, gating, webhooks, and MCP but nothing about a testing environment mirroring production payment flows. Since Autumn sits atop Stripe, this is a fair and applicable axis for a billing product, but it's simply undocumented here.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Attaches a plan to a customer. Handles new subscriptions, upgrades and downgrades.”

   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

Refunds

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

   weight 3 · round to Mollie
   Autumn—none0/10

   No evidence pack items mention refunds at all—no dashboard refund UI, no refund API endpoint, or partial-refund logic; docs cover checks, tracking, attach/subscriptions, credit systems, and CLI/MCP but never refunds.

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

   No evidence in the pack addresses multi-currency charging, FX conversion, or settlement to a founder's home currency; documentation covers pricing models, metering, and Stripe catalog sync only. Community threads even highlight Autumn's dependency on Stripe alone with no other payment processors, but nothing on currency/FX handling either way.

   • [claimed-docs] “Catalog plans now accept a `processors` object so Autumn can reuse your existing Stripe catalog instead of minting new objects.”
   • [community] “Concern raised that Autumn is only built on Stripe, with no support for other payment providers like Paystack, which is needed for regions l…”

   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
   Autumn~partialprobed6/10

   Autumn exposes a broad API (check, track, attach, credit systems, usage-based pricing) plus a CLI (`atmn push/pull/preview`) that can define and sync pricing config as code, and an MCP server for AI-native access to billing/customer/plan tools — strong evidence of API-driven control. However, the docs also show a 'pull' workflow for dashboard-created products, implying some setup still originates in the dashboard UI, and there's no explicit statement or independent test confirming full 1:1 parity between every UI action and API/CLI capability. Missing for 10: explicit parity documentation or proof that all dashboard-only actions (e.g., initial product/catalog creation, Stripe processor linking) are fully replicable via API/CLI without ever touching the UI, and independent verification of this parity.

   • [claimed-docs] “const response = await autumn.check({ customerId: "user_123", featureId: "messages" });”
   • [claimed-docs] “await autumn.track({ customerId: "user_or_org_id_from_auth", featureId: "messages", value: 1, });”
   • [claimed-docs] “Credit systems let you track actions with different credit costs from a single balance pool.”
   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “You can preview your plans without pushing anything: bunx atmn preview”
   • [claimed-docs] “Autumn MCP connects AI assistants to Autumn's billing, customer, plan, balance, and log tools.”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [probe] “official MCP server documented at https://docs.useautumn.com/documentation/mcp”
   • [probe] “official CLI documented at https://docs.useautumn.com/cli/getting-started”

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

   Autumn's docs show CLI sync/pull for pricing config (autumn.config.ts) and webhooks for event data, but there is no documented feature for exporting all customer/usage/billing data in an open format to allow a user or team to leave the platform. missing for 10: a documented full data-export or account-portability feature, open-format bulk export of customer/usage records, evidence of data portability upon offboarding.

   • [claimed-docs] “The `atmn` CLI lets you define your pricing plans in code via an `autumn.config.ts` file, and sync them to Autumn with a single command.”
   • [claimed-docs] “If you already have products created in the dashboard, run `atmn pull` to pull them into your local config.”
   • [claimed-docs] “Fired whenever a customer's plans change — new subscriptions, upgrades, downgrades, etc.”

   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

Marketplace

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

   weight 2 · round to Mollie
   Autumn—none0/10

   Autumn's evidence focuses entirely on single-party SaaS billing—metering, plans, entitlements, customer subscriptions via Stripe—with no mention of multi-party marketplace features like seller onboarding, payment splitting, or payouts (e.g., Stripe Connect-style functionality). No evidence pack item addresses marketplace/platform payment distribution.

   ⚑ 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