nihilist_best-practices

[formal summit]

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

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

[north hamlet]

Why would you want to do that?

Generally not recommend – most cards now support 3DS and ultimately it's up to the issuing bank whether they request 3DS/auth for the payment. Stripe.js facilitates the authentication flows for you, so not sure why you'd want to opt of that completely and potentially squander lots of potential payments from succeeding

[hazy depot]

we are on the process of migrating our payment system from the deprecate Source, Card and CardElement to the new PaymentIntent and PaymentElement as well. And in this first iteration we want minial changes as possible, and we haven't support 3ds before so we don't want to support it now

[north hamlet]

As I said, not really something we'd recommend especially if operating in SCA impacting regions (Europe, etc). Source API didn't support 3DS, but now Payment Intents and Payment Methods to so you should opt in to the default behaviour quite easily as I suggested

Otherwise you can use Radar to block all payments where 3DS is requested if you really want to

[hazy depot]

Is there any implication we should be aware of when using Radar to block all 3ds payments? We are currently generating invoice manually for customer in SCA regions, would radar block card payment from those invoices?

[north hamlet]

Not sure what you eman by 'implications'? You'd have a higher increase in payment failures if that's what you mean

Don't know what 'generating invoice manually' means so without an example I can't expand

[hazy depot]

genearte invoice manually means we create invoice through the dashboard https://dashboard.stripe.com/test/invoices/create, and not by calling POST
/v1/invoices but i'm not sure if it means the samething when we use and older version of stripe API . Sorry for the confusion 😅 . But my guess is that radar would both block payments requires 3ds for both type of invoices above? Is it correct?

[north hamlet]

Depends on how you configured the Radar rule I guess. To be clear, 3DS can still be requested on invoices. The critical difference is that using the Dashboard to initiate payments will flag them as MOTO and thereforew out of scope for SCA (and 3DS)

[hazy depot]

ok tks for your answer. I figure it's easier to spend a bit more time setting up 3ds. Background for this question is we are also migrating our interal subscription model to stripe's Billing as well. So handle renewal for customer with PaymentMethod that requires 3ds would means extra work for this iteration, but i guess it worth the update.

[north hamlet]

If correctly configured then we optimise any off-session, recurring payments to be exempt from SCA too. Obviously the bank can still request 3DS for those, so you need to implement recovery steps into your integration

[hazy depot]

yeah it's the recovery steps that i'm worrying about. And to make sure i'm correct, configure correctly here means setup_future_usage to off_session for PaymentMethod and PaymentIntent for any billing of a subscription. Or is there anything else in settings dashboard that i need to pay attention to