#invisible-poles_connect-funds-flows

1 messages · Page 1 of 1 (latest)

chrome narwhalBOT
#

👋 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/1295416202721628221

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

agile matrix
#

Hi 👋

If the customers are not paying any funds, what will you deduct your fee from?

formal coral
#

the original product price.

For example, let's say Product A costs 29.99, but the first 100 users get it for free. And let's say our platform takes 10%.

In this case, our platform should receive 2.99 * 100 = $299 for those 100 users, even though they didn't pay anything -- i.e. the Product's creator is paying our platform $299 for the codes

#

ideally, it would be great if the creators can just fully manage these codes without us needing to do anything -- but if the fastest/easiest solution is for us to generate a code of some kind for them, that's fine.

agile matrix
#

Hmmm.... 🤔

Okay so here's the problem with that. In all our standard Connect funds flows (https://docs.stripe.com/connect/charges), the funds you, the plattform, collect come out of the amount the Customer pays. If the Customer doesn't pay anything, you don't get anything

formal coral
#

I see -- so it sounds like the invoice method I proposed above is probably the way to do it?

agile matrix
#

In that case you could track the transactions and then directly invoice the connected account. In that scenario you would also have a Customer object on your Platform account that mapped to each Connected Account

formal coral
#

as in we'd want to link each User with an associated Stripe Customer account, in order to track their usage of the Connected Account's free promo code? Which we then invoice based off of?

#

just confirming I understood correctly

agile matrix
#

So here's how I would do it.

  • I would create a Customer object to represent each of my Connected Accounts and put a reference to their account in the Customer metadata property: https://docs.stripe.com/api/customers/create#create_customer-metadata
  • I would create Price objects that correspond to the application fee % you plan to collect for each Connected Account (maybe a bit tedious but it'll help with reporting).
  • Then, using a Connect Webhook, create Invoice Items for each $0 transaction you wish to collect a fee for and regularly Invoice your Connect Accounts.
formal coral
#

very helpful.

one follow-up: What if a given User (my platform's data object) is both a buyer and seller, thus, they have a Stripe Customer object associated, as well as a Stripe Connected Account associated? Each would have its own ID and be its own sepeate object from a Stripe perspective, right?

agile matrix
#

Correct. You would need to manage the relationship in your own data system. However, I do recommend making use of the metadata property on most Stripe objects to add any helpful reference numbers or other information.

#

For instance, you could add a user_id key and store your own unique ID value

#

Then you can easily look up the User object from either Connect Account or Customer

formal coral
#

fair enough -- thanks, this gives me the general idea of what needs to be done.

But that leads me to another question from a bit earlier.

#

for curiosity's sake, is there a document about connected accounts managing/generating their own promo codes?

agile matrix
#

Not specifically. That depends on how you create charges

formal coral
#

We create a CheckoutSession with the pricing set based on the seller

agile matrix
#

If you use Direct Charges, the Promo codes (as well as any transactions) occur on the Connected Account

formal coral
#

We use Destination Charges

agile matrix
#

In that case, since all the payment objects exist on the Platform Account, you would also need the Promo codes to exist there as well.

#

You could provide a UI that allows Connected Accounts to create their own Promo Code objects on your account

#

But you would not be able to control which Promo Codes applied to which Checkout Session based only on the Connect Account

#

You could make that work if you have specific Product objects for each Connected Account though

#

And you could use the coupon.applies_to.products parameter to ensure that specific promo codes only apply to specific products

formal coral
#

so we have a data object in our Systems called "MarketplaceProduct" -- which is basically a single "sellable thing".

Would you advise making a Stripe Product object for each of our "MarketplaceProduct" objects? And then link the Stripe Product objects to the CheckoutSession's line items? I.e. using SessionCreateParams.LineItem.PriceData.builder().setProduct(productId)?

And then when we generate a promo code in the Dashboard, we just specify that the code only applies to specific products?

#

maybe that's what you just said

#

but I want to verify

#

this has been very helpful and I really appreciate you taking the time to help out here

agile matrix
#

Yes that sounds like that would achieve the desired behavior

formal coral
#

Excellent, are there any price requirements for Stripe Products?

#

I know you can't create a checkout session with a total cost of < $0.50

agile matrix
#

Ah, you do need to create a Price object related to the Product if you want to use it in Checkout. You can specify amounts smaller than $0.50 but the total needs to be above that threshold

formal coral
#

do you have a doc/guide about creating Products?

agile matrix
formal coral
#

Perfect.

#

and I assume there's no issues with updating a price object?

agile matrix
#

Depends what you mean by "updating"

formal coral
#

as in let's say the seller decides to make their product cost $10 instead of $15

agile matrix
#

That's a different Price object

formal coral
#

we can just update the price's unit amount, right?

agile matrix
formal coral
#

I see -- but then we can update the product with the new price object?

#

and can we delete the old price object?

agile matrix
#

Yes!

#

Well you cannot "delete" it (because that breaks referentiality with existing invoice records) but you can mark a price as not "active", aka active=false

formal coral
#

I see. Got it.

#

I think that's everything!

#

thank you so much

agile matrix
#

Great 🎉 happy to help 🙂

formal coral
#

I have one more question completely tangential to everything above

#

should I create a new question?

#

it's about pay-what-you-want charges

agile matrix
#

You can stay here.

That feature is availale in Checkout but I thin that's the limit of it's scope

formal coral
agile matrix
#

Jinx

formal coral
#

hahaha yep

#

but anyway, my question for that was about fees

#

if a checkout session has a minimum total price of $0.50, then how does that work?

And further, how do application fees work in this case? (I have Stripe configured to always apply 15% fees -- so I don't actually have to specify it when I create my price objects).

agile matrix
#

Honestly, when you get to these types of scenarios I find the fastest way to figure out how it works is to build it in Test mode and run through the Checkout process end-to-end

#

That's what I would do

formal coral
#

fair enough and probably accurate.

#

I'll do that

#

thanks

agile matrix
#

👍