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

# For tech

> The CTO / engineering-lead lens: integration surface, ongoing burden, security model, and store-policy compliance.

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:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="DNS CNAME for branded checkout">
    `subscribe.yourdomain.com` (or similar) → Recurr-hosted target. SSL + cert provisioning are automatic. Your DNS team ships this once.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/compliance/apple), [Google Play compliance](/compliance/google-play), and [EU DMA](/compliance/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 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

None of these are blockers — they're context that adjusts the cohort spec or integration shape.