#harryyy27_unexpected
frigid tangleBOT
👋 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/1225774087889092740
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
light glacierBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- harryyy27_unexpected, 20 hours ago, 24 messages
cursive cradle
👋 happy to help
balmy wing
brilliant 😄
cursive cradle
yes this is expected because the underlying PaymentIntent is in requires_action status
balmy wing
Ahh okay. So I do not have any bugs to worry about then..
cursive cradle
no
balmy wing
So what stripe webhook should I use for handling actual invoice payment failures?
cursive cradle
you're passing a PaymentMethod to the Subscription creation right?
balmy wing
one sec..
cursive cradle
So what stripe webhook should I use for handling actual invoice payment failures...
the one you're using now
you just need to see why the invoice failed
balmy wing
sure one second
i don't add a payment method at the subscription creation step, i enable automatic payment methods
"in_1P2AesJ5yVLZr7JEUF8QglPX"
this is one of them
the payment then always goes on to succeed
well.. nearly
haha
cursive cradle
let me check
balmy wing
thanks
light glacierBOT
cursive cradle
basically what you can do is that you can retrieve the PaymentIntent and look at its status, if it's requires_action this means that the customer needs to authorize the transaction via 3DS for example
balmy wing
the problem is, this whole chain of events is triggered between me clicking stripe.confirmPayment and the window asking me to confirm with my bank appearing, so even if I could see the requires_action status I'm not sure how to stop stripe from pinging those webhooks
round badge
you can't, but why is it an issue that you get the webhooks?
ultimately you handle 3DS by confirming the PaymentIntent from the Subscription's first Invoice on the frontend, which is what the guide at https://docs.stripe.com/billing/subscriptions/build-subscriptions?ui=elements covers.
if the issue is with your backend code not knowing that it needs to ignore certain events, note there is billing_reason on the Invoice object https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason to know it's the first invoice of a Subscription(and is thus handled in your frontend/subscription creation flow) rather than a recurring one that requires contacting the customer again
balmy wing
ohh.. so is the invoice failure event reserved for any other events that would actually completely stop the payment in addition to intermediate events between starting the payment and successfully completing it? If I had to send an email to a customer after a payment had failed would it be better to use payment_intent.failed but during the subscription renewal phase?
round badge
well invoice.payment_failed happens even if the 'failure' is just that the payment needs 3DS, and including if it's the first payment of the subscription(and is already being handled in your frontend)
I think that's your confusion. And I agree it's annoying, it just works that way for the benefit of legacy integrations that don't handle 3DS and would treat this as a regular declined payment.
You can set up your logic to ignore(return a HTTP 200 to the webhook and do no other action) the event if it's billing_reason:subscription_create as I mentioned; and then you only do the "email customer about payment failure" for recurring invoices, for instance.
balmy wing
ahh okay. I will add that logic into my webhooks then.. thanks!