#denjaland_connect-onboarding

1 messages · Page 1 of 1 (latest)

tidal frostBOT
terse laurelBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

tidal frostBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1235957748605390928

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

plucky hill
#

hiya

#

I'm implementing an onboarding flow ith the embedded components

#

but when I create a new account on the server and get the information returned

#

I have the following payload:

#

(only pasting requirements):

terse laurelBOT
plucky hill
#

Why do.I have a list of currently due, but is current_deadline <null>,

#

?

#

to be clear: this is right after account creation, so there is no onboarding done yet by the user - it's the initial state

obtuse halo
#

Hi there 👋 it's because they're past due requirements, so they're due immediately. They're also populated in past_due for this reason.

plucky hill
#

okay

#

we have to test too many variables - sometimes you need to add some summary in your objects

#

I'm just truying to implement the "right" logic to guide the user to "hey you have to complete your onboarding still"

tidal frostBOT
#

denjaland_connect-onboarding

plucky hill
#

would this make sense?:

1/ disabled_reason || !charges_enabled --> RED FLAG - block all payments
2/ !payouts_enabled --> ORANGE FLAG - alert that user should complete some data in order to accept payments
3/ currently_due.length>0 || eventually_due.length >0 --> notification that they should complete some data at their soonest convenience but still have some time

#

what would be the best check to find out whether initial onboarding was complete? that seems like a flag that would make so much sense to add in the object

#

so we could do if (!account.onboarding_complete) { show 'complete onboarding' }

#

so we can make a proper distinction between "hey you're still in initial onboarding" or "hey we have some new requirements for you"

obtuse halo
#

It depends on what your integration needs and what capabilities you're onboarding your users into. Generally checking for disabled_reason being null, charges_enabled being true, and payouts_enabled being true are good indicators that an iaccount is able to process charges and payouts and is ready for use.

plucky hill
#

but then to alert user that there are additional requiremenst that need to be filled, we need to check other fields again

obtuse halo
#

Yup, you'll want to continually keep an eye on requirements and future_requirements, as they no ones may be added in order for us to comply with necessary KYC regulations.

plucky hill
#

okay and once we have any requirements, we should be fine with embedding the embeddable onboarding component, and that component will ensure it collects all missing required info, right?

#

so disabled_reason / charges_enabled / payouts_enabled or any (future) requirements, and I should show a button to display a modal in which we embed the onboarding embeddable, and that should be safe, correct?

#

as in "be able to handle all use cases"

obtuse halo
plucky hill
#

yes I noticed that - thanks for proactively pointing it out though!$

#

so my logic would be if I have "current" requirements, I only collect these, but if I only have eventually due ones, I'll set the collection option to that instead. That way I shorten the onvoarding process to only what's really necessary to begin with, but then display the modal for users who want to complete the rest too

#

that sounds like a good way of doing it.

#

having said that - can I "play" with the accounts in the dashboard (setting a new eventually due req for testing purposes for instance?)