#sean-trustap_unexpected
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1250103917409341470
๐ Have more to share? Add details, code, screenshots, videos, etc. below.
Hi there ๐ are you working on building a new integration here, or maintaing an existing one? It looks like you're still using type when creating the Connected Account, which is now our older way of doing things and the error seems to be providing information about using the controller hash instead.
If this is a new integration, I'd recommend exploring leveraging the controller hash as that should better align with that support article:
https://docs.stripe.com/api/accounts/create#create_account-controller-losses
If you'd prefer continuing to use type, I think you'll need to explore using a different account type, but I'm not exactly sure which one. My guess offhand would be standard, but express might work too.
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Hi @daring parrot , thanks very much for the information. We're trying to apply existing code to a new use case. In that case, does the type parameter effectively change the default configuration of the new account? If we were to omit type and successfully create the account, are there blockers we could expect when using "legacy" flows without type, or are the APIs largely backwards-compatible with typed accounts?
Yes, the controller hash is our new approach which allows more granular control regarding settings for the Accounts being created, with the type predecessor there were only three account types with less flexibility. I do believe the flows are largely backwards compatible, but would recommend extensive testing to ensure any changes to the account structure don't impact other parts of your flow.
Perfect, thanks very much for the information, that answers all my questions ๐