> ## 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. # Model assumptions > The assumptions behind Recurr's public audit and docs: store fee rate, web-billing cost, migration cases, settlement timing, and what gets refined later. The public audit is designed to answer one question quickly: **is the migration opportunity large enough to justify a Migration Review?** It is not a full financial model. The Migration Review and Migration Analysis refine the inputs with your real store mix, plan mix, subscriber data, geography, and implementation constraints. ## Core assumptions | Input | Public audit baseline | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Store-fee rate | Your supplied blended rate, or 22% if unknown | | Migration cases | 40% conservative, 55% base, 70% optimistic | | Recurr platform fee | 3.5% on web-billed subscription revenue, flat (no Y1 step-up) | | Migration performance fee | 2.5% per migrated subscriber, tied to the Migration Program; lands across the first 12 months on web | | Stripe processing | Stripe's standard rates pass through — **2.9% + \$0.30 per transaction** in the US (varies by region and payment method) | | Average transaction (ARPU) | $17 baseline (50/50 mix of $10 monthly and \$100 annual) — sets the per-transaction flat-fee impact | | Cash-flow timing | 45 days of *net* migrated annualized revenue (ARR after store fees) pulled forward once | The model is intentionally simple. It is meant to show order of magnitude without forcing you through a data-room exercise before you know whether the opportunity is worth a conversation. ## Store-fee rate If you know your blended app-store fee rate, use it. If you do not, the audit uses **22%** as a representative blended rate across iOS year-one subscriptions, iOS year-two subscriptions, and Google Play subscriptions. Your Migration Analysis replaces this with the actual mix if you provide it. ## Web-billing cost Web billing has two cost layers, kept separate because they move differently and you control them differently. ### Recurr's fees * **Platform fee:** 3.5% on web-billed subscription revenue, flat — no Y1 step-up. Applies to every web-billed dollar. * **Migration performance fee:** 2.5% per subscriber migrated, tied to the Migration Program. Lands across each migrated subscriber's first 12 months on web. The audit treats this as an effective Year 1 cost so the recovery math nets it out. Recurr's combined Y1 take on a migrated subscriber is **6%**; Y2+ steady-state is **3.5%**. ### Stripe processing (pass-through) Stripe's standard rates: **2.9% + \$0.30 per transaction** in the US. Lower in EU/UK/AU (typically 1.5–1.7% + a local flat fee). Higher for some international card mixes and local payment methods. See [Stripe's pricing](https://stripe.com/pricing) for the full schedule. The per-transaction flat fee's impact on your **percentage basis** depends on average transaction size (ARPU). At the model's \$17 ARPU baseline, the flat fee adds **\~1.76 percentage points** to the Stripe percentage. Annual-heavy books (larger AOV) feel it less; small-ticket monthly-heavy books feel it more. ### Worked all-in (US baseline, \$17 ARPU) | Stage | Recurr | Stripe % | Flat-fee impact at \$17 AOV | All-in | | ---------------------- | ------------------------------ | -------- | --------------------------- | ------------ | | First 12 months on web | 6% (3.5% platform + 2.5% perf) | 2.9% | +1.76 pts | **\~10.66%** | | Year 2+ ongoing | 3.5% (platform only) | 2.9% | +1.76 pts | **\~8.16%** | EU/UK/AU run lower because Stripe processing is \~1.5–1.7% rather than \~2.9%, and local payment methods often have different (sometimes zero) flat fees. The [live audit](https://recurr.dev/audit) resolves your country-specific Stripe rate. International cards, low-ticket monthly plans, local payment methods, chargebacks, taxes, and currency conversion can move the exact payment-cost line. Those are Migration Review details, not reasons to block the first audit. ## Cash-flow release The audit models the one-time settlement benefit as **45 days of *net* migrated annualized revenue pulled forward** — your share after store fees, not the gross customer payment. Apple holds the gross GMV during settlement but only owes the developer the net. That equals roughly **12.3% of net migrated revenue**, once. At a 22% blended store-fee assumption, the conservative public rule of thumb is **\~9% of migrated ARR** (12.3% × 0.78). At the base 55% migration case and the same 22% assumption, that's roughly **5.3% of total ARR** as a cash-flow release. Your audit reports the specific figure using your actual blended rate — apps on lower blended fees see proportionally more cash because the discount is smaller. This is not P\&L lift. It is timing: revenue that would have arrived later under app-store settlement lands sooner through web billing. ## What the public audit does not model * Holdout-relative churn impact * Offer cost or incentive cost * Monthly vs annual transaction-count effects * International card mix and local payment-method mix * Subscriber-level renewal timing * Cohort-specific migration rates * Support load during migration waves Those inputs matter. They belong in the Migration Review and Migration Analysis, where the model can use the real app context instead of generic assumptions. [Run the audit](https://recurr.dev/audit) or [book the Migration Review](https://recurr.dev/apply).