Recently one user subscribed to our annual plan, however the webhook failed to proceed because the App user ID returned only the RC Anonymous ID ( $RCAnonymousID… ).
I have no idea why it happens and not sure what to do next, all I can do is wait for him to contact us. Any advice?
FYR, all other users has successfully logged in with the correct App user ID.
+4
I also have the same issue. Revenuecat send a correct APP_USER_ID for INITIAL_PURCHASE, CANCELLATION and UNCANCELLATION, but the EXPIRATION event does not contain the APP_USER_ID, only anonymous id was given.
+9
One thing I can think of is if .reset() or .logout() was called before the event was dispatched, or maybe the user moved to a different device and didn’t log in? Hard to say exactly, but the app_user_id field should be the latest non-anonymous ID, if set. Another thing to check is the `aliases` array in the webhook and if there’s any non-anonymous IDs sent through that array.
Do you have any example Event IDs we can look up?
+4
One thing I can think of is if .reset() or .logout() was called before the event was dispatched, or maybe the user moved to a different device and didn’t log in? Hard to say exactly, but the app_user_id field should be the latest non-anonymous ID, if set. Another thing to check is the `aliases` array in the webhook and if there’s any non-anonymous IDs sent through that array.
Do you have any example Event IDs we can look up?
Can you take a look at this Event IDs :
- 66BE2A05-8095-42A1-90C3-34F4A2C509E0
- 824593DE-FFFF-48C3-BA56-C31D9B95DCD2
- 49EEE057-34F4-46AF-AA06-063D69ACBDB3
- 75EC3B94-3F97-45B3-AB62-372A86874864
+7
One thing I can think of is if .reset() or .logout() was called before the event was dispatched, or maybe the user moved to a different device and didn’t log in?
Not possible in my case.
Another thing to check is the `aliases` array in the webhook and if there’s any non-anonymous IDs sent through that array.
We’ve already check all aliases from our webhook if the app_user_id is an anonymous id.
Do you have any example Event IDs we can look up?
623b179d-119c-4976-ab75-05a0dd90c5bd
Edit: Sadly, this user has issued a refund already.
+7
Just wanna add one more thing, have you received any reports that RC is being listed in any anti-tracking app?
+9
In general, if you’re able to set the customer facing subscription status from the SDK directly, then have more asynchronous processes to ensure eventual consistency of server-side subscription status your customers are at least immune to these cases where things get out of sync. If realtime server-side subscription status is a requirement, then having a way for the customer to restore purchases and manually trigger a re-sync would be my recommendation.
You could have a “Restore Purchases” button in your app that required the customer be signed in (if that’s how your app is supposed to work) by checking the `isAnonymous` property on `PurchaserInfo`. Then if that customer triggers a restore, you know you’ll get a `TRANSFER` webhook soon if that customer was accidentally logged in with a different account or something.
I’m going to share both of these threads with our product team as well for feedback!
+7
ok, thank you.
Is there a way to test the restore purchases flow on dev?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.