#Steve1662 - payment element return URL
uncut panther
bright dagger
hey there, can you share a snippet of your code where you're seeing this? I'm not sure I fully understand the issue you're describing.
bronze sundial
NP. Reference line 96 and the call to stripe.confirmPayment.
Docs I'm using: https://stripe.com/docs/js/payment_intents/confirm_payment
bright dagger
Steve1662 - payment element return URL
OK and where in your code are you seeing something unexpected?
bronze sundial
On our review step after I enter the 3DS cc number and other info and click our 'Pay' button the 3DS modal pops. Looks like this:
bright dagger
Which test card are you using?
bronze sundial
When I click either of the buttons on that modal the client side code execute the 'wasPaymentConfirmed' method (reference code line 67). It then does a GET to the redirect_url and then cancels the request. Looks like this in the browser:
4000008400001629 source: https://stripe.com/docs/testing
noble smelt
Hi there 👋 I'm jumping in as my teammate needs to step away shortly. I want to make sure I'm understanding your scenario correctly. Is it correct that the browser doesn't complete the redirect to the return_url? It just looks like it starts and then stops?
bronze sundial
Hey. Thanks for jumping in.
It does hit the return_url.... I'm running this locally and it hits my breakpoint.
noble smelt
Is this flow that you're testing publicly available somewhere that I can access so I can test it out?
bronze sundial
Unfortunately, it is not. The code has to work before we put it in our release pipeline.
noble smelt
The error that you're seeing for the request to the provided return url, is that error being thrown by your code?
bronze sundial
The return_url does not throw an error. It works as expected.
What appears 'off' to me is the call being made to the return_url is cancelled. Fairly sure this would be in stripe's code. Reference the call chain:
noble smelt
I'm going to run some tests on my test site and check whether I see similar behavior.
bronze sundial
👍
noble smelt
I believe I'm seeing the same behavior, where when using a 3DS card there is a request made to the return_url, however I'm not being redirected to that return_url.
bronze sundial
Glad you're able to reproduce. Is that expected?
noble smelt
I'm not sure off-hand, and am looking into that.
Sorry, reaching out to my teammates about this, and I will probably be a bit.
bronze sundial
Got it. Thanks.
noble smelt
Apologies for the delay, and thank you for your patience. This is not expected behavior, and is something that our teams are currently looking into.
I do want to add a little bit of additional context that I have, in case you see a difference in that behavior based on the test card that you use. It seems like this behavior is currently only impacting 3DS1 authentication flows, and that if a card uses 3DS2 then this behavior is not being encountered.
bronze sundial
Ok. Would a ticket be created or how would I go about tracking the status this?
Follow up question. Via the stripe dashboard I can see the 'Payment authentication' report and get the count of payments that are impacted. Is there any way to know the ones that would be 3DS1 vs 3DS2? I ask because I'll have to answer the impact of this if we were to release this change.
noble smelt
We don't do tickets from this forum, but you could reach out to our support team to get one started for this topic:
https://support.stripe.com/?contact=true
Sorry, we don't know much about the reports that are available in the dashboard and whether the new authentication report provides details of 3DS1 vs 3DS2. Our support team may have more insight on that. The only thing that is jumping out at me from looking at the structure of what is shown on that page, is that frictionless authentications are only available with 3DS2.