#loaderchips_best-practices
1 messages ยท Page 1 of 1 (latest)
๐ 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/1268132938252292141
๐ 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.
- loaderchips_code, 2 hours ago, 47 messages
- loaderchips_code, 4 days ago, 13 messages
- loaderchips_docs, 6 days ago, 23 messages
๐ happy to help
Hey Tarzan
We recommend using Direct Charges with Standard Accounts
thanks for ur time
which entails creating all the objects on the connected account
i see. so in that situation customers cannot be shared between Platform and connected account correct?
right but they will have different customer ids
so we cannot crossreference them
yes correct but you can pass in the metadata of the customer a unique ID of your own across all the accounts
this way you can find them afterwards
just taking a step back so you get the full context. We are moving from express connect account to a standard connect account. Currently all our objects, subscriptions etc belong to the platform account. For the purpose of migration it would have been ideal if everything stays the same after the migrate (utopian! i know ๐ ) So what we are looking for is the path of least resistance to do this
ideally as u mentioned already, the best way is for us to create direct charges in the connected account and have all the objects reside there. So this becomes the worst case approach for us. What we are looking for an approach that is something in between if possible.
maybe it's worth looking at this doc first https://docs.stripe.com/connect/migrate-to-controller-properties
Learn how to work with account controller properties instead of specifying account types.
at the same time would you mind explaining why this change of strategy?
like understanding why you want to move to "Standard" (which you can now do with less friction with controller properties) is necessary for you
would help me guide you
i think its mostly to reduce our financial liability. there are people who donate to nonprofits which are not enrolled with us
and disbursing that amount becomes very difficult
i m looking at the doc and it is certainly promising
if that can solve our problem, nothing like it. we can continue using our express account.
"like understanding why you want to move to "Standard" (which you can now do with less friction with controller properties) is necessary for you" -- this will only apply to our child accounts as a platform correct? In other words "our" (the platform's) account type does not change with controller properties. But we can change the properties of our customers ( express connect-ed accounts) with this
the problem with Shifting liability becomes a matter of either using Direct Charges or Destination Charges with on_behalf_of
and not a problem of Standard vs Express
Standard vs Express is usually considered based on other factors including who should pay the Stripe fees
and whether the refunds/disputes etc. should be taken care of by the platform or by the connected account
etc...
ahh yes its the last point. we want disputes refund to be handled by connected account
so with that question settled, what would u recommend?
then you can't use Destination Charges
you can read more about that here https://docs.stripe.com/connect/charges#refund-creation
ok got it. so it will be direct charges. So just to summarize. in this option
- all objects need to be on the connected account
- platform can clone the customers but will not have direct connection with the customers on the connected accounts
- Account creation and onboarding:
Standard Connect accounts must complete Stripe's onboarding process themselves.
we cannot create or manage bank accounts for Standard Connect accounts. - Payment flows:
Payments are processed directly on the connected account, not through our platform.
Funds from successful charges go directly to the connected account's balance.
5.Fees and transfers:
we cannot take a cut of the payment automatically - any platform fees must be handled separately.
Direct charges (charging on behalf of the connected account) are not possible with Standard accounts.
6.API usage:
Most API requests must include the Stripe-Account header or stripe_account parameter to specify which connected account we're acting on behalf of. - Webhooks:
we should set up webhooks for each connected account separately.
Webhook events will be sent directly to the connected account, not to our platform.
8.PCI compliance:
The connected account is responsible for their own PCI compliance.
we cannot use our platform's Stripe.js or Elements implementations for the connected account.
9.Account management:
Standard accounts have full control over their Stripe Dashboard and account settings.
our platform cannot modify critical account information or settings for the connected account.
10.Reporting and payouts:
The connected account manages their own reporting and payout schedule.
our platform does not have direct access to the connected account's balance or payout information.
this is information gathered from various docs. If these can be verified. (especially point 7 and 8 ) that would be fantastic
ohh hello @elder hound
point 5 is not correct, you can take fees, and you can(and usually always) use Direct Charges for Standard.
point 7 is not correct, you set up a Connect endpoint on your platform(https://stripe.com/docs/connect/webhooks)
point 8 is vaguely correct, ultimately you are building the technical integration for them. They are not developers, you are, you are writing the Elements etc integration that is called on their behalf.
rest of it seems fine
ahh u r right about point 5. I think it should instead have been destination charge.
one more question about BillingPortal. Since this is created like this for a stripe connected account
session = Stripe::BillingPortal::Session.create(
{
customer: donor.stripe_id,
return_url: checkout_success_url,
configuration: configuration_id # If you're using a custom configuration
},
{
stripe_account: connected_account_id,
api_key: platform_secret_key
}
)
it will only show information for that customer specific to that connected account. we cannot force the billing portals to show information across multiple customer ids unified across multiple stripe accounts?
correct