Stripe Billing vs Recurly

Agent access

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

   weight 2 · round drawn
   Stripe Billing✓fullprobed9/10

   Stripe hosts an llms.txt at docs.stripe.com/llms.txt (HTTP 200) and markdown-formatted docs (e.g. billing.md), confirming agent-friendly documentation is directly accessible. Missing for 10: independent/third-party confirmation that agents successfully consume these files in practice beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/billing.md # Billing Create and manage subscriptions, track usage, and issue invoices. …”

   proof ↗⚑ flag

   Recurly✓fullprobed9/10

   A live llms.txt is confirmed via direct probe (HTTP 200) at docs.recurly.com/llms.txt, and Recurly also documents a public MCP server (Compass) that connects AI dev tools directly to its documentation and API knowledge, giving agents a first-party structured path to Recurly's docs. missing for 10: independent/community confirmation of agents actually using these endpoints successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.recurly.com/llms.txt # Recurly Documentation Documentation > Welcome to the Recurly Documentation …”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”
   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Billing
   Stripe Billing✓fullprobed7/10

   Stripe Billing is fully accessible via API and has a documented CLI for building, testing, and managing integrations from the command line, both of which support headless/CI automation, and webhooks enable event-driven automation flows. Missing for 10: explicit CI pipeline examples (e.g., GitHub Actions) or documented headless-mode flags for the CLI, and independent confirmation of CI usage.

   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”
   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”

   proof ↗⚑ flag

   Recurly~partialclaimed4/10

   Recurly offers a full REST API and official client libraries (Ruby, Node, Python, .NET, Java, PHP, Go) which could be scripted headlessly in CI, but there is no explicit documentation of a CLI, CI/CD examples, or automation-focused tooling for headless/agentic workflows. missing for 10: explicit CI/headless usage examples, a documented CLI tool, evidence of non-interactive/automation-first design beyond generic API/SDK availability.

   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [claimed-docs] “The Recurly Native Mobile SDKs allow you to integrate recurrent payments in your existing Android or iOS apps in a matter of minutes.”

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Billing
   Stripe Billing✓fullprobed8/10

   Stripe (parent product of Stripe Billing) documents an official MCP server that lets AI agents interact with the Stripe API, confirmed by both docs and probe evidence. Missing for 10: no independent/community hands-on validation of the MCP server specifically, and no detail on which Billing-specific endpoints/tools are exposed via MCP.

   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Recurly~partialprobed7/10

   Recurly ships an official 'Compass' MCP server that connects AI dev tools directly to Recurly's documentation and API knowledge, confirmed both in docs and via a live probe of the docs page. However, evidence only describes it as a documentation/knowledge connector, not a full agentic interface for performing billing actions (e.g., managing subscriptions, invoices) via MCP. Missing for 10: evidence of MCP tool-calling for actual account/subscription operations, independent hands-on validation of the MCP server in use.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Billing
   Stripe Billing✓fullprobed8/10

   Stripe documents an official Stripe CLI for building, testing, and managing Stripe integrations from the command line, confirmed by both docs and probe evidence. Missing for 10: independent hands-on community reports specifically about CLI usage/quality (community evidence here focuses on billing fees, not the CLI).

   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly—none0/10

   No evidence of an official Recurly CLI; documentation instead references client libraries (Ruby, Node.js, Python, etc.), mobile SDKs, and an MCP server for AI tools, but nothing about a command-line interface.

   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [claimed-docs] “The Recurly Native Mobile SDKs allow you to integrate recurrent payments in your existing Android or iOS apps in a matter of minutes.”
   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Billing
   Stripe Billing✓fullprobed9/10

   Stripe Billing is fully drivable via the well-documented Subscriptions/Invoicing/Usage-based/Prorations APIs, with webhooks for events and even an official CLI and MCP server for agent-driven access. Missing for 10: no published OpenAPI spec discoverable at standard locations (404s on probe) and no independent hands-on confirmation of full API parity for AI-agent workflows.

   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/billing.md # Billing Create and manage subscriptions, track usage, and issue invoices. …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly✓fullprobed8/10

   Recurly documents a full public API with official client libraries in seven languages, entitlements checkable via API, and even an MCP server (Compass) exposing API/doc knowledge to AI tools, indicating strong API-first, AI-accessible design. missing for 10: independent developer corroboration of API robustness/rate limits and no evidence of API versioning or webhooks documentation depth.

   • [claimed-docs] “Entitlements can be applied across platforms (web, mobile, and app stores) and checked in real time via the Recurly API.”
   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.recurly.com/llms.txt # Recurly Documentation Documentation > Welcome to the Recurly Documentation …”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Billing—none0/10

   The evidence pack shows Stripe's MCP server and CLI for agent integration, but nothing documents scoped or least-privilege API credential issuance for agents (e.g., restricted API keys with granular permissions) — this specific capability is absent from the pack. Missing for 10: documentation of restricted/scoped API key creation, permission granularity controls, and any agent-specific credential-scoping workflow.

   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”

   proof ↗⚑ flag

   Recurly—none0/10

   No evidence of scoped or least-privilege API key/credential issuance for agents; the MCP server (recurly-docs-12, recurly-probe-2) only connects AI tools to documentation, not scoped API credentials, and no API key management or permission-scoping docs are present.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Recurly
   Stripe Billing~partialprobed4/10

   The pack shows Stripe exposes a public API, an official CLI, and an MCP server for agent access, and the llms.txt note implies npm-published SDK packages, but there is no explicit documentation of official language SDKs (Node/Python/Ruby/etc.) or SDK-specific guides in the evidence pack. Missing for 10: explicit SDK reference docs/links, language coverage list, and any independent corroboration of SDK quality or agent usage with them.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly✓fullprobed8/10

   Recurly documents official client libraries across seven languages (Ruby, Node.js, Python, .NET, Java, PHP, Go) plus native mobile SDKs for iOS/Android, giving AI-native developers a solid multi-language SDK surface, and an official Compass MCP server ties AI tools into its API docs. Missing for 10: independent hands-on developer confirmation of SDK quality/reliability and no explicit mention of AI-specific SDK tooling beyond the MCP docs connector.

   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [claimed-docs] “The Recurly Native Mobile SDKs allow you to integrate recurrent payments in your existing Android or iOS apps in a matter of minutes.”
   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Stripe Billing
   Stripe Billing✓fullclaimed7/10

   Stripe's docs explicitly describe webhooks pushing real-time event data when things happen in the account, which is the standard mechanism for subscribing to billing-related events (e.g., subscription/invoice lifecycle). Missing for 10: no specifics on which billing event types are supported, no documentation of webhook endpoint management via API, and no agent-specific webhook subscription flow (e.g., via MCP) tying it to the 'AI-native' framing.

   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”

   proof ↗⚑ flag

   Recurly~partialcommunity3/10

   The only mention of webhooks in the evidence pack is an indirect community comparison noting Recurly automates retention 'without needing to implement webhooks' for dunning, implying webhook functionality exists, but no first-party documentation, API reference, or event-list evidence describes how to subscribe to or configure webhooks. Missing for 10: official webhook API/docs, list of subscribable events, setup instructions, and any AI-agent-specific webhook integration guidance.

   • [community] “Comparing Stripe and Recurly: It's faster to get going with Stripe (no merchant account required) but Recurly appears to offer more automate…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Stripe Billing—none0/10

   Evidence shows only standard analytics dashboards (docs-11) and an MCP server for external agents to call the API (docs-18), but nothing indicating the product itself generates AI-driven insights or suggestions from a merchant's billing data. missing for 10: any AI/ML-generated insights or recommendation features, in-product analysis narratives, or evidence of generative AI surfacing suggestions from billing/subscription data.

   • [claimed-docs] “Monitor overall performance at a glance”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”

   proof ↗⚑ flag

   Recurly—none0/10

   No evidence Recurly generates AI-driven insights or suggestions from a merchant's own subscription/billing data; the only AI-related feature (Compass MCP) merely connects AI dev tools to documentation/API knowledge, not to account data analytics.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Billing
   Stripe Billing~partialprobed6/10

   Stripe Billing ships genuine background automations that run autonomously without manual intervention — recurring subscription billing, smart retries for failed payments, and webhook-driven event automation — and it exposes an official MCP server letting AI agents interact with the Billing API, aligning with the AI-native automation story. However, there is no evidence of an AI-native automation/rules builder (e.g., agent-authored workflows, scheduled agent tasks) beyond the MCP connector and the native recurring-billing engine. Missing for 10: dedicated AI-agent workflow/automation builder, evidence of agents autonomously configuring or modifying billing automations, independent hands-on validation of MCP-driven autonomous operation.

   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”
   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Recurly~partialclaimed4/10

   Recurly ships built-in autonomous background processes—dunning campaigns (up to 50 targeted campaigns), automatic backup payment method fallback, and involuntary churn recovery tools—that run without manual intervention once configured. However, there is no evidence of a general-purpose automation/workflow builder, triggers, or agent-configurable rules engine that an AI-native user could set up beyond these fixed billing-retention features. Missing for 10: a configurable automation/rules engine, evidence of user-defined triggers/actions beyond dunning, and any AI-agent-specific automation tooling.

   • [claimed-docs] “merchants on Professional and Elite plans can create up to 50 targeted campaigns for different customer segments or plans”
   • [claimed-docs] “Involuntary churn happens when customers are lost due to factors outside their intent — expired cards, bank changes, or failed payments. Rec…”
   • [claimed-docs] “Let customers designate a backup payment method so service continues automatically if their primary payment fails.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Stripe Billing—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Recurly—none0/10

   Recurly is a subscription billing platform; evidence shows an MCP server for connecting AI dev tools to documentation/API knowledge, but nothing indicates a built-in AI assistant within the product that users can delegate tasks to.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round to Stripe Billing
   Stripe Billing~partialprobed6/10

   Stripe documents an official MCP server that lets AI agents interact with the Stripe API (which includes Billing endpoints for subscriptions, invoices, etc.), enabling natural-language-driven operation via an AI agent layer. However, this is evidenced only via first-party docs at the general Stripe API level, not Billing-specific NL commands, and there's no independent/hands-on confirmation of it working well for Billing tasks. Missing for 10: Billing-specific natural-language examples, independent/hands-on validation of MCP-driven billing operations, and documented limitations/edge cases.

   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Recurly~partialprobed4/10

   Recurly's Compass MCP server lets AI dev tools query Recurly's documentation and API knowledge, which is a step toward AI-native/agentic interaction, but the evidence describes it as a knowledge/docs connector rather than a natural-language interface for actually executing billing operations (e.g., changing subscriptions, issuing credits) end-to-end. Missing for 10: evidence of natural-language command execution for actual account/subscription actions, hands-on proof of the MCP server performing operations (not just doc lookup), and any client-facing chat/NL interface.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Stripe Billing—none0/10

   The evidence pack contains no mention of an interactive API reference with runnable/executable code examples for Stripe Billing; it only covers docs, CLI, MCP server, and general billing features. Absence of evidence for this applicable capability yields 'none'.

   ⚑ flag

   Recurly—none0/10

   Evidence shows client libraries, SDKs, an MCP server for docs/API knowledge, and an llms.txt file, but there is no mention of an interactive API reference with runnable/live-executable examples (e.g., a try-it-now console). Missing for 10: interactive API console, runnable code examples, in-browser execution/testing of API calls.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.recurly.com/llms.txt # Recurly Documentation Documentation > Welcome to the Recurly Documentation …”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Billing—none0/10

   The evidence pack shows an explicit probe for OpenAPI/Swagger spec files at all standard paths returning 404, and no docs or community item mentions a downloadable OpenAPI/equivalent spec for Stripe Billing's API; only llms.txt and markdown docs endpoints are confirmed, which are not API specs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/billing.md # Billing Create and manage subscriptions, track usage, and issue invoices. …”

   proof ↗⚑ flag

   Recurly—none0/10

   The evidence pack shows official client libraries, mobile SDKs, an llms.txt file, and an MCP server, but no mention of a downloadable OpenAPI/Swagger spec or any machine-readable API schema file. Since Recurly is an API-based product, this axis clearly applies, but there is no evidence of the specific capability requested.

   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.recurly.com/llms.txt # Recurly Documentation Documentation > Welcome to the Recurly Documentation …”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Stripe Billing—none0/10

   The evidence pack never mentions a Stripe test mode, sandbox environment, or test API keys — only general docs on billing features, CLI ("build, test, and manage... from the command line"), and MCP server access, none of which document an explicit non-production sandbox for safely testing AI-driven billing workflows. Since sandbox/test-mode support is a mainstream, applicable expectation for a billing platform, its absence here yields 'none' rather than 'na'.

   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly—none0/10

   No evidence pack item mentions a sandbox, test/dev environment, or test API keys for Recurly; documentation covers subscription changes, billing, and MCP tooling but not isolated test environments. Missing for 10: any mention of sandbox/test mode, test credentials, or separation from production data.

   ⚑ flag

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

   weight 2 · round drawn
   Stripe Billing—none0/10

   The evidence pack covers Billing features, pricing, fees, and community reactions but contains no mention of API versioning scheme, version pinning, or a documented deprecation policy for the Stripe API. Missing for 10: any documentation of API version headers, changelog/versioning policy, or deprecation timelines.

   ⚑ flag

   Recurly—none0/10

   The evidence pack covers subscription features, client libraries, and an MCP server, but contains no documentation of API versioning schemes or a deprecation policy. Missing for 10: any mention of API version headers/URLs, changelog, or a documented deprecation/sunset policy.

   ⚑ flag

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

   weight 2 · round to Stripe Billing
   Stripe Billing~partialprobed5/10

   Stripe Billing exposes a full REST API, CLI, and MCP server that could be scripted for bulk actions, and docs mention importing many existing subscriptions from third-party systems in bulk. However, there is no explicit documentation of batch/bulk endpoints, rate-limit-aware bulk workflows, or AI-agent-specific bulk operation support beyond general API access. Missing for 10: explicit bulk/batch API endpoints, documented bulk operation patterns via CLI/MCP, and independent evidence of successful large-scale bulk usage.

   • [claimed-docs] “You can import existing subscriptions from third-party billing systems (such as Zuora, Recurly, Chargify, or Chargebee) into Stripe Billing.”
   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly~partialclaimed3/10

   Recurly's docs mention bulk data import/export to populate accounts and analyze records, which implies some bulk operation support, and API client libraries could theoretically be used to script batch changes. However, there is no explicit documentation of a bulk-update/bulk-cancel/bulk-modify API for subscriptions, invoices, or entitlements, nor any AI-native tooling for orchestrating such bulk actions. missing for 10: explicit bulk subscription/invoice update API, bulk operation endpoints or SDK examples, evidence of AI-driven or agentic bulk workflows, independent confirmation of bulk import scale/performance.

   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Import customer data to populate accounts and records across your Recurly account.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”

   proof ↗⚑ flag

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

   weight 3 · round to Stripe Billing
   Stripe Billing~partialclaimed5/10

   Stripe Billing ships built-in automations tied to events (Smart Retries triggers on failed payment events, entitlements auto grant/revoke access) and exposes webhooks so developers can build custom event-triggered actions, satisfying the spirit of 'rules trigger actions on events.' However, there's no documented no-code/rule-builder interface for defining arbitrary trigger-condition-action rules — webhooks require custom code to consume events. Missing for 10: a dedicated rules/automation engine or UI for defining conditional triggers, and evidence of AI-native/agent-configurable rule definition beyond raw webhooks.

   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”
   • [claimed-docs] “Determine when you can grant or revoke product feature access to customers.”
   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”

   proof ↗⚑ flag

   Recurly~partialcommunity4/10

   Recurly ships built-in automated responses to specific billing events—dunning campaigns triggered by failed payments (up to 50 targeted campaigns) and automatic fallback to backup payment methods—but these are pre-defined behaviors within fixed billing workflows, not a general-purpose rule engine where users define arbitrary event→action logic. Missing for 10: a configurable trigger/condition/action framework (e.g., custom webhooks-driven rules, if-this-then-that automation builder) and evidence of user-defined (not just Recurly-provided) automation logic.

   • [claimed-docs] “merchants on Professional and Elite plans can create up to 50 targeted campaigns for different customer segments or plans”
   • [claimed-docs] “Involuntary churn happens when customers are lost due to factors outside their intent — expired cards, bank changes, or failed payments. Rec…”
   • [claimed-docs] “Let customers designate a backup payment method so service continues automatically if their primary payment fails.”
   • [community] “Comparing Stripe and Recurly: It's faster to get going with Stripe (no merchant account required) but Recurly appears to offer more automate…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Stripe Billing
   Stripe Billing~partialprobed6/10

   Stripe Billing's core function is automating recurring billing workflows (subscriptions, trials, retries, prorations) and it exposes an API, CLI, and MCP server that let an AI-native user programmatically create/manage these recurring billing schedules. However, this is scoped to billing/subscription recurrence, not general-purpose job/workflow scheduling, and there's no explicit documentation of a 'subscription schedule' or cron-like workflow orchestration primitive beyond subscriptions/retries. missing for 10: dedicated subscription-schedule/workflow-scheduling docs, independent hands-on confirmation of AI-agent-driven recurring job setup via MCP/CLI.

   • [claimed-docs] “Use Stripe Billing to manage subscriptions and invoicing. It automates recurring payments, creates custom pricing plans, and handles billing…”
   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”
   • [claimed-docs] “Use the Trial Offer API to manage both free and paid introductory periods for your subscriptions with a single API integration.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly~partialclaimed5/10

   Recurly's core product is built around recurring billing cycles that run automatically (subscription renewals, usage-based billing at cycle end, dunning email campaigns), which functions as a domain-specific recurring workflow engine, but it offers no general-purpose job/task scheduler an AI-native user could configure for arbitrary recurring workflows. Missing for 10: a generic scheduling/automation API or cron-like mechanism for arbitrary AI-driven tasks, and any evidence of AI-agent-triggered scheduling beyond built-in billing cycles.

   • [claimed-docs] “Recurly's usage-based billing model lets you charge customers at the end of each billing cycle based on their actual consumption”
   • [claimed-docs] “merchants on Professional and Elite plans can create up to 50 targeted campaigns for different customer segments or plans”
   • [claimed-docs] “Involuntary churn happens when customers are lost due to factors outside their intent — expired cards, bank changes, or failed payments. Rec…”
   • [claimed-docs] “Recurly bills only the difference during an immediate change when the underlying plan is unchanged.”

   proof ↗⚑ flag

