#weboar_unexpected

1 messages ยท Page 1 of 1 (latest)

exotic violetBOT
#

๐Ÿ‘‹ 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/1476260211256721541

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

muted ibex
velvet patio
#

Well, but it is not about a decline

#

Seems to be an integration issue

#

I got an increase in the declines, from nothing to 15 a day

#

I am wondering if there is something that has changed and then I need to adapt my integration

muted ibex
#

if you want to share a PaymentIntent ID from before and another from after i can take a quick look, but there are a lot of non-integration reasons why things like this could be occurring

velvet patio
#

ok.. let me look for you! Thanks!

#

Also, from before, maybe the one I give you doesn't require 3ds or similar... so not sure it will be a good execrcise.. but let's try!

#

Give me a minute please. This will take 5 mins to get the info

#

Failing One: pi_2T4lWuTBhCBlgQTi0Flz6UtG

#

Success One: pi_2T1sCaTBhCBlgQTi2Ua5ADts (last week, still not sure if required 3ds secure, which seems to be the point of failure)

muted ibex
#

ok yes, this looks like a pretty typical typical issuer decline, which our team here on the discord don't know as much about as integration issues. i can't really speak to why you're seeing an increase in these (you can chat with our support team about that) but if you want to discuss how your integration should be handling these scenarios we can get into that

velvet patio
#

ok, give me a few minutes.. will keep on reviewing and come back... si that ok?

muted ibex
#

yep! let me see if i can dig up and share some docs resources in the meantime

velvet patio
#

Thanks!

#

The issue is that I see something very black and white.. None until Feb 20th.. And then, started... so it must be something in the integration

muted ibex
#

the structure of the requests you're making before and after are pretty much identical, it looks like you're collecting the same types of information, etc - i've looked at a few layers and it doesn't look like your integration has changed

#

banks have their own complicated logic for when they do and don't require 3Ds authentication, and on top of that Stripe has our own risk engine which will sometimes request it (although i don't think that happened in this case)

velvet patio
#

I think the issue is on the setup intent, could be?

#

Failing One: seti_0T4lcITBhCBlgQTioGrIA2ho

muted ibex
#

what makes you think that? again the setup intents look pretty much identical to me before and after, you're also setting them up for usage: "off_session" in both cases

velvet patio
#

Well, i had no issue at all until Feb 20th

#

Question is why before Feb 20th 3d secure was being handled gracefully and suddenly, not

#

Gemini tells me it is because the off_session doesn't relate well with 3d secure auth

muted ibex
#

which is why i said above that i can chat about how your integration should be handling these cases (which basically consists of notifying the customer that their payment failed and bringing them on-session to confirm payment using the same client_secret), but as i said above there are a lot of non-integration reasons why 3Ds challenges could change over time, and our support team can usually help you understand those better than we can here on the discord

velvet patio
#

I see.

muted ibex
#

what gemini is probably referring to is the fact that when you specify off_session: true for a PaymentIntent the payment will be declined, rather than the typical flow of the PaymentIntent transitioning to status: "authentication_required", but regardless of how you're confirming the payment the bank could request 3Ds in any of these cases

#

and if you want to maximize payment success rate your integeration should be able to handle 3Ds, so it's worth looking into setting this up eventually in my opinion. but as i said before the change in 3Ds auths doesn't look like an integration issue, and although you could change your integration to handle these cases better, the changes i would recommend won't necessarily reduce your chances of getting a 3Ds challenge, it will just help you handle them gracefully

velvet patio
#

I see.. ok...

#

so, which changes do you recommend?

muted ibex
#

i alluded to it above, but basically the steps are

  1. you set up a webhook and listen for payment_intent.payment_failed events like this one
  2. you inspect the failure code and in cases where it's authentication_required, you notify the customer that they need to come online to complete payment (typically via email)
  3. you display some UI to the customer (for example our Payment Element) and use the client_secret from the failed Payment Intent to create your elements instance
  4. the customer completes payment via the UI you've brought them to
velvet patio
#

ok, but my customer is online... do you recommend I contact him by email?

muted ibex
#

if your customer is online then why are you passing off_session: "true" when creating your PaymentIntents?

velvet patio
#

if your customer is online then why are you passing off_session: "true" when creating your PaymentIntents?
Want to use the info for later charges as well

muted ibex
#

that's different - off_session: true is for specifying that this specific payment is happening off-session. setup_future_usage is used to set up a card for future payments

#

and these payment methods are already being set up in your confirmation token => setup intent flow for off session payments, so you shouldn't even need to pass that on the PaymentIntent

#

(you can see the confirmation token being created with that property here, and here for the setup intent)

#

what i would recommend doing in test mode / a sandbox is try removing that off_session: true flag and using the always authenticate test card, which should result in the PaymentIntent going into a status of requires_action, and then try calling that handleNextAction to handle the 3Ds authentication step

exotic violetBOT
velvet patio
#

OK, there is stuff to enhance... but why suddenly this seems to not work from Feb 20th and on?

muted ibex
#

sorry, again that's where our team can't really help you

velvet patio
#

ok.. thanks! I will review the recommendations and come back if I need help! Thanks ๐Ÿ™‚

muted ibex
#

yep! best of luck

velvet patio
#

Thanks!

velvet patio
#

Are you sure setup_future_usage is already being used on the setup_intent ?

#

I have just inspected one and is on null

tender roost
#

hi there - I'll be taking over for solanum here. setup_future_usageisn't a property on the SetupIntent

velvet patio
#

(sorry, inspected the payment_intent... that attribute is not on the setup_intent)

tender roost
#

But, that's what a SetupIntent is - a SetupIntent's purpose is to collect a payment method for future use. It cannot create a payment.

velvet patio
#

Solanum said before:

setup_future_usage is used to set up a card for future payments
...
and these payment methods are already being set up in your confirmation token => setup intent flow for off session payments, so you shouldn't even need to pass that on the PaymentIntent
#1476260211256721541 message

tender roost
#

Yeah, setup_future_usage is a parameter on the PaymentIntent which you can use to set up a payment method for future payments during payment.

SetupIntents by default set up a payment method for on or off session payments according to their usage parameter.

#

Solanum said you don't need to pass SFU on the PaymentIntent because the payment method is being set up for future usage when you create a confirmation token and then confirm a SetupIntent

velvet patio
#

ok... so kind of like all Payment Intents are created for future usages.?

tender roost
#

No, not at all. PaymentIntents create payments, that is what they do. It would be poor design to require a SetupIntent on every single payment method that you wanted to save, so we offer a property that lets you set up a payment method during payment

#

But you by no means need to pass setup future usage on all PaymentIntents.

velvet patio
#

is that a new attribute?

tender roost
#

Nope

#

But what's your real question or point of confusion?

velvet patio
#

just don't have that in my code and was wondering why I didn't noticed that

#

Thanks! Will come back if I have any question!

tender roost
#

Okay!