#tuan-tran_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/1222550675960103075
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
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?
Yes, we have
You can access this page, add a ticket to cart then provide an email and checkout with Link
Wonderful, thank you. Passing that on
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.
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?
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.
So you're saying three payments need to be completed to see what you're describing?
That's right. I'm sorry for that missing step.
Gotcha, let me step through that.
UserA checked out the first time. UserA checked out one more time and entered the OTP. Then UserB checks out.
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.
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.
I'm pretty sure there is not a way for you to forcibly invalidate the stored authentication.
Thank you for the information, toby!
Should I wait here for your checking with the team?
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.
No problem at all, please take your time.
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.
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.
Any time, glad I could help!
Have a great day, bye bye!