#jket
hazy rampart
Hi there. One sec
Is there a hard requirement to use Standard accounts + Direct charges?
Destination charges could avoid these pitfalls
gray echo
Right now standard accounts + direct charges is strongly preferred, I may be able to use destination charges, but we really want it to be the connected account company being the one creating/receiving the funds directly
hazy rampart
Yeah that makes sense and is a great use-case for Standard + Direct. The issue with Direct charges is obviously the cloning situation. You cannot clone from Connect account back to Platform (only Platform to Connect). Because of this, you'll need to modify your flow so that payment methods are also collected and stored on the Platform first
gray echo
I see, and so to be clear, it's not possible to clone from connected account to connected account?
And when you have a moment, (no rush I know you have multiple threads going), but I was still curious about my last question:
If I have a platform customer and clone them to a connected account multiple times (using a token set on the 'source' property for customers.create), will it duplicate that customer on the connected account, or update the customer on the connected account?
In this scenario I'm thinking of the situation where I've already cloned an account from platform to connected account, and a payment method has been updated on the platform account but not on the connected account yet, how do I update the connected account's payment method for that customer?
hazy rampart
Yeah not possible cloning connect to connect. Cloning again will create a new customer. However, if you are managing payment methods on the platform, one thing you could do is just create a new payment method for any updates. Then, clone that payment method over to your connect accounts this way after an update: https://stripe.com/docs/payments/payment-methods/connect#cloning-payment-methods. No need to create a new customer
gray echo
Ok I see, so essentially clone the customer over one time, then for future payment method updates clone the payment method itself
hazy rampart
Exactly
gray echo
Ok, thanks for answering my questions! Very helpful
hazy rampart
No problem
Just note that creates a new payment method object
Doesn't update the existing one
Which in most cases is what you want to do anyway
Like if card number changes or something, you can't update that. You would need to create a new payment method object anyway. However, if you are calling the update payment method endpoint to update the billing address on the card (for example): https://stripe.com/docs/api/payment_methods/update. Then, you'd need to just make that update request on each connect account. That can be done async though. Like if the customer is on session, you just make the api call once on the platform (or store the updated billing details in your db). Then, you could have some background job/task to update the payment method billing details for each connect account's corresponding payment method.
spiral yokeBOT
gray echo
Ok gotcha, makes sense
One other question, could you explain the difference (or point me somewhere that does) the difference between direct charges (i.e. for invoices) vs using the "on_behalf_of" setting with destination charges?
For destination charges, the platform will still take payment first and then automatically transfer, and I know ACH transfers don't work with destination charges, but are there some other details I'm maybe missing there?
shy scaffold
Yeah there's a lot to explain here but first question - what kind of connected accounts are you working with? standard? express? custom?
gray echo
Standard accounts
shy scaffold
So I'll start off by saying if you have standard accounts we almost always recommend using direct charges
gray echo
Right, I'd prefer to use direct charges (you can see above thread for some wrinkles in our use case)
shy scaffold
ohhh interesting - give me a minute to read back and think
gray echo
Ok no problem, I appreciate it
shy scaffold
Yeah I see the issue here - you want to use invoicing (which requires a customer) but you also want the ability to clone payment methods
gray echo
Right, it mostly boils down to for new customers—where we don't have their payment info yet—we have situations where we'd like to just send them an invoice and have them enter their payment details then and there, but then we can't get the payment details back out of the connected account if we do a direct charge invoice. We could live with that, but was interested in the 'on behalf of' + destination option
shy scaffold
The problem with on_behalf_of + destination is the liability gets really blurred there (because the charge is now created on the platform you are now liable for chargeback for that charge) whereas with direct charges the liability would fall the the connected account
gray echo
I see, and same with the Stripe fees and refunds
shy scaffold
Yeah - and things like radar rules will be pulled from the platform (w/ destination charges)
gray echo
Ok, thank you for the info!
I think we're going to be ok with using direct charges for invoices, and not getting payment methods back out of the connected account for now. In the future we'll setup our service to collect payment methods ahead of time when creating invoices, so we can save payment methods on the platform's customer object.