#weboar_unexpected
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/1476260211256721541
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
hello! generally speaking we can't help out with decline related questions here on the discord server, for that you'll want to chat with our support team at https://support.stripe.com/
Popular articles
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
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
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)
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
ok, give me a few minutes.. will keep on reviewing and come back... si that ok?
yep! let me see if i can dig up and share some docs resources in the meantime
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
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)
I think the issue is on the setup intent, could be?
Failing One: seti_0T4lcITBhCBlgQTioGrIA2ho
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
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
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
I see.
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
i alluded to it above, but basically the steps are
- you set up a webhook and listen for
payment_intent.payment_failedevents like this one - 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) - you display some UI to the customer (for example our Payment Element) and use the
client_secretfrom the failed Payment Intent to create your elements instance - the customer completes payment via the UI you've brought them to
ok, but my customer is online... do you recommend I contact him by email?
if your customer is online then why are you passing off_session: "true" when creating your PaymentIntents?
if the customer is online then you shouldn't be passing that flag, and you should just be prepared to handle the PaymentIntent going into status: "requires_action" and when that happens you call this function on your frontend: https://docs.stripe.com/js/payment_intents/handle_next_action
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
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
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
OK, there is stuff to enhance... but why suddenly this seems to not work from Feb 20th and on?
sorry, again that's where our team can't really help you
https://support.stripe.com/ is the way to go for questions like that
ok.. thanks! I will review the recommendations and come back if I need help! Thanks ๐
yep! best of luck
Thanks!
Are you sure setup_future_usage is already being used on the setup_intent ?
I have just inspected one and is on null
hi there - I'll be taking over for solanum here. setup_future_usageisn't a property on the SetupIntent
(sorry, inspected the payment_intent... that attribute is not on the setup_intent)
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.
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
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
ok... so kind of like all Payment Intents are created for future usages.?
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.
is that a new attribute?
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!
Okay!