For our Stripe integration, we are currently sending the token over to RevenueCat (RC) when we receive the customer.subscription.created event, as instructed in the documentation here.
However, as far as we can tell, when this event fires, Stripe hasn't necessarily completed processing the transaction/payment and therefore RC immediately receives a BILLING_ISSUE and CANCELLATION event from Stripe, which is what we are seeing in the "Customer History" for users. From a quick test, if we delay the POST to RC with the token by even a couple of seconds, we successfully receive the subscription and do not receive the issues mentioned above because (presumably) Stripe has finished the processing on its side by that point.
Example user:
My question is, should we instead be listening for the customer.subscription.updated and POSTing to RC at this time? It seems like customer.subscription.updated fires a couple of seconds after .created once Stripe has done a bit more processing, which I believe would prevent the BILLING/CANCELLATION events firing in the same way the delay did, just more controlled than an arbitrary delay.
As far as we can tell, our users that show the issues in their timeline are actually perfectly fine (we see `Subscription renews on 2024-04-22` in the top-right Entitlements section for the user), it's just unfortunate that they receive the BILLING/CANCELLATION issues on their "Customer History" and could obscure real issues.
Any help from anyone who has successfully integrated Stripe, we’d be very grateful! Thank you!
