Connected accounts viewed through the dashboard provide insufficient context to work properly

[dan-massey]

Is your feature request related to a problem? Please describe.
I'm struggling to make my app work correctly with Connected accounts viewed through the dashboard of the parent Connect account.

1. I have a Stripe App that displays a component in the stripe.dashboard.customer.detail viewport
2. I have installed that App on a Connect account (let's call it A1, Account ID acct_1IfGs2KHtUMqOYFU)
3. Inside that component, I can get the current Customer ID from the extensionContext extensionContext.environment.objectContext.id and the account ID of A1 from the extensionContext.userContext.account.id
4. This works fine for dashboard pages for Customers of A1, e.g. /test/customers/cus_OGAUOfA0Iey1jj
5. My Stripe app shows up if I open the Customer page for a Connected Account (let's call it C1 with Account ID acct_1Q3W5yGfrzfb7Jof) , e.g. by going to /test/connect/accounts/acct_1Q3W5yGfrzfb7Jof/customers/cus_QvMqTWzSvF9Gxm
6. extensionContext.userContext.account.id gives me the Account ID of A1 not C1
7. This causes me problems because when my background tries to make a call to the Stripe API, it references the correct customer ID but A1s Account ID and the API call is rejected.

Describe the solution you'd like
Either:

• A way to get both Account IDs when viewing dashboard pages within a connected account
• Or a way to prevent my component showing up in the stripe.dashboard.customer.detail viewport in it's within a connected account (to stop it from being broken)
• Better documentation of viewports within Connected Accounts.

[bensontrent]

I think I see where you're coming from here. Let me confirm your circumstance:

1. Anyone who installs your app essentially becomes your connected account.
2. However, you do not have permission to access data on your connected account's connected account, when you app is viewed as a child of the account in the dashboard at a https://dashboard.stripe.com/${isTest ? "test" : ""}/connect/${accountId} view

Is this correct?

Side note, I ddin't know it was possible for a parent account to install an app on behalf for all their connected accounts, except when using the Connected Apps beta using a custom (non-stripe) dashboard. This could be an interface bug where your app is shown in the Stripe sidebar in the connected account view when it shouldn't be.

[dan-massey]

Yes, that's what I saw.

I've only reproduced this in test mode in the connect account I'm developing my app in, with the app installed in test mode. I don't know if it occurs when an end user installs the app from the marketplace.

I'm also not sure what the intended behavior is.

(If it's intended that Marketplace apps can be installed by a Connect account on behalf of all connected accounts and it becomes possible for the installed app to work correctly, it would be great to get enough information to be able to charge an account a subscription based on total number of accounts.)

[bensontrent]

I'm still working on a Stripe Apps Production example app that would facilitate charging for an app.

You don't have access to your connected accounts' connected accounts.

But say you offer a required login within your app to your microsite to facilitate payments for your app's subscription or usage; this is the direction you'd need to go. Imagine, say, your app has a login button. The login button would lead to a microsite automatically creating a Stripe User. This Stripe User would live in your API. Your user would also live as an actual user in another Stripe Company (from there, you could charge a subscription or usage fee).
My example app is still a few months away. I met with the Stripe Apps team about this issue, and I know it's now on their roadmap...so they may offer their own solution. Give me a little patience, and I'll publish my production-ready example:

The example has these features:

• A login firewall
• A Firebase (for auth) and a subabasse.js (for API) backend.
• Each new user in your app becomes a Stripe Customer and a separate Stripe Company
• You'll be able to query if the user has not paid, is on a free trial, or is past due, or is allowed to use the app