Subscription Management
Appfunnel is the entitlement layer for your subscriptions: define your products once, map them to access levels, and check who has access from your own app, so a subscriber who paid on the web unlocks Pro inside the app through the same system.
Entitlements are the access levels your app actually checks. You name each product and the entitlement it grants; web checkouts and store subscriptions fold into one access state per customer; and the IdentitySDK lets your app ask “does this customer have Pro?” and branch. One source of truth for who paid, spanning your web funnel and your app. No separate receipt-validation to wire up.
Define your products once, use them everywhere
A subscription is only useful if your product knows what it unlocks. Define each product and the access it grants once, and let the funnel, the paywall, and your app all read the same catalog.
One product, one identity. Each product is a named slot in your catalog: its identifier, price, trial, and billing period defined once. The funnel and paywall only ever reference the slot, never a hard-coded SKU.
Pricing lives in one place. Amounts, trials, and intervals resolve from the catalog at read time in the funnel’s active locale, so a price change is one edit, not a hunt through pages.
Products map to entitlements. A product grants one or more entitlements: the named access levels your app actually checks (premium, pro, team). Group them into tiers without rewiring anything downstream.
Gating outlives your price list. Your app gates on the entitlement, never on a plan id, so you can rename plans, run price tests, or add a tier and never touch the code that unlocks features.
One entitlement system across web and app
Entitlements are the layer between what someone bought and what your app unlocks. Map products to access levels once, and check them anywhere: the same answer on the web and in the app.
Define the product in your catalog
Name it once: identifier, price, trial, billing period. It becomes the single source of truth the funnel and your app both read.
Map the product to an entitlement
Bind the product to the access levels it should grant. Several products can grant the same entitlement, and a tier is just a set of them.
A purchase resolves to access
When someone subscribes on the web funnel, Appfunnel resolves the purchase through the catalog to the entitlement keys it grants. No manual receipt bookkeeping.
Your app asks who has access
Drop the IdentitySDK into your app and ask whether a customer holds an entitlement, then branch: unlock the Pro screen, or show the paywall. One check, not a per-store integration.
Web purchase unlocks the app. A subscriber who paid on your web funnel holds the same entitlement inside your app: the whole point of web2app. One identity, one entitlement, wherever they signed up.
One layer across every source. Web checkouts (Stripe and Paddle) and store subscriptions (App Store, Google Play) fold into one entitlement state per customer, not three disconnected systems you reconcile by hand.
Resolved at cold launch. Access is computed server-side so your app can decide what to unlock on launch, without a slow client round-trip, and keep the last answer when the network is flaky.
Gate a feature in one check. Ask “does this customer have Pro?” and branch. The SDK abstracts the plan, the provider, and the platform away, so your gating code stays about access, nothing else.
How you identify your users
Entitlements only unlock if you know who the buyer is. Every customer has an email: the identity key that links a purchase on your web funnel to the same person in your app. How they log in is your call; these are the common patterns, and once the email is established, the access earned on the web unlocks in the app.
Email-only login. The app emails a one-time code; the customer enters it once to sign in, and never needs it again on that device.
Password at checkout. The email is captured on the web funnel and the customer sets a password right there. The same credentials log them into the app.
Password on first app entry. The first time the customer enters their email in the app, they set a password to use for every login after.
Access that stays honest over the whole lifecycle
Access has to stay right long after checkout: through trials, failed charges, cancellations, and refunds. Appfunnel derives an honest access state from the subscriptions themselves and keeps it in sync with the provider.
Access follows the money. Trials, active, past-due, canceled, and expired each resolve to an honest access state: a canceled sub still grants what was paid for until its paid-through date, never a second longer.
Grace and dunning, built in. A failed charge drops into a grace window instead of yanking access on the first retry, so a billing hiccup doesn’t lock out a paying customer mid-recovery.
Drift gets reconciled. A reconciler re-checks subscriptions against the provider every few hours and repairs status, period, and cancellation drift, so a missed webhook can’t quietly strand a customer in the wrong state.
Refunds settle correctly. Refunds and chargebacks flow through to the entitlement, so access reflects what was actually kept, and test purchases never grant real access.
The revenue is measured. MRR, ARR, ARPU, retention, and refunds are reported on the same subscriptions your entitlements read. See the analytics suite.
One customer, one ledger. Per-product subscriptions across providers collapse into one access state per customer: the single source of truth for who paid, ready for support to inspect.
Where teams use it
Unlock the app from the web
Sell the subscription on a fast web funnel, then let the app read that same entitlement on first launch: the web2app loop closed end to end.
Gate premium screens
Wrap a screen or feature in an entitlement check and let the SDK decide: Pro sees it, everyone else sees the paywall.
Leave receipt-validation behind
Retire the hand-rolled receipt-checking service; map products to entitlements once and check access the same way everywhere.
Run tiers and bundles
Group products into Starter, Pro, and Team tiers, or grant one entitlement from several SKUs, without touching the code that gates features.
Questions, answered directly
Can I sync entitlements to RevenueCat?
If you already run RevenueCat, you can sync to it. It’s supported for Stripe and Paddle. Worth knowing the tradeoffs: RevenueCat charges 1% of the revenue that flows through it, and you set your products up in both places. Or use Appfunnel’s built-in entitlements and skip that overhead: you define products and access levels once, right here, and check them from your app.
How does a web purchase unlock Pro inside the app?
A purchase on your web funnel resolves through the product catalog to the entitlement keys it grants, tied to the customer’s identity. Your app asks the IdentitySDK whether that customer holds the entitlement and unlocks the feature: the same access state, whether they paid on the web or in the app.
What sources feed the entitlement state?
Web checkouts through Stripe and Paddle are live today; store subscriptions from the App Store and Google Play fold into the same entitlement layer, so one customer’s access reflects every source at once. Your app checks a single entitlement rather than reconciling three billing systems by hand.
Do I have to hard-code plans and prices into my app?
No, that’s the point of entitlements. Your app gates on a named access level like pro, not on a plan id or price. You can rename plans, run price experiments, or add a tier in the catalog and never touch the gating code, because the mapping from product to entitlement lives in Appfunnel.
What happens when a payment fails or a subscription is canceled?
Access follows what was actually paid for. A canceled subscription keeps access until its paid-through date; a failed charge enters a grace window during dunning instead of revoking immediately; refunds settle through to the entitlement. A reconciler also re-checks subscriptions against the provider on a schedule and repairs any drift, so a missed webhook can’t leave a customer in the wrong state.
Is access resolved on the server?
Yes. Entitlement state is computed server-side from the customer’s subscriptions, so your app can decide what to unlock at cold launch without a slow client round-trip, and hold the last known answer when the network is unavailable.
Related features
Payments & Billing
The Stripe and Paddle subscriptions your entitlements are derived from.
AI Web Builder
Where products are referenced as the shared pricing source of truth.
LTV Analytics & Attribution
MRR, ARR, retention, and refunds on the same subscriptions.
A/B Experiments
Test offers and tiers, decided on the revenue they actually earn.
Developer platform
Drop the IdentitySDK into your app to check entitlements and gate features.
One entitlement layer for your web funnel and your app.
Define products once, gate your app by access level, and let a web purchase unlock Pro in the app: free for 14 days.