#benk

1 messages · Page 1 of 1 (latest)

proud haloBOT
pulsar egret
#

Hi! Let me help you with this.

#

Yes, please share the PaymentIntent ID pi_xxx

#

And also screenshots and screen recordings of the issue, if possible

paper geode
#

hi vanya

#

here is the timestamp and ID:
2023-02-06 16:30:27 pi_3MYXaHFK5HQUlGOt0b5PkMRO

#

unfortunately we don't have a screenshot

pulsar egret
#

It seems like this PaymentIntent was cancelled by you via Dashboard with cancellation_reason: "duplicate".

#

Is this related?

paper geode
#

that was cancelled manually

#

but we are interested to see what may have caused the issue where our paypage didn't get a response from Stripe

#

we are wondering if it was caused by a timeout or perhaps we are doing something wrong

pulsar egret
#

It depends on your integration.

#

paypage didn't get a response from Stripe
Not sure what you mean by this
What response are you expecting?

paper geode
#

the final authorisation

#

so the cardholder goes through the 3DS authentication flow without issues until the last leg when the CRes is submitted to Stripe server doesn't yield the authorisation result

#

this is happening time to time and most of the time everything work with the 3DS authentication (incl. getting the authorisation result/response)

#

I'm not entirely familiar with the Stripe 3DS client library but I would expect you can configure the timeout and/or some sort of logging of the steps if necessary?

#

does it make sense?

#

are you able to look into the authorisation itself based on the PaymentIntent Id?

tender reef
#

The PI you shared was canceled. Do you have another example?

paper geode
#

yes I know it was cancelled through the Dashboard but I would imagine you still to be able to look up through your internal logs?

#

I do have 3 other IDs but I'm not sure what their state is (eg: cancelled or not)

#

the reason this authorisation was cancelled is that since our paypage didn't get the authorisation result back from the Stripe library our system never knew the authorised outcome of the payment

tender reef
#

Let me see

paper geode
#

2023-02-07 20:22:23, pi_3MYxgHFK5HQUlGOt1YibzcDM
2023-02-12 13:11:40, pi_3MafLBFK5HQUlGOt1Lp74ZBG
2023-02-19 16:21:40, pi_3MdFdtFK5HQUlGOt1iRCsIMx

#

these are all from the same merchant

tender reef
#

pi_3MYXaHFK5HQUlGOt0b5PkMRO was in a requires_capture state before you canceled it. 3DS/auth was requested and passed successfully.

paper geode
#

yes we know that it was 3DS authenticated

#

The problem lies elsewhere. Since our integration works most of the time (read after the 3DS authentication completed our paypage gets a response out from the Stripe JS library for us to complete the capture), we are wondering if this could be something to do latency or longer server processing causing timeouts, and potentially network issues.

tender reef
#

read after the 3DS authentication completed our paypage gets a response out from the Stripe JS library for us to complete the capture
You shouldn't really rely on that. Webhooks would be a better implementation here

#

we are wondering if this could be something to do latency or longer server processing causing timeouts, and potentially network issues.
I'm not sure unfortunately. It's really hard for us to have any other insights into this without some kind of reproduction. Everything looks fine from our side

paper geode
#

we are relying on your Stripe.js to talk to our paypage and telling it that the authentication has completed and capture is now required. I understand this is the lesser of the stable approach since we are talking about client-side with a single point of failure (timeout, network issues, JS library crash) which then leaves our paypage with an "unfinished" status whilst the authentication has completed.

tender reef
#

understand this is the lesser of the stable approach since we are talking about client-side with a single point of failure (timeout, network issues, JS library crash) which then leaves our paypage with an "unfinished" status whilst the authentication has completed.
This is exactly why we recommend webhooks for fulfilment/post-payment actions.

paper geode
#

yes, although that's an offline(ish) approach whereas we would like to get the status update on the paypage whilst the flow is handled on the client

#

looking at the docs you do have support for something like this:
stripe.retrievePaymentIntent(clientSecret)

tender reef
#

Yeah, there's methods to support that. But they don't fix the underlying issue here

paper geode
#

ok thanks for the help

#

I think that's it for now

tender reef
#

You should listen for payment_intent.updated events, check the status field and when requires_capture you can capture the PI async via a webhookj

#

Right now you're relying on users being redirected to your return_url which doesn't always happen for a multitude of reasons

paper geode
#

ok thanks, we are planning to make some changes based on this but I'm not sure which solution we will go with

narrow hull
#

Hey! Taking over for my colleague. Let me catch up.

paper geode
#

thanks!

narrow hull
#

where is the payment_intent.updated event documented? The one I found
I think there was a missunderstand previously with my colleauge, sorry, there isn't a public webhook event. You can retrieve the PaymentIntent and check its status:
https://stripe.com/docs/api/payment_intents/retrieve

#

If you want to get notified when a payment_intent is in requires_status then once you confirm the payment and you get the result of the PaymentIntent your integration should notify it self (make a call from your frontend to your backend...)

paper geode
#

cool thanks

narrow hull
#

Yes you can do it also from the frontend, you'll get the status field as it's ETRIEVABLE WITH PUBLISHABLE KEY

paper geode
#

cool thanks again and have a great weekend!

narrow hull
#

Thanks, you too!