#cows_api
brisk palmBOT
đ 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/1509221536635293767
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
sly dust
hello! to be honest our team doesn't know a whole lot about the dashboard so i might neeed to send you over to our support team for help with this one, but lemme see if i can find a quick answer for you
woeful notch
Thanks for the quick response! Looking forward to understanding how this is supposed to work.
sly dust
ok i'm just triple checking here but i think the answer is that they should only be able to disconnect if they were set up as connected accounts via oauth
generally accounts created by your platform, even those with full dashboard access, are considered to be controlled by you
let me test a couple things real quick though
woeful notch
I see. I assume this holds true even if they're connecting via an existing Stripe account?
In that case, is there a way we as the platform can programmatically request the disconnection? Ideally we don't want every customer disconnection request to involve manual work from an account holder on our side.
If that's not possible, I've also considered not disconnecting and simply stop using the old acct_xxx id. But I assume this means our customer will continue to see our platform listed in their dashboard?
sly dust
if they have a pre-existing stripe account the only way to connect is via oauth, and that's precisely the circumstance where they can voluntarily disconnect via the dashboard
what's the specific use case you're building for? if you want a very lightweight way to interact with other accounts (that they can easily de-authorize) then stripe apps might be a good route for you
also FYI i need to step away for a few minutes
woeful notch
I didn't know existing accounts can't connect using the Accounts API... that's quite surprising.
I'm implementing a payment system for a business-to-business marketplace. This Connect process is for sellers so they can be paid via PaymentIntents. They generally already have their own Stripe accounts, so we're just linking them to their accounts on our marketplace. Our setup process also involves stipulating account capibilities (eg. card/us_bank_account), which is currently passed via accounts->create() call - I assumed the onboarding process would be collecting additional information from the user if the existing account provided lacked those capabilities.
Does OAUTH better support this use case? What happens if they link an account that doesn't have the required capabilities?
sly dust
ok yes, if you want a configuration where people are bringing existing accounts (and want them to be able to disconnect) then oauth is the only way to get them connected properly
i'm 90% sure you can still call the account update API to request capabilities via oauth, let me triple check that
woeful notch
Ok, just for the sake of understanding, I do remember seeing the option to log into an existing account when following the link created by accountLinks->create(). In fact, I used that option the second time when linking the account I created the first time connecting. What exactly happens when that option is used?
This is what the onboarding URL shows.
"Have a Stripe account? You can use the same email address."
sly dust
ahhh i think the wording there is just confusing, you can have multiple stripe accounts with the same email, but this is still creating and onboarding a distinct stripe account controlled exclusively by your platform
woeful notch
That makes sense. Glad I learned this now and not later, haha...
Ok, I'll swap our implementation to use oauth instead. Thanks for all your help!