#NeatFastro - Onboarding

1 messages · Page 1 of 1 (latest)

pale sphinx
#

Hi 👋

worn hamlet
#

hi let me finish me question first

pale sphinx
#

but I can't decide on which condition it will redirect the user to dashboard
Quoting here for context

worn hamlet
#

if you don't mind

pale sphinx
#

As long as you keep it in this thread

worn hamlet
#

but I can't decide on which condition it will redirect the user to dashboard

#

I'm listening to stripe events (webhooks) specifically for the "account.updated" event

#

what is the best way to find out that the user has successfully completed the onboarding flow and his account is active

#

is "requirements.eventually_due.length == 0" a good option

# 
  account.requirements.eventually_due.length === 0 &&
  account.future_requirements.eventually_due.length === 0
) {
  // redirect to dashboard instead of onboarding
}```
#

can you guide me a little

pale sphinx
#

Account requirements is a good place to start

#

I think you would want to check not just eventually_due but also any past_due or currently_due

#

However, it may make more sense to store a boolean on your end that indicates if the account has fully onboarded.

worn hamlet
#

I'm also thinking to check if the "charges_enabled" is true or does all the "capabilities" set to "active" can also be a good indicator

worn hamlet
#

Can you ask around (from your colleagues) that what's the best way

#

I don't think currently_due is the right way to check

#

is anyone there?

pale sphinx
#

Hi, yes I'm here but I'm answering multiple people

#

Can you explain why you wouldn't want to examine currently_due ?

worn hamlet
#

because "currently_due" will only list out the required info that needs to be collected for a given (current) step, their might be more steps after the current step

#

at least that what I think so

pale sphinx
#

Right, but if eventually_due is empty but there are requirements that are currently_due that is an edge case your approach could miss

worn hamlet
#

"eventually_due" won't contain all the required fields list that are ultimately needed/required (eventually) ?

#

let's just assume we have total of 3 steps

#

currently user has completed step 1 and is in the middle of step 2

#

the "currently_due" will list all the fields that are needed to complete this step 2

#

but "eventually_due" will list all the fields that will be needed to complete both the step 2 and step 3

#

looks like @pale sphinx alone is handling all the questions

#

but I also have to go

pale sphinx
#

You are correct that eventually due will handle both current and future requirements

#

And yes it's just me

worn hamlet
#

So can I take my answer (the code snippet) as the final and correct answer or is there a better way to detect the completion?

worn hamlet
pale sphinx
#

Honestly the best answer would be to build this using your test mode API keys, create a bunch of connect accounts at various stages of onboarding, and test how your button works

#

I've created 46 accounts in Test mode so far to try out different ideas with Connect

worn hamlet
worn hamlet
pale sphinx
worn hamlet
#

yep all the required fields has to be provided and all the verifications has to be done then the account will be considered complete and the user can/will be able to visit/see his dashboard

#

looks like these if required also appears within the "eventually_due" list

pale sphinx
#

I would still want to test this pretty thoroughly to be certain of the final behavior

worn hamlet
#

I know regular stripe support team won't be able to help

#

with this

pale sphinx
#

Not this particular approach AFAIK

#

I still think this approach would a good way to achieve the functionality you are looking for. And it would only take a couple hours to create a few test accounts and walk through the process

worn hamlet
#

Sadly I'm not a web dev but mobile dev so all these sessions and cookies and a bit foreign to me

#

Looks like they are just checking if user has "StripeAccountId" or not and based on that the user either get redirected to onboarding or dashboard

pale sphinx
#

Right so I think you should implement your approach and test it with a couple of accounts.

worn hamlet
#

can you not ask some of your colleagues? 😭

reef marsh
#

catching up here one sec

#

mind catching me up to what your question is @worn hamlet ?

worn hamlet
#

do you want to me explain my question in different words?

#

My question is simple; how can we know that a user has successfully completed his connect onboarding so we enable the "go to your stripe dashboard" functionality in our platform

reef marsh
#

do you want to me explain my question in different words?
no, just that I'm someone else (not Snufkin earlier) and just wanted a recap from where you left off

how can we know that a user has successfully completed his connect onboarding so we enable the "go to your stripe dashboard" functionality in our platform
they have no fields in the requirements hash and they are charges_enabled: true and payouts_enabled: true

worn hamlet
#

ok so if these two "fields" are "true" then it means that use can visit his dashboard?

worn hamlet
reef marsh
#

what is "their dashboard" in this case? the Express account Dashboard?

#

what about the capabilities, do they all supposed to be set to "active" ?

well lets start here - what fund flow are you using? Direct Charges? or Destination Charges?

worn hamlet
worn hamlet
#

with some weird european methods like iDEAL

reef marsh
#

ok but I'm still not clear - what is a "users" Dashboard? Is it your own Dashboard? Or is it the Stripe Standard account Dashboard?

#

direct charges
Ok then yes you do need to consider the capabilities for those local EU payment methods as werll

#

those need to be active

worn hamlet
reef marsh
#

how can we know they have successfully completed the stripe connect express account creation process
sure but I answered that earlier, no? Happy to clarify if that wasn't clear

worn hamlet
#

if they have then we can give them the option to visit their stripe hosted dashboard for stripe connect express accounts

#

just to summarize

#

we need to check for:

#

"payouts_enabled", "charges_enabled" and all the "account.capabilites" are set to "active" ?

#

or should be also check if the "account.requirements.eventually_due" and "account.requirements.future_requirements" are empty

reef marsh
#

for a fully onboarded account, it would be both of the above two comments

i.e. "are payouts and charges etc enabled"
and
"have I collected everything possible even if due in the future, from this connected account"

worn hamlet
#

ok got it thank you very much for the help

#

I also have another question (stripe node ts sdk) regarding the account object type

#

can I ask that here?

reef marsh
#

sure

worn hamlet
#

why metadata is not the field of the type "Account"

stripe_account_object_type_metadata_error.png
#

any idea?

#

when creating accounts we can add metadata

#

at line: 432

Screenshot_2022-04-26_at_11.27.14_PM.png
reef marsh
#

looking

#

sorry can you clarify? Not seeing what you mean here:

why metadata is not the field of the type "Account"

#

ah I get it, looking

worn hamlet
#

"Stripe.Account" type does not has a field named "metaData" but "Stripe.AccountCreateParams" has one which is weird

reef marsh
#

full disclosure I'm not a Typescript expert so bear with me

worn hamlet
#

ah that worked

#

thanks for the help

reef marsh
#

np!

worn hamlet
#

now I can't destructure the metadata object

#

how can I get the values out of metadata

#

will this work:

#

metadata['key']

reef marsh
#

I don't know! not a TS expert haha but I'd say try that

#

like your approach works for regular JS but not sure what TS paradigms are

worn hamlet
#

if it works for js then it works for ts too

#

cause ts is a superset (js but with extra features) of js