#bas1920_best-practices

1 messages · Page 1 of 1 (latest)

pale kernelBOT
#

đź‘‹ 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/1217430724290809927

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

coarse linden
#

We have a site with a multi-layered reseller system and a subscription service.
For all income, we transfer a set amount to different underlying resellers. So when we charge a customer through their subscription, we transfer 10% of the amount to account A, 10% to account B and 20% to account C for instance. We keep the remaining 60% in this example.
Is it possible to set this up automatically (via Stripe Connect)? Or should I use custom payouts to track income and divide it myself through the use of the API?

#

That was the full question.

urban crystalBOT
gritty canopy
coarse linden
#

Is it best to do this with webhooks? So receiving all succesfull payments on a webhook, dissecting the payment (where it came from) and then creating the payouts manually?

gritty canopy
#

Seems logical yes. You would need to initiate the transfer first to move the balance to the related accounts

#

The payout to the external account is a separate process

coarse linden
#

Would all subscription incomes also flow through these webhooks?

gritty canopy
coarse linden
#

Thanks!

#

But using SC&T I'm reading that I should use the transfer_group property initially when creating the payment intent. Can I use transfers without using the transfer_group property?

#

This would allow me more flexibility to decide who gets what upon payment succeeded

#

So I would like to decide, when the webhook is run upon the succesful payment intent, which Connect accounts get how many.

#

I think in my case the transfer groups is not needed?

gritty canopy
#

It's optional yes

gritty canopy
coarse linden
#

I don't really grasp the notion of these transfer groups. As I see it right now, when I receive a payment succesful (webhook), I create several Transfers to the associated accounts, transfering a share of the total amount to the respective Connect accounts.

#

So in my example, if I receive 100 dollars I:

  • create a transfer of 10$ to account A,
  • create a transfer of 10$ to account B,
  • create a transfer of 20$ to account A.
#

I don't see what the 'transfer groups' adds to this process.

#

Or is transfer groups, in this case, a mechanism to later track the division of the total amount between account A, B and C? So I can later see which payment they refered to?

gritty canopy
#

It's just a way to associate a transfer (or transfers) with an internal reference/record. It doesn't affect Stripe functioanlity at all:

The transfer_group only identifies associated objects. It doesn’t affect any standard functionality. To prevent a transfer from executing before the funds from the associated charge are available, use the transfer’s source_transaction attribute.

coarse linden
#

But in my case there are no charges, right? Because I do not manually charge customers. They get charged through their subscription?

gritty canopy
#

There is always an underying Charge object for each payment

#

Anyway, that's related to source_transaction param – not transfer_group

#

As I explained, it's just a way to include a reference that ties the transfer(s) to an internal order or something

coarse linden
#

Ok, thanks a lot