#overture8_webhooks
frigid charmBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1230446858602549270
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tender rockBOT
finite bane
Hi, let me help you with this.
I am not exactly sure what you're trying to achieve, on the high level. Do you mind elaborating?
frigid charmBOT
mellow hazel
Sorry - got stuck on a phone call. The main issue is around invoice states. When an invoice shows a "failed" or "retrying" in the Stripe dashboard, the actual Invoice is still in a "open" state. So, Stripe must be using a combination of the state of the invoice and the state of the PayementIntent to decide if the invoice shows as "failed" or "retrying" in the Stripe dashboard. I want to know what that logic is, so I can show the sane derived state in my apps UI. Does that make sense? btw, this isn't really a "webhook" related query - must have picked the wrong category by mistake.
median hollow
Yeah those Dashboard labels don't really map directly to an API enum/field
Can you share an example in_xxx that has those Dashboard labels/statuses?
mellow hazel
Sure, here are a few:
in_1P6Xf3B3t6gffdAg6IDvlMnx - retrying
in_1P5d4RB3t6gffdAgjPlyRWX7 - failed
median hollow
Taking a look
mellow hazel
Thanks
median hollow
OK, so 'failed' maps to when all automatic retries have been exhausted. Once that happens, you can configure what we do with the invoice in your settings. This is reflected on this API field: https://docs.stripe.com/api/invoices/object#invoice_object-next_payment_attempt
i.e. null once all retries have been attempted, otherwise a timestamp
An example on this event for in_1P6Xf3B3t6gffdAg6IDvlMnx: https://dashboard.stripe.com/events/evt_1P6Yr8B3t6gffdAgFJycooPq
mellow hazel
Does this logic hold true for when the payment type is direct debit bacs? It seems to me, that for direct debit, we need to look at the paymentintent?
median hollow
We don't retry BACS payments so there'd be no retry attempts: https://docs.stripe.com/billing/revenue-recovery/smart-retries#:~:text=To avoid bank fees%2C Stripe doesn’t retry invoice payments that customers made with bank debit methods including%3A BECS direct debit%2C Bacs direct debit%2C or SEPA direct debit.
mellow hazel
Ah, ok. For direct debit, what is the best way to be sure the invoice is in a failed state?
median hollow
What do you mean by 'failed' state? As I said, that's not an API enum just a pseudo Dashboard label
mellow hazel
Yeah - I guess my issue with direct debit is that the invoice will be in an "open" state - but the related payment could have failed. Should I look at the payment intent for this scanario?
median hollow
Yes, you can check latest_payment_error on the PI for specific details: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-last_payment_error
mellow hazel
Ok, is the latest_payment_error field a consistent indicator of an error having occurred - or should I use the PaymentIntent status (check if it is anything other than succeeded?). Just wondering if there is any scenario where the PaymentIntent will be in a failed state but latest_payment_error is null?
median hollow
latest_payment_error will include actual details regarding the type of failure (i.e. decline, insufficient funds, etc). status will, in most cases, just be requires_payment_method
mellow hazel
Ok, perfect. Thanks for your help man. Appreciate it.