Agent operations

1. ai-native userAn agent can operate my billing — create a subscription, apply a credit, change a plan — through a programmatic surface with scoped permissions

   weight 3 · round to Stripe Billing
   Stripe Billing~partialprobed6/10

   Stripe Billing exposes a full programmatic Subscriptions API (create, change plan, proration preview) and an official MCP server letting AI agents interact with the Stripe API, which supports the 'agent operates billing programmatically' story. However, the evidence never documents scoped/restricted permission controls for agent access, nor explicit 'apply a credit' functionality, so the scoped-permission and credit-specific parts of the story are unevidenced. Missing for 10: documented scoped/restricted API key or permission model for agent use, explicit credit-application API evidence, and independent corroboration of the MCP server's agent workflows.

   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [claimed-docs] “You can preview a proration to view the amount before applying the changes.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Recurly~partialprobed5/10

   Recurly exposes a full REST API and client libraries covering subscription changes, credits, and invoices (recurly-docs-1, -2, -9, -13), which could technically be driven by an agent. However, the only AI-specific surface documented, Recurly Compass MCP, is explicitly a documentation/knowledge connector for AI dev tools, not an operational interface for executing billing actions (recurly-docs-12, recurly-probe-2), and there is no evidence of scoped/restricted API keys or permission models designed for autonomous agent use. Missing for 10: an agent-oriented action interface (e.g., MCP server or agent SDK) that can actually invoke billing operations, and documentation of scoped/least-privilege API credentials for agent access.

   • [claimed-docs] “Recurly gives you full control over how and when subscription changes take effect. Upgrade or downgrade a plan, adjust quantity or price, ad…”
   • [claimed-docs] “Recurly bills only the difference during an immediate change when the underlying plan is unchanged.”
   • [claimed-docs] “Credit invoices give every credit its own distinct invoice — separate from charge invoices.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

