#sandy.nozaki

1 messages · Page 1 of 1 (latest)

marble boneBOT
terse basalt
#

Hi there! Just to confirm, are you using the legacy Charges API or working with PaymentMethods and PaymentIntents?

umbral ether
#

currently legacy but will migrate to paymentintents

#

currently, on our platform...our customers check out with an agreement...sellers confirm the order and charge when they are ready to ship at which the final amount updates due to shipping costs. There's no other action needed for the customers after checkout.

terse basalt
umbral ether
#

so youre saying with paymentintent, you can authenticate the card at the time of saving the card?

#

well i think currently when we send card info via stripejs stripe verifies/confirms the card details with the issuing bank then if successful returns a token to us

#

so ok validating card is currently already being done

#

but thats not the same thing as 3ds

terse basalt
#

when you create a PaymentMethod and attach that PaymentMethod to a customer, this could also trigger a card validation

#

that's correct, 3DS is totally different

umbral ether
#

yeah so thats clear...

#

i want to know if we can use 3ds

#

in our currently payment flow

#

from my knowledge, customer needs to be present in the whole payment flow in order to authenticate with 3ds

#

is that true?

terse basalt
#

The legacy Charges API does not support 3DS/Strong Customer Authentication

umbral ether
#

yeah but im saying with paymentintent

terse basalt
#

The PaymentIntents API does support 3DS and yes, a customer must be on session to complete the authentication.

umbral ether
#

if we were to migrate to paymentintent, does the customer still need to be present thru the whole payment flow aka completed payment?

terse basalt
#

If you want to save a card for future off-session use (while a customer is not present), you should use SetupIntents to collect payment details. If 3DS is required at that point, the customer will go through that flow. You can later use the saved payment details for off-session payments but it's still possible that issuing banks may require additional authentication from the customer again

#

If that's the case, the PaymentIntent will be in a requires_action state and you'll need to bring the customer back on session to complete authentication

umbral ether
#

ah so at the time of actually processing the final payment, the customer will need to be present?

terse basalt
#

they may need to be present for the actual payment, depending on what their bank decides

umbral ether
#

so if we saved cards using setupintents to collect payment details and 3ds was required which was completed then used that card for future payments(bank didnt require authentication), would we qualify for a liability shift?

terse basalt
marble boneBOT
umbral ether
#

currently, on our platform...our customers check out with an agreement...sellers confirm the order and charge when they are ready to ship at which the final amount updates due to shipping costs. There's no other action needed for the customers after checkout.

#

i want to know how and where we can implement 3ds

torpid barn
#

Hi @umbral ether I'm taking over.

#

The card issuer determine if a 3DS is needed, and your customer will be asked to complete a 3DS authentication when required. If you want to enforce it, there's a radar rule allows you to request 3DS when the card supports 3DS.

umbral ether
#

ok but wouldnt the customer need to be present for it?

#

cos currently our customers just check out meaning theres no auth or capture on their side

#

once they check out our sellers/connected accounts confirm the amount and capture it

umbral ether
torpid barn
#

When you 1/ attach the card to your customer and 2/ charge the card.

umbral ether
#

ok so youre saying that when we attach the card to the customer...we can require the 3ds at which the customer can go thru that flow of authentication.

#

AND again at the time of charge but that would require the customer to return since the transactions are merchant initated

torpid barn
#

Yes, if you set a radar to always request 3DS if the card supports 3DS.

umbral ether
#

so once the 3ds authenticated at the time of attaching card to customer, the customer only has to be present IF the bank requires them to authenticate again?

torpid barn
#

Is your question about whether the customer needs to be present for 3DS authentication?

umbral ether
#

well im getting diff answers

#

stripe support is telling me that the customer needs to be present thru the whole payment flow in order to authenticate w 3ds

#

but youre telling me that we can authenticate at the time of saving card via 3DS and later use that saved card for future payments where a bank can decide whether or not to require authentication again at the time of processing payment

