#bar2-3dsredirect
sharp pagoda
Hello! Are you asking this because you have logic that's hit when your customer reaches the redirect URL? It's always possible for customers to exit the flow before the redirect is able to finish
tight glacier
well yes for that reason, plus the user also doesn't tell he paid and ends up paying twice, about the other half of your reply, the user followed the 3d (since 3d was approved I can tell that) but still we didn't get the callback.
is there anywhere on the dashboards we can debug the callback events fired? and track down that specific payment id's callbacks?
sharp pagoda
A couple of questions:
- What does your payment flow look like now/which of our libraries are you using?
- Are you saying that there are customers who are still in the checkout flow and just never getting redirected even though they've never exited the flow?
There aren't any specific dashboards that you can easily find which customers did finish the redirect - that'd be something you have to log on your end
tight glacier
let me take a timeout and check a few things before I continue the conversation and save us both some time, brb 🙂
tight glacier
allright, I was talking about "return_url"
so what happens is: we initiate the payment, user follows the redirect link we get from stripe, then our return url is, on rare occassions, not fired.
so user finishes the 3d operation successfully but we do not get the callback about the event and are kept in dark
sharp pagoda
And are you using Stripe.JS + Elements (just want to confirm this isn't a mobile integration)?
tight glacier
neither, all handled on backend
no frontend library involved
we initiate the payment on backend via PaymentIntent, grab the url from the stripe response, push it back to the customer, customer follows the 3d redirect, takes the action (doesnt matter if successful or not) and the return url is not fired rarely
our platform works on both mobile and web, so we have a "one-for-all" solution implemented
(ios + android + web)
I have an example payment id as well by the way
since all events are stored on our end, I was able to track one down
sharp pagoda
Usually this is just because the customer has exited the flow too early, but you're sure this was for a customer that never left the checkout flow, right?
tight glacier
i mean it was at requires_action state, then went succeeded
would there be a scenario that customer left the flow but a 3d pending payment got approved anyway?
if not, im positive that was not the case.
sharp pagoda
Yes, a customer could confirm the 3Dsecure flow (so payment succeeds), and then choose to close the window before the redirect completes. The redirect to the return_url is not what determines whether authentication is successful - it's completely expected that authentication finishes BEFORE the redirect finishes
tight glacier
hmm, I see what you mean.
so maybe we need to set up webhooks for succeeded events for a fallback scenario to cover this?
sharp pagoda
Yup! That's what i'd recommend
tight glacier
allright karbi, thanks a lot for the help!
sharp pagoda
glad i could get that clarified! 👍