#Village_Admin-webhook

1 messages · Page 1 of 1 (latest)

zenith elm
#

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

whole sparrow
#

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?

zenith elm
#

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

whole sparrow
#

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?

zenith elm
#

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

zenith elm
#

Yeah I am finding more about that. I thought it should be sent

#

Bear with me

whole sparrow
#

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
zenith elm
#

Yeah you are right, customer.subscription.updated is for different things like status update

whole sparrow
#

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?

zenith elm
#

Did you trigger any action that change subscription billing cycle?

whole sparrow
#

No, just when the auto renew happens for subscriptions

zenith elm
#

Otherwise you can fire Retrieve Subscription API

#

It should returns all the current information about this Subscription

whole sparrow
#

The only thing i saw available to me for auto renewals was
invoice.paid > data.object.lines.data.0.period.end
I prefer not to use lines like the [0] variable as it leaves room for unknowns / error.

#

But okay, i guess it is what it is. Thanks. Im done for now.