#Ioanna
1 messages · Page 1 of 1 (latest)
Yeah or not allow the user to add a 3DS payment method because there is a certain type of card that regardless the setup will always require authentication
Yes
Gotcha
Hmmm yeah so we only support errors_on_requires_action for PaymentIntents and not SetupIntents
Why do you not want to have a customer go through 3DS exactly?
Because basically the way this works is they set up their payment intent and when they use a credit to perform and action on the web app I hold the funds and capture them on action completed. And noe I've ended up with a bunch of payments I can't capture
I'm not sure I understand. If they complete 3DS on set up then we apply for an exemption from 3DS in the future and (the vast majority of the time) they should not be required to authenticate again for the off-session charge
Can you provide me an example I can look at?
ofc 1 sec
pi_3Mg3DxK9qmDpbyxA0CW5MHM5
and somehow his first credit got charged just fine: pi_3Mg2sSK9qmDpbyxA1BAuljVY
which has confused me quite a bit
Thanks looking
This test card seem to replicate the error
The weird thing is that normally I would expect to not be allowed to capture the funds either if I need authorisation to collect them
Well you are attempting to authorize when you create/confirm the PI
ok is there a workaround?
So yeah this example does look like the issuer was just weird and still forced 3DS even though the card was set up correctly initially.
There is no way to predict this from happening
It is always ultimately up to the issuer for whether 3DS is required. So if you want, when you create the PaymentIntent you can pass errors_on_requires_action (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-error_on_requires_action) to know that 3DS was required and handle accordingly. But the only way forward here is to bring the customer back on-session to either complete 3DS or collect a new payment method.
got it ook thank you very much!