#LeXuS
autumn rose
balmy needle
payment_method_types are the types that it is possible to pay the intent with
If you are using automatic payment methods, that list will be automatically populated based on your settings and which PMs support the currency and so on that your intent is set up for
Can you tell me more about what this check in your code is trying to do?
full marlin
Basically we handle acss_debit and card payments in a different way on our server. In order to determine which flow to follow, we check what we have on the payment_method_types
And it used to be determinstic for us (we never saw that problem until recently)
balmy needle
So you are checking the payment method that was used?
For that you will want to look at the type of the payment method that is in the intent's payment_method field. payment_method_types is not intended to be used like this and will always be able to have other types in it
When retriving the payment intent, you can expand payment_method to get the full PM information back with the intent https://stripe.com/docs/api/expanding_objects
full marlin
I'm using the object that is sent in the webhook event and I wanted to avoid retrieving information again
Which I don't think I have control on (and so I can't expand on it)
balmy needle
In my payment_intent.succeeded events, I can see payment_method_details on the charge that is listed on my intent without any expansion
Though it looks like my test event is using somethig that recently changed so it might not show the same for you.
I would suggest looking at a payment_intent.succeeded event in your dashboard and seeing if you can find payment_method_details anywhere in the initial event that you are getting back
full marlin
Yeah I saw that but I don't have that in the Stripe type on my server (maybe I need to update my SDK to get it)
balmy needle
Otherwise you will either have to do a retrieve or wait for the charge.succeeded event which should ahve this info but you would have to connect it later
full marlin
Or I can add a custom type to read it but I would like to avoid doing that as well
full marlin
Otherwise you will either have to do a retrieve or wait for the `charge.succeede...
Yep I already do something on the charge succeeded for acss_debit but it's not the same behavior as the payment_intent succeeded
They happen at very different times for acss_debit but almost simultaneously for cards (which is the root of the problem)
balmy needle
Are you also listening to the event for when the intent goes in to a processing state? That should trigger immediately when the ACSS payments are submitted
full marlin
Yeah that too
Wait I have a doubt I'm checking the code for somthing. The case I'm mentioning is specific to invoices for us because we have a seperate flow for subscriptions
And indeed, maybe listening for payment_intent.succeeded and invoice.payment_succeeded is useless
balmy needle
Yep sometimes the info isn't on the most directly related event. Some API lookups or alternate events are needed for some checks