#atronador_unexpected
craggy cosmosBOT
👋 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. Thank you for your patience!
⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.
🔗 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/1214667941359128709
📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.
spare micaBOT
quiet lynx
Thank you for sharing the examples. I believe are some error codes for which Stripe retries charge automatically. I believe authorization_required is one of them
calm silo
Understood...but this is not ncessarrily a 3DS auth, right? I mean, it doesn't seem like the user is involved. And the charge goes thru as a regular, non 3ds charge. The reason I'm asking was to make sure I'm not adding friction by actually avoiding 3DS for these cases...
quiet lynx
@honest ledge please open a new thread following the guidelines in #help channel.
I think the first decline here was from issuer wanting to run 3DS auth check.
When stripe retried, I believe 3DS was prompted and the customer authorized the payment.
calm silo
hmmm...but if that was the case the payment would end up being 3DS protected, and it is not.
This patter is common. I have 30 or 40 payments like this today..
quiet lynx
Let me talk to a colleague about this
calm silo
The rule that avoids the 3DS specifically also checks if three_d_secure is recommended or required..... If it is recommened or required, it does not avoid it
Looking at the logs, I get the feeling this is some sort of silent retry, but not sure how or why the payment overrides the authorisation-required, and is still not 3DS.
Thanks..
quiet lynx
So the customer did go through 3DS for the successful charge. However, it's something that can happen with MasterCard transactions, it's transparent to the customer (they don't get a challenge or any added friction), it improves conversion, and reduces fraud.
calm silo
hmmm...but from a fraud perspective, since I don't see a 3ds (whether explicit or flow), should i expect the charge to have liability shift?
Is there any way to check on the logs or any parameters that may indicate so?
Usually when a charge goes thru frictionless 3ds, at least there is a comment and explicit message about this.
There is nothing for these..
quiet lynx
For the type of 3DS customer went through (transparent), it is not eligible for liable shift no.
calm silo
hmm...ok, strange. Thanks!
quiet lynx
Yeah, sorry for a bit vague answer but this sort of authorisation flow is a bit hard to grasp for me too 😅
calm silo
no worries!