#anhnh_docs
velvet steepleBOT
đź‘‹ 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/1376747512966414458
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- anhnh_docs, 4 days ago, 15 messages
late finch
hi @velvet chasm , whether or not a card requires 3DS later on cannot be predetermined. The issuer is ultimately the entity that determines whether or not the customer needs to go through authentication.
Your integration should be able to handle all scenarios, which includes whether 3DS is required later or not.
velvet chasm
Hi @late finch , thank you for support
that means even if I'm using a card (the card requires authentication for the initial setup, then succeeds for subsequent payments) and the payment is successful after setup, the card issuer may still require 3D Secure for every transaction in the future, right?
late finch
We wouldn't actually know whether 3DS is required for every transaction in the future, but using setup intent does not mean that the customer will never go through authentication again.
Actually, could you share with me your concern about this?
if you use Stripe methods such as .confirmPayment () [0] for on session payments, Stripe will automatically prompt the 3DS modal for the customer to authenticate
[0] https://docs.stripe.com/js/payment_intents/confirm_payment
velvet chasm
We are considering supporting 3D Secure (3DS) cards in our system.
Our system currently charges customers on a monthly basis, and this is done automatically using cards they have previously registered.
Therefore, I want to understand 3DS thoroughly.
As I understand it, in the case of a card with the type Authenticate unless set up, if I use it with a Setup Intent, I will be able to perform auto charges for future payments
we don't implement charge from user screen, so I don't use confirmPayment.
currently, I use paymentIntents.create with confirm = true
late finch
If you don't mind, could you share your account id so that I can take a closer look at how your integration works? You can find your account id by logging in to  https://dashboard.stripe.com/settings/account  . It'll have the prefix acct_
velvet chasm
sorry, I don't have permission to access to production account.
But I can describe with you
Currently, we still use charge API
late finch
That's okay, I do recommend migrating to use Payment Intents for 3DS support. The Charge API doesn't support 3DS.
velvet chasm
Yes, we ahve already migrated to use Payment Intents
late finch
Since you are charging your customers on a monthly basis, and I’m assuming you’re doing this off-session and your customers won’t be online to make the payment, you’d want to ensure that payment methods are saved using setup intents properly, and the payment intents are always using payment methods saved through setup intents.
velvet chasm
yes, that correct
because we don't currently plan to change our system to process payments during the user's session,
I would like to make a partial adjustment by supporting 3DS cards in one specific case first — where authentication is only required during the setup phase.
late finch
Generally, if a payment method is properly saved through Setup Intent for off_session usage, it quite rare that requires authentication during the off_session payment later. So in this case, the authentication will only happen during the setup phase.
Though its rare, it is still possible for the card issuer to prompt authentication again. I think you might find this page helpful to know the considerations you should take into account when processing off_session payments: https://support.stripe.com/questions/what-is-the-difference-between-on-session-and-off-session-and-why-is-it-important
velvet chasm
yes
btw, how can I determine whether a card always requires authentication or only during the setup phase?
I’m thinking of charging the customer $1 after registering the card to check, then refunding it.
late finch
how can I determine whether a card always requires authentication or only during the setup phase?
This is not possible. I don't recommend charging the customer $1 to check and then refund it either. Because you would incur processing fee while doing so, and could appear as a fraudulent transaction to the card issuer.
late finch
yup
velvet chasm
I see this section, how can we qualify for an SCA exemption?
late finch
SCA exemption is something our authentication engine requests on eligible user's behalf, based on the payment they make meeting certain criteria. We have more info about this in our docs: https://docs.stripe.com/payments/3d-secure/strong-customer-authentication-exemptions
the exemptions are handled automatically. its not something users need to worry about!
velvet chasm
So with the case (handle off_session with 3ds card), you can support us SCA exemption?
late finch
Stripe requests the exemption where relevant but it still boils down to the card issuer's decision. If the card issuer decides to require the customer to perform 3DS, authentication will be requested.
late finch
No, its when the payments are actually processed, after the customer saved their payment method through SetupIntent.
velvet chasm
yes, Stripe will handle the authentication on our behalf, but if the card issuer decides to require the customer to perform 3DS, authentication will still be requested
supple dune
I think you are over thinking this. The key point you need to take away here is to use SetupIntents to setup your PaymentMethods for future usage off-session. Whether or not 3DS is required for the SetupIntent or subsequent PaymentIntents, is determined by a variety of factors.
Like what aure has mentioned, once the SetupIntent is successful and you have a PaymentMethod, you can use that PaymentMethod for subsequent off-session payments for the customer. It’s quite uncommon for payment methods that were successfully set up for off-session usage with a SetupIntent to require authentication. However, if the issuer does require authentication for an off-session payment, it will fail with an authentication_required error. In that case, we recommend bringing the customer back on-session to complete the payment.
Payments can fail for various reasons, such as declines, so you'll want to ensure your application is built to handle these scenarios properly.