#appocc - Subscription Groups

1 messages · Page 1 of 1 (latest)

orchid mica
#

So you are trying to group actual users into groups which are each Customers with subscriptions?

jolly pewter
#

yeah.. it is exacly as slack for example

#

they payment is performed in the group level...

#

the model is price per user

so.. if they add an user, it updates group's subscription addin one more to subscription amount...

the opposite happens when removing

#

Im trying to think in the best stripe way of doing it

orchid mica
jolly pewter
#

I thought in creating 3 products. Free, team and enterprise (these types would be set in metadata)

free plan has price 0

pro plan has 2 prices, yearly and monthly... and they're charged per user

enterprise is different and most likely will be managed from stripe platform and not necessarily be per-seat

#

so it is kinda hybrid...

orchid mica
#

Okay so yeah that would be some separate pricing models but your application could select which one is appropriate based on your criteria.

jolly pewter
#

ok, but regarding ther update

#

is it ok to have so many subscription updates?

#

for example...lets say that somebody creates a group and upgrades is to pro... it has now one member...

not he invites 5 more... so the subscription would be updated 5 times...

then he removes one user because it was added wrong... the system updates subscription once more...

this sounds reasonable??

#

will proration_bahavior take care of this itself?

#

it is not irony.. Im actually asking.. sorry for the lack of english skill lol

orchid mica
#

In this case, I think, you would be adjusting the Usage records

jolly pewter
#

usage records?

orchid mica
#

Sorry, I was thinking of a different subscription approach.

#

The subscription should not have any problems with the number of updates.

jolly pewter
#

it is price x number of seats... simple as that... I understand that stripe's pro rations will deal with all the math so the charge happens in the right amount...

#

is that a right assumption?

#

no matter if I update them hundreds of times per group?

orchid mica
#

Over what period of time?

jolly pewter
#

monthly I suppose...

orchid mica
#

And if you mean per Customer, let's try and use that term

jolly pewter
#

we have groups with hundreds of people... I guess the saas model would be less... but at the beginning... an group admin would invite several people

orchid mica
#

As far a Stripe is concerned, you. have one Customer who is purchasing a number of licenses.

#

Well, in this case I would configure your app to try and consolidate the changes a user makes but it should be fine if they are increasing/decreasing their license amounts regularly.

#

So let's say you have a group admin and they are making some changes:

  1. Remove one user
  2. Add three users
  3. Upgrade plan

In this scenario (as long as it was all occurring within one session in your app), I would aggregate those changes and then only make the change to Stripe once they "Confirm Changes" or something like that. Make sense?

jolly pewter
#

it makes sensde but it would make the managing experience way more paynful... I was actually looking for something like slack

#

do tyou think it is a problem doing it right away?

#

have you seen this approach causing issues before?

#

because there is nothing to confirm... a customer subscribed to pro plan.. the price is price per seat... if you have 10 seats, 10 x the price... if you have 5, then 5x the price...

#

I dont see the point of summarizing it

#

it will just create friction, do you know what I mean?

orchid mica
#

I get what you mean. I haven't run into this scenario though. Fortunately Stripe's test mode allows you to test this type of integration pretty thoroughly.

#

I would recommend you write the skeleton of this integration and test out a very high volume of changes to see the behavior.

jolly pewter
#

Im not worried about the heaviness, but with the output in the invoice

#

do you feel that it is gonna get ugly?

#

all those changes?

fallen night
#

@jolly pewter Sorry we didn't see your follow-up! Do you still have questions? I'd be happy to help if you do

jolly pewter
#

Because if I perform all these changes and the invoice still looks ok, I'm fine with it

fallen night
#

And by changes you're referring to changes to the subscription that are adding/removing seats or upgrading/downgrading to a different pricing plan right?

#

The "heaviness" of the Invoice will depend on your proration behavior - if you're generating prorations for every single one of these changes, you have the potential of accumulating a lot of different invoice items.