#fonikoagouriog_best-practices

1 messages Ā· Page 1 of 1 (latest)

hushed bluffBOT
#

šŸ‘‹ Welcome to your new thread!

ā²ļø We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

ā±ļø We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1257679349675462706

šŸ“ Have more to share? Add details, code, screenshots, videos, etc. below.

velvet wasp
#

hi there!

drowsy mango
#

so this is my guide to upgrading and downgrading - i thought so, but i wanted to double check. thanks!

#

What about the less products and more prices, or separate product for each price choice? is there anything i can read or can you assist me on that?

velvet wasp
#

What about the less products and more prices, or separate product for each price choice?

#

I'm not sure I understand the question

#

can you clarify what you are trying to do and what's the issue?

drowsy mango
#

we currently have 2 offerings in our platform: a Standard subscription and a Full subscription. We offer these products in 1 month plans and in 6 month plans each with different prices of course. We also differentiate the prices based on the type of the customer (Company or Public Agency)

hushed bluffBOT
drowsy mango
#

so essentially, we have 2 offerings * 2 plans * 2 customer types so in total 8 different prices

#

what i am trying to understand is: Do i create 2 products (1 for the standard sub and 1 for the full sub) and list all prices below these products?

#

or do i create 8 different products with 1 price each?

#

what is the difference between these 2 implementations?

ebon forge
#

hey there, just stepping in for my teammate who needs to step away shortly

drowsy mango
#

all prices are recurring

#

hello!

ebon forge
#

Reading through what you've shared so far, give me a few minutes šŸ™‚

drowsy mango
#

all you need! thanks for the swift replies

#

amazing support

ebon forge
#

Regarding the products or price dilemma, I have not understood exactly what the difference is between them. Is using less products and more price differentiations in them for having a more organized structure purposes only, or does it have a functional difference?
Also, i would like to know if its best for me to use a different product for each price or have less products with different prices. For example, we currently have 2 products: a Standard subscription and a Full subscription.
Let's first address this modelling question

#

Products are the thing you are selling and should be shared only for the exact same product/service.

#

In your example, if the "Full" customers have access to more/different features than the "Standard" customers, these are not the same product/service and should not be the same Stripe Product.

drowsy mango
#

yup, understood. so i have 2 products

#

standard sub + full sub

ebon forge
#

Prices are meant to represent different ways to charge for that single product/service. For example, your Standard plan might be prices at $10/mo or $100/year, or Ā£8/mo and Ā£90/year, but they all get access to the same thing.

#

So those would all be individual Prices that point to the same Product

#

Different currency, amount, or recurring cadence

drowsy mango
#

yeah this was my understanding too, but why should i not create a different product for each price? do i gain/lose anything functionality-wise?

#

do i lose for example, functionality in subscriptions? because a recurring product creates a subscription automatically

ebon forge
#

You would lose the ability to use features like upselling annual from monthly in checkout, or using the Pricing Table optimally, and you'll have seeming duplicates in your product catalog, but no there is no issue with additional products

drowsy mango
#

understood. thank you very much!!!

#

i literally moved from another payment platform to Stripe some months ago because everyone kept saying about the support

#

first time experiencing it first hand lol

#

unbelievable

#

thank you

ebon forge
#

Quite welcome!

#

Glad that was a helpful explanation šŸ™‚

#

OK, so now we've got the modelling piece set, you were asking about upgrade/downgrade too

#

Aside: I'll also mention that the Product name is what is shown on invoice lines for subscriptions, which is a reason to keep those specific to the service/feature being sold.

#

UPGRADING/DOWNGRADING a subscription by adding/subtracting an amount of money based on the remaining time of the subscription automatically.
Can you say more about the customer-facing experience here?

#

I'm not sure I understand what you mean by "adding/subtracting an amount of money"

#

I think you might be referring to invoicing for the difference in price for an upgrade, or crediting for a downgrade, but want to make sure i understand the goal before explaining more

#

