Stripe Billing vs RevenueCat

Agent access

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

   weight 2 · round to Stripe Billing
   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

   RevenueCat✓fullprobed8/10

   RevenueCat serves a live llms.txt (HTTP 200) describing itself in agent-friendly terms, and docs pages throughout the evidence pack use the .md suffix convention (agent-oriented docs format) confirming machine-readable documentation exists. missing for 10: no root docs.md index (404) and no OpenAPI spec discoverable, which would round out full agentic documentation coverage.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.revenuecat.com/llms.txt # RevenueCat > RevenueCat is the App Monetization OS for mobile and web app…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.revenuecat.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”

   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

   RevenueCat~partialclaimed5/10

   RevenueCat exposes a REST API authenticated via API keys and supports server-side data import/export (revenuecat-docs-5, revenuecat-docs-4, revenuecat-docs-7), which enables non-interactive, programmatic use suitable for automation pipelines. However, there is no explicit documentation of CI/CD integration, headless test runners, or scripted deployment workflows. Missing for 10: explicit CI/CD examples, headless SDK testing guidance, and confirmation of non-interactive automation use cases.

   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “Importing existing purchase data to RevenueCat can be done server-side, or client-side.”
   • [claimed-docs] “RevenueCat delivers your apps' data to a cloud storage provider or to email on a schedule you control.”

   proof ↗⚑ flag

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

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

   RevenueCat✓fullclaimed8/10

   RevenueCat documents an official MCP server that lets AI assistants manage subscription apps, Products, Entitlements, etc. directly, without the dashboard, which directly satisfies the story. Missing for 10: independent/hands-on third-party corroboration of the MCP server working, and technical setup/auth details beyond the docs summary.

   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”

   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

   RevenueCat—none0/10

   No evidence pack item describes a dedicated official CLI tool; the closest items are an MCP server (revenuecat-docs-9), an AI toolkit doc (revenuecat-docs-8), and a natural-language analytics assistant 'Rico' (revenuecat-docs-10), none of which are described as a command-line interface. Missing for 10: explicit CLI product/documentation, installation instructions, command reference, or community confirmation of CLI usage.

   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”

   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

   RevenueCat~partialprobed6/10

   RevenueCat confirms a REST API secured by API keys (revenuecat-docs-5) and even offers an MCP server letting AI assistants manage subscriptions programmatically (revenuecat-docs-9) and an AI toolkit (revenuecat-docs-8), showing real support for AI-driven API access. However, probes for a public OpenAPI/swagger spec or docs.md all 404 (revenuecat-probe-2, revenuecat-probe-3), so a fully documented, discoverable public API reference isn't evidenced. Missing for 10: a published OpenAPI/API reference spec, broader REST endpoint documentation beyond auth, and independent confirmation of programmatic API usage outside RevenueCat's own docs.

   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.revenuecat.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”

   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

   RevenueCat—none0/10

   Evidence shows RevenueCat uses API keys for authentication (revenuecat-docs-5) and has an MCP server/AI toolkit for agents (revenuecat-docs-8, revenuecat-docs-9), but nothing describes scoped, granular, or least-privilege API key permissions for agents — no mention of read-only keys, role-based scopes, or key restriction settings.

   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   RevenueCat✓fullclaimed8/10

   RevenueCat ships official native SDKs (iOS, and implied Android/cross-platform per GitHub repo) with well-documented capabilities—purchases, entitlements, customer info, authentication—that developers, including AI-native ones, can build against directly, and this is corroborated by both first-party GitHub repos and extensive docs. Missing for 10: independent hands-on developer corroboration specifically praising SDK integration ergonomics, and explicit multi-platform SDK breadth beyond iOS in the evidence pack.

   • [github] “Fetch products, make purchases, and check subscription status with our native SDKs.”
   • [claimed-docs] “Entitlements are used to ensure a user has appropriate access to content based on their purchases, without having to manage all of the produ…”
   • [claimed-docs] “The CustomerInfo object contains all of the purchase and subscription data available about a customer.”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   RevenueCat✓fullclaimed7/10

   RevenueCat explicitly documents webhooks for real-time event notifications, letting external systems (including AI agents) subscribe to subscription/purchase events. Missing for 10: no first-party docs on webhook payload schema/customization or independent hands-on confirmation of reliability, and no mention of AI-specific webhook consumption patterns.

   • [github] “Get notified of real-time events through webhooks.”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”

   proof ↗⚑ flag

