#theplay3r_api

1 messages ¡ Page 1 of 1 (latest)

oak jacinthBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1423011033072533674

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

primal umbra
#

Hi, we can't advise on tax, however, I'm happy to help with your API questions. Is it correct that you'd like to only pass a partial amount to your connected accounts?

#

And to achieve that/ calculate the amounts you need the address before the checkout session is created?

hushed shore
#

I don't really need advice on tax, more so on how to withhold it using Stripe APIs, as we are using Stripe to automatically calculate this tax.

So yes - we would only like to pass a partial amount to our connected accounts.

Our fee should be 10% + tax, as we are the ones liable for tax. (Marketplace)

Currently, if we create a subscription checkout session and set transfer_data[amount_percent] to 90, it will transfer 90% including the tax, which is not what we want, nor need.

#

As explained above, we are circumventing this by calling the preview invoice API, and calculating the percentage based on that (eg. the amount with tax)

For this, as explained above, we need to know any coupons and the customer's address before creating the checkout session, which is not ideal for retention. (User has to fill our form, then again fill Stripe's checkout form)

primal umbra
#

You will need to collect that information on your own UI in this case. There is not a way to collect these details to calculate the amount to transfer to your Connected Accounts automatically on a custom logic like that.

#

Could you pass a lower percent from each transaction? Then, at the end of the month, you can calculate the total/true up and then make one-off Transfers?

hushed shore
#

The issue with that is, that our connected account's currency is different from the currency of our platform.

#

Also, can we use transfers if our platform is in a different country than the connected account?

#

We could probably use reverse transfers, but then again we run into the issue of currency conversion

oak jacinthBOT
primal umbra
#

I see your issue here.

#

Wait, which currencies? It should work the same way as you're passing the destination details

hallow owl
#

I think that this suggestion from the doc you linked to may be the most straightforward way to handle this:

For the subsequent billing cycles, you can create a webhook that listens to the invoice.created event and you can also update the Invoice, including the application_fee_amount with the flat amount that will be held by your platform including the total tax amount.
Does that sound viable for your usecase?

hushed shore
#

Yes, we use that. But only for subsequent billing cycles as mentioned.

#

We cannot use that for when the subscription is created

hushed shore
#

If that would work, that could indeed be best.

hallow owl
#

My colleague had to step away, but if you are asking about creating the subscription without a destination and then creating the transfer once the payment is paid, that would work in terms of getting the funds sent to the connected account properly. The thing I am trying to think through is whether that would mean that you would need to handle the first payment differently than subsequent ones for things like refunds

#

Just confirmed that refunds would need to be handled differently. For the refunds on recurring payments by the subscription, you would be able to just do the create Refund API call and pass reverse_transfer: true to get your funds back from the connected account. Meanwhile, because the first payment would be using the Separate Charges & Transfers flow in this scenaio you would have to make two API calls, one to create the refund and one to create the transfer. To keep things simpler, you could just use that two API call pattern for both scenarios.

#

Unfortunately that looks like it is kind of a theme for your usecase. It is reasonable, but just outside what our APIs have built in functionality for, so I think there will be additional API calls at a lot of your steps as you've seen.

hushed shore
#

Sorry, I think I'm kind of lost.

#

So, what I should do is to create checkout sessions as-if I was not using Stripe Connect, internally I would keep track of these payments and who they "belong to", at the end of the month, I would then internally calculate how much each connected account is owed and based on that I will create transfers from my platform account to each connected account.

hallow owl
#

Oh gotcha, yeah that could definitely work, just more ledgering on your part.