#Shadowed
trim cobalt
last solar
Hi there!
It's completely up to the bank to request 3DS or not. So your application need to handle the case where 3DS is required for an off session payment: tell the customer to come back to your website/app, and re-confirm the PaymentIntent on the frontend to trigger the 3DS flow.
cyan flint
Sorry I was not clear enough in my previous (long) message. I already implemented everything that is required, as per documentation, in order to enable 3DS validation and off_session payments.
However, the specific test card that I provided, is reflecting the case when the 3DS validation is ALWAYS required, even for off_session payments.
What I want to do is to identify these kind of cards (always requiring 3DS) because, due to my current flow, I need to do the payment only off_session without having 3DS validation for every single payment.
So if it is not possible to overcome this issue, I need at least to identify these specific "always requiring validation" 3DS cards.
For example, among the possible 3DS test cards, there are:
- 4242 4242 4242 4242 - Only requiriing 3ds configuration once, every future payment intent is accepted without 3ds
- 4000 0025 0000 3155 - Requiring 3ds configuration and validation once, every future payment intent is accepted without 3ds
- 4000 0027 6000 3184 - Always requiring validation, every future payment intent is always requiring 3ds.
the third case is the case that is incompatible with my current payment flow
I need to identify these kind of cards. How can this identification be achieved?
last solar
What do you mean by "identify these kind of cards"? You can't know in advance whether a card will require 3DS or not in the future.
It's the bank, that for every transaction, decide if they want to show 3DS or not.
cyan flint
So you confirm that, in case of card number 3, the user configures and validates the card once the he/she adds it. However, when doing the a off_session payment intent, the transaction will be declined, because the user needs to do the 3DS validation again. Right?
last solar
Yes, test card 3) above will always require 3DS. so for off_session the payment will be declined
cyan flint
Therefore, when the user is adding this kind of card (3), how can I inform the user that he cannot use this card?
last solar
You can't know in advance whether a card will require 3DS or not in the future.
There is no "this kind of card" in real life. This is just a test card to run some tests while building your Stripe integration. In real life it's the bank that will determine for each transaction whether or not run ask for 3DS.