#meek

1 messages · Page 1 of 1 (latest)

rocky trailBOT
burnt nebula
#

Sorry I couldn't respond to your previous message because it was locked. But i am still unsure on how to approach this

plucky karma
#

Hi, no worry

#

You seem to have 3 layers, which could be hard to model in 1 price. Maybe you want multiple price

#

ie. Whenever a team member join, you create a Price with flat fee = $10

#

Then in that Price, setup multiple tiers for each site, each tier has $20.

#

And then on 1 tier, for each client joining, charge by quantity of the clients * $10

burnt nebula
#

Hmmm i am having a hard time understanding how this will work

#

So a user signs up for my site, then creates a website...

#

It tells them they need to pay...so would i create a stripe checkout session with subscription and a line item of the $20 price?

plucky karma
#

Think of price modelling first

#

How to use Price to model your business. After you are done, it's easy to just use the price Id to create Checkout Session

burnt nebula
#

I guess my question is I have gone through the link you have sent me but i still don't know the best pricing model to choose for my use case...

#

I have a few projects on stripe and they all use the flat rate model but for the use case mentioned above, which model best suits it

plucky karma
#

ie. Whenever a team member join, you create a Price with flat fee = $10
Then in that Price, setup multiple tiers for each site, each tier has $20.
And then on 1 tier, for each client joining, charge by quantity of the clients * $10
How about this

burnt nebula
#

Yeah i don't understand how your option works. I might need you to dumb it down for me some more. Sorry

