Skip to content
RevTurbine Docs

What Owns What

RevTurbine sits between your app and Stripe, and the single biggest question a technical evaluator has is “where does each piece of truth actually live?” Here’s the map.

The map

Section titled “The map”
ConcernRevTurbineYour appStripe
Plan catalog — which plans/tiers exist✅ Authoritative (the Playbook)—mirrors as products
Pricesmirror (UI helper)—✅ Authoritative
Subscription status — active / plan / canceledholds the server-derived plan and payment state (from Stripe webhooks) and delivers it to the SDK through the client sessionmay pass plan_handle as an optimistic override at the upgrade moment; supplies it always in local mode✅ Authoritative
Feature-access policy — what each plan entitles✅ Authoritative (entitlement rules)——
Usage countsevaluates them against limits✅ reports usage (rt.update)—
Checkout & paymentstarts it (a CTA opens checkout)hosts the flow✅ Processes payment
When to show a placement / upsell✅ Decides (decision engine)renders the <Slot>—
Billing-critical enforcement — actually granting a paid actionadvises (policy)✅ Enforces (server-side)—

Reading the map

Section titled “Reading the map”
  • RevTurbine owns policy, not money. The plan catalog, what each plan entitles, and when a placement shows are all RevTurbine’s — a PM edits them in the dashboard and releases, with no code deploy. RevTurbine never charges anyone.
  • Stripe owns money and subscription state. Prices, who is subscribed, and payment processing are Stripe’s. RevTurbine mirrors prices into the Playbook as a UI helper for rendering — but Stripe is the price authority. With Stripe connected, subscription webhooks update the customer’s plan and payment health on RevTurbine’s side and the SDK receives them through the client session — see Billing & Stripe. Your app can pass plan_handle in user context as an optimistic override (at the upgrade moment, before the webhook lands); in local mode it supplies the plan always.
  • Your app owns enforcement and usage. You report usage, you host checkout, and — critically — you enforce billing-critical actions on your server. See Client vs Server Enforcement.

What this buys you

Section titled “What this buys you”

Because your app only ever knows slots and entitlements — never plan names or prices hard-coded in code — cascading monetization changes stay out of your codebase. Launch a new plan, run a discount, restructure tiers: the catalog and policy change in RevTurbine, the numbers change in Stripe, and your app keeps rendering the same slots and checking the same entitlements. The first monetization strategy is never the last — and this split is what keeps your code from having to change every time it moves.

Section titled “Related”