#daniele_radar-block
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/1227187534518419456
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
screen here for more immediate info
You'd like to know why the initial attempt was blocked, but the subsequent attempt succeeded?
Looks like there was no CVC passed with the initial payment attempt, so as per the rule in your screenshot it was blocked
Follow-up attempt provided the CVC and it passed the check with the issuer
are we sure that's what happened?
cause it also says that 3DS was attempted but the customer could not be verified
Totally unrelated – 3DS was attempted but either not supported on the card or customer not enrolled
alright, ty
In those scenarios we will try and proceed without 3DS:
If the issuer doesn’t support 3DS at all or has an outage, Stripe might attempt to complete the payment without authentication if permissible.
https://docs.stripe.com/payments/3d-secure/authentication-flow#:~:text=If the issuer doesn’t support 3DS at all or has an outage%2C Stripe might attempt to complete the payment without authentication if permissible.
Other scenarios: Depending on the reason the payment triggered 3DS, it might be permissible to continue authorization for the charge in edge cases. For example, a result of attempt_acknowledged leads to a charge and the PaymentIntent transitions to a status of processing.
Is essentially what happened with that 3DS challenge flow