brayden-account-events

[opaque jay]

We can chat here

[grim mesa]

So maybe a rundown of what we're trying to achieve might be helpful? Then you can make some recommendations.

We're using Custom Connect Accounts to verify identity and get a bank account added for payouts

The process for verification and account adding is through the Stripe hosted Connect forms

We'd like to basically understand when a user of ours has completed the flow, become verified, and connected a valid account to enable payouts

Then we'd also like to understand when anything changes for the connected account so that we can take features away from the user until they resolve the situation and become payout eligible again

In order to do this, we've setup a webhook endpoint to listen to account.updated events.

Based on the payouts_enabled flag returned, and the lack of currently_due requirements, we determine if an account is payout eligible, which unlocks features for the user in our app

[dark atlas]

brayden-account-events

@grim mesa yes that all sounds overall correct, what is blocking you?

[grim mesa]

I'm just trying to understand how to avoid toggling payout eligibility incorrectly, should we receive account.updated events out of order

Which maybe shouldn't be a concern? I'm looking for some clarity on that

Since multiple events fire over the course of the user going through the stripe hosted flow, there seems to be a possibility that we would mark our user eligible based off of one event, then receive another event that would cause us to mark the user as ineligible..

and maybe this can be mitigated by just retrieving the Account object from the event and using that as source of truth, data-wise? Instead of relying on the data in the event itself?

[dark atlas]

Events can happen out of order, even if they don't, your own code can fail processing one

You can retrieve the Account if you want but that doesn't mean you won't get another event 10 seconds later.

Really I would put this information in a queue with some delay so that I don't immediately email someone about lack of access when it's in the middle of being resolved or vice versa

[grim mesa]

If we consistently retrieve the Account with each event, it would seem as if we would always get the accurate information about the Account though, right? i.e. if we receive an event with data saying the account is not eligible, but we look at the Account object and see that it is we would be able to make a decision to not process the event's data?

[dark atlas]

sure you can but that doesn't solve the fact that you can get another Event 10 seconds later that changed the account's state

[grim mesa]

Right, but we would fetch the Account for that event as well and see that the account's state did actually change

Which seems like it would work okay for us only changing our side based off of the Account's state instead of off of the event's data. The event would more just be a signal for us to retrieve the Account object and verify the current state of the object

[dark atlas]

sure

[grim mesa]

Okay, I think that makes sense. I appreciate the information!