Agent queries

1. ai-native userAn agent can answer questions about my billing state — MRR, delinquent accounts, upcoming renewals, a customer's invoices — by querying the platform directly

   weight 2 · round to Stripe Billing
   Stripe Billing~partialprobed6/10

   Stripe ships an official MCP server explicitly for AI agents to interact with the Stripe API (docs-18, probe-4), which would let an agent query subscriptions, invoices, and customer records directly; docs also show subscription/invoice/analytics APIs (docs-2, docs-8, docs-11) that could back such queries. However, there's no direct evidence the MCP/API surfaces higher-level billing-state metrics like MRR or delinquency status as first-class queryable objects, and analytics is described as dashboard-facing rather than agent-facing. Missing for 10: explicit MCP tool/API documentation for MRR aggregation, delinquent-account flags, and renewal-forecast queries, plus any hands-on agent demo confirming these questions can be answered end-to-end.

   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [claimed-docs] “Create, customize, and send a Stripe-hosted invoice from the Dashboard, with no code required.”
   • [claimed-docs] “Monitor overall performance at a glance”

   proof ↗⚑ flag

   Recurly~partialprobed4/10

   Recurly exposes a REST API and official client libraries that could let an agent fetch account/invoice/subscription data, and entitlements are described as checkable in real time via the API. However, the only AI-agent integration evidenced (Compass MCP) is explicitly scoped to documentation and API knowledge, not live billing-state queries, and there is no evidence of dedicated endpoints/reports for MRR, delinquent-account lists, or renewal forecasts that an agent could query directly. missing for 10: evidence of an MCP or agent-facing endpoint returning MRR/delinquency/renewal data, documentation of a reporting/analytics API for these metrics, independent confirmation of agent-driven billing queries working in practice.

   • [claimed-docs] “Recurly Compass MCP connects your AI development tools directly to Recurly's documentation and API knowledge.”
   • [claimed-docs] “Entitlements can be applied across platforms (web, mobile, and app stores) and checked in real time via the Recurly API.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [claimed-docs] “Modify invoice details post-issuance — including account notes, due dates, PO numbers, customer notes, and terms — to keep records accurate.”
   • [probe] “official MCP server documented at https://docs.recurly.com/recurly-subscriptions/docs/compass-public-mcp-server”

   proof ↗⚑ flag

Billing cycles

1. ops userControl billing anchors and cycles — calendar vs anniversary billing, alignment across a customer's subscriptions, custom invoice dates

   weight 2 · round to Recurly
   Stripe Billing—none0/10

   The evidence pack covers subscriptions, usage-based pricing, prorations, trials, and invoicing generally, but nothing documents billing_cycle_anchor controls, calendar-vs-anniversary billing options, cross-subscription alignment, or custom invoice date setting. Missing for 10: any doc/community mention of billing cycle anchor parameters, alignment across subscriptions, or custom invoice date configuration.

   ⚑ flag

   Recurly~partialclaimed3/10

   Evidence only shows post-issuance invoice detail edits (due dates, PO numbers, terms) via recurly-docs-10, which loosely touches 'custom invoice dates' but doesn't address billing anchor/cycle configuration. No documentation covers calendar-vs-anniversary billing modes or aligning billing cycles across a customer's multiple subscriptions. Missing for 10: explicit billing anchor/cycle-start configuration, calendar vs anniversary billing toggle, cross-subscription date alignment tooling, and any independent/hands-on confirmation of these mechanics.

   • [claimed-docs] “Modify invoice details post-issuance — including account notes, due dates, PO numbers, customer notes, and terms — to keep records accurate.”

   proof ↗⚑ flag

