Skip to main content
Existing web billing is usually a positive signal. It means the work changes from establishing a new rail to extending the rail you already have, then bringing app-store cohorts onto it over time.

​
Why it helps

Payment rail exists

Stripe or Paddle setup, payout flow, tax posture, and refund processes may already be in place.

Subscriber language exists

The brand may already know how to explain web billing, billing help, invoices, and account management.

Data model exists

Web subscriptions may already connect to analytics, finance, and access systems.

Oikos has a base

Oikos can run across the connected web book, not just newly migrated subscribers.

​
What changes with Recurr

Recurr does not ask you to abandon a working rail. The question becomes:
  • How should app-store cohorts move onto the existing rail?
  • What subscriber surfaces need to improve?
  • How does access continuity work for migrated subscribers?
  • How should ascension keep migrating new store cohorts as they mature?

​
Whole web-book model

Oikos runs on the connected web book. That keeps reporting, lifecycle logic, subscriber treatment, and billing operations consistent. If part of the web book is excluded, the operating layer loses context. That is why the standard model is not campaign-by-campaign or slice-by-slice.