#swoliosis_webhooks
tulip horizonBOT
đ 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/1475892693774369083
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
surreal whale
hi there, yes, by default the balance_transaction won't be available until the charge.updated event is fired for the transaction. this is due to one-time payments using asynchronous capture by default, which speeds up confirmation of the payment at time of purchase, but has the drawback you're noticing of updating the full details on the object later
we have a doc that describes this here: https://docs.stripe.com/payments/payment-intents/asynchronous-capture#listen-webhooks
tulip horizonBOT
solar pine
Thanks for the response. So it's sounding like we'll have to have two entirely separate flows for the different payment types? I was really hopeful we could listen to both charge.succeeded and charge.updated events, check for balance_transaction and then grab the needed info (customer + line items to check if a specific product was purchased). But It looks like subscriptions usually just return charge.succeeded and that can actually happen before I can get the line items from the checkout or invoice?
fading bay
Hi there - taking over for denton here, who needs to step away
let me just catch up
Do you have an example Subscription that I can look at? Just the sub_123 will be fine and then I can find the events from there
solar pine
Sure thing, let me grab one.
sub_1T4Ol2BNIsXC7YAhlOzobwXq
Just to further clarify on what I'm trying to build. I really just want the simplest way I can know when a payment has been completed and be able to get the net amount in our settlement currency, the customer who did it, and the line items for the purchase. Regardless of if it's a subscription or one_time payment.
I assumed I could just work backwards from charge.updated in the case of one_time payments, but it is frustrating to have drastically different flows for gathering this information.
fading bay
I think Payment Method type also plays a role. Do you accept bank debit payments? Because for ACH and the like, Stripe doesn't really know whether the payment is successful for a period of some days and I think you won't see the charge.updated event until it goes from pending/processing to success/fail
that is - ch_3T4OPMBNIsXC7YAh2md3uVc2/evt_3T4OPMBNIsXC7YAh2cB5rLj6 is a card payment and the latest payment on sub_1T4Ol2BNIsXC7YAhlOzobwXq is using a Link payment method
solar pine
I believe we do, which is fine if I can just listen for the successful payment event. I don't need it the second they finish checkout, just when we know money has hit our account. But it just looks like often in the case of card payments on subscriptions, I can't just listen for charge.succeeded as the supporting objects I need for the line items and customer info aren't ready yet.
fading bay
Sorry, helping other folks as well
solar pine
No sweat, appreciate your time
fading bay
Okay so why not, rather than keying on the event type, listen to both charge. events and then record the information you need about net amount from the balance transaction when you get it? So first case is you receive a charge.succeeded event but you don't have a balance transaction so you acknowledge the event and move on, and then you receive the charge.updated event some time later, you look at the balance transaction, it exists, and then you record the information you need?
Because we also don't guarantee ordering on webhook events and its conceivable that you could receive the charge.updated before the charge.succeeded, and then there are also cases of asynchronous failure, such as with bank debits
solar pine
Right, I was hopeful we could listen to both charge events. But it looks like on subscriptions we often get a single charge.succeeded event, but the checkout and invoice are not complete - so I cannot get the line items yet.
Subscription - charge succeeds and has balance transaction before invoice/checkout completion
One time - charge updates with balance transaction after everything else has settled
but sounding like I need to listen to many events and dedupe based on id or something
fading bay
Yeah, if you really want to only handle charge events, you might have to do something like polling the API for the Checkout Session or Invoice; by which I mean retrieve them every n period of time until they have what you need
Otherwise, yeah, I think you're going to have a different flow for recurring vs one time payments as far as the fulfillment/webhooks go
solar pine
Okay, just wanted to double check there wasn't something obvious I was missing. Thanks for the help
fading bay
Yeah, you're welcome!