#tuan-tran_unexpected

1 messages ยท Page 1 of 1 (latest)

tight wigeonBOT
#

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

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

thin oysterBOT
peak dune
#

I am reaching out to my colleagues about this behavior and will get back to you with what I can find.

#

Do you have a test site where we can see this behavior?

verbal perch
#

Yes, we have

#

You can access this page, add a ticket to cart then provide an email and checkout with Link

peak dune
#

Wonderful, thank you. Passing that on

verbal perch
#

Then open this page again, enter another email to checkout, and try to checkout with Link again. You'll see the authentication session of previous user will automatically login.

opal grove
#

Hi there ๐Ÿ‘‹ I was taking a look into this for you.

I ran through this flow on both your test site and mine.

I see the behavior you're describing, but also see that A) the previous email address is partially obfuscated and B) that the second payment can't be completed using the previous customers Link account unless they're also able to complete the 2FA challenge that gets triggered. Without access to the phone or email that belongs to the previous customer, that second payment can't be authorized and completed using the first customer's Link account.

Does that align with what you're seeing in your testing?

verbal perch
#

You're right. But if the UserA checkout the second time and passes the 2FA step. The third checkout session will not need the 2FA.

opal grove
#

So you're saying three payments need to be completed to see what you're describing?

verbal perch
#

That's right. I'm sorry for that missing step.

opal grove
#

Gotcha, let me step through that.

verbal perch
#

UserA checked out the first time. UserA checked out one more time and entered the OTP. Then UserB checks out.

opal grove
#

Ah, yeah, I see what you're describing, and can definitely understand why this looks unexpected. I'm going to try to check with my teams to confirm whether this is expected, and we anticipate customers will not use Link on shared devices.

verbal perch
#

Yeah, we understand how it works like that. We just want to confirm if this is expected and if there is a way to invalidate the Link authentication session from our app. Once we have this information, we can decide whether we want to change our approach.

opal grove
#

I'm pretty sure there is not a way for you to forcibly invalidate the stored authentication.

verbal perch
#

Thank you for the information, toby!

#

Should I wait here for your checking with the team?

opal grove
#

Yup, I'm typing that out now. I'll let you know if I get the sense I won't get a timely response to that.

verbal perch
#

No problem at all, please take your time.

opal grove
#

What I'm gathering so far, is that this is expected behavior, and that our teams are aware of this specific scenario that is a consequence of how we're handling this flow currently. It sounds like it's something we're hoping to improve, but I don't have context on what those improvements would look like or when they may be made available.

verbal perch
#

Thank you for the update. I will discuss this with my manager and contact Stripe in case we would like to request an enhancement.

#

I think that's all for me for today. Thank you so much for the great support.

opal grove
#

Any time, glad I could help!

verbal perch
#

Have a great day, bye bye!