torpid barn
#

I don't see these two statements contradict.

#

A 3DS authentication can happen during the payment flow, or when you save the card.

umbral ether
#

but what if the bank doesnt require authentication again? i mean then it would contradict

torpid barn
#

Again it's entirely up to the bank. Can you tell me what you want to achieve? so that I can design you a solution

umbral ether
#

we're looking into ways to prevent fraud

#

and we looked into 3ds because of the liability shift

#

but trying to see if we qualify...but it looks like we do but may need the customer to return to complete the payment

torpid barn
#

but trying to see if we qualify...but it looks like we do -> are you asking if you are qualified for 3DS?

umbral ether
#

qualify for liability shift

#

but thats only w the authentication which can also be required at the time of payment

torpid barn
#

OK. So your goal is to always request 3DS if the card supports 3DS?

umbral ether
#

well our goal was to request it at the time of saving card

#

and then using it later in hopes it wouldnt request 3ds again but i understand it all depends on the bank

umbral ether
torpid barn
umbral ether
#

ah so thatll just prompt for 3ds at the time of saving cards

#

and wont request it again after

torpid barn
#

Not really.

umbral ether
#

ah i gues it could still reques depending on the bank

torpid barn
#

The card issuer can still request a 3DS in subsequent payments if though a 3DS was authenticated during setup

umbral ether
#

but if bank requests and we dont then it wll be deemed as not authenticated

torpid barn
#

It depends on your radar rule.

If your disabled the default radar rule Request 3DS if 3D Secure is required for card , then the customer is unable to authenticate and the payment would fail.

umbral ether
#

yeah but if we were to just request 3ds only if transaction_type = setup_intent then the payment wouldnt fail but still wouldnt mean the bank wouldnt request again at which if requested and we didnt requires the payment wouldnt be qualifed to be authenticated

#

is that correct?

torpid barn
#

I don't get the second part -> wouldnt mean the bank wouldnt request again at which if requested and we didnt requires the payment wouldnt be qualifed to be authenticated

umbral ether
#

im saying...bank could still request 3ds again but we didnt create a rule to request 3ds is required for card therefore would just bypass meaning that payment wasnt authenticated

torpid barn
#

No. it can't be bypassed and the payment will fail because it can't be authenticated. So the advise here is do not disable the Request 3DS if 3D Secure is required for card default rule.

umbral ether
#

but what if we want to only request it at the time of saving card?

#

do we have to request again at the time of payment as well ?

torpid barn
#

Then you'll a risk of payment failures when 3DS is required.

umbral ether
#

so its all or nothing

#

at the time of saving card and will need to authentic again if bank requires if not the payment will not process

torpid barn
#

Yes you are right.

umbral ether
#

got it

#

thank you

#

i had one more question....so this is fraud preventing related

#

it looks like 3ds wont be an option for us so i wanted to ask this

#

well let me tell you about a situation

#

we have many customers that order from our site

#

those customers have many employees

#

sometimes, when an employee gets fired or quits they somehow log back into their account and order items then change the shipping to their own and submits the orders

#

so because of that we were thinking of requesting cvv when shipping address changes

#

of course when i say request cvv, the customer would need to enter it and then the cvv would need to get validated in order to process the order

#

is that possible?

torpid barn
#

Or you can just build a logic to always request for a new payment method when your customer add or update a shipping address.

umbral ether
#

our customers have like 20 credit cards

#

its not like feasible

#

so we want to reduce the friction

torpid barn
#

Do you store your customer's shipping address?

umbral ether
#

yes its saved

torpid barn
#

OK, so your system should know when the shipping address is changed when your customer place a order?

umbral ether
#

yes

#

and with that we want to prompt the reentry of cvv

torpid barn
#

then you can use the cvcElement to recollect the cvc, you can find the details in the link I posted earlier.

umbral ether
#

so youre saying when our system notifies us of shipping address change, we can prompt for cvv recollection at which itll validate it again?