#nickdnk-payout-events
bold sparrow
Hi 👋 so a quick bit of up front clarification:
For a subscription, you get both customer.subscription.deleted and customer.subscription.updated for the same event, so that you can react to the webhooks differently
I believe this depends on how you cancel the subscription. You only get both if the subscription is updated while it's being canceled. If you just cancel the subscription then you only receive thecustomer.subscription.deletedevent.
untold grail
take a look at sub_1K2iQVIFDslEWhBA272T5fE6
It was updated and canceled automatically at the same time, firing both events
the update being a move in status only
evt_1KJPMuIFDslEWhBAW3GvnRT3
evt_1KJPMuIFDslEWhBAjV5nVQiG
I would expect the payout to behave in the same way
bold sparrow
That's because that subscription's details are also being updated while the subscription is being canceled. If you just make a request to cancel a subscription then it will only trigger the customer.subscription.deleted event (confirmed in my test account at the start of this chat).
https://stripe.com/docs/api/subscriptions/cancel?lang=python
near minnow
hey there just catching up and taking over here, one sec nick
untold grail
Cool
near minnow
So the question; is this intentional?
See po_1KWAiTIRviNLId5iHQzgfAn7 for example
untold grail
I'm not saying you're wrong, just that it's a little inconsistent
near minnow
(just pulling in from main)
untold grail
sure
If an invoice changes status because of payment failure, you also get both invoice.payment_failed and invoice.updated
so yea, this was why I was expecting an update event for payout status change
I just wanted to clarify that this was not a bug and I'll just code for it.
near minnow
According to what I'm seeing, this is expected, not a bug -- our payout events are designed to produce only failed/paid/cancelled when transitioning to the terminal states
near minnow
But I'm going to file as feedback because i kind of agree we should emit updated events in those cases too
untold grail
It would make sense
I assume that would be listed in API changelog if you did cahnge it?
just so I'd know
near minnow
Depends on exactly what changed, or if were deemed additive etc
untold grail
okay, I just don't want to "do it twice" if it suddenly changes behavior
as I need to keep the updated event
also does this mean I have to subscribe to payout.canceled and payout.failed as well?
Because then I'm kind of not udnerstanding when the payout.updated would ever fire
going from pending to in_transit perhaps?
near minnow
That's right, update will fire in live move for the move to in_transit (which is not terminal)
untold grail
Okay
I hope you can see how inconsistent this is 😄
Haha
Compared to other resources
near minnow
I've already shared that feedback, i don't disagree with you 😄
untold grail
I'll just add similar handling for both paid, failed, updated and canceled
Anyway thanks again, I have all I need to make it work now
untold grail
Followup
If I do report runs on payouts that have failed, will the conetnt of the report be inversed?
Since the money returns to the customer's account
near minnow
Hmm not sure what you mean by reversed, but we also aren't super familiar with the reports content
untold grail
If a payout fails, it goes from paid to failed. If I then do a report run on that payout, after it has failed, will the content be inversed, since the money is now going back to the account?
But fair enough if you don't know
I would assume it would then contain https://stripe.com/docs/reports/reporting-categories#payout-reversal reporting category
Or maybe that's just part of the next payout that comes then
It probably is
near minnow
These would be additional transactions, yes, the payout and the reversal in that case
(since the amounts would have already been deducted from your balance)
untold grail
Cool