#dejmon_webhooks

1 messages ยท Page 1 of 1 (latest)

meager belfryBOT
#

๐Ÿ‘‹ 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/1303314665475932213

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

brisk pendant
#

Be with you shortly ๐Ÿ™‚

#

Hmm, not sure! My understanding is with delayed PMs like BACS that the Charge should not be created until the payment settles

royal talon
#

So the question is, why it is usually created?

brisk pendant
#

Yeah we're looking into this

royal talon
#

most of our BACS payments have on this stage charge object created and charge.pending event emited

brisk pendant
#

Honestly, I'm not sure why there's a difference here. Are you reliant on a Charge existing? My recommendation would be too not rely on that

royal talon
#

I always take a payment_method_details from the charge on that step, so that the client is notified about the payment has started using specific account number etc. (like last 4 digits etc.)

#

regardless it's a BACS or card payment

brisk pendant
#

Got it. In that case I'd recommend writing in to our team (via https://support.stripe.com/contact/email?topic=api_integration) and we can take a deeper look at this with the BACS team to understand what is expected here

royal talon
#

Ok, thanks for the advice. On the other hand, could you propose, from where can I get as well information about payment method details? I mean if it's any different way than from the charge?

#

As far I remember my initial thought was that If I use charge object, which contains payment_method_details, I won't need to do additional request for payment_method

#

But it looks like I will have to do that additional request to the Stripe everytime

#

becuase payment_method is attached to the even object only as a string, not an object

meager belfryBOT
brisk pendant
#

On the other hand, could you propose, from where can I get as well information about payment method details? I mean if it's any different way than from the charge?
payment_method_details on the Charge is one option, or you can expand the payment_method field on the Payment Intent

royal talon
#

Ok, but there is no any other solution than send the request for retreiving the payment method? Isn't there any option like expand for the events?

brisk pendant
#

Not with events I'm afraid no, you'd need to send the API request to expand the field

royal talon
#

Ok, thanks for your help ๐Ÿ™‚

bright bison
#

๐Ÿ‘‹ taking over for my colleague. Let me know if there's any follow-up Qs I can answer!

royal talon
#

Can I have one more question?

bright bison
#

yes sure

royal talon
#

to retrieve paymen method details, can I always rely on the payment_method instead of latest_charge object (and from there payment_method_details)?

bright bison
#

yes

royal talon
#

so let's say payment failed because insuficcient funds, customer changed the payment method -> payment_method property will be always up to date in the payment_intent?

bright bison
royal talon
#

Ok, I see. so once payment failed, payment_method is detached from the payment_intent and I should look into last_payment_error.payment_method

bright bison
#

I'm not sure the payment_method is detached to be honest, but I might be wrong

#

in all cases I recommend looking at that object to inspect everything related to why this payment failed