#bachir-reverse-charge
1 messages ยท Page 1 of 1 (latest)
Hello ๐
let me take a look
can you confirm if you're using direct charges or destination charges? @tender siren
I think we use destination charges. If I understand correctly the difference, we do not specify the Stripe Account ID of the connected account when making the request.
gotcha. So let me summarize what I understand so far, feel free to correct me at any point
- You're the platform and you have a standard connected account
- Incoming charge $15, you keep $5 application fee and send $10 to the connected account
- Then you make a partial refund of $10 which reverses the transfer proportionally to your account which is $8
Is that correct?
exactly
(we don't technically use the application fee field if that makes a difference, but it's the same reasoning)
In the case of partial refund, I don't think there's a way to reverse the full amount automatically
It'll reverse the amount proportionally when you use reverse_transfer
Let me check if you can do it manually
also let me make sure I didn't skip on this question ๐
- Is it the same behaviour for Custom accounts ?
I believe so. As far as my understanding goes, It is the intended behavior with destination charges per se and not tied to any specific account types.
Arf would be nice if the API explicitly allowed to set the amount to be reversed (the same way the amount to be transferred can be specified in the transfer_data when creating the charge).
I guess reversing the transfer manually would do the trick as a workaround ?
Yeah that should do the trick
alright thanks for your help hanzo, have a great day/evening ๐
have a good one ๐
Sorry to come in at the last moment, can you confirm you are using destination charges with standard connect?
To clarify, we typically recommend direct charges with standard accounts. Destination + Standard accounts can be more trouble than they are worth.
To acheive this kind of refund with a direct charge, you can create a full refund and specify refund_application_fee=false https://stripe.com/docs/connect/direct-charges#issuing-refunds
Hey @topaz flax, thanks for the clarifications. Indeed we are using destination charges with standard accounts, but we are currently migrating to Custom accounts so the idea is to stick with destination charges.
Do you confirm it is not possible in this case (destionation charges with Custom) to achieve what I am looking for ?
IT is possible with application fees
The idea is that you charge $10, you transfer $10 to the connected account and then you take back $1 as an application fee
In the future when you refund, you can reverse the full $10and the connected account is down $1 (your fee) that you keep for yourself
Does that work in the case of partial refunds ?
In my use case, the customer is charged $15 ($10 to go to my connected account, 5$ for me). I transfer the $10.
Then the connected account decides to refund the customer of the $10. Here a partial refund is used since we are not refunding the full charge.
We do not want connected accounts to have access to the full amount ($15) - they should only have knowledge of the $10. That's why we do not transfer all the $15 to the connected account while retaining application fees.
Hope it's clear and let me know if this is not the right approach for this problem.
you can combine application fees and transfer_data[amount] I think, have you tried?
But ultimately if you transfer $10 you can get $10 back by reversing the transfer, that works fine (with Custom/Express accounts)
What do you mean exactly by using the application fees ? During charge creation or refund ? I'm using the transfer_data[amount] = 1000 when creating the charge, so the transfer works just fine - it's the reverse_transfer boolean during refund creation that's not behaving as I want it to.
Yeah you can't use reverse_transfer: true since it will do a proportional refund. You have to reverse the transfer yourself
Alright, thanks!
You think the API will be updated in the future to allow specifying the reversed amount explicitly ? ๐
No I don't see us adding that in the future since you can do this by doing 2 calls