We integrated the web checkout with Adapty/RevenueCat so that purchases made on the web reflected immediately inside the app. My takeaways:
- Syncing prevents confused users. They create an account on web, open the app, and their subscription is already active.
- It kept analytics consistent. We could attribute revenue and still rely on subscription SDKs for entitlement checks.
- The tricky bits were mapping payment ids and handling edge cases like partial refunds or cross platform restores.
If you’ve synced web purchases with a subscription SDK what mapping or edge cases caused the most trouble for you?
I wrote a small service that maps web payment ids to the revenuecat user id and pushes a restore event.
It fixed most complaints where users paid but saw locked content.
The Web2Wave JSON helped wire the checkout events into that service quickly.
We push the web purchase to RevenueCat as a non app store transaction and then trigger a sync in the app.
It made the UX seamless and our analytics stayed intact.
Using Web2Wave made the event payload consistent across tests.
Mapping the web payment id to the app user id fixed almost all support tickets.
Make sure to handle refunds and report them back to the subscription service so entitlements update.
sync ids then stop support tickets fast
The key is a single source of truth for entitlement. When you accept payments on the web push a record to your subscription service with the external id, amount, and state. Then have the app call a restore endpoint that validates that record.
Watch out for partial refunds and currency mismatches. Also log web to app restores for auditability. This keeps both UX and reporting tight.
We had an edge case where refunds were issued on the gateway but not flagged in RevenueCat. Adding a webhook from our billing to the subscription service fixed the mismatch.
Make sure you test the restore flow on both iOS and Android. That was the biggest surprise for us.