#lukas.giniotis-invoice-payment
tired quartz
Hi
earnest torrent
Are you talking about invoice payment failures or webhook event deliveries? They're both mutually exclusive
i.e. the payment of an invoice isn't dependent on the success of an event delivery
tired quartz
Correct me if I'm wrong, but when a payment (not the first one) on subscription happens, there is an invoice.created event created and only an hour later come the success events. If my webhook responds with 500 to the invoice.created event, Stripe will retry the event for 72 hours (assuming it fails again) and only then deliver the success events
earnest torrent
Correct me if I'm wrong, but when a payment (not the first one) on subscription happens, there is an invoice.created event created
Yep, correct
only an hour later come the success events
You mean payment success? Yes, recurring payments are attempted ~1 hours after the invoice is created
If my webhook responds with 500 to the invoice.created event, Stripe will retry the event for 72 hours (assuming it fails again)
Correct, yes: https://stripe.com/docs/webhooks/best-practices#retry-logic
only then deliver the success events
What do you mean by this?
tired quartz
I mean that after 72 hours, if the invoice.created repeatedly fails, the payment success will be attempted instead of one hour after initial invoice.created event
earnest torrent
That shouldn't be the case, the separate invoice.payment_suceeded event (as an example) will attempt to be delivered alongside the invoice.created retries
It won't wait for the retries to fail before attempting the delivery
Does that make sense? What is the issue you're trying to solve?
In all cases I would recommend just fixing the 5xx errors
tired quartz
That's not what I am experiencing - I will provide an example if I can find it
earnest torrent
Please do!
tired quartz
Not sure if you can see the subscription, but here https://dashboard.stripe.com/test/subscriptions/sub_1LAUb5FDlhF015OLYGZoiAAS
earnest torrent
Taking a look
tired quartz
Draft was created on 17th, but succeeded only on 20th, 72hours later
Another subscription currently waiting 72 hours until payment succeeded https://dashboard.stripe.com/test/subscriptions/sub_1LArZVFDlhF015OLQekLOs4S
The issue I am trying to solve is - we have three webhooks listening to events. I would like the payment succeeded not to wait until all webhooks respond with 200.
earnest torrent
The webhooks are largely unrelated here, so you can discard those failing events blocking payment
tired quartz
Are you sure? When we have all webhooks responding with 'Success' we don't experience this problem, success is following invoice.created after an hour
earnest torrent
Is there an example of that? In the original Invoice you shared, this is the associated payment: https://dashboard.stripe.com/test/payments/pi_3LCfVnFDlhF015OL0XVyenLJ
The timeline of the actual payment lines up with the event delivery
I suspect it's related to the interval set on the subscription
tired quartz
It doesn't line up. The payment that you sent is completed on 20th, but it's for a draft that was created on 17th. Then another draft is created on 20th, which is now waiting for success. It's a bit confusing, since the interval of subscription is the same as the waiting time for the payment, so it looks aligned, but they are actually out of step by one iteration
earnest torrent
Yes, I meant that it lines up with the invoice.payment_succeeded event
The ~3 day delay is what I'm trying to understand. But this is not related to webhook delivery issues
We don't delay payment attempts based on whether webhooks are delivered or not
tired quartz
I will find examples where we have subscriptions align when we succeed on all webhooks if I can. It looks like a big coincidence if they are not related
This invoice was created, all events succeeded and the payment came on the same day
Please tell me if they are actually not related, I assumed this is a relatively small problem, but if it's not cause of webhook errors, it could be a bigger issue.
earnest torrent
Taking a look
tired quartz
Thank you
earnest torrent
Ok, looks like you're right – it is webhook related:
When you enable automatic collection, Stripe automatically finalises, and begins automatic collection of the invoice. We wait an hour after receiving a successful response to the invoice.created event before attempting payment. If we don’t receive a successful response within 72 hours, we attempt to finalise and send the invoice.
https://stripe.com/docs/invoicing/integration/workflow-transitions#finalized
My apologies. TIL!
earnest torrent
Not if you're listening for invoice.created events – do you require them?
That window (24-72hr) window exists before payment is attempted so that invoices can be modified if needed
The 72 hour window is to account for any downtime you may be experiencing, as you've not acknowledged/responded to the invoice.created event
So if you're not taking action following that event, then just stop listening to it
Otherwise I'd recommend making the handler for the event type bulletproof
tired quartz
Yes, we do. We listen to payment_intent.succeeded event, but it does not have a subscription id on it. So we use the invoice_created event to fetch the get the invoice id, so when payment_intent.succeeded we know what subscription the payment_intent.succeeded belongs to.
earnest torrent
Why not use invoice.payment_succeeded? Will return an Invoice with the subscription field
tired quartz
Not sure if invoice.payment_succeeded has all the info needed that is in payment_intent.succeeded, but if we listen to both at the same time we need to manage them coming in parallel. So our solution currently is invoice.created -> payment_intent.succeeded.
The situation is - we have three webhooks for three different environments (dev, test, preprod), so all of them listen to all events. So if I make a payment in test, the preprod webhook will 'misbehave', since the payment was done on another environment. We have implemented a solution which differentiates the environments, so that Preprod will return 202 if the payment is done in another environment. However there is an edge case that if we have not yet pushed this logic to preprod, it will fail with 500
So I was hoping that payment doesn't have to be delayed while waiting for all webhooks to succeed. Maybe if it gets one 200 success to Invoice.created it could go through.
This should be just an edge case, when we push to PreProd, this should solve itself, but it would be best if we don't have one environment depending on what's in another
winter oriole
Hi! I'm taking over this thread.
tired quartz
Hi
winter oriole
So I was hoping that payment doesn't have to be delayed while waiting for all webhooks to succeed. Maybe if it gets one 200 success to Invoice.created it could go through.
Unfortunately that's how Stripe works and that cannot be changed.
So you should either find a way for all your webhook endpoints to return 200, or remove some of the webhook endpoints that may fail.
Or, if you detect that an invoice is not automatically being finalized, you can also finalize it yourself with https://stripe.com/docs/api/invoices/finalize