Proration

1. finance leadMid-cycle upgrades and downgrades are prorated with documented, auditable math — credits, partial periods, and invoice line items that reconcile to the penny

   weight 3 · round drawn
   Stripe Billing~partialclaimed5/10

   Stripe docs confirm proration is supported with a preview capability before applying changes, giving finance teams visibility into charges before invoicing, and invoices/line items are generated automatically. However, there is no documented detail on the exact proration math methodology (day-count conventions, rounding rules), no auditable reconciliation reports, and no independent/community evidence confirming penny-level accuracy in practice. missing for 10: detailed documented proration formula/rounding rules, audit trail/reconciliation reporting for finance teams, independent verification of penny-accurate reconciliation.

   • [claimed-docs] “You can preview a proration to view the amount before applying the changes.”
   • [claimed-docs] “Create, customize, and send a Stripe-hosted invoice from the Dashboard, with no code required.”

   proof ↗⚑ flag

   Recurly~partialclaimed5/10

   Recurly's docs confirm mid-cycle changes are billed as prorated differences and that credits get their own separate, dedicated invoices, plus invoices can be amended post-issuance for record accuracy — supporting the core proration/credit reconciliation need. However, there's no documented breakdown of the proration math formula, no explicit audit trail feature, and no evidence (first-party or independent) that invoice reconciliation is verified to the penny in practice. Missing for 10: detailed proration calculation documentation, explicit audit-log/traceability feature, and independent verification of penny-accurate reconciliation.

   • [claimed-docs] “Recurly bills only the difference during an immediate change when the underlying plan is unchanged.”
   • [claimed-docs] “Credit invoices give every credit its own distinct invoice — separate from charge invoices.”
   • [claimed-docs] “Modify invoice details post-issuance — including account notes, due dates, PO numbers, customer notes, and terms — to keep records accurate.”

   proof ↗⚑ flag

Card recovery

1. ops userExpiring or replaced cards update themselves — network account updater, backup payment methods, and hosted update-payment pages

   weight 2 · round to Recurly
   Stripe Billing~partialclaimed4/10

   Stripe's customer portal (docs-12, docs-13) provides hosted pages where customers can update payment methods, and Smart Retries (docs-5, docs-6) addresses failed payment recovery, but the evidence pack never mentions a network account updater service or backup/secondary payment methods functionality explicitly. missing for 10: explicit documentation of card network account updater, backup payment method fallback logic, and independent confirmation these auto-update cards without customer action.

   • [claimed-docs] “Give your customers the ability to manage their account by setting up a customer portal.”
   • [claimed-docs] “Use the Dashboard to activate the customer portal and optionally customize branding and prefill customer email addresses.”
   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”

   proof ↗⚑ flag

   Recurly~partialclaimed5/10

   Docs confirm backup payment methods and general 'tools to proactively catch and resolve' involuntary churn from expired cards/failed payments, but the evidence pack never explicitly names or documents a network account updater feature or hosted update-payment pages. missing for 10: explicit documentation of account updater integration, explicit hosted update-payment page feature, and any hands-on confirmation these self-heal expiring cards.

   • [claimed-docs] “Involuntary churn happens when customers are lost due to factors outside their intent — expired cards, bank changes, or failed payments. Rec…”
   • [claimed-docs] “Let customers designate a backup payment method so service continues automatically if their primary payment fails.”

   proof ↗⚑ flag

Dunning comms

1. ops userConfigure automated dunning sequences — branded emails, in-app banners, grace periods, and final-state rules like cancel vs unpaid

   weight 2 · round to Recurly
   Stripe Billing~partialclaimed4/10

   Stripe Billing docs confirm automated Smart Retries to recover failed payments, which is the core of dunning automation, but the evidence pack lacks any mention of branded dunning emails, in-app banners, configurable grace periods, or explicit final-state rules (cancel vs. mark-unpaid) that the story requires. missing for 10: branded email templates, in-app banner configuration, grace period settings, explicit cancel-vs-unpaid final state rules.

   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”

   proof ↗⚑ flag

   Recurly~partialcommunity5/10

   Docs confirm dunning campaigns (up to 50 targeted campaigns) and proactive involuntary-churn tools like backup payment methods, and community evidence corroborates automated dunning emails as a differentiator vs competitors. However, there's no documentation of branded email customization, in-app banners, configurable grace periods, or final-state rules distinguishing cancel vs unpaid outcomes. missing for 10: branded email templates/customization, in-app banner support, grace period configuration, and cancel-vs-unpaid final-state rule settings.

   • [claimed-docs] “merchants on Professional and Elite plans can create up to 50 targeted campaigns for different customer segments or plans”
   • [claimed-docs] “Involuntary churn happens when customers are lost due to factors outside their intent — expired cards, bank changes, or failed payments. Rec…”
   • [claimed-docs] “Let customers designate a backup payment method so service continues automatically if their primary payment fails.”
   • [community] “Comparing Stripe and Recurly: It's faster to get going with Stripe (no merchant account required) but Recurly appears to offer more automate…”
   • [community] “Chargify finally has statements. Recurly has a large emphasis on making sure your customers are retained -- so much so that they added their…”

   proof ↗⚑ flag

Smart retries

1. finance leadFailed renewal payments are retried automatically on an ML- or schedule-optimized cadence that measurably recovers involuntary churn

   weight 3 · round to Stripe Billing
   Stripe Billing~partialclaimed6/10

   Stripe Billing documents Smart Retries, an automated system that retries failed subscription/invoice payments to reduce involuntary churn, directly matching the story's core ask (docs-5, docs-6). However, evidence doesn't detail ML- or schedule-optimization mechanics, retry cadence customization, or quantified recovery metrics, and community evidence focuses on pricing/fees rather than corroborating recovery effectiveness. Missing for 10: independent/hands-on evidence of measurable churn recovery impact, specifics on the ML/schedule optimization logic, and customer-facing proof of recovered revenue rates.

   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”

   proof ↗⚑ flag

   Recurly~partialcommunity5/10

   Recurly documents dunning management and involuntary-churn tools like targeted campaigns and backup payment methods, and community commentary notes Recurly's automated retention/dunning emails as a differentiator, but there is no evidence of ML-optimized or schedule-optimized retry cadence logic, nor any quantified recovery-rate/churn-reduction metrics. missing for 10: documentation of the actual retry scheduling/ML logic behind payment retries, evidence of adaptive or optimized cadence (vs simple campaign rules), and third-party or first-party data on measurable involuntary churn recovery.

   • [claimed-docs] “merchants on Professional and Elite plans can create up to 50 targeted campaigns for different customer segments or plans”
   • [claimed-docs] “Involuntary churn happens when customers are lost due to factors outside their intent — expired cards, bank changes, or failed payments. Rec…”
   • [claimed-docs] “Let customers designate a backup payment method so service continues automatically if their primary payment fails.”
   • [community] “Comparing Stripe and Recurly: It's faster to get going with Stripe (no merchant account required) but Recurly appears to offer more automate…”
   • [community] “Chargify finally has statements. Recurly has a large emphasis on making sure your customers are retained -- so much so that they added their…”

   proof ↗⚑ flag

Entitlement checks

1. developerFeatures and limits are modeled as entitlements attached to plans, and my application can check a customer's entitlements at runtime via API or SDK

   weight 3 · round to Recurly
   Stripe Billing~partialclaimed5/10

   Stripe explicitly documents an Entitlements feature for granting/revoking product feature access to customers, matching the story's core idea of feature entitlements tied to products/plans, but the evidence pack gives only a single high-level doc link with no detail on the runtime API/SDK check flow or independent corroboration. missing for 10: specifics on the Entitlements API/SDK call for runtime checks, code examples, and community or hands-on validation of the feature.

   • [claimed-docs] “Determine when you can grant or revoke product feature access to customers.”

   proof ↗⚑ flag

   Recurly✓fullclaimed6/10

   Recurly's docs explicitly describe an entitlements feature that can be checked in real time via the Recurly API across platforms, matching the core of the story. Missing for 10: detailed documentation of how entitlements are attached to specific plans, explicit SDK-level (not just API) entitlement-check examples, and independent/hands-on confirmation of this specific feature.

   • [claimed-docs] “Entitlements can be applied across platforms (web, mobile, and app stores) and checked in real time via the Recurly API.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”

   proof ↗⚑ flag

