#a.reit-connect

1 messages · Page 1 of 1 (latest)

plush iron
#

No, Connect is the way to build this

#

what's wrong with using Connect exactly?

#

if it's emails/branding/exposing Stripe, you have the option of using Custom accounts which are entirely whitelabelled and we will never email them, you are responsible for 100% of the onboarding and ongoing interaction with that accounts

#

it's a valid option but a lot of work requiring a large development team, but that's the tradeoff

topaz fable
#

Regarding emails/invoices ok.

Regarding api upgrades. When we are using connect and keep the API of our platform (main) account updated, we do not have to care about the API of the sub-account, right?

We think of using direct charges, so, creating customers/subscriptions/invoices directly in the connected account. Here we would also not need to take care of the connected accounts api version, as we only interact with the API of our main platofmr account, right?

#

One more thing regarding invoices/emails. If we are able to get access to the connected accounts, we can disable them entirely right? As discussed in the previous threads of today.

plush iron
#

ok there's so much to unpack here

#

so give me a few minutes

topaz fable
#

Ok thanks! Sorry for that

plush iron
#

ok so

When we are using connect and keep the API of our platform (main) account updated, we do not have to care about the API of the sub-account, right?
yes you only interact with the API using your own API keys, so everything is formatted/interpreted in your own API version , regardless of the specific ways you use Connect. The connected account's versions don't matter if you build things the correct way

We think of using direct charges,
that's really a complete non-runner if your whole requirement is Stripe not sending receipts/emails etc. If you use Direct, the account holder of the connected account controls email settings, not you as the platform.

if we are able to get access to the connected accounts, we can disable them entirely right?
you would never log into your Standard accounts(which is the only account type you should use with Direct) no, and there's no API for controlling those settings, it's up to the owner of the account

#

you really want a Destination charges model where you process the payments on your platform and control what the customer interacts with, and just transfer funds to the connected accounts.

topaz fable
#

"The connected account's versions don't matter if you build things the correct way"
What do you mean with "building things the correct way"?

"If you use Direct, the account holder of the connected account controls email settings, not you as the platform."
So you mean if we don't use direct charges, we can control every settings?

"you really want a Destination charges model where you process the payments on your platform and control what the customer interacts with, and just transfer funds to the connected accounts."
But with that approach we would mix up customer/subscription as well as product data of all our sub-accounts in our main account, right?

plush iron
#

So you mean if we don't use direct charges, we can control every settings?
sure, since then it's just your Stripe account processing all the payments, so you control everything(and are liable for all refunds/disputes etc) about the customer experience , and you just send raw funds to the connected accounts

#

But with that approach we would mix up customer/subscription as well as product data of all our sub-accounts in our main account, right?
yes, but that's how it is really, you can find strategies to manage the complexity if it's a problem

#

there's not really great answers for your specific use case here, so I'm just telling you what seems most appropriate to me based on your needs

topaz fable
#

Ok - but if we use destination charges, we also have to take care of wiring the stripe fees to our sub-accounts, right?

"there's not really great answers for your specific use case here, so I'm just telling you what seems most appropriate to me based on your needs"
So, you actually don't have any customers you are aware, which are having the same or similiar use cases?

plush iron
#

well it's specifically because you want Direct charges but don't want to let the account holder control the email settings

#

which just is not a well-supported part of the product(might be different if there was an API for letting the platform control email settings but there isn't), it's definitely something that comes up and there is feedback about, but it is how it is today

#

we also have to take care of wiring the stripe fees to our sub-accounts, right?
you pay the processing fee, so just set your application fee on the charges to let you cover that and take a profit, it's easier than trying to move the fee around

topaz fable
#

Ok - yeah the problem is that our platform wants to send very customized emails and invoices with different templates etc. Therefore, we wanted to disabled all emails from Stripe.

plush iron
#

cool cool. We're slowly moving to a world where you can control more about Standard accounts(https://stripe.com/docs/connect/platform-controls-for-standard-accounts is part of the ongoing work) so probably eventually it might be possible to control the account's email settings, but no timeline or commitment so like I said, I would go with a Destination model today personally

#

I have to go but my colleague Toby is here to help

topaz fable
#

Thanks karllekko! That helped a lot.

You mentioned that there are strategies to manage the complexity of having all customers/subscriptions/invoices in our main platform account, is this anywhere documented in the your docs? Is there any way of filtering customers/subscriptions/invoices by sub-account?

Regarding stripe fees: Is there a way to get the stripe fees in real time (while creating the subscription) and immediately set this as application fee? Or do we have to do this afterwards? Are there any best practises described in the docs?

Hi tobi! Thanks for your help!

#

And one more thing - direct or destination charges are regardless of the account type, right? So, if we want to do destination charges, we still can use standard account type in connect, right?

lime sedge
#

I'm not aware of a way to filter objects based on the related connected account. You can use the metadata parameter on the various objects to provide discerning information:
https://stripe.com/docs/api/metadata

Application fees on subscriptions are tricky because they're percentage based rather than being fixed amounts. You won't be able to know the Stripe fees in real time and will either need to estimate them or wait for the payments/charges to occur and then review the fees.

Stripe API reference – Metadata – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

No, we don't limit the type of charges that you can use based on the connected account type.

topaz fable
#

Thanks toby

Do you have any limits in creating customers/subscriptions/invoices or products/pricings per product in one account? As we will have a lot of them if our platform is growing.