#rust_error
green estuaryBOT
đź‘‹ 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/1450876189517545636
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- rust_connect-extensions, 5 days ago, 29 messages
safe arch
Continuing "what have you already attempted"
from the platform account I connected to instead, i get the error message i pasted. My main question here is if this is possible or if i can even get access to my ac_2's connected accounts. For reference this is what stripe support through email was telling me.
Thank you for your prompt response and for confirming your decision to proceed with parallel support. We're happy to assist you in this process. Below are the necessary considerations and steps for both setting up parallel support and moving forward with the transition.
Setting Up Parallel Support
Configuration Options:
You'll need to implement logic in your application to differentiate between the two integration paths (existing Stripe Connect and the new Stripe Connect Extension) based on customer settings. This might involve adding a configuration flag or setting in your database that indicates which integration a customer should use.
API Integration:
Update your API calls to take into account which system the customer is using. This might involve routing requests to appropriate endpoints for connected accounts based on their designated integration type.
Reauthentication Process:
Make sure to communicate clearly with customers about how the reauthentication will work for those on the new extension. You'll want to provide guidance on any necessary changes they should be aware of.
Documentation:
Review the following Stripe documentation, which will provide you with essential information on integrating both systems:
Stripe Connect Overview
Building Extensions
Additional: https://support.stripe.com/questions/us-verification-requirements-for-platforms-with-custom-accounts-faq, https://support.stripe.com/questions/payouts-or-charges-not-enabled-for-connected-accounts-with-platform-gathered-verification-requirements, https://support.stripe.com/questions/connect-platforms-manage-onboarding-and-risk-requirements-for-connected-accounts]
My three follow up emails:
Thanks for the guidance on our side. To confirm - what specific action does Stripe need to take to enable the Extension for our account if any? And once we're ready, how do we signal to you to flip the switch? Should we reply to this thread with a target date/time?
Following up on our discussion, I have an urgent need for clarification, as I am receiving conflicting information from Stripe support on Discord.
The core problem is a customer whose Stripe setup is a Connect Platform with a connected account. The customer's main account is the Platform, but all their invoicing and subscriptions originate from their Connected Account.
When we currently use Connect OAuth, it authenticates to the customer's Platform account. However, we need access to their Connected Account, where the actual billing data resides.
Can you please confirm if the Connect Extension will allow us to authenticate to and access the user's Connected Account? To be clear, we need the user to log in and then grant us access to the Connected Account associated with their main Platform account.
Regarding the parallel support configuration for the Connect Extension:
Could you please provide some specific examples of what the implementation for both Configuration Options (Item 1) and API Integration (Item 2) would look like in practice?
This will help us visualize the required logic to differentiate between the existing Connect platform and the new Extension for our customers.
Thanks!
Their response
Thank you for your follow-up! I’m glad to provide further clarification and guidance regarding the Stripe Connect Extension and your integration setup.
To enable the Stripe Connect Extension for your account, generally, there are no specific actions required from Stripe unless there are unique configurations for your account.
Regarding your urgent need for clarification on accessing the connected account through the Connect Extension: Yes, the Stripe Connect Extension will allow you to authenticate and obtain access to a user's Connected Account. The reauthorization process, where the user logs in and grants you permissions, will provide your application with the necessary access specifically to their Connected Account where their invoicing and subscriptions reside. This means after transitioning to the new setup, you will be able to authenticate users against their Connected Accounts under their associated Platform account.
To help you visualize the required logic for implementing parallel support, here are some more concrete examples for Configuration Options and API Integration:
Configuration Options (Example)
Database Schema: You may want to add a column like integration_type to your customers' database table that indicates whether they are using the "Legacy Connect" or "Connect Extension."
Configuration Flag: Create an admin interface or API where you can set this flag for specific accounts, allowing you to switch them between integrations as needed.
API Integration (Example)
Routing Requests: In your API logic, you can conditionally route requests to different endpoints based on the integration_type.
OAuth Flow: Adjust the OAuth flow to trigger version-specific flows based on the integration_type.
I hope this clarifies your concerns. We're here to support you during this transition, so let us know how we can assist further.
My response:
Upon review, it appears that we do require the read_only scope. Before proceeding, I wanted to clarify: would obtaining access to this scope affect our existing read_write permissions?
If not, would it be possible for you to grant us access to the read_only scope?
Their response:
1. OAuth Implementation
Same OAuth URL: Yes, you will still use the same OAuth URL: https://connect.stripe.com/oauth/authorize.
Same Client ID for Both?: It depends on whether you are handling distinct configurations for the existing Connect and the extension. If you decide to maintain separate integrations (e.g., different routes for "Connect" and "Extension"), then you may want to use different client_ids to manage permissions and scopes appropriately. However, if both integrations use the same authorization flow or permissions, you can use the same client_id.
Same Webhook Endpoint: Yes, you can continue to use the same webhook endpoint for both integrations. You may need to differentiate how you handle events based on integration context within your webhook handling logic.
What Is Different: The differences may lie in how you handle the permissions and scopes, as well as routing those requests internally. You will need to determine the user experience based on whether the user is utilizing the existing Connect flow or the new Extension flow, which may necessitate additional logic on your end.
For the specific scenario where a user has a Platform Account (acct_PLATFORM) and a Connected Account (acct_CONNECTED):
Selecting the Connected Account: When going through the OAuth flow, users will authenticate with their Platform Account. However, they won’t select the Connected Account separately during this flow. Instead, when they authenticate, you will receive access to the Connected Account associated with that Platform Account as defined by the permissions granted during the OAuth process.
Authentication Details: After successful OAuth authentication with acct_PLATFORM, you will receive access tokens that allow you to interact with acct_CONNECTED. It’s important to note that Standard accounts usually can only connect to one Platform, which implies that they must authenticate through the main Platform account to access the connected functionality.
3. Read-Only Scope
Using read_only Scope: If you received an error when trying to use scope=read_only, it indicates you need to request the read_write scope instead, which is acceptable for both Connect and Extension modes. If you have specific use cases requiring read-only permissions, you can specify that and we would assist you with any possible exceptions.
To test the "Connected Account under Platform Account" scenario:
In test mode, you can create a "Test Standard Account" and associate it with the "Test Platform Account." You can still simulate the connected account behavior by using your acct_PLATFORM to make requests, while using related test credentials.
Concrete Implementation Questions
OAuth Parameters for "Extension" vs "Connect" Mode: The OAuth parameters enabling "Extension" vs "Connect" are largely based on the client_id and scopes you specify during the OAuth flow. You use the same OAuth URL but configure the applicable scopes and client IDs as needed.
Different Client IDs: If you choose to keep the integrations separate, then yes, use different client_ids for each mode. If you decide to unify the approach, you can utilize the same client_id.
Different Redirect URIs: Different redirect URIs are recommended if you're processing responses differently based on the integration type. This allows you to handle the returned data appropriately depending on the type of connection made during OAuth.
Regarding the read_only scope access, we can help you with that. Let me reach out internally to discuss on this and get back to you at the earliest
My response:
Thanks for the detailed explanation - that really helps clarify things.
Quick follow-up question: is the Extension actually limited to read_only, or could we use read_write as well? If read_write works for the Extension, it sounds like all we really need to do is capture the connected_account_id when users authenticate with their platform account - is that correct?
To be direct: we're currently blocked on testing this due to lack of documentation and what appear to be scope permission issues on Stripe's side. We need to be able to use the Extension and retain everything we can do today (read_write access via Connect platform standard account OAuth). Whether the Extension ends up being read_only or read_write doesn't matter to us - we just need to be unblocked so we can test and complete this migration.
Can you please enable whatever we need on your end to move forward? Is there anything you'd need from us to make that happen and is there anything else we would need enabled on stripe?
Their response:
Thank you for your continued engagement and for clarifying your needs regarding the Stripe Connect Extension. I’m here to help you get unblocked as quickly as possible.
The Stripe Connect Extension is not limited to read-only access. You can indeed use the read_write scope for the Extension just as you do with the standard Connect OAuth flow. The read_write permission should allow you to perform all operations that you currently handle through your existing Connect integration, assuming the necessary endpoints and functionalities are in place.
You are correct that capturing the connected_account_id during user authentication with their Platform account is essential. Once a user authenticates, you will obtain access to their associated Connected Account, allowing you to continue your billing and invoicing operations as you currently do.
If there are specific configurations that need to be handled on our side to facilitate testing or if you require a specific setup for your accounts, please let me know, and I will coordinate to ensure those are enabled. If there are ongoing permission issues or specific configurations blocking progress, I can escalate this matter to ensure it is addressed promptly. Please provide any detailed error messages or issues you’ve encountered, so we can present those clearly on our side.
Thank you for your patience, and I'm here to ensure you can move forward without further blockers.
my response:
Thanks for your continued assistance and descriptive responses, they've been extremely helpful!
To test the Platform + Connected Account scenario before we deploy, how can we create a test environment that simulates this? Specifically:
Do we need a separate test Stripe account set up as a Platform with Connected Accounts?
Will this work in test mode given the 'one platform per account' limitation?
Can you provide test credentials or a sandbox account that simulates this scenario?
I ask this because:
1. Test mode seems to be the only way to verify if an extension works (haven't been able to get this to work in sandbox and doesn't seem possible).
2. May be wrong on this, but it doesn't seem like stripe allows me to test the exact scenario where I, acct_MY_PLATFORM can create another acct_USER_PLATFORM with a acc_USER_CONNECTED tied to the user platform. Could you confirm if this is the case as well ?
Our logging is ready, we just want to verify it works before asking real customers to re-authenticate.
Their response/end of thread:
I’m glad to hear that you’ve found the information helpful! Testing your integration thoroughly before deployment is definitely a good strategy. Let’s go through your questions regarding setting up a test environment for the Platform and Connected Account scenario.
Yes, you will need to create a test Stripe account that is set up as a Platform. You can do this by navigating to the Stripe Dashboard and creating a new testing account. Make sure to configure it specifically as a Connect platform when doing so.
The "one platform per account" limitation does apply even in test mode. This means that while you can create Connected Accounts under your test Platform account, you cannot create another separate user-account in test mode using the same credentials associated with your primary account. However, you can simulate this by using the test accounts separately and ensuring that the functionality works as expected.
Unfortunately, Stripe does not provide sandbox accounts directly for creating multiple connected accounts tied to the same test platform account. However, during testing, you can create several test accounts that can represent your users. Here’s how you can simulate this:
- Create a separate test account for your platform.
- Use the provided test API keys (begins with sk_test_ & pk_test_) for connecting accounts, performing OAuth calls, etc.
- Utilize test user credentials to emulate different connected accounts. You can find relevant test account types and their behavior in the Stripe testing documentation: https://docs.stripe.com/testing.
You're correct that test mode is essential for validating the functionality of the extension. This way, you can check the OAuth flow and see how your application interacts with Stripe without affecting live customer data.
If you haven't done so already, please create your test Platform account and set up Connected Accounts under it using the test API keys.
Use the appropriate testing strategies as mentioned to verify functionality, checking the OAuth flow and ensuring that you can authenticate against both the Platform and Connected Accounts.
Once you have your test setup, please proceed with your tests. If you run into any specific errors or require clarification on handling distinct scenarios in the test environment, don’t hesitate to keep me posted.```
barren remnant
So my colleague in the previous discord thread is correct. You as the platform cannot access your connected accounts' (connected via oauth) connected accounts
safe arch
got it, just want to double confirm
- When the user connects their platform account, I cannot gain access to their connected accounts
- My customer's connected account cannot auth into my platform ?
barren remnant
Correct
safe arch
Is there a difference betwen a platform and extension ?
barren remnant
Not in terms of what you're trying to do
The above is still impossible
Also extensions are deprecated
And Stripe Apps are the newer approach
safe arch
understood and confirming again, this is incorrect as well ?
