#poor-jw_best-practices
1 messages ¡ Page 1 of 1 (latest)
đ 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/1375117748853805068
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Briefly, no, don't do this and you can't know the answer you want.
This is not something determined at the card level, 3DS is decided per transaction/auth attempt by the issuer.
You need to set up your integration to handle authentication requirements as they happen, including for your off-session payments
If a bank wants 3ds during an off_session=true payment, it should get declined with authentication_required at which point you need to contact your customer to get them on-session to complete the payment
the 3155 test card is the happy path here, where the customer completes 3DS on session for the initial payment then you can do off-session payments later without 3ds
But even when previously set up like this, an issuer always has full discretion to require 3ds for any future payment
@dense stream thank you. but is it allowed? I mean, will I get banned if I do this check? Also, my app could make a check and decide to tell the user that they can add the card, but will have to be charged within 7 days, since payment intents can hold authorization for 7 days?
I can't speak to that specifically, I don't know. I can say you should not be creating real authorizations if you don't intend to collect payment, generally.
For specific supportability and TOS questions, you'll have to speak with our support team: https://support.stripe.com/contact
My app is kind of specific, so having this certainty adds value (it's not due to revenue loss or anything, but more like a feature thing).
@dense stream i don't agree that the check doesn't make sense. I mean, a card that requires 3DS for off session payment intent, will require it (most likely), in a week/month. The converse (not requiring now => won't require in future) is not necessarily true, I understand
I mean, a card that requires 3DS for off session payment intent, will require it (most likely), in a week/month.
this isnt really true either.
@dense stream support says: Upon checking here, uncaptured payments are simply payments that haven't been finalized (captured) yet, and they can be a normal part of some business models. So it will not affect your account.
ok, i think i may need to do some real world analysis on this, to know what are the probabilities. maybe you know the rates?