#terrence_webhooks
1 messages ¡ Page 1 of 1 (latest)
đ 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/1363992072985772112
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Ah, okay, looks like this might be due to Connect
What do you mean by Connect?
Let me take a step back. You mentioned webhooks above but I don't see any event destinations listening for events from the account where this payment exists. Can you share how you're determining whether or not to cancel a PaymentIntent?
Also, do you have a PaymentIntent for a payment that "behaved normally"?
Webhook might not be the right word, but I don't know of a better term at the moment. We have a 20 minute ttl. After 20 minutes, if a payment still has a status that is a subset of "Processing" then we will attempt to cancel it
Yes, I can get an example of a "normal" one
How do you know if a payment is still "processing"? Do you retrieve the PaymentIntent?
ch_3REAdUKE5vuXycZ4093sfANu
I have the charge Id for the one that is normal
As far as I know, we don't retrieve the PaymentIntent in that flow. We go off of the payment record in our database. Potential enhancement here I can raise to the team
Thanks for the second ID. I don't see anything different between these: both originated from server-side code that created and confirmed PaymentIntents using an existing PaymentMethod. Both PaymentIntents transitioned to requires_action state since additional authentication was needed by the end customer. In both cases, the customer completed additional authentication successfully and both payments succeeded.
In both cases, we emitted payment_intent.succeeded and charge.succeeded events so, had the integration been listening for these event types, it could have skipped any logic to try to cancel the PaymentIntent
Back to the Connect piece: these payments are being triggered by a platform on a standard account. The platform can listen for events that occur on connected accounts by setting up Connect webhooks: https://docs.stripe.com/connect/webhooks
Thanks for looking. I'll bring this back to the team and see if there's some other angle I haven't considered.
Will also double check the webhooks if I can