#_nerder
grand boughBOT
Hello _nerder, we'll be with you shortly! Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
• _nerder, 6 days ago, 15 messages
spare mantle
Yes, this is very possible because we don't guarntee webhook event ordering (https://stripe.com/docs/webhooks#event-ordering).
There's a couple of different ways to handle it - retry would work or you could go in a different direction and assume that if you get the payment_method.attached event the customer has to exist and retrieve the Customer to populate your DB (or whatever else you're doing in your webhook event handler)
vestal vine
ok, so i'll just remove the customer existence check and upsert the customer when arrives
spare mantle
yup that'll work!
vestal vine
makes total sense
one little problem tho, payment_method.attached will only contain the customer id right? not the entire customer object
and for replicate this into my db i'm using a metadata, of which I will not have access too
spare mantle
Yeah that's why I mentioned you'd need to retrieve the Customer
vestal vine
ah ok! Sorry i miss that part
so it's okay to retrieve the customer first. Even if the webhook has not been delivered, the customer realistically is already in your system
so customer.retrieve will find it
spare mantle
Yup! If the customer ID is in the payment_method.attached event then it definitely exists
vestal vine
okok, now it's clear
usually my strategy has been to rely on my DB when fetching the customer, but instead it makes more sense to retrieve the entire object from you as a source of truth
All clear!
spare mantle
👍 glad I could help!
vestal vine
Since we are here then, I have a peculiar scenario
with payment_method.detached, sometimes the customerId is not there. Why is that?
spare mantle
Hmm... do you have an example I can look at?
spare mantle
Ah! So I believe the payment_method.detached event acts similarly to our *.updated events. If you look at that event in the dashboard you can see it has a hash called previous_attributes withcustomer nested inside it. We do that to indicate it previously had customer but it's since been unset with this event
vestal vine
Ah! Interesting
so i need to change my code to fetch it from that
This was a recent change tho? I've seen it working before
spare mantle
I don't think it was a recent change - from what I can see on my end it's been like this since 2019
vestal vine
ah ok, than I must be mistaken
spare mantle
but if you have an example of it populating customer for detachement events I'd be happy to look
vestal vine
I don't clearly remember, but I must remember incorrectly
than it makes me wonder, this will work even for schedule when a subscription is updated?
I mean, it will come back to null when the scheduled update has been performed?
sterile mural
Hi there 👋 jumping in as my teammate needs to step away soon. Yes, once a Subscription Schedule has ended, if it's end_behavior is set to release, the association of it from the Subscription object will be removed.
One thing to be wary of there though, is that the Subscription Schedule gets released at the end of its last phase, even though its last change typically happens at the beginnig of that last phase.
vestal vine
ok