mdubya_

[prisma thistle]

Hi there!

what's your question?

[heady hearth]

im setting up my endpoint and currently working my way thru all the customer.subscription.x and invoice.x events

how come when i create a new subscription, the sequence of invoice events is

[prisma thistle]

this is explained here: https://stripe.com/docs/webhooks#event-ordering

[heady hearth]

saw that

but thats not the order im getting

im using a failing card in this example

my order is
invoice.payment_failed -> invoice.payment_action_requored -> invoice.created -> invoice.finalized

[prisma thistle]

Sure, but like explained in the link I shared:

Stripe doesn’t guarantee delivery of events in the order in which they’re generated

so your code will need to handle any possible order

[heady hearth]

not a problem. just noticed every time i run the trigger, thats the exact same sequence.

in that same vein,

[heady hearth]

if a invoice.payment_fails to deliver, it will automatically retry ~2 hours later.

[vestal wyvern]

👋 taking over for my colleague. Let me catch up.

[heady hearth]

howdy

hypothetically.
i receive invoice.payment_fails but it fails delivery so it will retry in 2 hours.
in the meantime, i receive invoice.payment_succeeds
and then the two hours go by

will i still receive the invoice.payment_fails retry?

[vestal wyvern]

once an invoice succeeds the retry won't happen

[heady hearth]

i can deal with events out of sequence. but if i get in.fail -> in.succeed -> in.fail because the first event wasnt delivered, that would be difficult

but you're saying that wont happen?

[vestal wyvern]

oh! sorry I misunderstood the question

I thought the invoice will retry and not the event

actually if you're keeping tabs in your own db on this it's super easy to ignore that particular event

another protip and best practice suggestion we normally ask our users to do is to retrieve the object instead of relying on the event data

[heady hearth]

yea. i was largely leaning towards letting events maintain the integrity of my db values as to make sure they dont get out of sync w/ stirpe

stripe*

[vestal wyvern]

which means that once you receive the second in.fail event and you retrieve the invoice you can see it did succeed

[vestal wyvern]

but that's not really a good approach since events can be out of order

[heady hearth]

simple enough logic. just didnt know if there are exotic scenarios where it is possible that a invoice status could change from succeeded to something else

[vestal wyvern]

succeeded is a terminal status