#mikhail-larkin_best-practices
sudden houndBOT
👋 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/1379463541261602999
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
open reef
Hello for Stadandard Connect accounts we reccommend using our direct charges flow where you create the payment intents on the connected account with the Stripe-Account header and splitthe payment by setting an application_fee
https://docs.stripe.com/connect/direct-charges
This does mean that any other IDs that you specify on the payment intent should be objects that also exist on the connected account so you will need to clone down at least the payment method object on your customer to charge them on the connected account.
https://docs.stripe.com/connect/cloning-customers-across-accounts
You technically can use our destination charges flow which users transfer_data and such but that can make things like handling disputes and refunds more difficult with a Standard connect setup
proven bear
it means i need to create customers for each seller stripe accounts and create payment intent like this:
const paymentIntent = await stripe.paymentIntents.create(
{
amount: data.amount,
currency: data.currencyCode,
customer: data.stripeCustomerId,
setup_future_usage: 'off_session',
description: data.description,
},
{ stripeAccount: 'acct...' },
);
because if i use only platform customers i get "not found" error for other stripeAccount
indigo briar
Hi @open reef , I am @proven bear colleague and I am a little bit confused by the response. Does it mean that we have to create same customer on both accounts (platform as well as the connected account)? honestly it makes no sense to me as the "customer" is technically registered on our platform only once and they (the customer) can purchase from multiple vendors. If we clone the customer's data to connected account(s) and the customer changes something (like their address) we cannot (don't want to) update this data in every connected account... maybe I do not understand the idea correctly... 🤷♂️
open reef
Correct, in our API you can only work on objects on one account at a time so you will need to use the ID of a customer on the account that you are making the API call on. That would mean making copies of your customer objects and keeping them updated or copy the payment method down to each account each time you want to charge their PM on the connected account. I get that that doesn't make sense with all use cases out of the box but that is how our API works there
indigo briar
I has many implications. Would the new api Account v2 help us somehow to solve this issue?
open reef
Good question, I am not as familiar with that API. Looking in to whether that would enable a different flow for you here
indigo briar
@proven bear has tested the transfer_data: { destination: data.stripeAccountId }with standard account in a testing mode and it created transactions in both - the platform as well as the connect_account dashboard. Is that correct way how to do it?
open reef
I would reccommend not using that for your actual charges. The API works for the initial payment, but it can create a lot of problems for handling things around the payments down the line. It looks like the main ones are:
- The standard account dashboard isn't built to handle this flow so your connected accounts wouldn't be able to handle customer support issues like refunds, disputes, chargebacks. For any of those they would need to reach out to you or you would have to code up a separate system to initiate those for them.
- Stripe Tax has extra limitations in what it can calculate tax for
- Liability for chargebacks will be on your account but Standard accounts don't support account debits so you would want to make sure to create a customer and have a PM on file to charge when that comes up.
indigo briar
So how would you recommend to do this? We create the "customer" on the platform and store the customer's data (such as address) in our "platform" stripe account. next the vendor1, vendor2, ... will be created as standard connected_accounts and the customer can purchase on the platform marketplace from any of those vendors. The basic idea was we create the customer once on the platform account and simply assign connectedAccount as the vendor. Now it looks like this is not a way. We would have to create (clone) the customer to each connected_account (the purpose of this is beyond my understanding). What will happen if the vendor would login to their (connected) account and change the customer address on Stripe dashboard? The platform will never know this nor the customer, right?
Considering payment_methods - we create those payment methods on the platform as well. The payment methods have indeed the customer.id which is (again to my understanding) the customers in the platform. If we create the clone of the customer for each connected account during the checkout session does this mean the customer would have to create the payment_method again for each purchase from a new vendor? If so I don't see any purpose of the platform. Please explain
open reef
If you are creating customers on each standard account, then you only have to clone down the PM and attach it once. Payment methods are one time use if not attached to a customer, so if you aren't using customer objects on your standard accounts you would be copying the PMs down to the connected accounts each time.
The idea behind standard accounts is that they are their own full Stripe account, so they do own the objects that are on them and are able to do things like update fields on them or initiate a new payment for a given customer themselves from their UI. The purpose of the platform here is to orchastrate payments between multiple parties.
Taking a step back, can you tell me more about why you are looking to use standard connect accounts rather than Express, Custom, or one of the configs from? It sounds like you may want more control over all parts of this than our standard connect offering allows. One of our other configurations may make more sense for your setup
indigo briar
well, main reason is our limited liability
also the destination charges and transfers are quite demanding especially regarding EU regulations for marketplaces when the payment is not sent directly to the seller (reduced by the platform fee). the organization (platform provider) is/can be considered a financial institution with all the legal implications.
as we plan to simplify the customers and vendors lives by managing their data only once on the platform (addresses, payment_methods, connected_accounts) we were aware of "some" standard accounts limitations but now it looks like standard accounts actually do not allow us to use any of the actual platform features. We've spent on the stripe integrations thousands of hours and now it looks like (at least) express is the only option to move forward. can you confirm my understanding of this is correct?
sudden houndBOT
open reef
Gotcha, for the limited liability that is only supported by connect configurations where the accounts have full dashboard access, which is when we recommend using our direct charges flow, which is what requires the PM cloning and customer creation on the connected accounts.
It sounds like I may have miscommunicated earlier. Standard Connect platforms absolutely are platforms, they do have to copy data more for this flow depending on how you do it, but they can coordinate multi-party payments much the same as any other platform on Stripe. Can you speak to what specific platform functionality isn't usable here?
indigo briar
ok, let's explain it on simple flow:
the customer register on the platform (enters their address, country, etc. and we create the customer object on the platform). Next the customer goes to the marketplace and buy product1 (from a vendor1) with a new card (nowdays we store the card info with the payment_method.id for the customer in our database). Next the customer decides to go back to the marketplace and buy product2 (from a vendor2). To simplify the process the customer can select existing card and we create the payment_intent.payment_method_id.
what would we have to do if we want to utilize these existing features (same address, same card, etc.)? to my understanding with standard connected_accounts the customer always has to type the card information (such as number, expiration and cvc) when purchases from a new vendor for the first time. we would have to change the card store per vendor (connected_account) to enable use the same card for the second payment from the same vendor. right? Same for the address - we would have to send the address for the checkout from our own database but do not create customers for the transactions.
Do I understand this correctly?
frigid glade
Hi hi! I’m going to be taking over for my colleague here. Please give me a minute to read back and understand things.
You can absolutely do what you're trying to do. We have a guide here: https://docs.stripe.com/connect/direct-charges-multiple-account
indigo briar
indigo briar
ok, we'll read this for sure. what about customer's details? can we do the same thing with customer_id?
frigid glade
No, but those details are available for your app to just copy over, so you can do that.
indigo briar
does it make any sense to dig deeper to Accounts v2 api? does it help us in any way to simplify or extend current flow?
indigo briar
We still struggle with accessing detailed information about connected_account details after onboarding. We would like to monitor specific changes made on the account after onboarding so e we can update the data in the platform database.
To my understanding we have just limited options here.
frigid glade
What information about the Connected Account are you looking for?
indigo briar
literally anything we can get 🙂 for the beginning full addresses and business information, tax registrations and settings, bank accounts, etc. we would like to display part of this information (based on our platform terms and conditions) to the customer or use it for generating reports or forms.
frigid glade
With Standard Accounts, there's only so much information available to you; what you have access to will be found by retrieving the account: https://docs.stripe.com/api/accounts/retrieve
indigo briar
Last question regarding creating customers on the connected accounts. Without creating the customer on the connected account and just cloning the payment method will this provide us with the checking of the original payment method ID and the customer to avoid error when using payment method of one customer for a purchase made by another one?
frigid glade
I don't understand your question.
indigo briar
We have already met situation when we send wrong payment method id and got this error. Will the cloning keep this check working?
frigid glade
Can you share the Request ID for that one?
indigo briar
Not really. It happened in the past and i wasn’t successful in reproducing it
proven bear
I read the Stripe guide on Direct Charges with multiple accounts, and I’m still confused about one part. If I clone a PaymentMethod from the platform account to a connected Standard account, and then create a PaymentIntent in that Standard account using the cloned PaymentMethod — can I still use application_fee_amount to collect a commission as the platform?
sudden houndBOT
sonic lichen
I read the Stripe guide on Direct Charges with multiple accounts, and I’m still ...
yes! this is possible
sudden houndBOT
indigo briar
ok, we'll look into this tomorrow. it is possible we'll come back with this topic. thank you