| HN Mirror

Hi, I have two tickets open which are really causing a lot of issues for us:

- Expiration webhooks are not always sent, so customers keep their entitlement way after they should: Ticket 13919 (although it's been spread across a few as it must close them after a while or something)

- A much more urgent issue I opened a couple weeks ago: Customers that cancel and then re-subscribe for a trial at some point in the future have no webhook sent at all. The dashboard says their trial has started, so revenuecat knows the trial exists, but no webhook event is actually sent for it. This is causing a mess of customers who sign up but don't get their entitlements and end up asking for a refund or sending an angry email. Ticket 16016

- I've noticed a bunch of weird bugs, sometimes only affecting one customer so I haven't opened a ticket, but it just makes me question things. For exmaple, we implemented trials in April but our dashboard shows trial signups and conversions from last year. That is not possible, so I question the accuracy of the trial stats as well. Another issue from long ago was that the product_change event on android commonly sends the wrong new product ID, so we just have to ignore it. I was told this is a limitation of the play store though, but it wasn't obvious from the docs back then (not sure if it is fixed now). This makes it difficult to reflect what plan a user switched to within the app, since the product change event can't be trusted. Like most of the issues, the RC dashboard shows it correctly, it is just the webhook that is wrong (which is why I couldn't understand the response that it is a play store bug, when RC shows it right on their end but sends the wrong/old ID in the webhook) Since android downgrades are immediate, the initial_purchase that follows will actually set the correct ID, so that is the workaround for now that I found. (Hopefully I got that right, I'm reading the comments for the workaround we added)

I really want to see revenuecat work and succeed, because it is a great idea and for the most part made implementing subscriptions much easier, there are just a lot of edge cases we keep running into. Support is also not the most helpful, but I understand they are probably swamped. The android bug I mentioned above, the solution was to just use the RC api to fetch the status rather than using the webhook. Why would the API return a different ID than the webhook sent 50ms before? I'm not sure why there is such a disconnect between webhooks and what the API/dashboard returns. It would also be great if you could add a dashboard for support tickets rather than having to use email, it would keep things more organized, as I often need to contact support directly because the community tech support forum is a graveyard. I understand technical issues should be directed there, but they often sit for weeks with no response. Even with these issues I'd still recommend RC in general though. If these issues are happening with a company who's purpose is to handle them, I can't imagine how difficult it would be to implement a subscription system from scratch.