Web purchases in an app that already runs on RevenueCat or Adapty.

The constraint

Most subscription apps on iOS do not ask the App Store whether someone is subscribed. They ask RevenueCat or Adapty, which answer from receipts they have already validated. Every paywall, every locked feature and every restore button reads that one answer.

So a subscription sold on the web has to arrive in the same place. If it only exists in Stripe, the app needs a second check, every feature gate needs to read two answers, and the day they disagree is a support ticket.

Three ways to get it there

Sell on the web through them. RevenueCat and Adapty both offer web paywalls and web billing of their own. The purchase lands in the same system as the in-app ones, with their charts across all three stores. It is the most integrated option, and it is priced on revenue.

Report Stripe purchases to them yourself. Run the checkout on your own Stripe account and have your server tell the platform about each subscription. It keeps the customer on your account; it also means writing, and running, the server that listens to Stripe and makes those calls, including the retries when their API is down.

Have the funnel tool grant the entitlement. The checkout runs on your Stripe account and the tool, which already listens to Stripe, grants and revokes access on the platform as the subscription changes. This is what Passback does.

How the grant works

1. The app puts its user id on the funnel URL as u=: RevenueCat's app user id, or Adapty's customer user id. It rides through checkout on the session's metadata and is recorded when the customer returns.
2. You enter a secret key and one name in Settings: the entitlement identifier for RevenueCat, or the access level for Adapty. Keys are sealed at rest.
3. While the subscription is active or trialling, access is granted server to server: a promotional entitlement on RevenueCat for the plan's length, or an access level on Adapty until the end of the paid period.
4. When it is cancelled or goes unpaid, it is revoked. A payment that has failed but is still being retried is left alone, so the customer keeps what they paid for while Stripe tries the card again.
5. If their API is down, the change waits in a queue and is retried after 2, 4, 8 minutes and so on, up to four hours apart. After eight failures it stops, you get an email, and one button in Settings sends it again.

In the app, that is one extra argument when PassbackKit is created. The existing entitlement check starts saying yes, and nothing else changes. The details are in the documentation.

What it looks like on their side

On RevenueCat a web purchase appears as a promotional entitlement, which carries no revenue. The customer is subscribed in every check; the money is not in RevenueCat's charts. It is on your Stripe account, and the funnel's conversion and revenue are in Passback's funnel analytics. If one chart with every store's revenue in it matters more than owning the customer, RevenueCat's own web billing is the better fit; the trade is set out in Passback vs RevenueCat.

Before you start

• Identify the user before the funnel opens. RevenueCat's anonymous ids work, but a customer who reinstalls gets a new one. If your app has accounts, log in to the platform with your own id first.
• Keep the App Store purchase. Web purchases add a door; they do not replace the one in the app. See showing a web checkout link inside an iOS app for where a link to the web is allowed at all.
• Price the web plan on its own terms. The saving is real on an annual plan and thin on a cheap monthly one; the sums are in App Store commission against Stripe's fees.

Checked against RevenueCat's and Adapty's server API references on 19 September 2026. Updated 24 September 2026. Corrections via contact. Related: Stripe checkout for iOS subscriptions, getting the customer back into the app after Stripe Checkout.