#Xavier
1 messages · Page 1 of 1 (latest)
hi! that's because the way trigger account.updated works is it creates a new account, then updates metadata on it, to trigger the event : https://github.com/stripe/stripe-cli/blob/master/pkg/fixtures/triggers/account.updated.json
so really you can just remove --stripe-account, it's not needed.
well I'm trying to see what the typical response of an actual account.updated webhook would look like
I'm not really interested in the platform account.updated
it's not a platform account.updated
it creates a connected account, updates that connected account, so it will generate an account.updated event on that connected account which is sent to your Connect endpoints, which seems like what you're looking for!
oh I see, so account.updated is creating a connect account and triggers?
yep, that's what I said!
haha yeah i realize that, I was rephrasing to make sure I understood 😄
Side question. If an account is not managed, I understand that we do not have access to the settings key, but I'm a little bit baffled that we do not have access to the payouts_enabled. I gather that's kind of what wraps up stripe's verification process.
What would you recommend otherwise to make sure this non managed connect account is legit
(apart from charges_enabled)
but I'm a little bit baffled that we do not have access to the payouts_enabled.
not sure what you mean by that, can you elaborate/give some examples? I created atype:standardaccount just now(if that's what you mean by 'not managed') andpayouts_enabledis returned in the JSON response
hum I just triggered the webhook as you mentioned and payouts_enabled is not part of the response
request id req_EsTmE0SolmTTta
you're on a 2015 API version from when the API was very different
it was called transfers_enabled back then because it predates https://stripe.com/docs/transfer-payout-split
oh wow, I didn't realize I was