#Landinster
worn vortex
mental elm
👋 Hi there, Happy to help!
Could you please share the related Invoice or PaymentIntent ID ?
vale mason
It's not a payment Intent, it's for setup intents, and my question is more related to following a correct behaviour
mental elm
Or a SetupIntent id yes
If the 3DS authentication has failed, the setup_intent will has a status requires_action and it's not considered successful until the authentication is done
vale mason
seti_1Lg4zTFGCGcQJSoFo2rVbk1v
this one for example
but I'm getting successful invoices after the free trial periods ends
mental elm
If the 3DS authentication has failed, the setup_intent will has a status `requir...
Here is the status that will had the SetupIntent
https://stripe.com/docs/api/setup_intents/object#setup_intent_object-status:~:text=%2C requires_confirmation%2C-,requires_action,-%2C processing%2C
mental elm
seti_1Lg4zTFGCGcQJSoFo2rVbk1v
Give me a minute while I investigate
vale mason
yeap, I'm handeling the requires action, but even when the user doesn't complete it the subscription keeps the trial status, and the changes to active on finished the trial period and start receiving successfull payments
mental elm
Could you please share that subscriptionID ?
Because I need to see how that subscription was created
vale mason
sure
cus_MOskpZzVg5nbr1
customer id
sub_1Lg4zTFGCGcQJSoFmMiggfLr
subscription id
As said since I activated the option you can see in the screenshot, I can see more 3d secure are being requested. Before of that it wasn't being requested so frequently. So I want to know if it's necessary to mark that option or not, between other things
mental elm
As said since I activated the option you can see in the screenshot, I can see mo...
That depends on what Radar rules you set:
https://stripe.com/docs/radar/rules#request-3d-secure
It depends on your exact use case, but you can accept payment without activating the option then the default judgment on payment will be used. So you don't need to activate that option unless you have specifc need for it
vale mason
well, I want 3d secure on Setup Intent only when it's required, but my rules have not changed. What changed was to mark that option... So that's what I don't understand...
Also want to know about cases like the one shared, where the setup intent authentication was not successfull but later I was able to bill the customer
if it's possible and is or not recommended to do it...
mental elm
well, I want 3d secure on Setup Intent only when it's required, but my rules hav...
So you should disable that option
mental elm
Also want to know about cases like the one shared, where the setup intent authen...
Do you mean you billed the customer without even completing the 3DS authentication?
vale mason
yes
mental elm
if it's possible and is or not recommended to do it...
If the PaymentMethod resulting from the SetupIntent isn't fully authenticated and the SetupIntent hasn't a final succeeded status then it's not possible to use that PaymentMethod
vale mason
you can see it in the logs of that subscription
please check that subscription and you should see it, let me know if you need more ids
mental elm
Ok, give me couple of minutes for deeper analysis
vale mason
sure
mental elm
So for that subscription, I see there is two invoices has been generated already:
First one for the trial: in_1Lg4zTFGCGcQJSoFpgePPM4G
Second one: in_1LhAQfFGCGcQJSoFHWf9alU1 been billed normally here is the related PaymentIntent:
https://dashboard.stripe.com/payments/pi_3LhBN1FGCGcQJSoF0onLxcXE
The PaymentMethod was made by this PayemntMehtod: pm_1Lg4zPFGCGcQJSoFM6GW3NMO it's well authenticaed I see no failed 3ds
vale mason
That payment method is the one that was setup with the Setup Intent, and it failed to authenticate
let me share some screenshots with you
The payment method was attached to the setup intent but failed to complete the authentication
mental elm
Did you configure your dashboard to send email to customer in order to update failed payment methods ?
In Manage failed payments Section
vale mason
Later a payment intent is created with the same payment method and it succeded without authentication
vale mason
Did you configure your dashboard to send email to customer in order to update fa...
Yes, I do
but the customer did not updated the payment method
he used the same, otherwise we should see a log about it
mental elm
ok, then the user get email in order to reauthenticate his payment method, just the 3DS authentication without adding new one
vale mason
are you sure about that? how is that not reflected anywhere?
because it's not the unique case we have, there are like many cases like this one...
is it any way to scalate this issue? or to contact with somebody to take a look into detail?
mental elm
Still looking on how the PaymentMethod was created
The setupintent you shared seti_1Lg4zTFGCGcQJSoFo2rVbk1v isn't the origin of the creation of the PaymentMethod pm_1Lg4zPFGCGcQJSoFM6GW3NMO
The PaymentMethod was created via StripeJs, here is the request:
https://dashboard.stripe.com/logs/req_jEZDCxs6vQwiXo
vale mason
but the setup intent is using that payment method...
https://dashboard.stripe.com/events/evt_1Lg4zVFGCGcQJSoFzB5mGMjX
so first I create the payment method and then I provision the setup intent with thay payment method
brisk void
Right, the setup intent is using the payment method but it is still a valid payment method event before the setup intent. So here basically the bank decided that even though 3DS didn't go through they would still accept the payment.
To avoid this scenario, you might want to either switch to creating the setup intent first and only using the PM that is created after the confirmation. Or you can add your own logic to not set the PM as the default for the customer or subscription until 3DS auth is complete
vale mason
Ok thanks, that has a lot of sense
brisk void
And to be clear, you can keep doing what you are doing now. I think the difference would mostly be that the liability shift and whatnot would not happen https://stripe.com/docs/payments/3d-secure#disputed-payments
Though I only know the API side of this so that may be something to ask our support team about
brisk void
Of course! Do you have any further API questions at the moment? Just making sure I'm not forgetting something
vale mason
well about the frist scrennshot I share, wanted to know what's the main difference between having or not having that option activated
this one, I mean
this is not an API question but if you could solve it I would really appreciate it 😉
brisk void
Good question. Checking in to that setting
vale mason
cool thanks
brisk void
Hey apologies for the long delay in an answer here. With that option turned on, your radar rules will apply to all of your payment intents and setup intents, with it turned off, the rules will only apply to payment intnets
vale mason
and 3D authentication is part of the radar rules right? or is it applied for Setup Intent even when this option disabled?
tall field
Hello 👋
Taking over as Pompey needs to step away
When you say "3DS auth as part of the radar rule" what exactly do you mean?
Are you seeing prompt 3DS auth when you create a SetupIntent?
vale mason
Hello Hanzo
yes, I'm seeing 3DS when creating Setup Intent
but looks like the percentage of 3DS auth incremented after enabling this rule
So wanted to know if there is some kind of correlation
tall field
There are some default radar rules that are enabled by default
vale mason
ok, even for Setup Intent right? perfect
tall field
You'd want to look under
https://dashboard.stripe.com/test/settings/radar/rules
Authentication Rules
the toggle that you enabled will apply those rules to SetupIntents too, yes.
tall field
NP! 🙂 Happy to help