#jrfr23
plain falcon
grave bluff
It's possible that the events are not delivered in order: https://stripe.com/docs/webhooks#even-ordering
Your system can retrieve the corresponding object to check the status.
turbid elk
Would it be only necessary to retrieve the current state of a resource from stripe in a webhook handler in those .updated events where its unclear if its being processed in order?
this seems like an incredibly important detail for anyone responding to webhooks
its been stressed to be mindful of not hitting the rate limit on api calls, yet it seems like for any webhook call thats perhaps not a *.created event that you cant be sure if you are receiving events out of order
and so you would need to request the current state of all items around a resource for many webhook calls
grave bluff
Can you share an example issue you faced with the event ordering, so that I can address further?
turbid elk
sure for the event "payment_intent.requires_action" how should I handle this if I get it say before the "payment_intent.created" event?
grave bluff
payment_intent.requires_action event has no dependency on payment_intent.created event. When you receive payment_intent.requires_action event, your system should bring back the customer to perform the action
If you use Payment Intent with Payment Element integration, you shouldn't need to rely on payment_intent.requires_action event as the server/client response should return the status for client to handle the action
turbid elk
With an ACH payment method I'm understanding that the payment intent could fail days after the customer has completed their interaction with the payment element. For example if their bank account had insufficient funds
so if we are a 3rd party showing payments for a user and their status we would want to show the user any payments and what actions the user could take on those payments based on the lifecycle of those payments
grave bluff
In the case of ACH direct debit (delayed notification), the payment intent will be in payment_intent.processing when it's still processing, then payment_intent.failed or payment_intent.succeeded will be sent for payment outcome. They are in order: https://stripe.com/docs/payments/payment-methods#payment-notification
turbid elk
I could receive those events out of order though yes? and without having received a payment_intent.created event yet
so if I was showing users the payments they had with the ability to say let them cancel or refund those payments. If the first event I received was payment_intent.failed should I just treat that as the "created" event and if/when a created event comes in just ignore it?
grave bluff
Any payment_intent.* events receive will always have payment intent created. When you receive any other payment_intent.* event, your system can consider that the payment intent has been created and payment_intent.created can be ignored