#George Farhat
slim moat
hello! not necessarily, it's up to the issuers to determine whether 3DS is required, we wouldn't have full context over how or when the issuer needs 3DS
broken frigate
so is there no benefit to asking for the CVC on every consiquent purchase?
slim moat
although personally, i think requiring and going through 3DS is a way better way of preventing fraud
broken frigate
i see
When an attached method that has been saved for future onsession usage, gets used in a new intent without reentering a cvc token, what does the reponse come back with regarding the cvc check?
would it be unchecked or incorrect?
slim moat
hrm, it should be unchecked
broken frigate
ok
if i have a new user, and:
1-I collect a payment method before creating an intent with CVC in the Card Element
2-I create the intent (confirmation method AUTO, capture method MANUAL) with the method id from step 1
will the intent response have a cvc_check field?
slim moat
is there a reason why you're handling them in separate steps though?
you would save the number of steps/requests if you did them both in a single step
and used the Payment Element with a PaymentIntent instead of the card element + PaymentIntent
broken frigate
sorry i do use PaymentElement
not card element
but the process must be collect method details first, and then create payment intent server side
i have discussed this with your colleagues already and we reached that conclusion (for the steps/process)
slim moat
ah, i see. I don't know the answer off the top of my head, i'd suggest testing it out to see
broken frigate
right
in the types i dont see something relating to cvc checks
and all test cards ive seen dont check cvc
do you have a full list of all the test cards somewhere ?
actually i found the list
would you know if the cvc check happens when the payment intent is confirmed or when the intent is captured?
slim moat
the cvc check would occur when the PaymentIntent is confirmed (if it does). Definitely not when the intent is captured
thorny gyroBOT
slim moat
hmmm, actually, just a quick update here, it's not going to be possible to check this in test mode i think - the cvc_check will always be null since that data is never actually sent to the bank
Also, a correction to what i mentioned before -
When an attached method that has been saved for future onsession usage, gets used in a new intent without reentering a cvc token, what does the reponse come back with regarding the cvc check?
would it be unchecked or incorrect?
It might be unchecked or null - i'm not entirely certain which off the top of my head, you might want to write in to https://support.stripe.com/contact/email to see if we're able to confirm that for you
broken frigate
ok i see
so the cvc check happens on confirmation
its not in the types of the response of the intent creation though
is this something i have to expand?
slim moat
are you creating and confirming in the intent creation?
void prawn
You should be able to find the cvc_check field on the associated Payment Method objuect (if a card): https://stripe.com/docs/api/payment_methods/object#payment_method_object-card-checks-cvc_check
You'd need to expand the payment_method field on the PI
broken frigate
ok great
ill do that
thank you!
if the radar is set to block cvc fail, will the intent be created?
will the request fail or will the response come back with last_payment_error?
void prawn
I believe the PI would be created, there'd just be a failed payment attempt yes
Easy enough to test with: 4000000000000127
Or pm_card_chargeDeclinedIncorrectCvc
broken frigate
i see
so would i be able to re-attempt with the same intent but updating the cvc token?
void prawn
Well, not using that specific test card. You'd need to use a different card
broken frigate
yes ofc, i meant that if a card fails on cvc, if i would be able to re-use the same intent with a an updated cvc token
so i re-confirm the intent
void prawn
Yes, exactly. Re-confirm the same PI with an updated payment method
thorny gyroBOT
broken frigate
ok great