#terrence_webhooks

1 messages ¡ Page 1 of 1 (latest)

unique mirageBOT
#

👋 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.

slate frost
#

Hi there

#

Do you have an example PaymentIntent ID?

light oracle
#

Yes, one moment

#

pi_3REwZTKE5vuXycZ41FN3ydmz

slate frost
#

Ah, okay, looks like this might be due to Connect

light oracle
#

What do you mean by Connect?

slate frost
#

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"?

light oracle
#

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

slate frost
light oracle
#

ch_3REAdUKE5vuXycZ4093sfANu

I have the charge Id for the one that is normal

light oracle
slate frost
#

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

light oracle
#

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