#carson-3DS-testing

1 messages · Page 1 of 1 (latest)

slim agate
#

Hi there 👋 is this behavior consistently seen when using these two cards?

clever escarp
#

hi! yeah it seems like i can replicate it pretty easily

#

have done it a few times now with both and get consistent behaviour

low hare
#

Hello. Taking over for toby here. Can you try replicating it with your browser console open? What do you see in there?

clever escarp
#

don't see anything in there, i logged out the response, from confirmCardSetup() and i get a successful setup intent back

low hare
clever escarp
#

sure yeah give me a sec to grab that

#

i believe it's this one req_y0IGuZYIV3yl8N that's the one where i used the test card 4000000000003063

#

and then i believe req_ZoyiMKL0MlNuh1 is the id for the test card 4000000000003220

low hare
#

Gotcha. I'm going to ask a colleague about this, and I'll get back

clever escarp
#

hm, is that something that is an extra cost though?

#

is it the case that if we're not using Radar we have to build some extra functionality to support 3d secure? basically this has popped up because we've seen a few customers process a payment and get through our checkout but it comes through as incomplete due to 3d secure

lethal ocean
#

Hi Carson, I'm stepping in here for my colleagues.

#

That feature will use Radar to trigger 3DS on SetupIntents. 3DS will still be triggered on SetupIntents if the issuing bank requires 3DS.

#

However, the test cards you are testing with should only trigger 3DS based on Radar... so you really should be seeing the same behavior with both cards.

#

Will you toggle the setting and test again? That would help me determine if there is a bug with one of the test cards triggering 3DS with a SetupIntent without the necessary SetupIntent Radar Rules enabled.

clever escarp
#

ah yeah, looks like with the toggle on 4000000000003063 now shows the 3d secure modal

lethal ocean
#

Thanks for testing. This is an issue on our end and I'll file a ticket to get that fixed.

clever escarp
#

sounds good. i guess, does that mean anything for the issue im seeing where it seems like users are not seeing the 3d secure modal when they check out? would it be related to the radar rules not being on in the case where 3DS is required but not 3DS2?

lethal ocean
#

Can you provide me an example SetupIntent where you are seeing this behavior?

#

I just want to verify.

clever escarp
#

an example being an ID or something? or what can i give you to show you?

lethal ocean
#

Yes an example SetupIntent ID (seti_xxxx)

#

Or PaymentIntent ID.

#

Whatever is easiest.

clever escarp
#

pi_3KTopVJFtSe3alJH0JAuUAuy

#

that's a test one

lethal ocean
#

Thanks! Looking!

#

So for that example, 3DS is triggered due to your Radar rules + the 3063 card.

#

To confirm, you said you are seeing incomplete payments in production after a paymentmethod was set up with a SetupIntent?

clever escarp
#

it seemed to be that way, but i think it's actually when we trigger a paymentintent after a successful setup intent

#

which doesn't make a lot of sense i guess because usually the 3ds would come after a setupintent correct? it wouldn't be the case where the setup intent succeeds and then when we trigger a payment intent, that would require 3ds would it?

#

here's one from production, it ended up succeeding after because we asked the user to update their cc to try to resolve this: pi_3KR1nmJFtSe3alJH1CL5BKnu

lethal ocean
#

It is a bit complicated... first, the issuer can always require 3DS regardless of whether the card was set up previously. Second, on a small subset of SetupIntents we don't actually talk to the issuer and thus won't necessarily run 3DS. This is to prevent card-testing (we talk about this here: https://support.stripe.com/questions/check-if-a-card-is-valid-without-a-charge). You can still force 3DS on all SetupIntents via the API (https://stripe.com/docs/api/setup_intents/create#create_setup_intent-payment_method_options-card-request_three_d_secure) if you so desire, though I wouldn't really recommend that.

#

Thanks let me look at that example

clever escarp
#

hm i see

#

is the reason you dont recommend it because it's a bad user experience?

lethal ocean
#

Yes, I'd only recommend running an end-customer through 3DS when it is necessary.

#

Else your conversion will drop

clever escarp
#

yeah, makes sense

#

i think i have an idea of what might be our problem

#

i think maybe the setupintent is working fine for us, but we process the paymentintent through the backend and maybe it's not communicating properly with the front end to let it know it didn't pass

lethal ocean
#

For that example, you used a SetupIntent and then immediately charged the card. Is this your normal flow?

#

If so, you really don't want to be using a SetupIntent at all.

clever escarp
#

it's not immediate but it's shortly after

#

and we want to do it that way for recurring payments

#

/ to be able to charge offline

#

and i believe for another business related reason but i can't remember at the moment

lethal ocean
#

But you can set up a card for recurring payments (and offline payments) using a PaymentIntent by passing setup_future_usage which you are currently doing. And, this will make it more likely for 3DS to be run while your customer is on-session.

#

Okay I'd recommend checking on that. If you are charging ~immediately then you really don't want to use both a SetupIntent and a PaymentIntent.

clever escarp
#

hm yeah i think we explored this option but i can't at the moment remember why it didn't work for us

lethal ocean
#

Gotcha

#

Okay, well, the most important thing here is that you have an established flow to bring your customer back on-session to complete 3DS when it is required by the issuer.

#

With the example you provided, we did talk to the issuer for the SetupIntent confirmation and they just didn't require 3DS, but then they turned around and did require it on the actual charge just thereafter.

#

This does happen and you just need to be prepared to handle this scenario.

clever escarp
#

gotcha

#

that's weird that banks do it like that

#

maybe they think it's weird that we set up our payments the way we do lol

lethal ocean
#

Yes... it is mostly due to their own fraud models.

clever escarp
#

i think we decided to do a setup intent because we want to occasionally check the user out for free, but setup a creditcard on file for future payments, and paymentintents didn't allow us to do that, we had to charge a minimum of $0.50 or something

lethal ocean
#

Yes okay, that makes sense. In that case I would only use SetupIntents for that use-case, and just use a PaymentIntent for all customers that are paying immediately.