#ll0071-setupattempt

1 messages ยท Page 1 of 1 (latest)

viral cape
quartz brook
#

No. I'm looking for the Javascript code.

#

stripe.confirmSetup({
elements,
confirmParams: {
// Return URL where the customer should be redirected after the SetupIntent is confirmed.
return_url: 'https://example.com',
},
})
.then(function(result) {
if (result.error) {
// Inform the customer that there was an error.
}
});

#

Like this but to get the Setup Attempt not the Setup intent.

gentle cobalt
#

I don't know if that is returned in the client-side object. If it isn't, you may have to reach out to your server to have it look the attempt up

#

What info from the SetupAttempt are you looking for here that the Intent doesn't give you?

quartz brook
#

three_d_secure

gentle cobalt
#

What about the three_d_secure field on the attempt objecT?

#

In other words, what is your end goal here? I want to make sure I am addressing that, there may be an easier way to accomplish it

quartz brook
#

I want to know if a card require three_d_secure when setting up a new card. Now the only way I can know it, is when charging. But I want the info a soon as the card is setup.

#

Am I clear ?

gentle cobalt
#

I think so yes. Does that affect some of your client side logic or are you trying to display this information to the user?

quartz brook
#

Its for logic. If I knew that the card was three_d_secure from the start, I could prompt a message for the one charging the card to let him know that the customer need to approve it.

#

At the moment, I need to charge and catch the exception to know if the card is three_d_Secure and then sent the validation to the customer.

gentle cobalt
#

Ah is this charge offline (after the user has left and is no longer on session)? Or are you making the charge on the server immediately after setting up the card?

quartz brook
#

No not immediately, once the card is setup and associated with a customer, it can take days, months.. before the card is charge

#

So yeah It would be call offline I guess

gentle cobalt
#

Gotcha. In that case it does sound like the SetupAttempt is probably the way to check this to flag that to them (other than if you use a flow where you can see your SetupIntent in a requires_action state). If the list of setup attempts or the latest_attempt property are not filled out automatically, you may need to reach out to your server to be fully sure

#

I will try to test this myself but it might take me a bit as I seem to have broken my test project :/

quartz brook
#

in my setup_intent object, the latest_attempt property is null

#

oh wait no

#

its not null

#

So how do I get the SetupAttempt object with this property ?

gentle cobalt
#

Oh right that would be an ID not a full object. It looks like you will need to reach out to your server, have the server do the SetupAttempt lookup, and return the result

quartz brook
#

my backend is in c sharp, do you have the code for it ?

gentle cobalt
#

Looks like you can't directly look one up by ID but you can list all of the setupattempts for the SetupIntent by the SetupIntent's ID https://stripe.com/docs/api/setup_attempts/list?lang=dotnet

{
  Limit = 3,
};
var service = new SetupAttemptService();
StripeList<SetupAttempt> setupAttempts = service.List(
  options);```
#

Quick question: on your confirmed setup intent, do you see the payment_method property as an ID as well or as an object? If it is an object you may be able to see this info from there

quartz brook
#

Its an ID

#

Where do I put the SetupIntent ID ?

gentle cobalt
#

Whoops forgot the most important part.

{
  Limit = 3,
  SetupIntent = "seti_123"
};```
#

Either will work and it will be the same info, mostly a difference between looking up a list vs one object

quartz brook
#

Where is the info on the PaymentMethod ? This

#

"three_d_secure_usage": {
"supported": true
},

#

its always true, no ?

gentle cobalt
#

It should be false for cards that do not support 3DS.

quartz brook
#

Ok. Thank you! Can you keep the chat open, I might have more question later

gentle cobalt
#

Of course, I'll leave it open though we typically archive after about an hour or so. If the thread is closed when you get back you can ask in the main channel for it to be re-opened

quartz brook
#

Understood

quartz brook
#

if "three_d_secure_usage": {
"supported": true
},

#

it doesnt mean that it will request a 3D auth when charging, right ?

echo needle
#

not necessarily. It depends on the issuer or the bank

quartz brook
#

the property "card": {
"three_d_secure": null
}, in a setup attempts tell if it will request a 3D auth when charging right ?

echo needle
#

if the card supports 3DS and issuer/banks require it, it would ask for 3DS auth while you're setting it up for off_session use using SetupIntents

#

shouldn't ask for 3DS if you create an off_session charge later

quartz brook
#

But sometime it ask to auth one time (when setting it up) and for other card it can ask to auth on every transaction right ?

#

My question is how do I know if its gonna ask auth on every transaction or not

echo needle
#

As far as my understanding goes, there isn't a defined way to know for sure that 3DS auth will be required on every transaction or not.

If you've setup the card correctly for off_session usage, you shouldn't see 3DS auth coming up for off_session charges.

#

card[three_d_secure] only reflects if the card supports 3DS authentication or not

quartz brook
#

So the only way to know would be the check the charge event to see if it asks 3D auth or not

#

and from there I can start the workflow to ask for auth

echo needle
#

Are you using Charges API or PaymentIntents?

quartz brook
#

paymentIntent

#

actually both I think I see some charge in my list of event

echo needle
#

Okay so PaymentIntent status should change to requires_action

quartz brook
#

when the PaymentIntent is created the satus is "requires_source"

echo needle
#

right, that's when you provide the payment method/source

#

I believe you may be using an older API version ๐Ÿ™‚

quartz brook
#

when updated, its suppose to be "requires_action" ?

echo needle
#

If it needs 3DS authentication, yes it'd move to requires_action status

quartz brook
#

ok so im gonna see to update it then

#

and then I can check every payment intent if "require action" then I start the workflow

echo needle
#

cool, yeah the guide I linked above has more information about this flow for your reference
Good luck ๐Ÿ˜„