Back to News & Insights
Digital Marketing September 24, 2026 · 4 min read

The Web2App Funnel Where Users Pay on the Web and Open the iOS App Already Logged In, Even Before It's Installed

I built this crazy seamless system (Not sure, how its done usually in the industry), Where we are...

The Web2App Funnel Where Users Pay on the Web and Open the iOS App Already Logged In, Even Before It's Installed

I built this crazy seamless system (Not sure, how its done usually in the industry), Where we are acquiring users on the web funnel, making them pay on the web, and after purchase they land on the mobile app which is already authenticated even when it is not installed (thats the main sauce btw), hence reducing the friction of logging them again, getting rid of the apple tax, getting the retention of a native mobile app, bypassing the bitchy apple again with its ATT permission.

Read that again. Apple takes Up to a third of your revenue, for a payment sheet. So we just moved the money to the web. Apple only gets its cut when the purchase happens inside the app.

Imagine someone is scrolling and they see your ad. And you want them to leave, open the App Store, download 80MB, open the app, get through onboarding, and then decide if they want to pay.

From Ad -> quiz flow -> paywall -> paid. They never leave the browser, and the money is in before they've installed anything.

Since the purchase is happening outside of the mobile app, apple cant do anything, you can apply whatever black marketing tips and tricks you have learnt.

So, How to actually get your users to the app with logged in state even when they haven't installed the app?

Nothing can cross it, whether its cookies, session, or local storage. Your user was logged in on the web two minutes ago, and your app opens with zero idea who they are.

But there's one thing, one thing that really does cross the wall, and you're probably already paying for it: your attribution tool, i.e. Appsflyer.

It works like this: The user taps your link. The provider records the tap and sends them to the App Store. They install and open the app. The SDK asks its server: "did anyone tap a link for this phone?" If yes, you get whatever was on the link.

So the flow is : pay and sign up on the web, tap Get the app, install, and the token rides the link to the app's first launch

When the logged in user taps Get the app, your backend creates a one time token for them:

Few things to take care of during this process : Get the user from their logged-in session, not from anything the browser sends. Otherwise anyone could log in as anyone. Store only the hash. It should have a short lifetime. Keep it out of your logs.

What I found was that the app knew the install came from our link. It even gave us deeplinkvalue, But the main token was gone.

▎ For new users, the UDL method only returns parameters relevant to deferred deep linking: deeplinkvalue and deeplinksub1-10.

Since iOS 14.5, a fresh install only gets a handful of "safe" parameters. Your custom token= gets wiped out silently.

The fix is simple and stupid, We have to Put the token in one of the allowed slots:

The app sends the token to your backend, and the backend burns it and logs the user in:

We have to check the token and burns it in a single shot, so it can never be used twice.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation