#stenerali_unexpected
1 messages ยท Page 1 of 1 (latest)
๐ 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/1372641400641818845
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi ๐
Do you have example Payment Intents that show this state?
FWIW we have always strongly recommended against using Android WebViews and requested they use an actual mobile browser (Chrome, Firefox, DuckDuckGo). Much of the automatic functionality will be lost when using WebViews
yes, it's a mobile browser like chrome. pi_3RIr0wS1HYRUgD7I0MhuJCQD in acct_1PBX7HS1HYRUgD7I is a recent example
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Mobile Safari/537.36 EdgA/135.0.0.0
if you look at that account and filter on incomplete payment intents, you'll see a large volume since apr 27th and they are all 3d secure issues.
Unfortunately I can't see the Payment Intents associated with that account directly (we don't look at your dashboards unless we absolutely have to).
I can see that this Payment Intent entered a state of requires_action after the attempt to confirm. Also that this is being handled by the Payment Element with a deferred intent integration.
But that should have automatically triggered a 3DS challenge ๐ค
The payer reports they are not getting prompted for anything, the checkout button spins and eventually errors out withwhat looks like a decline
so the payment element is not providing the 3d secure challenge
Testing something myself
I tested in our test environment, and 3d secure is working from the test card flows. But I'm only able to test in desktop browsers.
Hmmmm... I was able to complete a Payment in my mobile Chrome browser
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Mobile Safari/537.36
Similar user-agent
are there known issues with 3d secure on mobile browsers when it comes to popups or blockers maybe?
Let me check with my colleagues.
Hello, my colleague has to step out but I am continuing looking in to this. I was able to complete 3DS on an android 10 device too. Not immediately seeing other reports of this issue but am still looking
Also how is 3DS being triggered on your page? Is the payment element directly confirming the intent and automatically showing 3DS when needed? Or are you using a method where handleNextAction needs to be called?
we are leaving it to the payment element during direct confirm.
Do you have a public test page I can try out our test 3DS card on? If I can reproduce it myself there that could be very helpful in us finding/addressing the issue.
unfortunately not. we only allow live mode in our public facing page
Gotcha, also just to make sure, you are the platform here for these calls correct? I do see other instances of that browser making payments successfully with 3DS on your account since. The unfortunate thing is that the failure isn't creating a specific failure on our end, it just looks like a lack of next step
Yes, we are the platform here. Unless you see something on your end in logs that indicates a problem in those requests, I guess our next step is to try and recreate with an appropriate browser in our test environment. Thanks anyway
Gotcha, if you do have further examples I can escalate them and see if my colleagues are better at finding patterns here. Though if you can find a way to consistently reproduce this that would be very helpful.