Connected accounts - calculating application_fee
284 views
Skip to first unread message
SJW
Mar 15, 2021, 7:09:12 PM3/15/21
to Stripe API Discussion
I have integrated Stripe and am playing with Connected Accounts.
thanks
I have successfully used the destination to pass the funds onto a connected account and pass back an application fee:
'application_fee_amount' => calculateAppFee($json_obj->amount),
'transfer_data' => [
'destination' => 'acct_xxxxxxxx',
],The application fee is calculated based on the purchase amount however, the stripe fees are variable depending on what card is being used.
Given there is no way for me to determine what type of card is being used, how do I determine the `application_fee_amount` without knowing what Stripe will take?
I calculated using the domestic fee $0.30 + 1.75% BUT, when testing, the test card is a USA card which is an international card which calculates at $0.30 + 2.9% (effectively leaving me 1.15% out of pocket)
thanks
Remi J.
Mar 15, 2021, 8:29:40 PM3/15/21
to Stripe API Discussion
Hello,
My usual recommendation when someone asks this question is to avoid building your entire pricing model based on Stripe's especially in countries with multiple pricing schemes like this. While it's easy to say for me, I do believe it avoids those issues as you can't have your pricing be Stripe's pricing on top of your email provider's pricing and your cloud provider's pricing, etc. While you can take fees to cover exactly what Stripe would, it won't allow you to plan for future fraud or disputes. For example where there might be an extra $15 fee for each charge that is disputed and that you lose and need to cover. In that world, it is better to plan your pricing in a way where the domestic or international pricing doesn't affect your own bottom line directly.
With that said, you could determine whether the pricing applied will be domestic or not by creating the PaymentMethod upfront client-side and then modifying your application fee amount based on that information server-side. This would require extra API requests though so it might not be a good fit depending on how many payments you might be accepting in parallel. Alternatively you could take a larger share of the fee and partially refund it based on what fee Stripe really took by creating a refund [1] after the fact. While not the best experience on reconciliation it could potentially solve your problem.
I hope this helps unblock you though!
Best,
Remi
--
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
SJW
Mar 15, 2021, 9:23:58 PM3/15/21
to Stripe API Discussion
Oh... really?
I thought it was going to be a simple easy answer given anyone using connected accounts surely just wants to add a margin on?
My entire pricing model isn't based on Stripes - I just want to add a $0.50 or a 0.25% charge irrespective of what stripe charges - I want the charges to be irrelevant to the transaction charges - take the fee and let me add a margin... (I am already doing this with another payment gateway and looking at adding stripe as a 2nd payment option...)
I guess stripe isn't overly focused on this capability as it probably doesn't benefit them ... perhaps I just need to stick with what I've got.
On Tuesday, 16 March 2021 11:29:40 UTC+11, Remi J. wrote:
Hello,My usual recommendation when someone asks this question is to avoid building your entire pricing model based on Stripe's especially in countries with multiple pricing schemes like this. While it's easy to say for me, I do believe it avoids those issues as you can't have your pricing be Stripe's pricing on top of your email provider's pricing and your cloud provider's pricing, etc. While you can take fees to cover exactly what Stripe would, it won't allow you to plan for future fraud or disputes. For example where there might be an extra $15 fee for each charge that is disputed and that you lose and need to cover. In that world, it is better to plan your pricing in a way where the domestic or international pricing doesn't affect your own bottom line directly.With that said, you could determine whether the pricing applied will be domestic or not by creating the PaymentMethod upfront client-side and then modifying your application fee amount based on that information server-side. This would require extra API requests though so it might not be a good fit depending on how many payments you might be accepting in parallel. Alternatively you could take a larger share of the fee and partially refund it based on what fee Stripe really took by creating a refund [1] after the fact. While not the best experience on reconciliation it could potentially solve your problem.I hope this helps unblock you though!Best,Remi
On Mon, Mar 15, 2021 at 4:09 PM SJW <shanno...@gmail.com> wrote:
I have integrated Stripe and am playing with Connected Accounts.--I have successfully used the destination to pass the funds onto a connected account and pass back an application fee:
'transfer_data' => [
'destination' => 'acct_xxxxxxxx',
],The application fee is calculated based on the purchase amount however, the stripe fees are variable depending on what card is being used.Given there is no way for me to determine what type of card is being used, how do I determine the `application_fee_amount` without knowing what Stripe will take?I calculated using the domestic fee $0.30 + 1.75% BUT, when testing, the test card is a USA card which is an international card which calculates at $0.30 + 2.9% (effectively leaving me 1.15% out of pocket)
thanks
To unsubscribe from this group and stop receiving emails from it, send an email to api-d...@lists.stripe.com.
Remi J.
Mar 15, 2021, 10:33:14 PM3/15/21
to Stripe API Discussion
That's definitely good feedback and something I've heard before from other developers but it's surprisingly not as common as you would assume.
We do have a way to add your fee onto whatever we charge on our end and this is done by using what we call Direct Charges [1]. This flow of funds is only recommended for platforms with Standard accounts but it does fit what you are looking for and is more common for platforms that add a service on top of Stripe. On the other hand, platforms using destination charges [2] more often build their own feature but with Stripe hidden or white labeled and in that case this flow is not yet possible though it's definitely nothing we talked about before. I'll flag internally though as something that we should continue re-evaluating more often!
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
SJW
Mar 15, 2021, 11:26:54 PM3/15/21
to Stripe API Discussion
Ok .... Just ran a test transaction and that is exactly what I was looking for.
Thanks. This is exactly what I want. Although, if you don't know the Stripe lingo (like me) - it is very difficult to understand what options I should be considering...
On Tuesday, 16 March 2021 13:33:14 UTC+11, Remi J. wrote:
That's definitely good feedback and something I've heard before from other developers but it's surprisingly not as common as you would assume.We do have a way to add your fee onto whatever we charge on our end and this is done by using what we call Direct Charges [1]. This flow of funds is only recommended for platforms with Standard accounts but it does fit what you are looking for and is more common for platforms that add a service on top of Stripe. On the other hand, platforms using destination charges [2] more often build their own feature but with Stripe hidden or white labeled and in that case this flow is not yet possible though it's definitely nothing we talked about before. I'll flag internally though as something that we should continue re-evaluating more often!
To unsubscribe from this group and stop receiving emails from it, send an email to api-d...@lists.stripe.com.
Remi J.
Mar 15, 2021, 11:32:36 PM3/15/21
to Stripe API Discussion
It's all based on what type of Stripe accounts you are using. If you use Custom or Express accounts, always use Destination Charges [1], which is what the code you shared originally was using. If you use Standard accounts, always use Direct Charges [2] instead. We have a documentation page on the type of charges to use [3] that explains some of the differences at a high level.
Ultimately the flow of funds, who is responsible for liability of refunds and disputes ultimately, who end customers will talk to about charges in general or whether your own customer (the connected account) has access to their own Dashboard is what you should focus on. The integration path (Direct versus Destination) is less of a conscious choice and just comes down to the first set of questions which is usually something you choose really early on in your integration.
I'd strongly recommend talking to our support team at this point so that they can look at your exact business model and what you are trying to offer your own customers and they can help you make the best choice. Feel free to mention this discussion with me here and it can help ensure you're aligned!
Best,
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
Reply all
Reply to author
Forward
0 new messages