#Ninjesus-webhook events
rotund iris
Hi Tarzan
brittle fog
Stripe does not guarantee delivery of events in the order in which they are generated
https://stripe.com/docs/webhooks/best-practices#event-ordering
rotund iris
Ok thanks, I understand that the order of event can be generated in "incorrect" order when dealing with different resources. But for a given resource it "should" be time ordered
otherwise there is no point of making different event types for same resource, as we must process them without trusting their type. For payment intents I listen to all event types and then when I process them I retrieve the payment intent from stripe as I cannot trust the data sent in event.
a simple payment_intent.update event could be less misleading for devs as they might assume that payment_intent.created always comes before payment_intent.processing
brittle fog
the above statement is valid for the same resource as well, this is the example we give in our docs
for the same subscription
- customer.subscription.created
- invoice.created
- invoice.paid
- charge.created (if there’s a charge)
and the charge gets created before the invoice gets paid
Your endpoint shouldn’t expect delivery of these events in this order and should handle this accordingly. You can also use the API to fetch any missing objects (for example, you can fetch the invoice, charge, and subscription objects using the information from invoice.paid if you happen to receive this event first).
rotund iris
Ok sorry for the misundestanding, when I mention "same resource", a "resource" is either a peyment_intent, or a subscription, or an invoice. I should say "object" instead of "resource". I totally understand that events for diferent objects have their own timeline. So it is understandable that invoice.created can be triggered either before or after subscription.created.
But invoice.created should always come before invoice.paid, as well as payment_intent.created should always come before payment_intent.processing, thus respecting their underlying objects lifecycle. Otherwise there is absolutely no point having different event types for each object, as the events might not respect their underlying objects lifecycle.
brittle fog
we can't guarantee that
it's not a problem of which resource gets created before which, it's about the delivery system
you shouldn't be mirroring every single event of the lifecyle
choose what's really important for you
what would help you get to your business needs
rotund iris
yes I understand that the delivery system is the problem It is for sure that payment_intent are created before being processed. So for each single payment_intent event, when I process the event, I retrieve the payment_intent from stripe API so I get actual payment_intent status instead of trusting the event data which can be wrong
because I can be sure I get updated data when I retrieve the resource from API. And also there can be some delay between event reception and event processing.
anyway thank you for your help.
brittle fog
FWIW, you could build your system in a way that if you receive the payment_intent.processing event you would see whether you already have the payment intent id saved in your db and add it if not
and when you receive the payment_intent.created event you would look to see whether there is a payment intent id in your db and add it if not
so basically you could have the same logic for two events, where you just check before handling the event