#MarcusStripe

1 messages · Page 1 of 1 (latest)

bold turtleBOT
little jewel
#

Hi 👋

The concept of statuses for a Connected account is unique to the Stripe dashboard, and is not included in the associated Account objects within our API.

Accounts may change states for various reasons, but a good example is if we need to collect additional information from Stripe accounts due to changing rules/regulations.

tight hound
#

ok regarding complete - I just mean the equivalent of this

#

I never got any concrete info, but for instance at the moment I have implemted COMPLETE as:
payoutsEnabled && !currentlyDue && !eventuallyDue

#

and ENABLED as:
payoutsEnabled && !currentlyDue && eventuallyDue

#

then further I check the disabledReasonCode.

#

PENDING_VERIFICATION("requirements.pending_verification"),
PAST_DUE("requirements.past_due"),
LISTED("listed"),
PLATFORM_PAUSED("platform_paused"),
REJECTED_FRAUD("rejected.fraud"),
REJECTED_LISTED("rejected.listed"),
REJECTED_TOS("rejected.terms_of_service"),
REJECTED_OTHER("rejected.other"),
UNDER_REVIEW("under_review"),
OTHER("other");

#

here i am not even fully sure of which of these related to rejected - but currenlly all starting with REJECTED I handle as rejected

#

so now I am looking for a status change diagram tthat shows me from which status an account could move to which.. over time..
(and why) and what to do then

#

?

little jewel
#

I don't think we have that documented, and I'm not sure I'm going to know all of the possible state changes as some of them may be triggered by verification processes that we aren't as familiar with as our colleagues in our Support team.

The changes that I can think of off-hand are:

  • Moving from "Complete" to "Rejected" because the account gets rejected.
  • Moving from "Complete" to "Restricted Soon" if new requirements are going to be added to the account

I think it's possible for an account to move from "Complete" to "Restricted", though "Enabled" may be an intermediary status there.

I don't know if it's possible for an account to move from "Complete" to "Pending".

#

But if you're working at the API level, then the API fields are more descriptive about what is changing and what needs to be done. For instance if new requirements are added to requirements.currently_due then you know there are new requirements that need to be collected.

tight hound
#

so basically you are saying, the status coud move between from and to any of the status, at any time, potentially, and I should prepare for it, yes?

#

If so - how to react on each of the statuses? Like rejected - it seems there are some really FINAL / bad states like FRAUD. I would assume in such case best is to close the customer's account or at least block and manually check it.

#

but then there are softer rejections, like timeouts

#

requirements.pending_verification
platform_paused
requirements.past_due

#

I assume in such cases, I could allow the customer to restart the proces?

#

and if yes, how to restart? By fully creating a new account, or updating the existing one?

little jewel
#

Yes, you should be prepared for accounts to move into any possible state. I'm not sure I understand the connection between timeouts and accounts being rejected, could you share where you're seeing those two concepts being associated?

tight hound
#

I lookd at the disabled reasons

#

for instance platform_paused I just checked

#

it seems, this only happens if the stripe main account admin goes to the dashboard and PAUSES the payment for the connected account

#

well then.. if I get it correctly. technically the account is still in good standing, just paused

#

then there is "requirements.pending_verification"

#

it seems here a verification was needed but not given, and so it is terminated - or PAUSED?

#

next is requirements.past_due - it seems, the account was not fully updated n time, and so is terminated.. but this again might not be final?

#

so those states, I assume the connect account holder could recover from, somehow

#

And then there are very STRONG disabled reason:
rejected.fraud
rejected.listed
rejected.terms_of_service
rejected.other
listed

Those to mean seem unrecoverable. Stripe connect account closed / terminated, bye bye... and i guess I would / should stop busines with this client

#

and last but not least, two states are unclear to me:
under_review
other

#

but probably also unrecoverable?

little jewel
little jewel
little jewel
tight hound
#

so for soft things like past_due -

#

how to recover?

#

a) by creating a new account

little jewel
#

No

tight hound
#

b) by creating a new link with status ONBOARDING

little jewel
#

By providing the missing information for the existing account.

#

What type of Connected accounts are you working with? (Express, Custom, Standard)

tight hound
#

b) by creating a new link with status UPDATE

#

for payouts only

#

for the link, there are these status:
account_onboarding
account_update
custom_account_update
custom_account_verification
or custom_account_verification

#

and again its not clear when to use which

#

Express

little jewel
tight hound
#

in the stripe api java library I am using

#

ok I assume it is legacy stuff only and I will then ignore it for now

little jewel
#

But account_onboarding is what you want to use.

tight hound
#

I re-read the documentation... it seems:

#

account_onboarding
Requirements().getCurrentlyDue().
Requirements().getEventuallyDue() are not empty

