#michael.ashton-connect-standard
1 messages · Page 1 of 1 (latest)
I'll look in to it-- might need to call the api to get that info.
(Probably before June 2021, if that's the issue here)
Yes, that's likely to be the issue
You can normally see from the controller hash on the Account object: https://stripe.com/docs/api/accounts/object#account_object-controller
The controller hash only contains "type": "account"-- I don't see any dates in the Account object after all.
Yeah there won't be a created field for Standard accounts
Yep, so it's not controlled by any single platform – it can have multiple connections
Hmm, ok-- I think I must not understand the difference between "Connected" and "controlled"
Can you tell me a bit more about the distinction?
This page will explain it better than I can: https://stripe.com/docs/connect/platform-controls-for-standard-accounts
I'm having a hard time finding the relevant information on that page. The bit that stands out to me is:
"""
Starting in June 2021, only a single Connect platform can be connected to a Standard account. This change also applies to platforms using OAuth with read_write scope.
"""
which seems to indicate that an account can only grant read_write permissions to a single integration. Is that true?
Could you share the account ID of the connected account so I can take a closer look?
Give me a second and see if I can get permission to do that. One moment.
As a rep of Stripe, are you confident that sharing that account id here is safe, or is there another way to get that id to you?
You can share it here, but you can always start a conversation with our support team through our portal instead if you'd prefer.
(Just make sure never to share your secret keys in a forum like this)
Ok, account id is acct_1DR4gdJNN4iokwSv
Thank you, pulling it up
Thank you for your patience, confirming details with my team.
Thank you so much for your patience! It does seem like this account is in this situation due to it being created prior to our platform control changes, and it having existing connections that we didn't want to inadvertently break.
Understood. So old connections are grandfathered in. The most recent of those connections is ours, made just yesterday I think. Because there were already two read_write connections on the account, we expected our attempt to connect to fail. That seems like it should be the case, even though the previous connections are grandfathered in. Is this a bug of sorts, perhaps? Something like:
"If an account had more than one connection prior to June 2021, allow multiple connections" where it should be "If an account had more than one connection prior to June 2021, allow multiple connections that were made prior to June 2021 but disallow any new ones"?
Apologies, I dropped off this thread for a bit. Checking in to what is expected with this behavior
And are there worries or questions you have about what this means for your connection to this account or is this still mostly about if it is expected to be able to connect in this situation?
No problem, thanks for your continued support! We're a platform that has a large number of clients with pre-existing stripe accounts that may or may not have pre-existing integrations. I think the biggest concern we have right now is the uncertainty around the "one integration" policy.
@latent matrix some platforms are exempted from this rule, for example analytics platforms and such (who need access to the full data). It's likely that yours might be. It's best to discuss with our support team instead of here though
Ok, thanks to everybody that helped with this one. I appreciate you taking the time!