Integration surface (one-time)
Total time for initial integration: 2–4 engineering hours, distributed across four steps: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.
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.DNS CNAME for branded checkout
subscribe.yourdomain.com (or similar) → Recurr-hosted target. SSL + cert provisioning are automatic. Your DNS team ships this once.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
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 app-store billing — 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