#bkrnetic

1 messages ยท Page 1 of 1 (latest)

plucky sorrelBOT
gusty cloud
#

For #2, no, you will never get an error that says a user has a connected account. You will always be able to add an account to your platform, even if that person already has a Stripe account with another platform. The standard way to do this now is that every platform would have an account for that user so they'd be pretty much completely separate.

#

For #1, yes, you will want to put all of your users through the same flow when they create an account on your platform. As far as I know, Stripe does not re-use the old KYC verification.

teal canyon
#

When using the refresh link for Connect onboarding, is it bad practice to include account id in the link? I imagine it is better to create new account and generate new account link for that new account.

gusty cloud
#

Can you tell me more about what you mean by refresh link? Account links are safe for users to see, they can't do anything with them unless they have your API secret key

teal canyon
quasi turtle
#

๐Ÿ‘‹ taking over, let us know if above helps or if you have follow ups ๐Ÿ™‚

gusty cloud
#

Ah, it is totally fine to include the account ID there and re-use the account when creating a new AccountLink for the user to onboard with

#

I do get what you are getting at security-wise, like a user could technically replace their account ID with someone else's but if you are just re-using account IDs they won't really be able to do anything other than put in their own info in the onboarding page.

#

You can create a totally new account if you want though you'll likely want to make sure to delete the old ones so your dashboard does not get cluttered

teal canyon
#

I understand now. Thanks for clarification.

As for the implementation of Stripe Connect Standard account creation, I would like to confirm with you my flow idea:

  1. Our mobile app pings the backend to retrieve account link. Backend creates an account, stores account ID in users table and generates account link with that ID.
  2. Mobile app opens the link and user is navigated to onboarding flow
  3. If user completes the flow successfully, user is redirected to the desired location in the mobile app (value of return_url)
  4. If users fails to complete the flow for whatsoever reason and tries to attempt the link for onboarding, Stripe redirects him to the value of refresh_url which should redirect user to new URL for onboarding. In that URL we can include account ID in order to create the new link for the same account previously created, not to make our dashboard messy.
  5. To make sure if user completed everything successfully, backend should listen to account.updated event and check the value of details_submitted field.
  6. We should provide users with the option to continue the flow some other time in case somebody exits the flow at some point.
gusty cloud
#

Yep that all sounds right to me

teal canyon
#

Thanks a lot Pompey, your help is very appreciated. Talk to you again if necessary. Cheers!

terse owl
#

@teal canyon How can I help?

teal canyon
#

As for the refresh link here: https://stripe.com/docs/connect/standard-accounts#return-user

Security wise - should it be a URL that goes into our platform and makes sure the user is authorized before redirecting to new Account URL?

Currently I implemented it as a basic redirect, but I am not sure that is the best since anybody can use the old link and then get redirected to the new one.

terse owl
#

You mean the refresh_url param?

teal canyon
#

Yes

#

We use mobile app that uses Flutter's WebView to open the link within the app. If user refreshes the URL it will redirect user to refresh URL. I assume it should be an URL that redirects user back to mobile app that pings the backend , retrieves the new account URL and then reopens the WebView and opens the new URL?

terse owl
#

It would generally be an endpoint in your app that creates a new Account Link for the acct_xxx ID in question and redirects the user to the new onboaridng URL yes

#

If you want to auth users at that endpoint then that sounds like a logical approach

teal canyon
terse owl
#

Yes I'd say you'd need to re-auth users at the refresh_url endpoint

teal canyon
#

Thanks @terse owl . Have a nice day!