Plan versioning

1. ops userChange pricing without breaking existing subscribers — versioned plans, grandfathering, and bulk migration tools for moving cohorts to new prices

   weight 2 · round to Stripe Billing
   Stripe Billing~partialclaimed4/10

   Stripe docs show proration previews for subscription changes and a tool for importing subscriptions from third-party billing systems, which touch on the mechanics of adjusting pricing without immediately breaking billing, but there is no documentation of explicit 'versioned prices' grandfathering existing subscribers, nor a dedicated bulk cohort-migration tool for moving groups of subscribers to new prices. Missing for 10: explicit grandfathering/versioned-plan documentation, a bulk cohort price-migration API/tool, and independent evidence that ops teams use it this way.

   • [claimed-docs] “You can preview a proration to view the amount before applying the changes.”
   • [claimed-docs] “You can import existing subscriptions from third-party billing systems (such as Zuora, Recurly, Chargify, or Chargebee) into Stripe Billing.”
   • [claimed-docs] “you can set up and integrate different types of usage-based pricing models with your SaaS product.”
   • [claimed-docs] “Determine when you can grant or revoke product feature access to customers.”

   proof ↗⚑ flag

   Recurly—none0/10

   Docs only describe changing an individual subscription's plan/price/add-ons (recurly-docs-1, recurly-docs-2); there is no mention of versioned plan definitions, grandfathering existing subscribers on old pricing, or bulk/cohort migration tooling for moving groups of subscribers to new pricing.

   • [claimed-docs] “Recurly gives you full control over how and when subscription changes take effect. Upgrade or downgrade a plan, adjust quantity or price, ad…”
   • [claimed-docs] “Recurly bills only the difference during an immediate change when the underlying plan is unchanged.”

   proof ↗⚑ flag

Invoices

1. ops userThe platform generates compliant invoices, credit notes, and receipts — sequential numbering, custom fields, memos — delivered to customers automatically

   weight 2 · round to Recurly
   Stripe Billing~partialcommunity4/10

   Docs confirm Stripe Billing/Invoicing can create, customize, and automatically send hosted invoices from the Dashboard (stripe-billing-docs-8), but the evidence never explicitly documents sequential invoice numbering, credit notes, receipts, or memo/custom-field compliance details, and a community comment even claims Stripe historically lacked easy 'email invoicing' compared to competitors (stripe-billing-comm-6). missing for 10: explicit documentation of sequential numbering, credit note generation, receipt issuance, and memo/custom field support with independent corroboration that these are compliant and automated end-to-end.

   • [claimed-docs] “Create, customize, and send a Stripe-hosted invoice from the Dashboard, with no code required.”
   • [community] “A team said they were 'writing code to move from stripe to recurly/adyen' citing that 'the analytics/easy plan mgmt and email invoicing in r…”
   • [community] “Confusion among users about what Stripe Billing actually includes: 'I thought Stripe Billing referred to the Customer Portal functionality a…”

   proof ↗⚑ flag

   Recurly~partialclaimed5/10

   Docs confirm invoice modification (notes, due dates, PO numbers, terms), separate credit invoices, and account/record-keeping features, implying automated invoice generation and delivery, but there is no explicit evidence of sequential/compliant numbering rules, custom field configuration on invoices, memo fields, or receipt generation/delivery workflows. missing for 10: explicit documentation of sequential invoice numbering compliance, custom fields on invoices, memo support, automatic receipt generation/delivery, and independent confirmation of these features working as described.

   • [claimed-docs] “Credit invoices give every credit its own distinct invoice — separate from charge invoices.”
   • [claimed-docs] “Modify invoice details post-issuance — including account notes, due dates, PO numbers, customer notes, and terms — to keep records accurate.”
   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”

   proof ↗⚑ flag

Multi currency

1. finance leadBill customers in their local currency with per-currency price points and consolidated reporting in my home currency

   weight 2 · round to Stripe Billing
   Stripe Billing~partialcommunity5/10

   Stripe Billing supports subscriptions and analytics, but a Stripe PM confirmed that multi-currency pricing currently requires creating a separate plan per currency rather than a single price point with per-currency variants, and reporting/analytics is mentioned only generically without evidence of home-currency consolidation across currencies. missing for 10: native single-price multi-currency price points (not per-currency plan duplication), documented consolidated/rollup reporting in home currency across multiple billing currencies, independent confirmation of this workflow.

   • [community] “For multi-currency subscriptions, Stripe PM confirmed you currently need to create a separate plan per currency (e.g. bronze_plan:eur), sinc…”
   • [claimed-docs] “Monitor overall performance at a glance”
   • [claimed-docs] “Use Stripe Billing to manage subscriptions and invoicing. It automates recurring payments, creates custom pricing plans, and handles billing…”

   proof ↗⚑ flag

   Recurly—none0/10

   None of the evidence items mention multi-currency pricing, per-currency price points, or consolidated home-currency reporting — the pack covers subscription changes, usage billing, dunning, entitlements, invoices, and general community commentary, none of which address currency handling. This is a fair capability to expect from a billing platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

Tax

1. finance leadSales tax, VAT, and GST are calculated on every invoice — natively or through a first-class tax integration — with the right registrations and rates

   weight 2 · round to Stripe Billing
   Stripe Billing✓fullclaimed7/10

   Stripe Tax is documented as a native, first-class feature that automates sales tax, VAT, and GST compliance directly within the Stripe ecosystem (stripe-billing-docs-15), aligning with Stripe Billing's invoicing flow. Missing for 10: independent/hands-on corroboration of tax calculation accuracy and detail on how registrations/rates are managed across multiple jurisdictions beyond the single doc reference.

   • [claimed-docs] “Automate sales tax, VAT, and GST compliance on all your transactions.”
   • [claimed-docs] “Create, customize, and send a Stripe-hosted invoice from the Dashboard, with no code required.”

   proof ↗⚑ flag

   Recurly—none0/10

   The evidence pack contains no mention of tax calculation, VAT/GST handling, tax registrations, or any first-party or third-party tax integration (e.g., Avalara, TaxJar) — invoicing/credit/dunning features are covered but tax compliance is entirely absent. missing for 10: any documentation of sales tax/VAT/GST calculation, tax registration management, or tax engine integration.

   ⚑ flag

Export

1. finance leadExport every subscription, invoice, and usage record — and port stored payment methods out to another provider — if I choose to leave

   weight 2 · round to Recurly
   Stripe Billing—none0/10

   Evidence only documents importing subscriptions *into* Stripe from other providers (Zuora, Recurly, etc.) and migrating customer/payment data *to* Stripe — the reverse direction (exporting subscriptions/invoices/usage and porting stored payment methods to another provider) is never documented. Community evidence even shows a team having to 'write code to move from stripe to recurly/adyen' themselves, implying no built-in export/portability tool exists.

   • [claimed-docs] “You can import existing subscriptions from third-party billing systems (such as Zuora, Recurly, Chargify, or Chargebee) into Stripe Billing.”
   • [claimed-docs] “Migrating your customer and payments data to Stripe is a multi-step process.”
   • [community] “A team said they were 'writing code to move from stripe to recurly/adyen' citing that 'the analytics/easy plan mgmt and email invoicing in r…”

   proof ↗⚑ flag

   Recurly~partialcommunity5/10

   Recurly docs mention a general 'Data Imports and Exports' feature for populating accounts and keeping compliance records, and a community comment specifically praises Recurly's gateway for supporting 'credit card portability' to another provider. However, there is no vendor documentation detailing bulk export of subscriptions, invoices, or usage records, nor an official description of the payment-method portability mechanism (it's only referenced anecdotally by a user, not documented by Recurly). Missing for 10: explicit docs on invoice/usage-record export formats and scope, official documentation of stored payment-method portability/migration tooling, and any independent verification that a full data export actually contains all subscription/invoice/usage history.

   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Import customer data to populate accounts and records across your Recurly account.”
   • [community] “I am in the process of integrating Recurly into my existing business... I want all the subscription management features Recurly provides. Fu…”

   proof ↗⚑ flag

