#lafafm-3DS-wallets

1 messages · Page 1 of 1 (latest)

hardy stratus
#

Hey there 👋 great question, please bear with me while I look into that.

#

I know when you're testing Apple or Google pay that we reroute those to a valid test card behind the scenes, I need to double check whether you might encounter a 3DS challenge though.

woeful yoke
#

I'm also interesting what's the right place of triggering confirmCardSetup (we are using SetupIntent mechanic here)

E.g. GPay card setup looks in a such way

  1. Mount payment request button
  2. There's a listener paymentRequest.on('paymentmethod' , which handles submit of PaymentRequestButton
  3. Inside that listener we should trigger a event.complete

So I'm not sure when should we call a .confirmCardSetup

  • After GPay card is retrieved and we already call event.complete('success')
  • Or before event.complete('success') and in case of unsuccessful 3ds check call event.complete('fail')
hardy stratus
woeful yoke
#

Ok, thank you

Made it as that page says, working fine

#

But one question is still actual
Any way to reproduce 3ds at least for Google Pay?

#

Or just by updating Radar rules to require 3ds for all supported cards ?

#

In theory, as I remember GPay / Apple pay converts all the card to 4242, which have 3ds supported

hardy stratus
#

So I've found that for Apple Pay, the 3DS flow is all handled outside of our control. Still double checking regarding GPay though.

sharp quartz
#

Hey sorry for the delay here, the latest info I could find is that this is managed by google for the cards saved in google pay. This extra confirmation flow covers the "browser saved" card in eg Chrome, which is not already authenticated.