Anyone has an idea about this, pls?
Hi @Silfalion-164ca8,
Can you detail a bit more which is the issue you are facing with the cancellation/refunds? If everything happens on device, you can always check if the user has an active subscription on the client.
You are safe to store the ids in your db, it is a way to track your users on the server side. Bear in mind that when a user deletes the app and reinstalls it will have a different id.
Let me know if this helps!
Hi @joan-cardona
Thank for the details!
To explain some more, my issue is that when cancelling or refunding the change is not immediate in the app, the listener doesn't get triggered, so I have to wait the 5 minutes the cache needs to refresh for the state of the app to be updated.
So my idea was to store them in the DB and listen to that in addition to Revenuecat user change.
Glad to know I can store them in the DB. Just to confirm, it's ok even if the data is publically accessible, right? I'm relying on anonymous Ids so there is no auth in place to secure the information, save for App check.
Also, I plan to call sync purchases when I receive an event from firebase when listening to those changes. Since I'm using anonymous users anyway, that should be alright regarding aliasing, right?
Hi @Silfalion-164ca8,
Do you have Platform Server Notifications set up? With that enabled we can get the refund notification faster. It’s okay to call sync purchases when you get the event, I don’t know what transfer behavior you want/expect but as long as you select your desired one, you should be okay with it.
Hi @joan-cardona,
Sorry for the late reply. Our concern was not receiving that update on device, so we had to setup a Firebase DB for it, working well so far. Here are some key points in case somebody else needs it:
- create a Firebase DB with a users collection.
- create a Firebase function that receives a revenuecat webhook . With authentication, it extracts the original app user id(important if your app doesn't have auth), and checks against the DB if the doc exist. If it does, it updates a timestamp field in the doc otherwise it creates the document(the document Id is the original app user id).
- publish the function and get its URI.
- create a revenuecat webhook that triggers on cancellation, uncancellation, refunds and expirations, or anything else you need that the client side doesn't react to already, and give it the URI of the function above.
Now all you have to do is listen to the Firestore document which has the original app user id(this is included in the customer info) on the client side as its ID. You can listen to it even if it doesn't exist yet, just check for that on the callback.
Inside the callback, call syncpurchases, fetch the customer info and refresh your state according to the result.
