#vlad_api
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/1426156862885068933
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- vlad_api, 3 days ago, 10 messages
I mean, I expect 0341 to fail with general decline, but right now it's failing due to 3DS
What is the goal of your test ?
We just test different aspects of our interaction with Stripe, and for that particular one - our handling for the failing payment
But does it matter? Right now I'm trying to understand why 0341 returned 3DS action required instead of regular decline
I don't think it does actually, your integration should handle both declines and 3DS
you can consider both failure or handle the 3DS one
We do, but in the documentation
https://docs.stripe.com/testing?testing-method=tokens
It clearly states that that card / token would fail the attempts of charge without any mention of 3DS
You do have additional section of 3DS cards, and we're using them for tests as well
Does it mean that any card can cause a 3DS confirmation right now instead of just the ones mentioned in 3DS section?
I don't think it does actually
I don't really understand that as well
I provided event id evt_3SGdfRKbHTyAU2AT0HXePz8M
It has a status requires_action while attemps to charge 0341
Yeah I agree, not sure why 3DS was triggered for that one honestly
Yea
Today it's reproducing constantly under such requests
req_oG75ifD6uoFJjV
Can I wait here until you know the core reason? Or you wouldn't check it for now, and I should expect requires_action for now?
And what happens if you confirm the 3DS ?
Let me try it out
After 3DS confirmation I'm getting generic decline
So card behave as usual except trigger of 3DS check before failure
Here's invoice id i was testing it with
in_1SGeYhKbHTyAU2ATKsbieU5T
The weird thing that seems it's requiring 3DS only on subscription update, but sign up still declines immediately
Please, lmk if you'd take any actions / investigate it on your side, so I know what to expect
Hey, I'm not sure either why the 3DS auth is being required, but I guess ultimately it is doing a fail which is the expected outcome
Hey
Yes, I agree, but we intentionnaly use 0341 to test cases of decline w/o 3DS dialog, and except of this card I don't see any other possibilities of doing it
I'm aware that we should support 3DS everywhere, but still
Can I ask you send us a support ticket, so that we can raise this to the internal team responsible for this, as it does seem not ideal that this beahviour occurs?
I can send you a DM with the link to do so
Yes, let's do it
I'll be more comfortable on proceeding with email as well
Hello @old magnet, we have sent you a direct message, please check it at https://discord.com/channels/@me/1426176145786798145
- 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
Done, thank you for assistance