#jfusco
sly stratus
Hello! The newer flow is intended to replace the older OAuth flow, and is the recommended approach.
Some use cases still require the OAuth approach, but most of the time the new approach works best.
copper folio
Ok, that's what it seems like. I guess my confusion was the side-comment in the newer flow: "This is the recommended method for creating standard accounts. If you’re an extension or an application that needs access to an existing account so you can provide services to your users, you can still use OAuth."
We do need the ability to connect a customer's pre-existing Stripe account, but seems like the newer non-oauth flow can also do that just fine
sly stratus
Well, no, it can't.
copper folio
i would just skip the account creation part, and go the the 2nd step to create the onboard link
sly stratus
The newer flow requires you to create the Standard account via the API. You can't connect to an existing one using that approach.
copper folio
really? seems like I could just do the newer flow by skipping to step 2
sly stratus
Give it a try; you should get an error. 🙂
copper folio
i did, and it worked in the test environment
i'm using api: https://api.stripe.com/v1/account_links, and using an existing stripe account, and it results in a link just fine, no error
sly stratus
Really? Can you give me the request ID so I can take a look?
copper folio
yes let me track that down, i can get that in the ui console? i don't see that returned in the json response.
sly stratus
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
copper folio
req_kdIs43KCoI0OwD
the 'account' in the request post has existed for a long time. we re-use it a lot to test our internal flows, e.g. where a customer has their own stripe account, as opposed to a more custom/managed flow.
odd owlBOT
copper folio
frankly, i don't understand why it wouldn't work (like you're claiming). why would the api on the create accountLink call know or care when the Account was created (whether just newly created like in step 1, or something older that's actually been used before).
sly stratus
And going though the Account Link's URL and completing the process connects that existing account to your account? Or does it create a new account and connect that?
copper folio
so let me try going into the link, which may raise another question...
ok, I did a second call to create yet another new link. In Stripe now in the accountLink url, and it's asking for my Taxpayer ID number
what am I supposed to type in there, this account link was created off of a 'sk_test' api key, so i'm assuming this is a test scenario. I'm trying '00-0000000' and the UI responds with: 'Invalid Tax ID. 00-0000000 is a disallowed value.'
sly stratus
Hm, since this is a Standard account you may need to use actual info. We only have test IDs for Express and Custom accounts I think, but let me double-check...
copper folio
ok, really?
What should be the Type value if it's a customer coming into our system to sell stuff (we are a ticketing/registration provider) and they already have Stripe setup? It should not be Standard, but Express or Custom?
sly stratus
But hang on, I'm not sure this is a fair test... is this account already connected to your platform?
copper folio
yes, it is already connected
sly stratus
Yeah, I think that's why it's "working".
copper folio
so i can try to create a new one also
sly stratus
If you create a new test account by signing up at Stripe.com in an incognito window and try that one what happens?
copper folio
would i really need to do it that way?
sly stratus
How else would you do it?
copper folio
create a new account, but still logged in
sly stratus
You want to test connecting to a Stripe account that's not affiliated with your own platform or account in any way, right?
You can create a new account in the Dashboard, I suppose.
copper folio
yeah, so if I create a new account logged in, you're saying it's automatically linked with our central platform account?
linked as in making payments on it and accessible via the platform account
sly stratus
No, it wouldn't be, but it would be associated with your personal user account.
copper folio
ok so i just created another account 'jim-test1', u.s. based
ok, so now I do get the error: "message": "You requested an account link for an account that is not connected to your platform or does not exist.",
sly stratus
Yep, there we go, that's the error! 🙂
copper folio
so the funny thing about all this, and maybe the documentation is not very clear, is that I thought this was the whole point of the create account link api. To get it connected to the platform. I create the account link using the platform's key, then the owner of the stripe account uses that link and logs in and so forth...
sly stratus
The new flow starts with the platform creating the Stripe Account itself, then you can create an Account Link for it and give it to the intended account holder so they can onboard onto that account.
Account Links can't be created for arbitrary accounts, only ones that are connected to your platform.
copper folio
so we do need to keep the existing Oauth flow for clients that happen to have their own Stripe already then
sly stratus
The Account Link isn't for connecting (that's already happened) it's for onboarding or updating account details.
Yep, you need to keep OAuth if you need to connect to existing Stripe accounts you did not create.
copper folio
is that ever going away, or is there a thought to maybe consolidate onto a single flow regardless of if the platform created the account or it was separate and pre-existing? or is Oauth flow going to be around for a while, and you guys have no plans to change that at this point?
sly stratus
I do not know of any plans to change things in this regard. OAuth is going to stick around for use cases like yours, and the new flow will stick around for all other use cases.
copper folio
ok. we definitely need to support both. Some clients especially larger ones already have Stripe, many do not. Probably 80/20 rule, where 80% will be brand new w/no current stripe account.
i had another question related to both flows. Both involve at some point a link going out to the user, you guys want it directly in the flow and not emailed to the user, then they do "stuff" in the Stripe link, then submit, and then it's linked... so there's no way (i'm guessing) to link up an account purely by API calls, right? There always has to be some intermediate action the user takes via a link into Stripe?
sly stratus
I have to run, but @austere hare can answer your latest question. 🙂
copper folio
this is a research item we're doing, investigating making the onboarding even more seamless and easy beyond what it is now
ok
@austere hare not sure if you saw that question from 4 minutes ago
austere hare
Apologies, still catching up on the server. Reading your latest question now
copper folio
take your time, no worries
austere hare
I thought that if you created the new account with your platform key it would already be connected and just needed onboarding. It is sounding like that is not the case?
For Standard Connect flows you will need some link like that for onboarding at some point. I think Custom accounts are the only ones that don't require the user themselves to manually intervene at some point
copper folio
so for the 'brand new' account use-case, now i do understand after chatting on this thread that yes it seems like it is "linked" if we create the new account ourselves, that newer flow. So does that mean we could start taking payments on it? Maybe not remit anything since no bank account, but taking payments would be nice.
i.e., they don't have to complete 'onboarding' via that link for us to start taking payments?
the other question I had - why don't you guys like or recommend just emailing the account link to the user? You recommend not to do that, and just have this link put right into our existing app's UI flow. We kind-of would prefer if it's sent out via an email, but then of course there's the issue where it expires after one hour which is not ideal.
i'm referring to a comment in your docs: "Warning
Don’t email, text, or otherwise send account link URLs directly to your user. Instead, redirect the authenticated user to the account link URL from within your platform’s application."
austere hare
They would have to complete onboarding to be enabled for payments. I can find our doc on checking their capabilities so you can see this in test mode yourself.
copper folio
ok, so they would have to. no big deal, i just wanted to be sure.
austere hare
I think that that is because the account links are one-time use. Often email and chat clients will try to be helpful and access the link so they can give a preview of the page but that ends up invalidating the link
copper folio
so why don't you recommend just emailing out the link, why that warning?
ok, so it's all about the expiration time on the link
that makes it sketchy to be emailed because of the tight time constraint
austere hare
Not a time restraint actually just a visitation restraint. The very first time the link is visited it will be invalidated
copper folio
ok, so then why the warning on it being emailed?
austere hare
I do think there is a security angle here too. The user shouldn't be able to get to this unless they are authenticated with you as that doc calls out
copper folio
ok
austere hare
I've definitely had email clients that auto expand pages. Was once even talking to a dev where it turned out their clipboard manager that was silently visiting their links and invalidating them even when they just copy and pasted
copper folio
maybe we can have the link be a link or button in our app that the user clicks on when they want to do the onboarding
the onboard account link i mean. i'm just trying to see if we can get around it having to be force-fed directly into our UI flow
austere hare
Yeah, I think having a level of indirection there will be helpful. You can always create a new link and just direct them there
copper folio
i suppose we could just always create a new link if we had to, every time they clicked on some 'onboard' button or link on our App, then re-direct to that new account link on stripe. We'd want to keep track of account capabilities, i.e. if they are fully onboarded then the link should then be disabled or hidden.
or look at the 'details_submitted' param on their Account.
also, with the use-case where it's a pre-existing Stripe account that we are trying to connect to, seems like that has to be the older Oauth flow, and that does seem like it should directly be in the flow of the UI like we do currently.
odd owlBOT
copper folio
although maybe that's another thing that is just a link or button in our app to 'link' or connect to it, the oauth flow at: https://connect.stripe.com/oauth/v2/authorize/etc...
because i don't think that oauth connect link has an expiration. The user could I think just click on it and complete that flow when they're ready to. This would be for bigger clients that perhaps already have Stripe.
we're just trying to determine feasibility of getting the linking of accounts not directly in the face of the user shoe-horned into our UI flow, but something they could perhaps click on when they wanted to or were ready to.
i assume that connect via ouath link, that doesn't have a time expiration, right?
terse ferry
No, that link is static/long lived
The account specific Account Links though are sensitive. They're specific to that account and time limited.
copper folio
yeah, it seems like it is, i don't see anything specific on it like the account link onboard for a brand new account
yep
so the oauth flow i could maybe have that as a link in our app, again if the User already had their own Stripe account for a while. then they just click on it whenever
terse ferry
It's an older flow we don't recommend anymore. For new accounts we suggest creating those via the API and using the Account Link flow.
copper folio
yes, it's an older flow, but a minority (maybe 10% or whatever) of our clients especially bigger ones may already have Stripe. So it seems like we need to still have that old-school Oauth flow for that use-case.
but for the 80 to 90% of clients we onboard yet who want a new Stripe (standard) account, we should probably use that newer 'create and onboard' flow: https://stripe.com/docs/connect/standard-accounts
does that make sense? If so, I think I'm good for now on questions, i'll probably log out for the day.
terse ferry
Yep, that's right! THat's what we recommend for new accounts
copper folio
yep. and i think that's the majority case especially for most of our smaller to middle sized customers.
we also have by request the ability to create a 'custom' stripe account for them, totally different flow where it's what you used to call the 'managed account' scenario. that is pretty seamless and i think should remain in place.
ok, if this all makes sense, i guess i'll log out
terse ferry
You can also create and manage custom accounts if you need to, but yes that's a very different integration with different responsibilities and liability for your platform: https://stripe.com/docs/connect/accounts#choosing-approach
BUt you can create and use both types of account in parallel without issue, if thats what you mean
copper folio
yes, we already have been doing this, really both flows for quite a while, for more than 7 years.
i was just trying to see areas we can update a bit and streamline. For managed account I think we're good because the client isn't really re-directed and we mostly handle the stripe stuff for them, they just need to give the bank account info for Payouts.
really was just trying to simplify a bit the Standard account flow
Ok, I need to get going.
thank you for helping out!
terse ferry
NP - have a good one!