#Harald Petersilka-qs
1 messages · Page 1 of 1 (latest)
Hi @jaunty oracle , amazing, thanks!
just give me a moment to go through your message
Could you please point out why exactly this is a not recommended approach?
I don't know the context in which you discussed this with my colleague so I wouldn't be able to know why he suggested that. His reasons my be justifiable from the context of that conversation
to answer your questions
That was the original discussion (hope the link works): https://discord.com/channels/841573134531821608/969219233563176980
I prefer focusing on trying to answer your current questions
Sure!
So are there more drawbacks when using on_behalf_of with Standard Connected accounts than the two we've already discovered?
- refunds at the Connected account do not show up at the Platform account and vice versa
This could be easily fixed if you listen to the Connect Webhook events
- the payment description is not visible at the Connected account payment list, it seems to be replaced by the payment id
could you share an example please?
Sure!
in the first screenshot (the one with "... invoice...") you'll see how it looks like at the Platform and in the second you'll see how it looks like at the connected account.
So Description and Customer are missing.
Yes because basically you're creating the invoice on behalf of the Connect Account, so what they will see is something related to the payment that was transferred to their account
So it's actually two transactions - first - the payment to the Platform account - second - the transfer to the Connected account?
yes
Ok, makes sense! Is there any chance to add additional information to the second transaction? (like description and customer)
could you please give me an example of those py_xxx
you mean the acutal value?
yes please. any would be good
that's the id of the US$32.00 payment: py_1KvIEGRUTNPyo9pV757mT0ey
thanks
just a sec
could you please give me the invoice id related to that payment?
invoice #35292936
in_xxxx
Ah. Sorry. there is no Stripe invoice linked to this payment.
the Id of the payment instead
the py_... ? isn't that the above one?
I'd have the transfer id, it that would be of any help: tr_3KvIEFDdRNthIL2D3FUjDL4f
yep no worries!
Ok, makes sense! Is there any chance to add additional information to the second transaction? (like description and customer)
you have to do that manually, by updating the py_xxx object on the connected account.
The first step is to get the id of the transfer associated with the charge which is in the transfer property on the charge object. Then, you would retrieve that transfer and you’d see the destination_payment property corresponding to the payment on the connected account (py_XXX).
(You can get all of this in one API call by using the expand feature(https://stripe.com/docs/expand) )
Then, once you get this, you’d call the Update Charge API (https://stripe.com/docs/api#update_charge) using the Stripe-Account header (https://stripe.com/docs/connect/authentication) so that you can set the description or metadata you want on that payment.
That's a great help, thanks!
So finally - do you see any other drawbacks with using on_behalf_of with Standard Connected accounts?
yes, we recommend Direct Charges for Standard accounts, not Destination charges.
For example in this model, your platform is the one paying the Stripe fees, and your platform has to issue refunds and handle chargebacks/disputes, and the Standard account has no visibility into that.
that might be what you want though, and it's technically allowed, but usually we suggest Direct Charges for Standard.
and the Standard account has no visibility into that.
like you said, they don't see any of the customer details
they only see the money you send them, not the payment or customer details etc.
Ok, got it.
But direct charges need the customer at the Connected account and cannot be used with customers that are managed by the platform account, correct?
yes
you can theoretically clone customer payment methods to the connected account (https://stripe.com/docs/connect/cloning-customers-across-accounts) though