#gallopinggoose_14721
woven urchinBOT
Hello! We'll be with you shortly. 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.
- gallopinggoose_14721, 3 days ago, 15 messages
woven pawn
Hello! We're not constantly updating the card behaviors, no. As you pointed out we did switch them from 3DSv1 to v2 recently, which is likely the cause of the issues you're seeing. Maybe the cards are interacting with your Radar rules differently now?
graceful cove
Would radar rules explain this behaviour? It seems like the underlying property of the cards are different than documented atm. For example, 378282246310005 is now acting the same as 4242424242424242, in a way that is expected for 4242 but unexpected 0005. From my testing results this seems to be a bug? But that's just based on the Dashboard and not looking under the hood
In the way that 4242424242424242 was asking for a challenge last week, that seemed to be a bug that was fixed
woven pawn
Can you clarify exactly how 378282246310005 is behaving in an unexpected way?
graceful cove
It should be acting as "3DS not supported", which I think looks like this https://dashboard.stripe.com/test/payments/pi_3Oe5VT2k4WuoSsum0ECxYWSX "3D Secure was attempted but is not supported for this transaction"
At the moment it is acting like this https://dashboard.stripe.com/test/payments/pi_3OeLaj2k4WuoSsum0dCQ7PSW "3D Secure attempt acknowledged"
woven pawn
Why should it be acting like 3DS is not supported?
graceful cove
Which is more similar to 4242's 3DS supported, Unenrolled
You can see 4242's similar behaviour here (https://dashboard.stripe.com/test/payments/pi_3OeLeC2k4WuoSsum1I7TPxsv)
Last week, 4242 was erroneously asking for a challenge (https://dashboard.stripe.com/test/payments/pi_3OczY62k4WuoSsum1iiXgrEb) so its clear that the underlying 3DS behaviours have been changing
As I understand it, radar rules only change requests for 3DS but cannot dictate how the 3DS is processed, and that is an underlying card property
woven pawn
What's your ultimate goal? Is this behavior breaking something on your end?
graceful cove
Yes our frontend automation processes have been working around 3DS and the transition from 3DS1 -> 3DS2 test cards broke our automation since the confirm process seems to process differently now. We got around that temporarily by using 0005 since it avoided 3DS but now it seems like its broken again because it still goes into 3DS supported flow. The ultimate goal is to get that working again haha. My purpose for asking today is: 1. Confirm if the behavour of 0005 is indeed unexpected, 2. Ask if there is a changelog for these invisible processes where we can keep updated on these changes as the docs seem to be out of date
Just another example of the docs being out of date, the test cards seem to be differentiated between 3DS2 and 3DS still, when they should all be labelled as 3DS2 now https://stripe.com/docs/testing#three-ds-cards
woven pawn
Let me investigate internally, hang on...
graceful cove
Thanks, I appreciate it
woven pawn
Sorry for the delay, there's a lot going on in this area currently. 😅
graceful cove
No worries, I expected that was the case
woven pawn
Okay, I can confirm the 378282246310005 test card supporting 3DS is a bug and is slated to be fixed. There is not currently an ETA for the fix, unfortunately.
graceful cove
No worries, its nice to know that I'm on the right track
woven pawn
I can also confirm the Radar "request 3DS if supported" rule is triggering 3DS on almost all test cards now, where as it wasn't before.
graceful cove
Is there anywhere I can monitor for these changes?
graceful cove
I can also confirm the Radar "request 3DS if supported" rule is triggering 3DS o...
Is this intended?