#thepera-3ds-payments

1 messages · Page 1 of 1 (latest)

outer cargoBOT
woeful ember
#

thepera-3ds-payments

#

So you need to make sure you use the "right test card" to model the flow you are after

cinder mica
#

I did notice that actually previously i was using 4000000000003220 which was just wrong as it required 3DS ALL the time

#

I then switched to 4000000000003055 which i assume should work for my case

#

but when i used that to create the payment method and intent it never generated a 3DS flow even once

woeful ember
#

Give me a concrete example of a pi_123 and I can look

cinder mica
#

seti_1MoCovBSvemLMLiIOiKXkzkl

#

this would be the setup intent

#

i expected it to give me the 3DS flow but it did not

#

unless it has something to do with radar settings? but im not too familiar with how that works

woeful ember
#

you're going too fast and typing short sentences. Please try to summarize clearly like your first question originally. I need the PaymentIntent where the 3DS is required and shouldn't

#

I looked at the Customer associated with that SetupIntent but you never used it for a PaymentIntent? So I'm not following what the problem is @cinder mica

cinder mica
#

My apologies. Here is the paymentIntentID that I just generated using CC 4000000000003055. PI: pi_3MoDRPBSvemLMLiI09TcjFte. I expected to be challenged for 3DS here so I could test if creating a setupIntent would make it so that the user would no longer be challenged for 3DS in the future when using this payment method. I just generated a new set, sorry for the confusion.

woeful ember
#

his card requires authentication for off-session payments unless you set it up for future payments. After you set it up, off-session payments no longer require authentication.

#

the PaymentIntent you just created it not off session.

#

so that's the disconnect/confusion. If your customer is on your website paying again, most banks will want 3DS again. It's fine, you confirm client-side, do 3DS as needed and it works.

#

Skipping 3DS is usually something you do when trying to charge the card after the fact, like a Subscription, or some incidentals after a rental. In that case you have to pass off_session: true on the PaymentIntent creation. And you also confirm server-side.

#

In that case 3DS would be skipped

#

but for on session payments, that test card will always require and do 3DS

cinder mica
#

I see that makes alot of sense. Thanks for clearing that up! My second question then is how come this card did not prompt a 3DS flow? It just worked right off the bat even tho it is listed as a 3DS supported card? Does it have something to do with radar rules (Im not too familiar with that unfortunately)

woeful ember
#

In which case? In the SetupIntent or the PaymentIntent?

cinder mica
#

The payment intent: pi_3MoDRPBSvemLMLiI09TcjFte

woeful ember
#

3DS isn't really a guarantee.

#

Sorry I worry you're thinking about this the wrong way. Your integration is correct, it will "just work" you're fine

outer cargoBOT
cinder mica
#

Ok i think i understand, so basically if I want to take an off session payment i have to pass off_session: true when creating the payment intent. After that it does not matter if the CC used requires 3DS or not, it will work.

woeful ember
#

not exactly: in that case, we will "try to skip 3DS" and the bank will "hopefully say yes" but in other cases it will be a decline (similar to not having enough funds)

cinder mica
#

I see, is there no way to guarantee that it will be a success? For example creating a setup intent with off_session: true when they first enter their payment method. Then when we create the payment intent with off_session: true then it should always work? Sorry if this doesnt make sense. Still tryng to learn how to use Stripe.

woeful ember
#

no, you can never guarantee a payment will be a success

cinder mica
#

I see alright, ill do some testing with this new info and see if it works. Thanks for your time!