#connor_3ds-legacycard

1 messages ¡ Page 1 of 1 (latest)

sage sunBOT
#

👋 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/1448445845644247212

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

crisp willow
#

We have been on Stripe for 8+ years and many of our current customers have cards (card_xxxxxxxx) created through the Sources API. Recently, we migrated to PaymentIntents, and request 3DS on all new attempts to create a Card in the SetupIntents/PaymentMethods API as well as on all PaymentIntents (including PaymentIntents using old Source cards).

When we see that a Customer is present and has selected an old Source card, is it possible to request 3DS verification then and there and convert it into a PaymentMethod without the need to re-enter payment merhod details?

true trench
#

@crisp willow there's no way to turn an old Card (card_123) or Source (src_123) into a PaymentMethod (pm_123) no

But that should not be needed. We made those objects forward compatible with the new API

crisp willow
#

Totally understood on the forward compatibility side, I was just wondering if we could request 3DS up front to prevent friction later on

#

(when the payment method is used off-session later)

true trench
#

you shouldn't really need to do that. Older objects were "grandfathered" in a pre-SCA world and shouldn't need this I think

crisp willow
#

Oh hmm, we were still seeing 3DS challenges on older cards

true trench