t-i-d-e_api

[median forge]

👋 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/1235701496079974400

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[fresh night]

Hi there!

Taking a look at the event you shared

[mossy depot]

Thanks, I am not sure if this event is the one you need evt_3PC6uPKPZ3B79iBx0WEldWQk

basically I am just confused why the payment intent is automatically confirming after I go through the 3d Secure Authentication

[fresh night]

Both events are linked to the same PaymentIntent so either one works for me! I see the PI was created with confirm: true so there's no need for an explicit/additional call to /confirm

[mossy depot]

Ahh ok that makes sense. What does stripe reccomend. To leave confirm: ON and wait for a webhook to verify the payment succeeded after the 3d verification, or set confirm to false and manually confirm it when they are redirected back to my site after the 3d verification?

[fresh night]

Ah, sorry, I misspoke though it's related. The reason that an additional server-side call to confirm after completing 3DS authentication wasn't required was because of confirmation_method: automatic (this is the default) and passing confirm: true

We recommend using confirmation_method: automatic so you can confirm using a publishable key if needed. Once you confirm a PaymentIntent client side and a customer completes 3DS successfully, no additional confirmation is needed

[mossy depot]

Ok, so should I just confirm the payment intent was completed by taking the returned URL and retrieving the payment intent using an API call to check its status?

[fresh night]

Or you can use webhooks and make sure to listen for payment_intent.succeeded events instead of making individual calls to retrieve the PaymentIntent manually

[mossy depot]

thanks. what is reccomended?

maybe the webhooks in case the users cell service is bad and the redirect does not work as intended

[fresh night]

Yep, we recommend using webhooks for that specific reason. A user may not always hit the return URL so listening for these events is key

[mossy depot]

Thanks!

Is this the webhook I would use?

Is 3ds considered a delayed payment method?

[fresh night]

No, that event is specifically for integrations that use Stripe Checkout. Since you're working with PaymentIntents directly, you'll want to listen for payment_intent.succeeded

[fresh night]

No. Delayed payment methods are those like ACH debit in the US (since it can take days for funds to move) or something like vouchers (OXXO in Mexico, Konbini in Japan)

[mossy depot]

Gotcha, thanks and is there a way to filter out webhooks that are only coming because of the 3ds Confitmkation?

[mossy depot]

makes sense

[fresh night]

Kind of? You could listen for payment_intent.requires_action since this event is emitted whenever a PaymentIntent's status is requires_action but there's no way to filter events so you only receive payment_intent.succeeded events for PaymentIntents that required 3DS

[mossy depot]

Ok. Thanks. One more question. How should I handle situations when a payment intent is incomplete and will never be completed?

So that there dont become thousands of incomplete payment tab

[fresh night]

That's totally up to you. You can leave them as is; there's no harm in leaving them in that state.

You could also explicitly cancel them: https://docs.stripe.com/api/payment_intents/cancel

[mossy depot]

Ok, thanks

[fresh night]

Note that canceling a PaymentIntent means no further action can be taken with that PaymentIntent