#Village_Admin-webhook
1 messages · Page 1 of 1 (latest)
They are async and you can't rely on the order
We are sending them in the order, but it really depends on the network, the internet etc
It's a common case that for several events generated at almost same time, some could arrive earlier than others
I also noticed when a customer subscription auto renews it doesn't fire off a customer.subscription.updated event. Shouldn't it as one of the fields is data.object.current_period_end which should get updated?
So its possible to get a invoice.paid or customer.subscription.updated before a customer.created happens?
Will the stripe hive get mad at me if i response code 400 on things like invoice.paid if no customer exist on my end? As way to ensure i process the customer.created first which would then allow the invoice.paid to 200 on the retry?
So its possible to get a invoice.paid or customer.subscription.updated before a customer.created happens?
If those events are generated from same action, yes. But I don't think customer.created could be generated same time with customer.subscription.updated. To be updated the Subscription should exist already and tighted to a pre-existing customer
So in theory if i build in the 400 for non existing customers, in a perfect world that should never happen. But on the off chance it does, i dont get fubar on my end.
And is 400 the best code to use? Does stripe treat any of the reject numbers different? Is there one that means try again in a few seconds?
Per response code, Stripe only distinguish between 200/201 and the other. So it doesn't matter 400 or 500, it's still marked as "failed"
When some events are possibly generated simultaneously , yes on the off chance they could comes in different orders. But customer.created and customer.subscription.updated weren't possible to happen simultaneously in the first place
Any idea about this?
Unless i made a mistake, i only saw these events on a renew using the test clock
payment_intent.succeeded
charge.succeeded
customer.updated
payment_intent.created
invoice.updated
invoice.paid
invoice.payment_succeeded
invoice.finalized
Yeah you are right, customer.subscription.updated is for different things like status update
Is there a better way to get the new expiration date of their subscription besides invoice.paid > data.object.lines.data.0.period.end on renewals?
Did you trigger any action that change subscription billing cycle?
No, just when the auto renew happens for subscriptions