Skip to main content

Documentation Index

Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

The migration is deliberately light on engineering for apps with a centralized entitlement source. This page maps what your team does, what stays untouched, and what to look at if you’re evaluating the technical risk surface.

​
Integration surface (one-time)

Total time for initial integration: 2–4 engineering hours, distributed across four steps:
1

OAuth / API key into your entitlement system

Recurr connects to RevenueCat / Adapty / your own backend. OAuth is preferred. The connection is read + write — Recurr reads subscriber state and writes web subscription records back into the same system.
2

Stripe Connect Standard onboarding

Stripe account in your company’s name. You complete Stripe’s standard onboarding (~30 min). Web payments settle directly to your account; Recurr takes its fee as an application_fee on each charge.
3

DNS CNAME for branded checkout

subscribe.yourdomain.com (or similar) → Recurr-hosted target. SSL + cert provisioning are automatic. Your DNS team ships this once.
4

Webhook subscription

Recurr sends webhooks back to your entitlement system on subscribe / renew / cancel / churn events. The framework’s webhook spec is documented; your system receives the standard events.

​
What’s not on your team’s roadmap

  • No SDK install. Nothing to embed in the mobile app.
  • No app release. The mobile app binary stays untouched.
  • No new auth flow. Apple Sign In + Google Sign In are first-class on the web checkout; subscribers use the same provider they had in-app.
  • No migration build on your side. Recurr operates the campaign, dashboards, webhooks, and analytics.
  • No password / account-recovery flows on your side. The framework handles identity continuity end-to-end.

​
Ongoing engineering load

1–2 hours per week during active migration, primarily reviewing wave performance and signing off the next cohort. Most of this is review + alignment, not code. Post-migration, near-zero. New web subscribers route through the same rails automatically. The webhook → entitlement flow is steady-state.

​
Security + data model

  • Stripe Connect Standard keeps the merchant account in your company’s name. You’re not relying on Recurr-as-merchant.
  • PCI compliance is handled by Stripe’s hosted card entry. Your subdomain never sees raw card data.
  • Entitlement data lives where it lived before — your existing RC / Adapty / custom backend remains the system of record.
  • Identity tokens for Apple Sign In + Google Sign In flow through Recurr’s OAuth apps to your entitlement system, mapped to the canonical subscriber identifier.
  • No customer data egresses beyond what’s necessary for the migration: subscriber email + entitlement state for cohort selection, plus the webhooks carrying subscription events. Specifics are scoped in the DPA inside the MSA.

​
Store-policy compliance

The migration runs entirely outside the app binary:
  • No in-app links to web pricing
  • No in-app buttons routing to external checkout
  • No in-app messaging about migration offers
  • No SDK that could be later interpreted as platform-policy-violating
Communications happen via email and your owned web surfaces. See Apple compliance, Google Play compliance, and EU DMA for the specifics.

​
Failure modes + recovery

  • Failed web payment — Stripe’s dunning runs automatically; the framework also surfaces failed-payment events to support
  • Subscriber asks for refund — your standard refund policy applies; Stripe issues the refund, Recurr fee is reversed pro-rata
  • Subscriber wants to revert to IAP — supported. The web subscription is canceled; the subscriber returns to Apple/Google billing through normal store re-subscription
  • You want to leave Recurr — Stripe Connect account is yours; entitlement data is yours; you continue with whatever billing setup you choose

​
Things worth flagging in the Migration Review

If your app has any of these, mention them in the call:
  • A custom auth system that doesn’t easily integrate via OAuth
  • A StoreKit-only setup with no backend or entitlement provider Recurr can write into
  • Tightly-coupled in-app messaging about subscriptions that would need updating
  • An anonymous-purchase flow without account creation
  • An existing Stripe integration that you want to preserve alongside the new Connect account
  • A pending App Store or Google Play submission with subscription-related changes
None of these are blockers — they’re context that adjusts the cohort spec or integration shape.