Import

1. ops userMigrate live subscriptions in from a spreadsheet or a competing platform — including PCI-compliant card data transfer — without customers noticing

   weight 3 · round to Stripe Billing
   Stripe Billing~partialclaimed5/10

   Docs explicitly cover importing subscriptions from competing platforms like Zuora, Recurly, Chargify, and Chargebee (docs-10) and a general 'multi-step' customer/payments data migration guide (docs-17), which supports the platform-migration part of the story. However there is no evidence of spreadsheet-based import, no detail on PCI-compliant card data transfer mechanics, and no confirmation that migrated subscriptions continue billing seamlessly without customer-visible disruption. Missing for 10: spreadsheet import support, explicit PCI-compliant card token transfer process, and evidence/testimony that migration is invisible to end customers.

   • [claimed-docs] “You can import existing subscriptions from third-party billing systems (such as Zuora, Recurly, Chargify, or Chargebee) into Stripe Billing.”
   • [claimed-docs] “Migrating your customer and payments data to Stripe is a multi-step process.”

   proof ↗⚑ flag

   Recurly~partialcommunity3/10

   Recurly's docs mention generic data import/export tools (recurly-docs-11, recurly-docs-15) and a community comment notes Recurly's gateway offers 'credit card portability' (recurly-comm-7), suggesting some support for migrating billing data and card credentials. However, there is no documentation of a structured migration workflow, PCI-compliant card tokenization/transfer process, or assurance that live subscriptions migrate without customer disruption. missing for 10: explicit migration/onboarding documentation, PCI-compliant card data transfer mechanics, evidence of seamless customer experience during migration.

   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Import customer data to populate accounts and records across your Recurly account.”
   • [community] “I am in the process of integrating Recurly into my existing business... I want all the subscription management features Recurly provides. Fu…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Stripe Billing~partialcommunity6/10

   Stripe's API covers most Billing operations (subscriptions, usage-based pricing, prorations, trials, entitlements, invoicing) and there's also a CLI and MCP server for programmatic/agent access, but some UI-only features are explicitly dashboard-driven with no-code framing (e.g., hosted invoice creation, customer portal branding/activation), and community comments note gaps like easy plan management/analytics parity versus competitors. missing for 10: confirmation that customer portal setup/branding and dashboard-only analytics views are fully API-configurable, independent verification of full UI/API parity, and evidence addressing feature gaps raised by users (e.g., portal customization, analytics).

   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [claimed-docs] “you can set up and integrate different types of usage-based pricing models with your SaaS product.”
   • [claimed-docs] “You can preview a proration to view the amount before applying the changes.”
   • [claimed-docs] “Determine when you can grant or revoke product feature access to customers.”
   • [claimed-docs] “Use the Dashboard to activate the customer portal and optionally customize branding and prefill customer email addresses.”
   • [claimed-docs] “Let your AI agents interact with the Stripe API by using our MCP server.”
   • [claimed-docs] “Build, test, and manage your Stripe integration from the command line.”
   • [community] “A team said they were 'writing code to move from stripe to recurly/adyen' citing that 'the analytics/easy plan mgmt and email invoicing in r…”
   • [community] “Confusion among users about what Stripe Billing actually includes: 'I thought Stripe Billing referred to the Customer Portal functionality a…”

   proof ↗⚑ flag

   Recurly~partialclaimed6/10

   Docs show broad API coverage of core subscription, invoicing, entitlements, and data import/export features (recurly-docs-1,8,10,11) alongside official client libraries (recurly-docs-13), suggesting most UI actions are API-accessible. However, there is no explicit statement of full UI/API parity, and some UI-only features like dunning campaign configuration (recurly-docs-5) aren't confirmed as API-manageable. Missing for 10: an explicit parity guarantee or comprehensive API reference mapping every UI action, and independent confirmation that all UI-configurable settings (e.g., dunning campaigns) are exposed via API.

   • [claimed-docs] “Recurly gives you full control over how and when subscription changes take effect. Upgrade or downgrade a plan, adjust quantity or price, ad…”
   • [claimed-docs] “Entitlements can be applied across platforms (web, mobile, and app stores) and checked in real time via the Recurly API.”
   • [claimed-docs] “Modify invoice details post-issuance — including account notes, due dates, PO numbers, customer notes, and terms — to keep records accurate.”
   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”
   • [claimed-docs] “merchants on Professional and Elite plans can create up to 50 targeted campaigns for different customer segments or plans”

   proof ↗⚑ flag

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

   weight 3 · round to Recurly
   Stripe Billing—none0/10

   Evidence covers importing/migrating data INTO Stripe Billing (from Zuora, Recurly, etc.) but nothing about exporting a merchant's own subscription/invoice/customer data out in open formats to leave the platform. No documentation of a data export or portability tool for departing customers.

   • [claimed-docs] “You can import existing subscriptions from third-party billing systems (such as Zuora, Recurly, Chargify, or Chargebee) into Stripe Billing.”
   • [claimed-docs] “Migrating your customer and payments data to Stripe is a multi-step process.”

   proof ↗⚑ flag

   Recurly~partialcommunity4/10

   Recurly documents a data-imports-and-exports feature for populating accounts and keeping records, and community mentions note credit-card portability, suggesting some data can be extracted, but there is no evidence of a comprehensive, open-format (CSV/JSON) full-account export or an official data-portability/exit process. missing for 10: explicit open-format export documentation, full account data export scope, and confirmation of easy migration/exit workflow.

   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Import customer data to populate accounts and records across your Recurly account.”
   • [community] “I am in the process of integrating Recurly into my existing business... I want all the subscription management features Recurly provides. Fu…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Stripe Billing—none0/10

   Stripe Billing is a closed-source SaaS product; there is no evidence of any open-licensed source code being available for inspection. Documentation, CLI, and MCP server are all provided, but none imply open-source availability of the underlying product code.

   ⚑ flag

   Recurly—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Stripe Billing—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Recurly—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 2 · round drawn
   Stripe Billing—none0/10

   No evidence in the pack discusses data residency, regional storage options, or data sovereignty controls for Stripe Billing; the axis applies to a payments/data platform like Stripe but is unaddressed here.

   ⚑ flag

   Recurly—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic data control for Recurly; this is a fair axis for a SaaS billing platform handling customer/payment data, but absence of evidence means 'none'.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Stripe Billing—none0/10

   The evidence pack covers subscriptions, invoicing, tax, portal, MCP/CLI tooling, and pricing complaints, but nothing addresses data retention policies, deletion controls, or privacy/data lifecycle management for AI-native users. Missing for 10: any documentation on data retention settings, deletion/erasure APIs, or privacy controls for customer/usage data.

   ⚑ flag

   Recurly—none0/10

   Evidence covers subscription management, billing, invoicing, imports/exports and an MCP docs connector, but nothing addresses data retention policies, deletion requests, or privacy/GDPR-style controls for AI-native users. missing for 10: data retention policy documentation, data deletion/right-to-erasure mechanisms, privacy compliance controls (GDPR/CCPA), evidence of user-initiated data deletion API or workflow.

   ⚑ flag

Analytics

