Passback

Web-to-app funnels, explained

A customer finds your app on the web, answers a few questions, pays on a web page, then opens the app already subscribed. This guide covers each step: why it works, what Apple permits, how the return into the app happens, and where the money goes.

The shape of it

A web-to-app funnel is a short sequence of web pages that ends in a payment, followed by a handoff into a native app. The usual order: two or three questions that personalise the offer; a screen describing what the customer will get; a paywall with a price; a card form; and a confirmation page that opens the app.

It exists because of two facts about the App Store. The store takes a share of every in-app purchase: 15% or 30%, depending on your programme and how long the subscriber has been paying. And an ad click cannot be attributed through an install the way it can through a web page: a click on Meta or TikTok that lands on the App Store listing loses its trail when the install begins. A web page in between keeps the attribution and can take the payment before the install.

What Apple allows

Apple's guidelines have long allowed an app to honour a subscription purchased elsewhere, in the way a streaming app accepts a login for a plan bought on the web. What the guidelines restrict is the app steering users from inside the app to a cheaper price outside it. That restriction has been the subject of litigation and rule changes in several jurisdictions in recent years, and the details differ by region.

The distinction that matters for a funnel: the purchase happens on the web, reached from the web. The app's role is to recognise a subscriber. An app that does this, and does not advertise the web price inside the app in a way the current guidelines prohibit in its region, is following an established pattern. This is not legal advice. Read guideline 3.1 as it stands when you ship, and consult counsel if your app is in a closely reviewed category.

The trip back into the app

This is where most of the engineering lives. After paying, the customer opens the app and the app has to recognise them. There are four approaches:

  1. Sign in. The customer creates an account on the web; the app asks for the same credentials. Reliable, but an extra step at the end of a funnel that many people abandon.
  2. A code. The confirmation page shows a short code; the app asks for it. Reliable, but manual.
  3. A URL scheme. The confirmation page opens yourapp://paid?token=…. Instant when the app is installed; nothing happens when it is not, so a fallback is required.
  4. Claim by device. The app opens the funnel with a device id in the URL; the payment is recorded against that id; the app then asks whether the device is entitled. Nothing to type, nothing declared in Xcode, and it works whether the app was installed before or after the payment. This is Passback's default (details).

Universal Links, the https:// links that open an app directly, are the more robust form of the URL scheme. They require an apple-app-site-association file on your domain and an entitlement in Xcode. They are worth adding once a funnel is proven, not before.

Where the money goes

The other decision is whose payment account holds the subscription. Some funnel tools process payments through their own account and pay you out, charging a commission; the customer records belong to their system. Others connect to your Stripe account, so the charge is between you and the customer and the tool is not a party to the payment.

Passback uses the second model: direct charges on your Stripe account with no application fee, for a flat $250 a month. The practical consequence is that the funnel is replaceable. If you stop using the tool, subscriptions continue to bill and the customers remain in an account you control.

What a good funnel is made of

  • Three questions, not ten. Every screen loses people. Ask what changes the offer and omit the rest.
  • One recommended price. Two options is a decision; three is a comparison exercise. If you offer a trial, make it the default and state when the first charge occurs.
  • A confirmation page with one action: open the app. A button, a store badge for those who have not installed it, nothing else.
  • Measure drop-off per screen in people, not views. Then change one screen at a time.
  • Report payments to the ad network. Meta and TikTok optimise toward the events you send back; reporting purchases lowers acquisition cost.

Whether you should build one

If your app is free to download, sells a subscription, and you spend or plan to spend on paid acquisition, the store commission saved on web-acquired subscribers typically covers the cost of the tooling many times over. If your app is paid up front, or most of your installs come from App Store search, the case is weaker.

Updated 13 September 2026. Corrections via contact. Related: documentation, Passback vs RevenueCat.