#nielsen_best-practices
lean tapirBOT
đ 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/1333930948823224421
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
vast fractal
Hi there
Just to make sure we're on the same page, is your goal to decline/return an error if a customer attempts to pay with a card that requires 3DS?
hexed knoll
Effectively yes, and we basically do that now. But what appears to have happened is that the customer ended up with duplicate charges and created a dispute
the "incomplete" Payment intent is the one that required 3DS
the one that is disputed somehow did not require 3DS and went though
thru**
even though it was the same payment method
hexed knoll
pi_3QgqfCIv5qZ8Xj8O0pPHUaYp
pi_3QgqZWIv5qZ8Xj8O0lwuMVN8
vast fractal
Thanks!
I see like a 5 minute gap between these so something in your app triggered the creation and confirmation of pi_3QgqfCIv5qZ8Xj8O0pPHUaYp even though a previous attempt to charge this PaymentMethod resulted in a 3DS request
Taking a step back, I was referring to this parameter: https://docs.stripe.com/api/payment_intents/create#create_payment_intent-error_on_requires_action
I don't see you using error_on_requires_action when creating and confirming PIs which means PIs are allowed to transition to requires_action instead of returning an error
hexed knoll
Yes for sure the user tried to pay twice
For the payment intent that shows incomplete. would that show up in the customer's bank account though?
We have not bee able to communicate with the end customer about this, but the dispute says it's for a duplicate charge which leads me to believe that in their pending transactions they saw 2
So the first time they tried to pay, we return to them a failure. They try again and it was sucessful
they then saw in their credit card/bank account had 2 charges and disputed one
that's my guess of what's going on but I wanted to confirm with Stripe
vast fractal
Hm, so there usually would only be a record on the customer's statement if the PaymentIntent is confirmed. In the case of the PI that required authentication, the confirmation attempt has not been completed so I wouldn't expect this to show up on the customer's bank statement
However, their bank might be doing something different and may have surfaced this to the customer, it's hard to say
hexed knoll
Ok, if we set the error_on_rquires_action flag to be true what happens to the payment intent? does it get cancelled?
vast fractal
If you use error_on_requires_action when creating the PI, a PI is never created. Instead you get a 402 error with the decline code authentication_not_handled
hexed knoll
Ah ok, that may be the way to go for us then.
Lastly, why did the 2nd payment not require 3DS?
vast fractal
That was up to the issuing bank. I see they didn't require 3DS when the customer first set up this card client side via a SetupIntent
Note that even after setting up a PM for future off-session payments, issuing banks can always decide to require additional authentication
hexed knoll
So am I correct in my understanding that, a bank can at any time decide to require 3DS and that there is no*** stripe dashboard configuration/setting that we can do to prevent from using/storing such payment methods?
vast fractal
Well, if you use error_on_requires_action, you can then prompt the customer for new payment details and also detach the PM you tried to use initially. That said, as you saw, it's still possible that a bank may not require 3DS on a future payment with that same PM