Mapping web checkout ids to in-app entitlements with revenuecat—my pragmatic approach

I needed to make sure web purchases granted the same entitlements inside the app without confusing users. My approach was: create a server record for every web purchase with a stable user id, push that to RevenueCat as an external purchase, and have the app fetch entitlements on login.

The tricky bits were timing and duplicate events when users install the app before email verification. I solved this by marking pending entitlements and reconciling on the first successful app open.

How do you handle edge cases where users purchase on web but never log into the app?

I pushed web purchase receipts to RevenueCat as a non‑store purchase and used the email as the linking key.

If the user never opens the app I keep the entitlement active server side and email a magic link to claim it. I prototyped the flow quickly using a JSON funnel export I got from Web2Wave.com and it saved a lot of wiring time.

We mapped web checkout id to RevenueCat via a server call and then let the app pull entitlements on open.

To avoid angry users we send a claim email and deep link. Changes appear in the app instantly which made it safe to promote web purchases heavily.

I give users a link in the purchase confirmation that opens the app and forces a sync.

That fixed most mismatch cases for us.

Push web receipt to revenuecat

Have app pull entitlements on open

We ran into problems when users used different emails on web and app.

Solution was to allow a short grace period where support could merge accounts and claim entitlements manually. That handled under 2% of purchases and stopped most disputes.

I rely on email as the linking key and a claim link in the receipt.

Simple and mostly reliable.