#alex_best-practices

1 messages ¡ Page 1 of 1 (latest)

static meteorBOT
#

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

📝 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.

snow patrol
#

hello! can you explain what you mean by this? are you trying to both do an off session payment and also request 3d secure at the same time? that sounds a little paradoxical to me

limber imp
#

yeah, sorry I am essentially asking on behalf of a co-worker who has latched on to this idea of 3DS being part of why we are seeing a very high rate of failed payments.

#

So all of our charges happen off-session. What he is asking is: can we set some additional parameters that will effectively disable any requirement for 3DS authentication.

#

My understanding is that off_session: true already achieves this.

snow patrol
#

the short answer to that is no, 3ds can be required for off session payments still and there is no way to disable them entirely

limber imp
#

Then we looked at the docs and saw that 3DS specific set of params and we got wondering what any would do. Under payment_method_options.card.request_three_d_secure

snow patrol
#

what you want to do instead is implement a means to bring customers online to complete 3DS when they get into that state

limber imp
#

right

snow patrol
#

if you want to provide some example failed transactions i can sanity check that 3Ds is the reason too

limber imp
#

and are we right in saying that if the issue with the charge is 3DS related, that would come back as the error and the PI would then require action?
we are concerned that the underlying problem is being swallowed up and all we get back is incorrect_card_number which obfuscates the actual issue.

#

This is an example of the error we most commonly face: pi_3RrwzcBb49XQ2DGy0ytI5Zfy

#

Which I understand to be essentially a black box type of error that only the card issuer can demystify.

#

A few more examples:
pi_3Rvi1vBb49XQ2DGy1UGzqhnw
pi_3RucbQBb49XQ2DGy1qDJzGgR
pi_3RsfwhBb49XQ2DGy0LglZwfY

snow patrol
#

hmmmmm yeah for that first one it looks like a visa network decline code 14, which most resources online are suggesting to me that it actually is an invalid card number

limber imp
#

And given that charges with the same payment method previously succeeded

snow patrol
#

good question, lemme take a closer look

limber imp
#

thanks

snow patrol
#

ok yeah, i am not seeing anything obvious. your integration looks fine, and although it would make sense for you to handle 3Ds failures if you aren't right now, i don't think that will solve your immediate problem as this is not that

#

my team generally isn't as good at looking into production declines like this so i would recommend checking with our support team to see if they can help you figure out what's going on with these:
https://support.stripe.com/

limber imp
#

ok, thanks I can start a new thread there.