#bumbzor_code

1 messages ¡ Page 1 of 1 (latest)

bitter rootBOT
#

👋 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/1275791269456515162

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

chrome mossBOT
#

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.

waxen blaze
#

I don't have more info at the moment so hopefully the initial message can give you an idea of what the issue is.

sonic jungle
#

hi there!

#

is your goal to find the PaymentMethod ID used in a PaymentIntent?

waxen blaze
#

We have that working for one time payments in our code but for some different payment methods the location of the payment method is different.

sonic jungle
waxen blaze
#

like the actual data location is different depending on the payment method used so our code fails because it's looking in for example $intent->payment_method, which works fine for a normal Card payment, but for something like sofort it's not there

sonic jungle
#

can you share a PaymentIntent ID (pi_xxx) where you see this issue?

waxen blaze
#

one sec trying to get that for you

#

so that's the location (in the right) where our code looks for the data

code-we-check.png
#

that's an order with iDeal

actual-data-location.png
#

but you can see both IDs here, the one we look for and the one Stripe connects to the customer:

image.png
sonic jungle
#

can you share the exactly object ID or event ID your code is looking at?

waxen blaze
#

"payment_method": "pm_1PqDmpG2lcdV7TvNh58sozlU", exists and it's correct but that;s not the same one that is attached to the Customer

#

o the payment intent data that you have when the order is created is actually different from when it's completed

sonic jungle
#

"payment_method": "pm_1PqDmpG2lcdV7TvNh58sozlU", exists and it's correct
yes, like I said every PaymentIntent have a payment_method property. so it's working as expected
but that;s not the same one that is attached to the Customer
I agree it's a different PaymentMethod. is that an issue?

waxen blaze
#

Yes thats the issue. that the data is different when it's completed. And this happens only with some of the other payment method options like you see here with iDeal and others

#

the ID (if you look at the customer's payment method) pm_1PqDn1G2lcdV7TvNvw7Q6c1i is something that Stripe adds after the original creation. A conversion of something.

#

because of that, when our users try to purchase a recurring product now, with the way it is being handled for some payment methods, like iDeal above, they get this error

#

The customer does not have a payment method with the ID pm_1PqDmpG2lcdV7TvNh58sozlU. The payment method must be attached to the customer.

#

that existed initially pm_1PqDmpG2lcdV7TvNh58sozlU but now, the actual customer has a different one that Stripe added.

#

basically if there is an automated way we can get the converted/custom/new payment method ID from the one that's stored in $payment_intent->payment_method, without having to loop through sepa, sofort, etc. etc. that would be what we need

sonic jungle
#

sorry for the delay, we'll look into this

bitter rootBOT
raw shoal
#

Hello
Taking over
Give me a moment to catch up

waxen blaze
#

Ok here's something you can actually look at. This is the event: https://dashboard.stripe.com/test/workbench/events/evt_3PqDmrG2lcdV7TvN1RYch76p
In there you can see "payment_method": "pm_1PqDmpG2lcdV7TvNh58sozlU", so far so good. In our code, this is the Event that our Webhook is listening to (for recurring purchases) payment_intent.succeeded (the link I just sent). But in this Event, the pm_1PqDmpG2lcdV7TvNh58sozlU payment_method is NOT the one that Stripe creates and attaches to the Customer. Stripe creates/attaches a different one.

#

If there is a way for us to get the actual payment method that is attached to the customer via "payment_method": "pm_1PqDmpG2lcdV7TvNh58sozlU" somehow, that would work. Has to be on the same Webhook event: payment_intent.succeeded as that's what the code runs for Recuring purchases.

raw shoal
#

Let me ask a colleague to take a look, this might need a deeper look and discord is running busy

#

hang on

burnt gate
#

nd that does NOT exist in the payment_intent.succeeded event.
it's the latest_charge.payment_method_details.ideal.generated_sepa_debit

waxen blaze
#

@burnt gate that's in the charge.succeeded event and we don't listen for that for Recurring purchases.

burnt gate
#

it's normal to e.g. listen for invoice.paid and or payment_intent.succeeded and in the handler to make API calls to retrieve and expand related objects; not everything is in the payload of the event since that's a base view of the object

waxen blaze
#

so in the payment_intent.succeeded event, how could we obtan the actual payment method attached to the Customer? latest_charge.payment_method_details.ideal.generated_sepa_debit this might be different for each payment option.

burnt gate
burnt gate
# waxen blaze so in the `payment_intent.succeeded` event, how could we obtan the actual paymen...

I'd retrieve the PI expanding the latest_charge(see docs above), check if charge.payment_method_details.type == 'ideal' , branch to special-casing iDEAL and then if payment_method_details.ideal.generated_sepa_debit is set , then that's the one attached to the customer

you should probably also branch for other European payment methods that have the same behaviour like bancontact and sofort , and then test out each scenario and payment method in test mode to confirm

waxen blaze
#

ok so to sum it up. on the payment_intent.succeeded event, Retrieve the PI pm_1PqDmpG2lcdV7TvNh58sozlU (original one) and expand it for latest_charge and the correct Payment Method ID, which is the one actually attached to the customer will. bethere. Sounds about right?

burnt gate
#

Retrieve the PI pm_1PqDmpG2lcdV7TvNh58sozlU (original one)
pm_xxx is a PaymentMethod not a PaymentIntent.
But yes, you recieve if the event, if (event.type==payment_intent.succeeded) { pi = paymentIntents.retrieve(event.data.object.id, {expand:['latest_charge']}} and then in handling pi you can look at those details and figure out if it's a recurring payment or the first payment and what ID you need to save.

waxen blaze
#

one problem here is that payment_intent.succeeded runs before charge.succeeded so there is no latest_charge ? is this possible.

#

or running what you said, will have the latest_charge as it has ocurred in Stripe already?

burnt gate
#

you can recieve the events in any order but if you are looking at a payment_intent.succeeded it will have a latest_charge set.

waxen blaze
#

thanks guys! very helpful!

#

we have a plan of action now to look into

burnt gate
#

great!