How reliable is subscription state when web checkout writes to RevenueCat or Adapty?

I synced web purchases into RevenueCat so the mobile app always saw the same entitlements. That gave us a single source of truth for trial starts, conversions and renewals without requiring native purchase flows. In practice the subscription state was reliable once I ensured the web checkout sent the provider receipt and the user id consistently.

Problems I ran into were race conditions when the purchase finished before the app fetched entitlements, and occasional mismatches when users had multiple accounts. The fixes were simple: add retries, confirm receipts server side, and surface a manual restore flow in the app.

Has anyone documented specific edge cases when syncing web purchases into these platforms?

We pushed web purchases into RevenueCat and it worked well.

Key bit was sending a stable user id and the purchase token to RevenueCat right away.

Also built a retry for the app to fetch entitlements on first open.

That fixed most timing issues.

It was reliable after a short QA cycle.

Make sure the web checkout writes to the subscription provider and you have a clear restore path in the app.

This removed most drift and made reporting cleaner across web and mobile.

We used RevenueCat and saw near instant entitlement updates.

The only hiccup was when users had multiple accounts. A restore button solved that.

RevenueCat sync worked

Add a restore flow

Focus on three things. One capture a stable id so the web purchase links to the same app account. Two send the full receipt and any provider metadata to RevenueCat or Adapty immediately. Three handle timing by making the app poll for entitlements on first open and offering a manual restore. In my experience these steps remove 95 percent of state drift. For the remaining cases keep a lightweight support flow to reconcile purchases quickly.

It was mostly seamless.

Just make sure the web checkout sends the right user id and token.