1. founderI get MRR, churn, cohort retention, and LTV analytics computed from the billing source of truth, not a bolted-on BI export

   weight 2 · round to Stripe Billing
   Stripe Billing!disputedcontradicted4/10

   Stripe's docs only vaguely reference subscription analytics ('Monitor overall performance at a glance') with no explicit mention of MRR, churn, cohort retention, or LTV computation, and community evidence directly contradicts the claim that Stripe provides adequate built-in analytics, with one team citing lack of analytics as a reason for migrating away from Stripe Billing to Recurly. missing for 10: explicit documentation of MRR/churn/cohort/LTV dashboards, independent confirmation that these metrics are computed natively rather than requiring external BI tools.

   • [claimed-docs] “Monitor overall performance at a glance”
   • [community] “A team said they were 'writing code to move from stripe to recurly/adyen' citing that 'the analytics/easy plan mgmt and email invoicing in r…”

   proof ↗⚑ flag

   Recurly—none0/10

   The evidence pack covers subscription changes, dunning, entitlements, invoicing, and data import/export, but contains no mention of MRR, churn, cohort retention, or LTV analytics/reporting dashboards computed from billing data. Missing for 10: any documentation of built-in revenue/retention analytics, cohort or LTV reporting, or dashboards distinct from raw data export.

   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Import customer data to populate accounts and records across your Recurly account.”

   proof ↗⚑ flag

Gl sync

1. finance leadInvoices, payments, and recognition entries sync to my general ledger or ERP — QuickBooks, Xero, NetSuite — so the close doesn't need CSV surgery

   weight 2 · round drawn
   Stripe Billing—none0/10

   The evidence pack shows Stripe Billing's revenue recognition module (docs-7) and webhooks (docs-16) but contains no mention of native or documented sync to QuickBooks, Xero, NetSuite, or any ERP/GL system — only generic webhook/API primitives that a team would need to build custom integration on top of. Missing for 10: documented native connectors or partner integrations for QuickBooks/Xero/NetSuite, evidence of automated invoice/payment/rev-rec entry sync to a GL, and any customer account of eliminating manual CSV reconciliation.

   • [claimed-docs] “Simplify your revenue recognition with automated support for global accounting standards”
   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”
   • [claimed-docs] “Migrating your customer and payments data to Stripe is a multi-step process.”

   proof ↗⚑ flag

   Recurly—none0/10

   The evidence pack shows generic data import/export capability but no mention of specific GL/ERP integrations (QuickBooks, Xero, NetSuite) or revenue recognition sync. Missing for 10: any documentation of accounting/ERP connectors, revenue recognition automation, or close-process integration.

   • [claimed-docs] “Use it to populate your account, analyze performance and customer behavior, and keep records for compliance.”
   • [claimed-docs] “Import customer data to populate accounts and records across your Recurly account.”

   proof ↗⚑ flag

Revrec reports

1. finance leadRevenue is recognized on an ASC 606 / IFRS 15 basis — deferred revenue schedules and audit-ready recognition reports straight from billing data

   weight 3 · round to Stripe Billing
   Stripe Billing~partialclaimed5/10

   Stripe has a dedicated Revenue Recognition product that automates deferred revenue schedules per global accounting standards, directly matching the story's core intent, but the evidence pack gives only a single thin doc snippet with no mention of ASC 606/IFRS 15 specifically, no detail on audit-ready reporting outputs, and no independent/community corroboration of its use for finance audits. missing for 10: explicit ASC606/IFRS15 standard mapping, description of audit-ready report generation, independent or hands-on validation of the recognition reports.

   • [claimed-docs] “Simplify your revenue recognition with automated support for global accounting standards”

   proof ↗⚑ flag

   Recurly—none0/10

   Evidence covers subscriptions, invoicing, dunning, entitlements, and data import/export for general compliance, but nothing addresses ASC 606/IFRS 15 deferred revenue schedules or audit-ready recognition reporting specifically. Absence of evidence for this applicable billing-platform capability means it can't be credited as delivered.

   ⚑ flag

Lifecycle api

1. developerCreate, update, pause, and cancel subscriptions through a documented API — the full lifecycle without touching a dashboard

   weight 3 · round to Stripe Billing
   Stripe Billing✓fullprobed7/10

   Docs confirm subscriptions can be created and updated via the Subscriptions API (including proration previews for changes) and trials/usage-based pricing are API-configurable, plus CLI/webhooks support programmatic workflows without the dashboard. However, explicit documentation of 'pause' and 'cancel' endpoints isn't present in the evidence pack, only implied by general subscription management docs. missing for 10: explicit doc citation for pause-subscription and cancel-subscription API endpoints, independent hands-on confirmation of full lifecycle via API only.

   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [claimed-docs] “You can preview a proration to view the amount before applying the changes.”
   • [claimed-docs] “Use the Trial Offer API to manage both free and paid introductory periods for your subscriptions with a single API integration.”
   • [claimed-docs] “you can set up and integrate different types of usage-based pricing models with your SaaS product.”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/billing.md # Billing Create and manage subscriptions, track usage, and issue invoices. …”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Recurly~partialclaimed6/10

   Docs confirm a documented API for changing subscriptions (upgrade/downgrade, quantity/price, add-ons) with official client libraries in 7 languages, supporting programmatic subscription management. However, the evidence never explicitly documents 'create' or 'pause'/'cancel' endpoints—only mid-cycle change operations are detailed, so full lifecycle coverage is inferred rather than shown directly. Missing for 10: explicit documentation of subscription creation and cancellation/pause API calls, and any hands-on developer confirmation of the full lifecycle working end-to-end via API alone.

   • [claimed-docs] “Recurly gives you full control over how and when subscription changes take effect. Upgrade or downgrade a plan, adjust quantity or price, ad…”
   • [claimed-docs] “Recurly bills only the difference during an immediate change when the underlying plan is unchanged.”
   • [claimed-docs] “Official Client Libraries ### Ruby ... ### Node.js ... ### Python ... ### Dotnet ... ### Java ... ### PHP ... ### Go”

   proof ↗⚑ flag

Lifecycle events

1. developerEvery subscription state change — renewal, upgrade, payment failure, cancellation — emits a webhook or event my systems can act on reliably

   weight 2 · round to Stripe Billing
   Stripe Billing~partialclaimed7/10

   Docs confirm Stripe pushes real-time webhook events for account changes (stripe-billing-docs-16) and describe automated retry logic for failed payments (stripe-billing-docs-5/6), supporting reliable notification of key lifecycle changes like renewals and payment failures. However, the pack lacks explicit documentation enumerating specific event types for upgrades/downgrades/cancellations or delivery-guarantee details (retries, signing, idempotency) tied directly to subscription state transitions. Missing for 10: explicit list of subscription-lifecycle event types (e.g., customer.subscription.updated/deleted), and evidence of webhook delivery reliability guarantees.

   • [claimed-docs] “Stripe pushes real-time data to it when events happen in your Stripe account.”
   • [claimed-docs] “Smart Retries: Automatically retry failed payments to prevent involuntary churn due to temporary issues.”
   • [claimed-docs] “Stripe Billing can automatically retry failed subscription and invoice payments for you.”

   proof ↗⚑ flag

   Recurly—none0/10

   The evidence pack contains no documentation of Recurly's webhook or event system for subscription lifecycle changes (renewal, upgrade, payment failure, cancellation). The only indirect mention is a community comment noting dunning emails work 'without needing to implement webhooks,' which implies webhooks exist as an option but provides no detail on reliability, event types, or delivery guarantees.

   • [community] “Comparing Stripe and Recurly: It's faster to get going with Stripe (no merchant account required) but Recurly appears to offer more automate…”

   proof ↗⚑ flag

Self serve

