#itaied-connect
light cosmos
hi there! regarding the transfers, is your real aim to indicate to the connected account who the transfer is from?
wraith dagger
doesn't really matter actually..
I'm just looking for the most simple way to do the transfers
hopefully without having to go through the platform
light cosmos
that's not possible. The transfers must go through the platform.
wraith dagger
So I have to disable the on_behalf_of, correct?
light cosmos
sorry i'm a bit confused. You can continue to make the payments using on_behalf_of. It's just that Transfers don't have an on_behalf_of parameter [0].
wraith dagger
mm... I see why you are confused.
I'm using API calls for my connected account (https://stripe.com/docs/connect/authentication), which sets both the on_behalf_of and transfers the payment to the connected account instead of the platform.
For some payments though, we need to make another transfer to another connected account. In that case I have stop using that header, right?
light cosmos
yes, if you want to make a transfer to another connected account you would need to stop using that header
wraith dagger
OK I understand.
Can you elaborate what's the point of the transfer_group?
What is its use-case?
light cosmos
you can consider it as a label/tag. It's to easily find all payments/transfers with that label/tag
you don't necessarily need to use it
wraith dagger
ok. thank you very much for your supoprt 🙂
sweet herald
👋 happy to help
wraith dagger
@light cosmos Continuing the previous thread (I can't write messages since it's archived):
Is there any difference between using charge-transfer for 1 connected account (accepting the payment to the platform on behalf of the connected account and transfering to the connected account) and using destination charges?
Is destination-charges is a case case for charge-transfer for 1 connected account?
sweet herald
@light cosmos had to step away
wraith dagger
oh ok
sweet herald
I'm taking over for them
just give me a couple of minutes to catch up
I'll try to explain the differences between the Destination and the Direct Charges
wraith dagger
just to make sure, I'm asking about destination charges and Separate charges and transfers
sweet herald
oh my bad
using charge-transfer for 1 connected account (accepting the payment to the platform on behalf of the connected account and transfering to the connected account) and using destination charges?
this is the same thing, what you described is destination charges
wraith dagger
I see. So the destination charge is some kind of a shortcut for creating a transfer for 1 connected account, correct?
What about the limitations on separate charges? Are they enforced only for transfers or also for destination charges?
Stripe supports separate charges and transfers in the following regions: Australia, Brazil, Canada, Europe, Japan, Malaysia, New Zealand, Singapore, and the US. Separate charges and transfers are supported if both your platform and the connected account are in the same region (for example, both in Australia). For cross-region support, see the cross-border transfers docs.
sweet herald
when you talk about separate charges it means that you are splitting the money between multiple parties, destination charges means that you are collecting the money for a destination (your connect account)
I see. So the destination charge is some kind of a shortcut for creating a transfer for 1 connected account, correct?
yes correct
wraith dagger
ok thank you
sweet herald
let me know if you need any more help
wraith dagger
How can I make sure to execute the transfer only once? Is there some idempotence key?
I plan to listen to payment_intent.succeeded event and then execute the transfers. But after making the transfers my service may fail to respond to stripe, which will result re-sending the event that can cause re-transfer.
sweet herald
what I would suggest is a fire-and-forget strategy with your webhooks
meaning that you would not wait for that task (the transfer) to execute
but instead return an HTTP 200 as fast as you can and handle the task logic in a scheduler of some sort
as for idempotency you could always do that, here's a guide https://stripe.com/docs/api/idempotent_requests
wraith dagger
But it just moves the problem to the scheduler, how can I make sure the scheduler won't execute the transfer twice?
sweet herald
the event wouldn't be sent twice from Stripe if the transfer fails
wraith dagger
I think the idemptence key that you just sent me solves my problem. Awesome 😄