Their trial ended. Their card is four taps away.
Web funnels and paywalls for iOS apps. Run ads to a funnel before the app is installed, or open one from inside the app when a trial ends. Either way the customer pays on your own Stripe account, lands in the app already subscribed, and you can see which ad paid.
Your own Stripe account. No per-transaction fees.
Acquire on the web
An ad opens the funnel on a phone that does not have the app. The customer pays, then installs. Nothing here is inside the App Store.
Convert trials in the app
A trial ends and the app opens the same funnel with a device id. The one path that is subject to Apple's rules, and the SDK shows it only where allowed.
See what drove the revenue
The funnel is on your domain. Click, screens, paywall, payment: one record per person, and the conversion posted to the ad network from the server.
Try it
This is the real funnel, not a picture of one.
Tap through it. The screens, the paywall and the confirmation are the same components a customer sees at /f/your-funnel, in the default look. Yours wears your accent, your logo, light or dark.
What made you download Streak?
It decides which plan we show you.
The real funnel — tap through it
Most of it happens before the app is installed.
A Meta or TikTok ad opens the funnel on a phone that does not have the app. The funnel mirrors the app's onboarding: a few questions, the value, a paywall. The customer pays on the web, is sent to the App Store, and the app opens subscribed.
There is no app in this flow until the last step, so none of it is inside the App Store or subject to its rules on where a link may point. This is how the large subscription apps run their growth, and it is what this product was built to carry.
- 1
Ad
The click id and utm parameters arrive on the funnel URL.
- 2
Funnel
Questions, value, testimonials, paywall — on your domain, in the app's brand.
- 3
Checkout
Stripe Checkout on your own account. No app installed yet.
- 4
App Store
The confirmation sends them to install. The receipt carries a restore link.
- 5
App opens subscribed
The install asks by device, email or restore link and gets the subscription back.
Build the funnel. Connect Stripe. Hand the customer back.
- 1
Build the funnel
Question screens, value propositions, testimonials, a paywall. A live phone beside the editor renders the production component as you type, so the preview is always what customers will see.
- 2
Connect your Stripe
Your own account, through Stripe Connect. Prices are created on it, customers belong to it, payouts go to it. If you stop using Passback, every subscription keeps billing.
- 3
Hand them back
When the payment completes, a single-use token opens your app. Your app exchanges it for the subscription state, and the customer never sees a sign-in screen.
Your trial is live
Confirmed for you@example.com.
First payment on September 26, 2026
The payment settles
Paid on the web, subscribed in the app, no account to create.
The return into the app is the part most web funnels leave to you. Here it is three steps, and your app is involved in one of them.
- 1
The customer pays
On your Stripe account, with Apple Pay or a card, on the phone they are already holding.
- 2
Passback opens your app
Immediately, with a single-use token on the link. No email to confirm, no password to create.
- 3
Your app makes one request
It receives the plan and the renewal date, and shows the customer what they paid for.
Step three is a single HTTP request. There is nothing to install and no library to keep updated; the exact request, with your identifiers filled in, is on your settings page from the moment you sign up.
- Single-use tokens
- Each token is exchanged once and expires after five minutes. Only a SHA-256 digest is stored, so the database never holds a usable key.
- Recorded before the webhook
- The subscription is written when the customer returns from Checkout, not when the webhook is delivered. The app opens to an active subscription even on a slow connection.
- One API for every launch
- On every subsequent launch your app can query by device or email address. The response has the same shape, so there is one integration to build and test.
The funnel is on your domain, so every step is measurable.
Web-to-app did not start as a way round the commission. It started in 2021, when App Tracking Transparency took campaign attribution away from anything that happened inside an app. A funnel on the web gives it back: the click id arrives on the URL, a first-party cookie holds it, and every screen from there to the payment is a page you own. Nothing in Apple's privacy framework applies to it.
- One record from click to payment
- Every number is a count of distinct people. Drop-off by screen, the paywall's two figures, and what each question was answered, broken down by utm_source or by network.
- Conversions posted from the server
- When a visitor who arrived from an ad pays, the network is told server-to-server — Meta's Conversions API, TikTok's Events API — with the click id, the hashed email and the checkout session as the event id. A pixel the browser blocked changes nothing.
- Split tests by source
- Serve a second funnel to a share of visitors at the same address and read the two columns side by side. The report says how many payments each side needs before the difference means anything.
Current limitations
Stated here rather than discovered after you have built a funnel. Each has a working alternative today.
Where the in-app button may show
This applies to the in-app link only. Funnels reached from ads, email or the web are unaffected, because there is no app in that flow. Linking out of an iOS app to a web checkout is allowed in the United States and the EU today, and not in other storefronts. That is Apple's rule, not ours, and it can change.
Today The SDK asks which storefront it is in and shows the button only where it is allowed; elsewhere your App Store paywall shows. The list is a setting, so a ruling changes a row and not a release. Keep the App Store purchase visible beside the web one, and price the web plan on its own terms.
Reaching the app
A purchase has to find its way back into an app that may have been reinstalled, or may not be on the device that paid.
Today Four roads in: the device id, the instant return by URL scheme, a restore link in every receipt that opens the app as a universal link, and a grant straight onto the customer's RevenueCat or Adapty profile. The last needs no SDK at all.
An Android package
PassbackKit is a Swift package. Android is supported with code snippets rather than a library.
Today The snippets are in Settings with your identifiers filled in: the device id, the funnel URL, and a single GET request.
Refunds and support
Passback does not process refunds, change plans, or handle customer support.
Today Every customer is on your own Stripe account, so refunds and plan changes are handled in your Stripe dashboard.
Passback is never in the path of a payment.
Every charge is a direct charge on your own Stripe account, with no application fee. The customer record, the subscription and the payout are yours. There is no revenue share because there is no mechanism for one.
$250a month, flat
Founding price, held for as long as your subscription is active. $500 at standard pricing.
Early access, onboarding a few apps at a time