We accept payment on the web, then unlock in the app when the user logs in later. Mapping receipts into Adapty or RevenueCat was mostly smooth, but a few things bit us: forgetting to set a stable app_user_id, currency mismatches on intro offers, and trials starting before the app was ever installed.
What helped was sending a webhook on successful purchase to trigger entitlement sync, then forcing an entitlement refresh on first app launch if a token is present in the deep link.
What edge cases did you run into with web purchases flowing into Adapty or RevenueCat, and how did you handle restores, upgrades, and failed renewals cleanly?
Stable app_user_id solved most of it.
Webhook on purchase to set entitlements, then refresh on first app open. Watch trial alignment between web and app. Web2Wave’s templates nudged me to wire these correctly the first time.
I care about the first open experience. After web purchase, I send a webhook to the entitlement provider, then pass a token in the deep link. The app refreshes entitlements on launch. Web2Wave made this wiring fast.
Use one user id across web and app. Send a purchase webhook and force an entitlement refresh on first launch. That fixed delays for us.
Send webhook to refresh entitlements fast
Map web customer to app_user_id at checkout. Send purchase and renewal webhooks to Adapty or RevenueCat. Force entitlement refresh on first app open when a token is present. Align trial length and price across platforms. Handle restorations by prompting login. Monitor failed renewals and downgrade entitlements after grace. This prevents double billing and keeps access accurate.
We had duplicates until we set app_user_id early. Refresh on launch helps.