#david_3ds-incomplete

1 messages ยท Page 1 of 1 (latest)

little sealBOT
#

๐Ÿ‘‹ 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/1493739929249775734

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

cold agate
#

๐Ÿ‘‹ @visual geyser I don't really understand the framing of your question

visual geyser
#

hmm, maybe I don't understand fully how it works, lol. ๐Ÿ™‚ so basically we have a video of the user trying to pay, we call handleNextAction() in the front end SDK, but it just hangs, it never opens the iframe

#

and it never errors out. the user waits 30s and then bails

#

I'm wondering if their bank doesn't support iframes?

cold agate
#

seems unlikely, iframes are just how 3DS always works

visual geyser
#

that's what I thought, but the docs say:

Depending on the payment method and required action, the customer may be temporarily redirected from your site and brought back to the return_url parameter provided when the PaymentIntent is confirmed.

cold agate
#

But it's hard to say and I don't think we can debug something like this on Discord. I recommend reaching out to support and you likely want to ask the end customer to also share their JS console and the network tab to understand what requests are being blocked/erroring

#

yeah that sentence is generic about all payment methods like Klarna or Paypal require a redirect

#

david_3ds-incomplete

visual geyser
#

we log their network requests and console messages in PostHog, there were no errors or network failures

cold agate
#

yeah but you might not have access to those if they happen in our own iframes right?

visual geyser
#

that's probably true. I'm not sure they are able to reproduce this. so to confirm, if we do not pass a return_url in the payment intent confirmation, that wont affect how 3ds is handled?

cold agate
#

correct that won't

visual geyser
#

does the SDK have some sort of timeout already if the iframe doesn't load?

cold agate
#

it's tricky, I don't want to go too deep in the internals of Stripe.js but you don't always need an iframe to "load" visually on the screen. 3DS2 offers "fictionless authentication" where we pass some data about the device and the bank approves without any need for a UI to appear and the end customer to complete 3DS.

But yes we do have a timeout I think after 30s

visual geyser
#

ok, I guess I'm not really sure what to do here? like it doesn't sound like there is anyway we can mitigate this situation on our end?

#

I guess having better understanding of what is happening would be helpful here, like having callbacks, breaking it down into smaller promises or using an Observable would be useful here since we don't have any observability into what is going on.

cold agate
#

yeah but that really isn't a thing we'd ever do

#

Sorry, the next step is to collect more details from that end customer (which is not great I know) and then work directly with support at https://support.stripe.com/contact to investigate what happened

visual geyser
#

you'd never add a callback that would give us more insight into what is happening?

#

and by "insight" I just mean "waiting for user response" or "waiting for bank response" or something like that

cold agate
#

correct we'd never add something like this

#

really the issue is "why did this never complete or cleanly error" and that's what needs to be investigated then fixed

visual geyser
#

why "never"? I don't understand

cold agate
#

Because this is too focused on your specific example, it's not something we'd want to deploy and maintain for billions of 3DS events and the developer experience that goes with the cost of maintaining those events. I get the ask, I'm just trying to be clear about what we are likely to offer.
We've offered 3DS support for almost 10 years now in various ways and I have never seen the need for this (other than for cases like yours where the real issue is something went wrong in the confirmation/timeout)

visual geyser
#

to clairfy, there is something wrong, neither of us knows what is wrong, Stripe is unwilling to investigate this further without more information from the customer and there isn't a way we can automate getting that information for you?

#

and fruther, Stripe is unwilling to provide us a way to gather that information in an automatted way.

cold agate
#

unwilling is a bit strong. Impossible technically is better

#

Sorry, I get what you mean, but I'm not sure how to answer differently. We can't just go and push a complex infrastructure in Stripe.js to add various events to handleNextAction() just for your code. And we definitely can;'t ship this as a canonical feature (not without months of investments).

We can debug more internally. I did recommend working with the end customer to collect more details because it would help and your framing made it sound like the end customer could reproduce and was blocked from paying entirely. But you can reach out to support and discuss this with them and they can investigate the logs and try to track down what happened

visual geyser
#

Impossible technically is better
what makes it impossible exactly? it sounds like it would require some effort. I also think "just for your code" is excessively dismissive.

#

it would literally be to help you figure out what is wrong.

#

thanks for your help, I'll create a support ticket

cold agate
#

sorry I didn't mean to be dismissive, I'm just trying to explain that you need this for debugging

visual geyser
#

and what's wrong with that?

#

if we had this feture, I wouldn't have to try to get more information from the customer, who may be unwilling or unable to provide it

cold agate
#

The cost of development and maintenance is really high for something this specific. Most of what we ship in Stripe.js is aimed to work for years down the line.
My take is that even if this existed 5 years ago and you used it, it likely wouldn't have helped here assuming there is something wrong that got "stuck" inside Stripe.js somewhere.

visual geyser
#

I suppose my point is that Stripe should either 1) have this level of observability for themselves or 2) offer it to their customers so we can better diagnose the problem for you

cold agate
#

I think taking a bit of a step back if it helps provide some context: I've been doing this here for many years and I know our APIs inside out. So I was trying to be more direct about the next step instead of saying "that's a great idea, I recommend asking our support team to add this feature" which is a generic answer that usually goes into a backlog

visual geyser
#

honestly that's better than "never" which is objectively not true.

#

might we all be dead by the time the feature is added? yes, but that's still not never

cold agate
#

I disagree this is a better answer. I've done this for a long time and most devs here dislike the "oh yes we might add this" and they want the honest answer. I we don't add this in the next few weeks/months it doesn't really benefit the person asking for it.
But that's fair feedback overall and you can definitely ask our support team to track this feature request. It will definitely go in the backlog but it's true it could be built one day

visual geyser
#

I'm fine if you build the observability internally too, that's fine with me

#

but asking me to get more details from the customer seems like a gaiping hole in the observability

cold agate
#

Right now you have a one-off payment that never completed. It could be a lot of different things such as the browser crashing or the tab being closed. You mentioned having a video repro which implies the end customer is clearly on their device/laptop and not seeing anything happen visually in their browser.
In theory if they had a connection error somewhere, our own SDK (Stripe.js) should catch that and handle it gracefully. And what you describe about your own analytics is clear that you would have gotten the error and reported it somewhere.

So something happened somewhere that failed. We can investigate (and I did clarify this earlier) but having a clearer repro with more actionable details upfront helps make this much easier to debug. I know it's not great (and also called that out) but it is definitely helpful to collect the information especially if it is actively reproductible versus being a one-off weirdness.

So at this point, I'm really sorry about the interaction. I aimed for directness/quick recommendation but I definitely understand you preferred a different approach
So what I recommend is writing to support at https://support.stripe.com/contact and providing the info you have: your code, any metrics/logs you have around their attempt, the PaymentIntent id, the video and then our support team can investigate and narrow down what might have caused this