#mike_docs

1 messages ยท Page 1 of 1 (latest)

kindred plumeBOT
#

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

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

odd token
#

๐Ÿ‘‹ When a charge is created, the fee information should be immediately available in the balance_transaction object referenced on the charge. Or I am I misunderstanding what you're looking for?

kindred plumeBOT
fair shoal
#

not with asynchronous charge according to documentation

#

it's charge.updated webhook

finite pine
#

hey there ๐Ÿ‘‹ your understanding is correct - with asynchronous capture, some details around fees/balance_transaction details may not populate at the same time as the succeeded webhook, but at that point the charge has been authorised by the issuer

fair shoal
#

so which very-first webhook we can rely on to deliver the service?

finite pine
#

or else checkout.session.completed if you use Checkout Sessions (though both of these events will be fired in this integration)

fair shoal
#

ok, before using async charges we relied on charge.succeeded. that is why I asked

finite pine
#

that makes sense! in most cases charge.succeeded will also still fire, but charges are an older resource

we recommend relying on payment_intent.succeeded for confirming payment success

fair shoal
#

good to know

#

thank you