#

so this will allow to add missing data

#

and account_update can be called when the account is COMPLETE / in perfect standing, but the company moved to a new location, for instance, I assume

little jewel
#

Not for Express accounts, account_update is only available for Custom Connected accounts.

tight hound
#

--
The documentaiton says, update will re-display all fields.
and onboarding only the missing fields

#

but how could I then update customer information when they move to a new address???

little jewel
#

When looking at our API spec for Connect scenarios, you may see tags like CUSTOM ONLY beside fields or endpoints that indicate which type of accounts they can be used with.

tight hound
#

ok ... but... how could I then update customer information when they move to a new address???

little jewel
#

Double checking, but I think you need to direct them to the Express Dashboard.

#

If you want the ability to directly adjust the information related to your Connected accounts, then you'd want to use Custom connected accounts instead.

tight hound
#

but custom connected account, AFAIK means I have to implement the entire UI that stripe provides with mobile checking, document uploading, bank acccount validation.. everything... right?

#

that is out question for me atm... too much effort

#

How can the customers go to the express dashboard? Where does the api give me the link?

little jewel
little jewel
tight hound
#

now I am confused. So is there an "extra implementatin effort for custom accounts, or not?

little jewel
#

Well Custom accounts wouldn't have access to the Express dashboard, so if you wanted to provide the type of graphics and visual representations it includes then you would need to build that.

tight hound
#

Well Custom accounts wouldn't have access to the Express dashboard, so if you wanted to provide the type of graphics and visual representations it includes then you would need to build that.

#

But they would allow to create an update link

#

which sounds super nice

#

basically I want to show the payouts PENDING and DONE in my UI anyway

#

so the only reason to visit stripe would be to update the customer data

#

is there any extra effort needed with custom account then? besides that it allow to update the account using the same UI as the onboarding UI, as I understood?

little jewel
#

The one thing I need to double check about using the hosted flow with Custom accounts, is if the bank account information for the account still needs to be collected through a different flow (I know it needed to in the past but am not sure if that has changed).

tight hound
#

When can you do that? it's late and bed time for me.

#

To wrap up, it, you are not clear exactly which disabled reasons are final and which can be recovered from,
but some like
requirements.pending_verification
platform_paused
requirements.past_due
Can probably be recovered from.
In this case, I would create a new ONBOARDING link and provide it to the user.

In case of some states like:
rejected.fraud
rejected.listed
rejected.terms_of_service
I would terminate the customer account on my end.

With Express, I can ONLY use the ONBOARDING link. To update info later, I need to create
a one time link to the customer dashboard for the customer, or update the info myself.

With a Custom account, I can use ONBOARDING AND Update, but not the customer dashboard.

#

Correct / roughly correct?

#

The stripe documentation unfortunately is really unclear on those topics!

little jewel
tight hound
#

ok then just one more info for confirmation please:

#

so if I'd swith to custom connect accounts -

#

I could use the same / similar UI flow as the onboarding, the UPDATE also existing data.
WOuld this also allow to do both - add missing onboarding info AND overwrite existing data? That could be handy.

#

so if that is true, then actually CUSTOM sounds like the simpler process then "express"???

little jewel
#

Sorry, I'm not sure I understand the question.

tight hound
#

thing is.. we are not simple just paying out money.. we are collecting the amounts over 60 days... because it is related to stripe subsriptions (affiliate comissions) and we want to avoid that a subscription few is getting a refund... so we'd list all PENDING comissions, and then after over 60 days pay them out - and show them as paid out - so this UI we have / need in any case.

#

and do I need to make the decision between express and custom upfront, or could I also switch at a later time?

little jewel
#

You'll want to make that decision up front, otherwise you'd end up with two types of accounts. That would mean you'd either need to maintain two separate flows for the two types of accounts, or close the old type of accounts and then create new accounts of the new type for your users.

tight hound
#

ah so you are saying that express / custom info is embedded into the end customer acccounts, not into my own stripe account /dashboard generally?

little jewel
tight hound
#

So with custom connect, I could create an UPDATE Link. When the customer opens the link, my assumption / expectation is, the user would see the same kind of UI seen when they onboarded their account.. but just with pre-filled data, and they could update it.

little jewel
#

The UI is very similar, it doesn't take long to test it out, I would recommend running a test and looking at the UI/behavior to see if it fits what you're looking for.

tight hound
#

and my second question was... what happens when there is MISSING data, and an update link is created - would missing and existing data fields / pages be shown, or only the existing data to be updated?

#

because, I want to avoid creating the links twicde

pallid bay
#

👋 toby has to head out, but give me a minute and I can help

#

have you tried out these update links like toby suggested?

tight hound
#

no because as I stated its bed tme fo rme

#

ok good night