So lets say for a business like webflow.com or wix.com

  1. User signs up to wix/webflow
  2. The create a site (ex. cookies.com) that costs $20. (I dont know what you mean by "Then in that Price, setup multiple tiers for each site, each tier has $20.")
  3. They invite their coworker on the webflow/wix which is $10 per seat (I dont understand what you mean by "Whenever a team member join, you create a Price with flat fee = $10")
  4. They create a client for cookies.com to use the website which is also $10 per seat under cookies.com (I don't understand what you mean by "And then on 1 tier, for each client joining, charge by quantity of the clients * $10")
rocky trailBOT
burnt nebula
#

bump

plucky karma
#

Your pricing model is team member contains site, then site contains clients

#

so to build layers, you would want to have team members > sites > clients

burnt nebula
#

Yes i am following along so far...

plucky karma
#

So for each team member you create a Price with multiple tiers, each tiers representing a sites

#

And then in each tiers, you have quantity, representing the numbers of clients per tier (site)

#

Refer the Pricing model for creating a Price with multiple Tiers

#

That's some idea I have, but it's ultimately up to you to design your pricing model xD Maybe you can find a better solution using the Stripe API Price structure

burnt nebula
#
  1. What do you mean "create a Price with multiple tiers for each team member"? Like dynamically create a price with the api?
#

Could @native flame possibly chime in here please? I really appreciate your help @plucky karma but I am just not understanding the terms you are using

native flame
#

Hello, what is the best approach for a per-site model like webflow where users pay per site? Should there be just 1 checkout and i just update the quantity of the line items each time they make a new site? Or should i be creating new checkout sessions for each site?

The con to the ladder is that the customer will receive 3 different bills for 3 different sites
Actually here is show i want to set this up. I have 3 different prices

Per site -> $20: Whenever a new site is created, user pays $20
Per team member -> $10. Whenever you invite a team member to the main app, user pays $10 for each team member
Per client -> $10. Whenever a client is invited to the site the user created, user pays $10 for each client.

How do you want the invoice to look like? Do you expect each site to have it's own line item e.g. site A : 1, site A team member : 4, site A client : 5 , site B : 1 ...etc ? or you would expect it to look like sites : 3, team-member : 4, client : 5

burnt nebula
#

I am open to both options, but i think the first option is clearer on the invoice

native flame
#

the way i would go about it is probably different from orakaro. I would create a product and price for the site, team member and client.

image.png
#

if you create one Product for each site though, the number of Products you have is likely going to become unmanagable when you have a lot of users / sites

burnt nebula
native flame
#

no, as long as they are all the same billing interval e.g. all of them are charged monthly, you can combine them into a single Subscription

#

the second way i.e. sites : 3, team-member : 4, client : 5 (and not separate them by site A, site B, etc) will be easier to manage

#

you can save the details of each site in the metadata of the Subscription, or in your own DB

#

then ask the customer to view the specific details (breakdown) on your site maybe

burnt nebula
burnt nebula
native flame
#

3 products with 3 different prices then update the quantity

burnt nebula
#

This is what i had previously

Screen_Shot_2023-08-24_at_4.15.20_PM.png
native flame
#

personally i would do 1 product for site, 1 product for team members, and 1 product for team member

burnt nebula
#

Okay so then it brings me to my 3 scenarios

  1. User signs up and creates a site. I use await stripe.checkout.sessions.create to create the initial subsription. When he creates a second site, I will just update the quantity on the line item ?
  2. User invites a team member. Would I have to create a new stripe checkout session since that is a different product and site?
  3. Same question when a client is invited
native flame
#
  1. User signs up and creates a site. I use await stripe.checkout.sessions.create to create the initial subsription.

this bit is alright.

Q2, 3 are really the same and is about how to update the Subscription and collect payment.

Maybe you might want to adjust your flow slightly to allow the user to update their own subscription quantities using the customer portal? https://stripe.com/docs/customer-management

Customer management

Manage customer relationships with your business.

#

that'll be less work on your end

burnt nebula
native flame
#

just a heads up though, you should ensure that the user has paid the previous invoice before allowing them to update the quantity of the current subscription.

#

Stripe doesn't check if the previous invoice is paid before prorating, so you need to make sure you check for that

burnt nebula
#

Thats super helpful thanks for that heads up

native flame
burnt nebula
#

So hypethetically, if the user has 2 sites, 3 team members, and 2 clients, they will still be reciving 1 bill?

native flame
#

yep

#

test it out and poke around to make sure everything is what you expect

burnt nebula
#

Amazing!

#

So just to clarify one last thing, a check out (await stripe.checkout.sessions.create) will only be called the first time when a user creates a site, client, and user. So a total of 3 times per user. All subsequent additions (Ex. creating a second site or adding a new user) will just be updating the quantity

native flame
#

it would really just be once wouldn't it? the first time a user creates a site, i would expect them to have a site, client and team member?

burnt nebula
#

Hmm, when a user signs up, and lets say they have 0 sites, and want to invite a teammate to the app, then wouldn't they need to to call checkout?

#

And when a user signs up, and they are a one man company, so they don't need any teammates, and they create a site, wouldn't they need to call stripe checkout?

native flame
#

🤔 i guess i didn't fully understand how your business model works. I thought they would likely always have at least 1 site upon signing up, and always have at least one client and team member

#

i think the way to implement this is going to change then. Gimme a while to think about it

burnt nebula
#

Oh no im so sorry for taking up so much of your time! If there is someway i can buy you a coffee or something let me know

native flame
#

no worries, this is what we're here for 😁

#

A Checkout Session is always going to be for creating a new Subscription only. You can't update a Subscription with it.

burnt nebula
#

Also let me just give you a quick summary of the product

native flame
#

A customer portal also isn't going to allow you to add new products to the subscription. Only to update the quanties, or change plans

burnt nebula
#

Here is a quick description of the requirements of the business
A user signs up to create a portals/sites for a client to be able to log in and manage their email campaigns. The first portal and client is free. All subsequent portals/site will be $20. And all additional client accounts created under a portal with be $10.

The user themselves can invite their team members to collaborate. The team member invited is $10. Aka. $10/seat.

burnt nebula
burnt nebula
#

So based on those requirements, would you say i should have 3 different products still with the prices?

native flame
#

oh, if the first portal and client is free, then you need to use graduated pricing for the site and the client. Probably like this

image.png
#

hmmm, also cause we're using multiple products, you can't use the customer portal to update the quantity.

#

so yeah, looks like any updates to the Subscription (except for payment methods) will have to be done via the API instead and not via the customer portal

burnt nebula
#

So far correct?...

native flame
#

yep, looks right to me!

#

this is how it looks like with graduated pricing

image.png
burnt nebula
#

Actually sorry #1 should also be graduated pricing since the first portal/website is free correct?

native flame
#

🤦‍♂️ ah yes

#

you already understand the gist of it so....

burnt nebula
#

And if I may continue...
4. User signs up to our website. The first thing they want to do is invite a team member. Will they be calling stripe.checkout?
5. Another user signs up to use our website. The first thing they do is create a site. Will they be calling stripe.checkout?

#

I think this is where i get a bit blurry

native flame
#

have they already created a subscription?

burnt nebula
#

The brand new user, no.

#

They just signed up

native flame
#

your criteria for this would be "does the user already have a subscription? If not, call Stripe.checkout to create one for them"

burnt nebula
#

This is sounding more and more like my original code lol

native flame
#

why did you change it out of curiosity?

burnt nebula
native flame
#

looks about right to me, except you're not using pending updates i believe

burnt nebula
#

So i would make the stripe.subscriptions.update line a pending update? Like this?

native flame
#

yep

#

pending updates is to make sure the update doesn't apply if payment fails

burnt nebula
#

Absolutely fantastic. I am seeing the light at the end of this long tunnel thanks to you! XD

native flame
#

honestly, i feel that there's still a long way to go. Subscriptions is really complicated

#

there's still things like how to handle payment failures, amongst various other use cases which you probably have

burnt nebula
#

After the pending updates part, thats it? will they be directed somewhere to make the payment?

native flame
#

it'll try to charge automatically. I'm assuming you're using charge automatically for your subscriptions

#

if it fails, then you need to attempt to collect a new payment method from your customer to pay

burnt nebula
#

Got it, so once thats successful, I can just let my user know "Hey we charged your card $20 for this new site and now its available".

#

Lol i guess i should actually also let them know before i charge them XD

#

So i will basically do the same things for when they want to add a client and a user. Check if they have an existing subscription. If not create a stripe checkout

native flame
#

yep

burnt nebula
#

And somehow, by stripe magic, they will receive one bill at the end of the month

native flame
#

btw, you should add a comment in your code, to verify if the previous invoice of the subscription has been paid

#

like a todo

burnt nebula
#

Or did you mean I should i verify after the update?

native flame
#

verify before the update

#

if it's not paid, you should ask the user to pay first

#

you can test this out

#

try to update a subscription and the previous invoice is not yet paid

#

see the amount that the user is charged for the new invoice

#

When Stripe generates prorations for a Subscription update we don't check the status of the Subscription’s latest Invoice. Unless prorations have been disabled for that particular update, Stripe will calculate prorations under the assumption that the previous Invoice will eventually be paid (even if the latest Invoice has been voided). Essentially, the user may get free credit if you don't verify that the previous invoice has been paid

burnt nebula
#

That makes sense. Thanks for that.

#

Also since the first site is free, would they have an invoice?

native flame
#

but really though, if the user hasn't paid their previously invoice, i wouldn't want them to be able to upgrade since they still owe me money 😆

burnt nebula
#

Wouldnt that check fail?

native flame
#

which check?

burnt nebula
#

"Verify first if the previous invoice of the subscription has been paid."

native flame
#

sorry, i'm a bit confused, maybe you can explain a bit more?

burnt nebula
#
  1. User creates site #1 and is free. Stripe.checkout runs since they dont have an active subscription
  2. User creates a second site, since they have an active subscription, it goes to the other part of the code.
  3. The first thing it will do is to "Verify first if the previous invoice of the subscription has been paid." as the comment you suggested. Since the first site was free, there is no invoice, therefore wouldnt this fail?
native flame
#

there would still be an invoice i believe, although it would be for $0

#

maybe test that out to verify if i'm correct

burnt nebula
#

Got it

#

I need to go now but your help has been invaluable! Thank you soo soo much!

native flame
#

feel free to reach out again if you have more questions!