Agentic features

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

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

   RevenueCat✓fullclaimed8/10

   RevenueCat's Rico feature explicitly lets users ask plain-language questions about their data (e.g. "Why did MRR drop in Germany last week?") and get AI-driven insights, directly matching the story; charts/metrics dashboard provides the underlying data surface. Missing for 10: independent/hands-on validation of Rico's insight quality and broader coverage beyond the single documented example.

   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”
   • [claimed-docs] “RevenueCat charts allow you to understand your user base with key subscription specific metrics, filters, and segments.”

   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

   RevenueCat~partialclaimed3/10

   RevenueCat offers webhooks for real-time event notifications and scheduled data exports that run on a set cadence, which are background automations, but these are infrastructure features rather than AI-driven autonomous agentic workflows. The MCP server and AI toolkit let AI assistants configure or query RevenueCat interactively, not run persistent background automations. Missing for 10: evidence of AI agents autonomously triggering actions or workflows in the background without human initiation, scheduling/orchestration of agentic tasks, or any first-party 'automation builder' feature.

   • [github] “Get notified of real-time events through webhooks.”
   • [claimed-docs] “RevenueCat delivers your apps' data to a cloud storage provider or to email on a schedule you control.”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”

   proof ↗⚑ flag

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

   weight 3 · round to RevenueCat
   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

   RevenueCat~partialclaimed5/10

   RevenueCat documents "Rico", a built-in AI assistant in the dashboard that lets users ask plain-language questions about their data instead of digging through charts (revenuecat-docs-10). This shows a built-in assistant capability, but evidence only covers Q&A/insight generation, not broader task delegation or action-taking within the product, and there's no independent/community corroboration of its real-world reliability. Missing for 10: evidence of Rico performing actions/tasks beyond answering questions, and independent user reports validating its usefulness.

   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”

   proof ↗⚑ flag

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

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

   RevenueCat~partialclaimed6/10

   RevenueCat offers an MCP server letting AI assistants manage products/entitlements via natural language, and Rico allows plain-language analytics queries — both first-party docs confirm agentic/NL control of the dashboard. However, this covers admin/analytics operations, not the core end-user subscription flows, and there's no independent/hands-on corroboration of these NL features working reliably. Missing for 10: third-party validation of MCP/Rico usage, broader coverage of NL control across all product surfaces (not just admin tasks).

   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”

   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

   RevenueCat—none0/10

   No evidence of an interactive API reference or runnable examples; probes for openapi/swagger specs and docs.md return 404, and no documentation item describes a try-it-out console or embedded runnable code samples.

   • [probe] “PROBE docs-md: HTTP 404 at https://www.revenuecat.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”

   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

   RevenueCat—none0/10

   RevenueCat exposes a REST API (per revenuecat-docs-5) but no evidence of a downloadable OpenAPI/Swagger spec; the probe explicitly found all standard OpenAPI spec paths return 404, and no docs reference a machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”

   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

   RevenueCat—none0/10

   The evidence pack contains no mention of a sandbox/test mode, test API keys, or any mechanism to validate purchases/subscriptions without affecting production data—only production-oriented SDK, dashboard, and AI-toolkit/MCP features are described.

   ⚑ 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

   RevenueCat—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes returned 404s and no docs mention version lifecycle or deprecation commitments.

   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”
   • [probe] “PROBE docs-md: HTTP 404 at https://www.revenuecat.com/docs.md”

   proof ↗⚑ 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

   RevenueCat—none0/10

   The evidence shows RevenueCat's MCP server and AI toolkit let an AI assistant manage individual Products, Entitlements, and Offerings, and server-side import of existing purchase data exists, but nothing describes batch/bulk operations across many items at once (e.g., bulk-editing many products, mass customer updates, or batch API calls) for an AI-native workflow. Missing for full credit: explicit bulk/batch API endpoints, documentation of bulk operations via MCP/AI toolkit, and any example of operating on many items simultaneously.

   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”
   • [claimed-docs] “Importing existing purchase data to RevenueCat can be done server-side, or client-side.”

   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

   RevenueCat~partialcommunity4/10

   RevenueCat offers webhooks for real-time event notifications (revenuecat-gh-3) that can be wired to trigger external actions, but there's no built-in rule engine to define conditional logic or automated actions natively within RevenueCat itself. A community feature request explicitly asks for 'timed hooks' like trial-expiry reminders, indicating this kind of automation isn't natively supported (revenuecat-comm-6). Missing for 10: native rule/trigger builder, conditional logic definitions, in-product automated actions beyond raw webhook delivery.

   • [github] “Get notified of real-time events through webhooks.”
   • [community] “Feature request: handling timed hooks to send notifications, e.g. reminding users before a trial expires and subscription cancels.”

   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

   RevenueCat~partialclaimed3/10

   RevenueCat supports scheduled recurring data exports to cloud storage/email, which is a narrow instance of a recurring job, but there is no evidence of a general-purpose scheduler for recurring workflows or automations (e.g., via MCP/AI toolkit) that an AI-native user could configure. missing for 10: evidence of configurable recurring workflow/job scheduling beyond data exports, integration of scheduling with the MCP/AI toolkit or Rico assistant, and any cron-like automation API.

   • [claimed-docs] “RevenueCat delivers your apps' data to a cloud storage provider or to email on a schedule you control.”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”

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

   RevenueCat~partialclaimed6/10

   RevenueCat ships an MCP server explicitly for AI assistants to manage subscription apps, Products, Entitlements, and Offerings (revenuecat-docs-9), backed by a REST API authenticated via scoped API keys (revenuecat-docs-5), and SDK/dashboard features let you grant promotional subscriptions and view customer transaction histories (revenuecat-gh-4). However, the evidence centers on catalog/config management (products, entitlements, offerings) rather than explicit end-user billing actions like 'create a subscription', 'apply a credit', or 'change a plan' for a specific customer, and there's no documentation of granular per-action permission scoping beyond generic API keys. Missing for 10: explicit agent-driven customer-level actions (create subscription, apply credit, change plan) and detailed scoped-permission/role model for agent access.

   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [github] “See customer transaction histories, chart lifetime value, and grant promotional subscriptions.”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”

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

   RevenueCat~partialclaimed6/10

   RevenueCat's Rico assistant explicitly lets users ask plain-language billing questions like 'why did MRR drop,' and the MCP server/CustomerInfo API expose subscription and customer purchase data programmatically, showing agent-queryable billing state. However, there's no explicit evidence for querying delinquent accounts, upcoming renewals, or per-customer invoice histories via an agent interface. Missing for 10: documented support for delinquency/renewal queries, invoice-level querying, and independent confirmation of Rico's accuracy/scope beyond MRR examples.

   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “The CustomerInfo object contains all of the purchase and subscription data available about a customer.”
   • [claimed-docs] “RevenueCat charts allow you to understand your user base with key subscription specific metrics, filters, and segments.”
   • [github] “See customer transaction histories, chart lifetime value, and grant promotional subscriptions.”

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

   RevenueCat—none0/10

   No evidence pack items mention billing anchor/cycle controls, calendar vs anniversary billing alignment, or custom invoice dates — RevenueCat's documented features focus on entitlements, purchases, offerings, and analytics, not invoice/billing-cycle configuration.

   ⚑ 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 to Stripe Billing
   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

   RevenueCat—none0/10

   No evidence addresses proration math, credits, partial-period calculations, or invoice line-item reconciliation; documentation covers entitlements, SDKs, paywalls, and dashboards but nothing about auditable billing math for upgrades/downgrades.

   ⚑ 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 Stripe Billing
   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

   RevenueCat—none0/10

   RevenueCat's evidence covers subscription management, entitlements, paywalls, MCP/AI tools, and analytics, but nothing addresses card-level dunning recovery mechanics like network account updater, backup payment methods, or hosted update-payment pages — these are Stripe/payment-processor-level features that RevenueCat, as an app-store/subscription management layer, does not document handling itself.

   ⚑ 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 Stripe Billing
   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

   RevenueCat—none0/10

   The evidence pack shows RevenueCat's core subscription infrastructure (entitlements, offerings, paywalls, webhooks, exports) but contains no mention of dunning-specific features like branded recovery emails, in-app banners, configurable grace periods, or cancel-vs-unpaid final-state rules. A community comment even requests exactly this kind of timed-notification/dunning hook as a missing feature, reinforcing the absence of evidence for it.

   • [community] “Feature request: handling timed hooks to send notifications, e.g. reminding users before a trial expires and subscription cancels.”
   • [claimed-docs] “Paywalls — Remotely configure your product offering with powerful paywalls.”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”

   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

   RevenueCat—none0/10

   No evidence in the pack mentions failed payment retry logic, dunning, billing recovery, or ML/schedule-optimized retry cadences; RevenueCat evidence covers entitlements, paywalls, SDKs, analytics, and AI tools but nothing about involuntary churn recovery.

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

   RevenueCat✓fullclaimed8/10

   Docs confirm entitlements model access based on purchases without hardcoding product identifiers, and CustomerInfo (via SDK/API, authenticated by API keys) exposes purchase/entitlement data at runtime. This directly matches the story of entitlements attached to plans checked at runtime via SDK/API. Missing for 10: explicit code snippet showing an entitlement check call and independent/hands-on developer confirmation of the runtime check pattern.

   • [claimed-docs] “Entitlements are used to ensure a user has appropriate access to content based on their purchases, without having to manage all of the produ…”
   • [claimed-docs] “The CustomerInfo object contains all of the purchase and subscription data available about a customer.”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [github] “Fetch products, make purchases, and check subscription status with our native SDKs.”

   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

   RevenueCat—none0/10

   While RevenueCat's Offerings/Packages system (revenuecat-docs-8) implies some product versioning, there is no evidence of price-specific grandfathering, versioned pricing plans, or bulk cohort migration tools; the only 'migration' documentation (revenuecat-docs-4) concerns importing existing purchase data when onboarding to RevenueCat, not moving cohorts between price tiers post-launch. This is a fair capability to expect from a subscription billing platform, so the axis applies, but no concrete evidence supports it.

   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”
   • [claimed-docs] “Importing existing purchase data to RevenueCat can be done server-side, or client-side.”

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

   RevenueCat—none0/10

   No evidence RevenueCat generates compliant invoices, credit notes, or receipts with sequential numbering, custom fields, or memos; evidence covers subscription management, entitlements, paywalls, and analytics only.

   ⚑ 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

   RevenueCat—none0/10

   No evidence describes local-currency price points, per-currency pricing configuration, or consolidated home-currency reporting; the evidence pack covers entitlements, paywalls, SDKs, MCP tools, and dashboards but nothing about multi-currency billing or currency-consolidated financial reports.

   ⚑ 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

   RevenueCat—none0/10

   No evidence RevenueCat calculates or manages sales tax, VAT, or GST, nor any mention of tax registrations, rates, or a tax integration; RevenueCat's role for App Store/Play purchases means Apple/Google handle tax, and no tax-handling capability is documented for its own billing (e.g., Stripe-side) invoicing.

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

   RevenueCat~partialcommunity4/10

   RevenueCat offers scheduled data exports to cloud storage/email and REST API access to customer/subscription data (docs-7, docs-5, docs-3), which covers some of the 'export subscriptions/customer records' need. However, there is no evidence of invoice-level or usage-record export, and no mention anywhere of porting stored payment methods to another provider — RevenueCat itself doesn't store card details (they live with Stripe/Apple/Google), so this key part of the story is unaddressed. Community discussion even flags that migrating subscriptions between providers is 'hard to make smooth' (revenuecat-comm-8), reinforcing the gap. Missing for 10: documented invoice/usage export, explicit payment-method portability/export mechanism, and confirmation of smooth cross-provider migration.

   • [claimed-docs] “RevenueCat delivers your apps' data to a cloud storage provider or to email on a schedule you control.”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “The CustomerInfo object contains all of the purchase and subscription data available about a customer.”
   • [community] “User considering migrating to RevenueCat asks whether it can handle users moving subscriptions between iOS/Android in-app purchases and Stri…”

   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

   RevenueCat~partialcommunity4/10

   RevenueCat explicitly documents importing existing purchase/subscription data 'server-side or client-side' when migrating to the platform, which supports the core migration story, but there is no evidence describing spreadsheet-based import, PCI-compliant card data transfer, or explicit guarantees that migration is invisible to end customers. Community comments (revenuecat-comm-8, revenuecat-comm-3) show users actively wondering whether smooth cross-platform migration (App Store/Stripe) is even possible, indicating this remains an open question rather than a proven capability. missing for 10: PCI-compliant card data transfer mechanics, spreadsheet import tooling, documented zero-customer-disruption guarantee, and independent confirmation of smooth migration.

   • [claimed-docs] “Importing existing purchase data to RevenueCat can be done server-side, or client-side.”
   • [community] “User considering migrating to RevenueCat asks whether it can handle users moving subscriptions between iOS/Android in-app purchases and Stri…”
   • [community] “"Man I wish this existed 8 months ago when I built our own version internally! We have a mix of Stripe and App Store customers so we'll defi…”

   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

   RevenueCat~partialprobed6/10

   RevenueCat documents a REST API/authentication (revenuecat-docs-5), an MCP server that lets AI assistants manage apps, Products, Entitlements 'without using the RevenueCat dashboard' (revenuecat-docs-9), and an AI toolkit for setting up subscriptions, offerings, and packages (revenuecat-docs-8), showing strong API parity for core configuration tasks. However, no OpenAPI spec was discoverable (revenuecat-probe-3) and UI-centric features like paywall design, charts, and dashboard-and-metrics exploration appear tied to the dashboard or scheduled exports rather than full API control (revenuecat-docs-6, revenuecat-docs-7, revenuecat-docs-11). Missing for 10: publicly documented OpenAPI/full REST API reference, evidence that paywall building/analytics dashboards are fully API-accessible, and independent confirmation of complete UI-API parity.

   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “RevenueCat charts allow you to understand your user base with key subscription specific metrics, filters, and segments.”
   • [claimed-docs] “Paywalls — Remotely configure your product offering with powerful paywalls.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”

   proof ↗⚑ flag

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

   weight 3 · round to RevenueCat
   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

   RevenueCat~partialprobed4/10

   RevenueCat does support scheduled data exports to cloud storage/email and a REST API for programmatic access to customer/subscription data, giving some data portability. However, there's no documented comprehensive 'export all your data and leave' feature, no explicit open-format full account export, and no OpenAPI spec found (probe returned 404s). Missing for 10: a documented full-account data export/deletion workflow, explicit open-format guarantees, and confirmation of a public OpenAPI/schema for complete data extraction.

   • [claimed-docs] “RevenueCat delivers your apps' data to a cloud storage provider or to email on a schedule you control.”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”

   proof ↗⚑ flag

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

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

   RevenueCat~partialclaimed3/10

   RevenueCat publishes open-source client SDKs on GitHub (e.g., purchases-ios) showing feature code, but the evidence never states a specific open-source license nor shows the core backend/platform source, which remains a closed SaaS product. missing for 10: explicit license statement, evidence of core platform/service source being open, independent confirmation of license terms.

   • [github] “Fetch products, make purchases, and check subscription status with our native SDKs.”
   • [github] “Host and configure products remotely from our dashboard.”
   • [github] “Get notified of real-time events through webhooks.”
   • [github] “See customer transaction histories, chart lifetime value, and grant promotional subscriptions.”

   proof ↗⚑ 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

   RevenueCat—none0/10

   RevenueCat is delivered purely as a hosted SaaS platform (dashboard, cloud APIs, webhooks, MCP server) with no mention of an on-premises or self-hosted deployment option anywhere in the evidence pack; community discussion even treats it as an external service to 'switch to' rather than something to run locally. Missing for 10: any documentation of self-hosted/on-prem deployment, open-source core, or Docker/Kubernetes packaging.

   • [probe] “PROBE llms.txt: HTTP 200 at https://www.revenuecat.com/llms.txt # RevenueCat > RevenueCat is the App Monetization OS for mobile and web app…”
   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [community] “User asks why use RevenueCat over Stripe, which is developer-friendly, robust, and unlikely to disappear.”

   proof ↗⚑ 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

   RevenueCat—none0/10

   No evidence of data residency/region selection controls in RevenueCat's docs, GitHub, or community sources; nothing addresses where customer/subscription data is stored or region choice.

   ⚑ 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

   RevenueCat—none0/10

   No evidence describes data retention policies, deletion controls, or GDPR/CCPA-style data management features for RevenueCat customers or end-users; evidence covers subscription management, entitlements, dashboards, and AI tooling only.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Stripe Billing—none0/10

   Stripe Billing is a payments/subscription platform, not a developer tool with telemetry collection concerns, but no evidence addresses any telemetry/usage-tracking opt-out mechanism for AI-native users interacting with its API, CLI, or MCP server; the evidence pack contains no mention of telemetry at all.

   ⚑ flag

   RevenueCat—none0/10

   No evidence pack item addresses telemetry/usage-tracking opt-out settings for RevenueCat itself; the axis is applicable since RevenueCat is a SaaS platform/SDK that could plausibly document such controls, but nothing here does.

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

   RevenueCat~partialclaimed6/10

   RevenueCat's dashboard/charts and Rico assistant explicitly surface MRR and LTV computed directly from subscription/billing events (revenuecat-docs-6, revenuecat-docs-10, revenuecat-gh-4), and scheduled exports let founders pull this data (revenuecat-docs-7), all sourced from the billing data rather than a bolted-on BI tool. However, the evidence pack never explicitly mentions churn metrics or cohort retention analysis by name, so the story's full metric set isn't documented. Missing for 10: explicit churn-rate analytics, explicit cohort retention analytics/reporting.

   • [claimed-docs] “RevenueCat charts allow you to understand your user base with key subscription specific metrics, filters, and segments.”
   • [claimed-docs] “Instead of digging through charts and tables yourself, you can ask Rico plain-language questions like "Why did MRR drop in Germany last week…”
   • [github] “See customer transaction histories, chart lifetime value, and grant promotional subscriptions.”
   • [claimed-docs] “RevenueCat delivers your apps' data to a cloud storage provider or to email on a schedule you control.”

   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

   RevenueCat—none0/10

   Evidence shows RevenueCat offers scheduled data exports to cloud storage/email and webhooks, but nothing about direct sync of invoices, payments, or revenue recognition entries into QuickBooks, Xero, or NetSuite ERPs.

   ⚑ 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

   RevenueCat—none0/10

   Evidence covers subscription SDKs, entitlements, charts, and data exports, but nothing addresses ASC 606/IFRS 15 deferred revenue schedules or audit-ready recognition reporting. Missing for 10: any mention of deferred revenue calculation, revenue recognition compliance, or audit-ready financial reports.

   ⚑ 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

   RevenueCat~partialprobed4/10

   RevenueCat exposes API-based mechanisms for parts of subscription management (granting promotional subscriptions via API/dashboard, managing Products/Entitlements/Offerings via the AI toolkit and MCP server 'without using the dashboard'), and confirms REST API authentication exists. However, there's no direct evidence of documented endpoints to create, update, pause, or cancel a live subscription's lifecycle end-to-end, and a probe for OpenAPI/swagger docs returned 404s, suggesting the full API surface isn't publicly documented in this pack. missing for 10: explicit API endpoints for pause/cancel/update, a discoverable OpenAPI spec, and confirmation that full lifecycle actions (not just entitlement grants/catalog config) can be done purely via API.

   • [claimed-docs] “RevenueCat authenticates requests from the RevenueCat SDK and the REST API using API keys.”
   • [claimed-docs] “Set up subscriptions, including projects, apps, Products, Entitlements, Offerings, and Packages”
   • [claimed-docs] “The RevenueCat MCP (Model Context Protocol) server enables AI assistants to manage subscription apps, Products, Entitlements, and everything…”
   • [github] “See customer transaction histories, chart lifetime value, and grant promotional subscriptions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://www.revenuecat.com/openapi.json, https://www.revenuecat.com/swagger.json, https://www.revenu…”

   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

   RevenueCat~partialcommunity5/10

   RevenueCat explicitly advertises real-time webhook events (revenuecat-gh-3) and dashboard/customer-info data on subscription state (revenuecat-docs-3), supporting the general claim that lifecycle changes are exposed as events. However, the evidence pack lacks detail on which specific lifecycle events (renewal, upgrade, payment failure, cancellation) are covered, delivery guarantees/retries, or reliability at scale, and a community request for additional timed hooks (revenuecat-comm-6) suggests some lifecycle notifications are still missing today. Missing for 10: documented list of webhook event types, delivery/retry guarantees, and evidence of reliability under real-world load.

   • [github] “Get notified of real-time events through webhooks.”
   • [claimed-docs] “The CustomerInfo object contains all of the purchase and subscription data available about a customer.”
   • [community] “Feature request: handling timed hooks to send notifications, e.g. reminding users before a trial expires and subscription cancels.”

   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

   RevenueCat—none0/10

   The evidence covers RevenueCat's SDKs, entitlements, paywalls, and dashboard analytics, but nothing describes a hosted customer portal or embeddable UI components letting end customers upgrade/downgrade/cancel without a support ticket. Community threads even discuss the difficulty of managing cross-platform (iOS/Android/Stripe) subscription moves, but no resolution or feature is cited that gives self-service cancellation/upgrade capability.

   • [claimed-docs] “Paywalls — Remotely configure your product offering with powerful paywalls.”
   • [community] “User considering migrating to RevenueCat asks whether it can handle users moving subscriptions between iOS/Android in-app purchases and Stri…”
   • [community] “Feature request: handling timed hooks to send notifications, e.g. reminding users before a trial expires and subscription cancels.”

   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

   RevenueCat~partialcommunity3/10

   RevenueCat supports free-trial eligibility checks, entitlements, and granting promotional subscriptions, and webhooks could be used to build custom trial-reminder logic, but there is no documented native coupon/promo-code management or built-in trial-end notification feature — in fact a community post explicitly requests this as a missing feature ('handling timed hooks to send notifications... reminding users before a trial expires'). missing for 10: native coupon/promo-code support, built-in trial-end notification delivery, card-network compliance documentation.

   • [claimed-docs] “The Purchases SDK allows for easy checking of eligibility for introductory offers on iOS, so that you as the developer can display the prope…”
   • [github] “See customer transaction histories, chart lifetime value, and grant promotional subscriptions.”
   • [github] “Get notified of real-time events through webhooks.”
   • [community] “Feature request: handling timed hooks to send notifications, e.g. reminding users before a trial expires and subscription cancels.”

   proof ↗⚑ 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 Stripe Billing
   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

   RevenueCat—none0/10

   RevenueCat is a subscription/purchase management platform focused on entitlements, offerings, and billing data — nothing in the evidence describes streaming high-volume usage events (API calls, tokens, compute-seconds) with idempotent ingestion or backdating support, which is a usage-based metering capability outside RevenueCat's documented scope.

   • [claimed-docs] “The CustomerInfo object contains all of the purchase and subscription data available about a customer.”
   • [claimed-docs] “Importing existing purchase data to RevenueCat can be done server-side, or client-side.”
   • [claimed-docs] “RevenueCat charts allow you to understand your user base with key subscription specific metrics, filters, and segments.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://www.revenuecat.com/llms.txt # RevenueCat > RevenueCat is the App Monetization OS for mobile and web app…”

   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 to Stripe Billing
   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

   RevenueCat—none0/10

   RevenueCat's evidence covers mobile subscription entitlements, offerings, paywalls, and analytics, but there is no mention of tiered/volume/graduated/per-unit pricing, usage-based billing, credits, commitments, or overage handling — the core usage-metering pricing models in the story are entirely absent.

   ⚑ 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

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