Autumn vs Checkout.com

Agent access

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

   weight 2 · round drawn
   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

   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

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

   weight 2 · round to Checkout.com
   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

   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

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

   weight 3 · round to Checkout.com
   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

   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

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

   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

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

   weight 3 · round to Checkout.com
   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

   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

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

   weight 2 · round to Checkout.com
   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

   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

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

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Checkout.com
   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

   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

Agentic features

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

   weight 2 · round to Checkout.com
   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

   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

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

   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

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

   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

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

   weight 1 · round to Checkout.com
   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

   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

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

   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

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

   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

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

   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

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 Checkout.com
   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

   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

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

   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

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

   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

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

   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

Card acceptance

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

   weight 3 · round to Checkout.com
   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

   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

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 Checkout.com
   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

   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

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

   weight 3 · round to Checkout.com
   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

   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

No code selling

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

   weight 2 · round to Checkout.com
   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

   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

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
   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

   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

Integration reliability

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

   weight 2 · round to Checkout.com
   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

   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

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
   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

   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

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

   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

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
   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

   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

Refunds

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

   weight 3 · round to Checkout.com
   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

   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

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
   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

   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

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

   weight 2 · round drawn
   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

   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

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

   weight 3 · round to Checkout.com
   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

   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

Marketplace

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

   weight 2 · round to Checkout.com
   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

   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

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Autumn—none0/10

   Autumn is a billing/entitlements layer for AI and SaaS products; there is no mention anywhere in the evidence pack of data residency, region selection, or data storage location controls. This is an applicable axis for a data-handling SaaS product, but no evidence supports it.

   ⚑ flag

   Checkout.com—none0/10

   No evidence in the pack mentions data residency, regional data storage options, or user/customer control over where data is stored; while the product processes payments across many currencies/countries, this does not address data residency choice. This axis is applicable to a payments platform handling sensitive data but no supporting evidence exists.

   ⚑ flag