1. founderMy customers can upgrade, downgrade, or cancel themselves through a hosted portal or embeddable components, without a support ticket

   weight 2 · round to Stripe Billing
   Stripe Billing✓fullcommunity8/10

   Stripe docs explicitly describe a hosted Customer Portal that lets customers manage their own accounts (upgrade/downgrade/cancel) with Dashboard-based activation and branding, directly addressing self-service without support tickets. Community evidence corroborates the portal exists though notes some confusion over what's included and general pricing/product complaints unrelated to portal functionality itself. Missing for 10: independent hands-on report specifically confirming self-serve upgrade/downgrade/cancel flows work smoothly in production, and no mention of embeddable pricing-table/components for the same use case.

   • [claimed-docs] “Give your customers the ability to manage their account by setting up a customer portal.”
   • [claimed-docs] “Use the Dashboard to activate the customer portal and optionally customize branding and prefill customer email addresses.”
   • [community] “Confusion among users about what Stripe Billing actually includes: 'I thought Stripe Billing referred to the Customer Portal functionality a…”

   proof ↗⚑ flag

   Recurly~partialclaimed5/10

   Docs confirm customers can change plans (upgrade/downgrade, add-ons, proration) via Recurly's subscription APIs, implying self-service capability, but no direct evidence of a hosted customer portal or embeddable UI components for self-cancel/upgrade, nor explicit mention of eliminating support tickets. missing for 10: explicit hosted portal documentation, embeddable component/widget evidence, self-service cancellation flow.

   • [claimed-docs] “Recurly gives you full control over how and when subscription changes take effect. Upgrade or downgrade a plan, adjust quantity or price, ad…”
   • [claimed-docs] “Recurly bills only the difference during an immediate change when the underlying plan is unchanged.”

   proof ↗⚑ flag

Trials promos

1. ops userRun free trials, coupons, and promotion codes with automatic conversion to paid — including trial-end notifications required by card-network rules

   weight 2 · round to Stripe Billing
   Stripe Billing~partialcommunity4/10

   Docs confirm a Trial Offer API for free/paid trial periods and subscription automation (stripe-billing-docs-14, stripe-billing-docs-2), and community notes that Stripe emails (e.g., card update notices) are off by default and merchants can use webhooks instead (stripe-billing-comm-7), implying trial-end reminders aren't automatic out-of-the-box. No evidence pack items mention coupons or promotion codes specifically, nor explicit trial-end notification features required by card-network rules. missing for 10: coupon/promotion-code documentation, explicit trial-end notification/reminder feature docs, evidence of automatic trial-to-paid conversion flow, and confirmation of card-network compliance requirements being met.

   • [claimed-docs] “Use the Trial Offer API to manage both free and paid introductory periods for your subscriptions with a single API integration.”
   • [claimed-docs] “Create a new subscription in the Dashboard or with the Subscriptions API.”
   • [community] “Stripe Billing PM stated all customer emails (like credit card update notices) are off by default, matching behavior of other Stripe emails,…”

   proof ↗⚑ flag

   Recurly—none0/10

   The evidence pack contains no documentation of free trials, coupons/promotion codes, automatic trial-to-paid conversion, or card-network-mandated trial-end notifications. Related dunning/involuntary-churn features are covered, but none address trial or coupon lifecycle specifically. missing for 10: docs on free trial setup, coupon/promo code creation, automatic trial conversion, and trial-end notification compliance.

   ⚑ flag

Event ingestion

1. developerStream high-volume usage events — API calls, tokens, compute-seconds — into a metering pipeline with idempotent ingestion and backdating support

   weight 3 · round to Recurly
   Stripe Billing~partialclaimed2/10

   The evidence only shows generic usage-based subscription pricing support (stripe-billing-docs-3) with no documentation of a dedicated meter/usage-events API, idempotency keys, backdating of events, or high-volume streaming ingestion mechanics. Missing for 10: explicit meter events API docs, idempotent ingestion mechanism details, backdating/timestamp support evidence, high-volume throughput claims or benchmarks.

   • [claimed-docs] “you can set up and integrate different types of usage-based pricing models with your SaaS product.”

   proof ↗⚑ flag

   Recurly~partialclaimed3/10

   Recurly documents usage-based billing where usage-based add-ons are reported and billed at the end of a cycle (recurly-docs-3, recurly-docs-4), showing basic support for metering usage into billing, but there is no evidence of a high-volume streaming ingestion API, idempotency keys/idempotent ingestion, or explicit backdating support for usage events. Missing for 10: evidence of a streaming/bulk usage ingestion endpoint, documented idempotency guarantees for usage events, and backdating/timestamp-adjustment support for late-arriving usage records.

   • [claimed-docs] “Recurly's usage-based billing model lets you charge customers at the end of each billing cycle based on their actual consumption”
   • [claimed-docs] “Measured units describe the usage tracked by a usage-based add-on and enable consistent reporting across multiple add-ons and plans.”

   proof ↗⚑ flag

Pricing models

1. finance leadPrice with tiered, volume, graduated, per-unit, and hybrid subscription-plus-usage models — including credits, commitments, and overage — without custom code

   weight 3 · round drawn
   Stripe Billing~partialcommunity5/10

   Docs confirm Stripe Billing supports usage-based subscription pricing and custom pricing plans without code (stripe-billing-docs-1, stripe-billing-docs-3), and community corroborates per-user/per-usage/per-tier models (stripe-billing-comm-1). However, the evidence never explicitly documents tiered, volume, graduated, or per-unit pricing structures, nor credits, commitments, or overage billing mechanics as named capabilities. Missing for 10: explicit documentation of tiered/volume/graduated/per-unit price types, credits and commitment/overage billing constructs, and any hands-on confirmation these can be combined without custom code.

   • [claimed-docs] “Use Stripe Billing to manage subscriptions and invoicing. It automates recurring payments, creates custom pricing plans, and handles billing…”
   • [claimed-docs] “you can set up and integrate different types of usage-based pricing models with your SaaS product.”
   • [community] “Stripe Billing supports per-user, per-usage, and per-tier subscription models in an automated recurring billing fashion, covering the 3 stan…”

   proof ↗⚑ flag

   Recurly~partialclaimed5/10

   Recurly's docs confirm usage-based billing with measured units and flexible subscription/add-on changes (recurly-docs-1, recurly-docs-3, recurly-docs-4), which supports basic per-unit and subscription-plus-usage hybrid billing without code. However, the evidence never explicitly documents tiered, volume, or graduated pricing structures, nor named 'commitment' or 'overage' billing mechanics as configurable models. missing for 10: explicit tiered/volume/graduated pricing tier configuration docs, explicit commitment and overage billing mechanics, independent confirmation these complex pricing combos work without custom code.

   • [claimed-docs] “Recurly gives you full control over how and when subscription changes take effect. Upgrade or downgrade a plan, adjust quantity or price, ad…”
   • [claimed-docs] “Recurly's usage-based billing model lets you charge customers at the end of each billing cycle based on their actual consumption”
   • [claimed-docs] “Measured units describe the usage tracked by a usage-based add-on and enable consistent reporting across multiple add-ons and plans.”
   • [claimed-docs] “Credit invoices give every credit its own distinct invoice — separate from charge invoices.”

   proof ↗⚑ flag

Usage visibility

1. ops userCustomers and my team can see current-cycle usage and accrued cost in real time, with thresholds and alerts before an invoice surprises anyone

   weight 2 · round drawn
   Stripe Billing—none0/10

   Evidence covers usage-based pricing setup, proration previews, and subscription analytics, but there is no mention of real-time usage dashboards for customers/team, configurable usage thresholds, or proactive alerts before invoicing. missing for 10: real-time usage/cost visibility for customers and team, threshold configuration, proactive alerting before invoice generation.

   • [claimed-docs] “you can set up and integrate different types of usage-based pricing models with your SaaS product.”
   • [claimed-docs] “Monitor overall performance at a glance”

   proof ↗⚑ flag

   Recurly—none0/10

   Recurly's docs mention usage-based billing that charges at the end of the billing cycle and 'measured units' for reporting, but there is no evidence of real-time current-cycle usage/cost dashboards, customer-facing usage views, or threshold/alert mechanisms to warn before an invoice is generated.

   • [claimed-docs] “Recurly's usage-based billing model lets you charge customers at the end of each billing cycle based on their actual consumption”
   • [claimed-docs] “Measured units describe the usage tracked by a usage-based add-on and enable consistent reporting across multiple add-ons and plans.”

   proof ↗⚑ flag