#stevec0583
honest horizon
atomic vigil
The general recommendation to determine account verification is outlined here: https://stripe.com/docs/connect/identity-verification-api#determining-if-identity-or-business-verification-is-needed
orchid garnet
That info isn't very useful for onboarding though.
For example, my question above asks about how to handle cases where, for example, a user might have submitted the required info but (details_submitted == true), but also requirements_pending is false, and therefore they've done all they can at the moment and need to wait for Stripe.
That's just one permutation, but the stripe docs don't say how to handle that.
The docs you point to are more about giving warning that there might be more requirements in the future, or currently (or past due), however, they don't describe other cases.
atomic vigil
Then you'd look at charges_enabled and payouts_enabled to derive a general account status
orchid garnet
I think chatting about it isn't very efficient, since there are a lot of permutations.
Is the logic I provided airtight?
atomic vigil
You need to determine that really. I have zero context on your business/application and the requirements
orchid garnet
Does it give the user the correct message under the specific circumstances? (you could see my question as 4 separate questions)
It's not about any specific business, it's about how the combinations of values in Stripe's account.updated event payload map to what the user should do.
atomic vigil
You asked me if it's 'airtight'? I don't know what scenarios your integrations needs to account for so of course your application context is relevant
orchid garnet
For example, if Stripe was verifying the information already provided, it wouldn't be recomemnded that they keep revisiting their onboarding link and editing things and adding/removing things. But intead they should sit tight.
No, it's not.
orchid garnet
Let's skip questions 1. and 2. (since I think I guessed those correctly).
Here's question 3.: If the user has details_submitted == true AND no requirements_pending, they can only wait (e.g. check back in 15 minutes, or even a few hours/days in some cases).
Is my understanding correct?
I guessed, but prefer to be certain.
atomic vigil
Sure, verification is asynchronous yes. So you'd await subsequent account.updated event(s) where those fields would change to reflect the new status
And update your UI/logic accordingly
atomic vigil
Nope, each verification process is different. Our team would know nothing about that
orchid garnet
"nothing" is a strong word. For example, presumably we could reasonably assume it's less than 1 billion years?
So can you find out? Or... ??
Like, I want to give my users a message: "Please check back in 15 minutes" or similar.
Based on some realistic estimate.
atomic vigil
You'd need to speak to support. We can only help with technical question which verification duration is not
orchid garnet
Okay I'll follow up with support on the time frame when details are submitted and no requirements are pending. Thanks.
My only other quesiton is, aside from the 4 permutations I give above, are there any other possibilities that can arise?
atomic vigil
I guess an account rejection
orchid garnet
Interesting, I hadn't catered to that (I had assumed it would indefinitely have requirements pending).
What does account rejection look like in the account.updated payload?
atomic vigil
There'd be a requirements[disabled_reason] I believe: https://stripe.com/docs/api/accounts/object#account_object-requirements-disabled_reason
orchid garnet
seems sufficiently niche that I'll handle that case manually if/when it arises
atomic vigil
Should be possible to test by onboarding an account with test data that will fail verification