The billing error occurs when a store attempts to renew the subscription but can’t charge the customer’s card. When the billing issue is resolved, the subscription will therefore successfully renew and you will receive a RENEWAL event. There is no reason in the payload of that event.
@Jens I just upgraded to use webhooks and its almost not useable for me.
It feels to call the REST API on a web hook that is already containing the data as a workaround. Even if I would do so you never know for what id you have to call it, app_user_id, original_user_id, aliases etc.
Also it's not that easy because of transfers with transferred_from and transferred_to. Do I have to call for every single Id the REST endpoint and update my entries in my database?
I think there would be just a web hook that tells you the user and the state of their entitlements. When someone does a transfer it will just send multiple events, some for expiring and some for grant.
At this point I have to Know the internals and how revenue cat works to use it. Also the example events does not match up with the real ones for the same type.
Is there any complete implementation in any language that actually works and not only for some cases? I can't find nothing. It should be a pretty simple use case. Get always the latest state for each user change independent of any events, when something for a user changes you get that user event change basically.
it feels like at this point I can't implement this to work safely.
Hi @Sergej Sachs , we are working on a new version of our webhooks that will address your concerns This will take a few more months until it’s launched, though.
In the meantime: Yes, it’s best practice to call our REST API to get the most up-to-date information after receiving a webhook. You can call it for app_user_id, original_user_id or any of the aliases – since these accounts are aliased together in our backend, they will all return the same information (all of these are different identifiers for the same customer). If you are using identified accounts (i.e., using logIn() in the SDK), then in general, you should only ever have one non-anonymous account aliased together (i.e., one that is not starting with $RCAnonymousId). I would recommend only maintaining the non-anonymous record in your database.
The only time it might make sense to make two API calls to our REST API is indeed the transfer case, where you would call it for both transferred_from and transferred_to (since this case does affect two different customers).
Hi @Jens , This sounds great, I can wait a few months.
I will implement your suggestion until that with only getting each of the non-anonymous ids from the “from” and “to” arrays and fetch the data.
I have to to configure platform channels for each of the play stores to get faster web hook calls right? This will probably stay even on the new version of web hooks?
@Sergej Sachs yes, that’s correct. the reason is that some changes to the purchase we will simply not notice in near time. we regularly refresh the purchase status with the stores, but if e.g. a customer cancels their subscription, then without server-to-server notifications we won’t notice that cancellation until the next time we refresh the purchase status, whereas with server-to-server notifications we get notified about the cancellation immediately, and then we can send the webhook based on that updated information.
@Jens I noticed that “expires_date” from the /subscribe api is null but I have the entitlement. Does this mean its always with no expiration, basically unlimited?
Its like that in my case because it was a one time purchase but is it always like that? For subscriptions and one-time-purchases?
- I check if I have the entitlement, when no then its not purchased.
- If yes then I check the expiration date, if null its unlimited and he has the entitlement.
- If expires_date is smaller/earlier then current date, he has the entitlement active.
Thats the correct way right?
@Sergej Sachs yeah that’s exactly right!