Some possible flows are:

  • Prorate the change (up or down) and apply to next invoice
  • Prorate the change and invoice immediately for the difference (forced if changing recurring period)
  • Disable prorations for downgrades, ie do not credit time back for paid "premium" service
drowsy mango
#

the cases i was asking about i think are exactly the last 3 that you mentioned

#

specifically, our case is that: you have a company on the standard subscription plan for 6 months (pre-paid for 6 months recurring)

#

and then, on the 2nd month they decide they want the full subscription. this means that they want to upgrade their plan

ebon forge
#

Does that also use a 6mo cycle?

drowsy mango
#

so what i would like to happen is i would like to charge them the extra amount needed only for the upgrade for the remaining 4 months

#

I have in both 6 month cycle and in 1 month cycle

#

what should i use?

ebon forge
#

charge them the extra amount
Do you want them to be charged immediately for this?

drowsy mango
#

yup

#

for the amount needed for the upgrade to their plan only

#

so basically 4 months of full subscription

#

i think its this prorating thing but i just wanted to make sure basically

#

and when the new cycle starts, they will be automatically billed the Full sub's 6 months

ebon forge
#

You need to do both of these in a single update request to the subscription

drowsy mango
#

ok, understood

#

and the new price will be the full subscription 6 months or the 1 month? the 6 right?

ebon forge
#

That's up to you -- i was assuming you'd provide the matching interval price in the upgrade

#

Remember the Price controls the cadence

#

You can change the interval from 1 to 6mo if needed, thats fine but then the billing period will be reset and the invoice willbe forced even if you don't supply always_invoice

drowsy mango
#

so if i provide the 6 month pricing as the new price, they will be getting renewed to that new FULL sub after their current sub expires in 4 months that they have left lets say

#

and for the remaining 4 months they will pay the difference for the upgrade, correct?

ebon forge
#

Yes, if they are 2 months into a 6mo cycle on "standard" and you upgrade to "full" price also on 6mo cycle, the proration would be the price diff for 4 months of "full. Using always_invoice would charge that immediately.

drowsy mango
#

if the upgrade difference is 50$/month, they will be charged 200$ for the remaining 4 months and not a full 300$ price upgrade

ebon forge
drowsy mango
#

ok, great. understood

ebon forge
#

Well, let me clarify

drowsy mango
#

yup, that was what i was trying to do today, but wanted to double check if the article i found was correct first

#

because i did lots of test and at some point got burnt out

ebon forge
#

The way prorations work is you're credited for the unused time already paid, then charged for the remaining time at the new price

#

so say standard is $20/mo and your full is $70 and its a 6mo cycle

#

They paid 20*6 = 120 up front

#

Now we are 2mo in

#

If you upgrade to Full, then they get credited 4 months of standard (4x20=80) and get charged for 4 mo of Full (4x70=280), then the invoice is for 280 minus an 80 prorated credit = 200

#

The end result is what you say, but i want to make clear that it is not done by doing 4mo x (70 - 20), since that wont work for all pricing structures

drowsy mango
#

got it

ebon forge
#

(quantity might be different too, eg)

drowsy mango
#

ye i didnt think about the up front payment on the last 4 months

#

true

#

and a final question, does it matter WHEN during a month a user upgrades?

#

for example, will the charge be different if they pay on the 15th, which is half-way through the month already, rather than upgrading on the 1st of the month?

#

i suppose this calculation is automated anyway, but just asking for info

ebon forge
#

Yes, it matters, prorations are calculated to the current second by default

drowsy mango
#

perfect

#

i think i am more than covered

#

i seriously feel i cant thank you enough

#

1 hour and we solved the entire architecture of our payment plans hahaha

ebon forge
#

So eg you can invoice them for the upgrade as if it happens tomorrow, or at the end of the current month or whatever you need

drowsy mango
#

and the default is set to the exact time, right? so i can just leave it at default

ebon forge
ebon forge
drowsy mango
#

perfect, thanks!