#joshuacs94-multiple-setup-intents

1 messages · Page 1 of 1 (latest)

fresh coralBOT
#

Hello! We'll be with you shortly. 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.

karmic locust
#

Yep, no benefit. Is there a reason you are looking in to using a SetupIntent on an already saved payment method?

#

Actually there is one scenario where a user may do this: mandates for certain bank debits when using Connect

#

Some bank debits have mandates that are specific to an account, so you need to create a new setup intent on behalf of each account you want to take payment on.

quick vessel
#

Just wondering that because its possible for a PM to have different SIs with multiple statuses

#

Also, a couple of weeks ago, we had a customer with PM that became useless because the network blocked the card, it had a successful SI already before that, it was working fine, but after the network blocking the SI remained succeeded

karmic locust
#

joshuacs94-multiple-setup-intents

#

Yeah, SetupIntents are just a state machine for initially setting up the payment method. It is expected that the status would not change there

quick vessel
#

The only thing that changed was that I noticed the associated mandate was marked as inactive

karmic locust
#

Ah so this is working with mandates. Do you know if that is why your integration is creating multiple SIs for some PMs?

#

And if you want to listen for that more proactively, there is a mandate.updated webhook event

quick vessel
#

Yeah, its just that I thought that once a PM has a successful SI, the Payment Method will continue to be usable... until that happened and I found that even with an already successful SI its still possible to not be usable because of things like that

#

So... how should I proceed? Should I just create / confirm another Setup Intent?

karmic locust
#

Yep, so in that case it would also make sense to create a new SetupIntent with that PaymentMethod and have the user come back to your website or app to confirm it. That will set up a new mandate and the PaymentMethod should be usable again

quick vessel
#

and I guess once the mandate gets deactivated there is no way to activate it back again, right?

#

I think Stripe should move the associated setup intent into another state as well, because its obvious that having a successful SI is not a guarantee that the PM is usable without looking at the mandate

karmic locust
#

Correct, you can't reactivate a mandate, only create a new one

#

That would be a pretty fundamental change to how our intents work. I do understand how it would be intuitive for us to do that, but that is not how intents were intended to work. The idea for these bank mandates was that the mandate object is the thing you would check

quick vessel
#

got it, I will have to check the mandates as well

#

btw mandates are ignored for cards, right? Right now we are sending them no matter the PM type but I noticed that Stripe only use it if the PM is a us_bank_account

karmic locust
#

Yes, mandates are only for bank debits as far as I am aware

quick vessel
#

btw, the docs for Setup Intents do not mention the expand parameter, but it exists on the API, now Im using it to get the mandate in one call

#

nvm, I see its not mentioned for any resource

karmic locust
#

Yep yep, you can expand on pretty much every API call.

#

And then you can check the object definitions in the API ref, we show EXPANDABLE next to properties that can be expanded

#

Thank you for the feedback though, I will raise that we can make that clearer