#zzking1653_api

1 messages · Page 1 of 1 (latest)

gritty boltBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1356520012290068632

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

ocean fjord
#

The reason why I’m asking is because we are under tight timeline so we might not have enough time to implement the proper off-session solution, so I am wondering if we could re-use our existing “update payment method” feature which supports the on-session SCA when setting up the card. So if off-session SCA happens, we let customer update their card again (even with their existing old card) where we let the customer resolve the on-session SCA and then use the card that they just authenticated (again) to immediately pay off any unpaid invoices. Would it work ?

#

Also please notice the above work around is for the US customers where SCA is rare, compared to Europe

hexed steppe
#

Hi! Re-using your existing “update payment method” feature would require your customer to come online. Why not bring thme online to authenticate for the off-session SCA?

ocean fjord
#

Hi I understand. As said we already had the "Update payment method" feature in place whereas the off-session SCA has not been implemented yet and we are under tight timeline. Since the customers are mainly based in the US and chance of SCA is rare, we are wondering can we use "update payment method" as a work around "just in case" off-sesssion SCA happens

hexed steppe
#

To better understand the re-using of your "update payment method process", the customer will try to update the same payment method, you will create a setup intent, and then use the payment method to pay open invoices again correct?

ocean fjord
#

yes exactly. It's possible that customer use the new card too, which I think for sure would work, but I'm more interested to know what if they update the payment method with the same card

hexed steppe
#

The thing is that despite gping through another "update payment method" process, the next attempt for paying the invoices may still require 3DS.

#

Are these invoices one time or recurring invoices?

ocean fjord
#

recurring invoice

#

so we think the chance of off-session SCA is already low (creating card with setupIntent upfront first ) , and in the US is even lower. That's why we were thinking if "update payment method" could be a work around, given our tight schedule.

But I understand there is always a risk there.

hexed steppe
#

The user can then do a 3DS confirmation via a Stripe Hosted Link instead of going through the "update payment method" process.

#

Because as you mentioned, there is always a risk there.

ocean fjord
#

But in general , would "update payment method work ? (in case you know)

#

and I'm not asking for any confirmative answer here 🙂 , just like to know would it be a possible work-around

hexed steppe
#

I understand but it's difficult to say because yes you can get them to update the payment method but the customer can be required to go through 3DS auth.

ocean fjord
#

yeah, if 3DS auth is required during "update payment method" that's not a problem for us coz it's already handled

hexed steppe
#

I meant the 3DS may still be required after that, when you use the payment method you set up from the "update payment method" to pay for the invoices.

ocean fjord
#

I see. I think I have a better understanding now for the situation. Gernally speaking there is a always risk there

#

Thanks a lot for talking with me