search

bpuig / laravel-subby

Laravel Plan and Subscriptions manager.
https://bpuig.github.io/laravel-subby
MIT License
102 stars 42 forks source link

Behaviour of the (second) `renew()` #67

Closed boryn closed 3 years ago

boryn commented 3 years ago

renew() sets the starts_at at now and ends_at at "30 days" from now. The same happens when I fire the renew() for the second time. And when a person pays twice we actually should prolong ` his subscription for another "30 days", shouldn't we?

bpuig commented 3 years ago

Because renewal clears usage data. If this is changed to add another period to the end of current period, you do not get double amount of features, since there is no record of the amount of features you can use. You'd get the same number of feature usage but only a new period + what was remaining of it.

This would add another layer of complexity of features in plan, features in subscription and features in period.

boryn commented 3 years ago

Hmmm... But actually we know the feature allowances in plan_subscription_features? And we could double the value values? Or I'm mistaken?

boryn commented 3 years ago

But this keeps the definition of the allowance per period and in the following month the user world have doubled quota :)

On the other hand it's quite an important issue, as renewals don't always happen exactly at the end of the active period.

And imagine if the user's monthly subscription ends at 20. day and at 10. the user thinks let's go with the yearly plan. We would cut 10 already paid days.

bpuig commented 3 years ago

Hmmm... But actually we know the feature allowances in plan_subscription_features? And we could double the value values? Or I'm mistaken?

If you double them there, they will be doubled forever. And if you renew again they would be quadrupled. And also you can't resync with the plan because maybe it has changed and does not have the same conditions as when the user signed.

bpuig commented 3 years ago

But this keeps the definition of the allowance per period and in the following month the user world have doubled quota :)

Yep 👍

And imagine if the user's monthly subscription ends at 20. day and at 10. the user thinks let's go with the yearly plan. We would cut 10 already paid days.

If the user goes with the yearly plan it would be another plan with another type of features. But if what you mean is same plan different prices month vs year, yes it's an issue, but since pricing is not in this package... it's out of it. Maybe v5 should be all about payments, periods and currencies.

boryn commented 3 years ago

Why would you create another plan for the yearly subscription? I'd rather go with the changePlan().

And IMHO payments will be always out of the scope for the project, as there will always be too many options and renewing subscriptions can be easily done with Laravel events, just when we have a working base here.

I don't know yet https://bpuig.github.io/laravel-subby-schedule/ but maybe this project is just the answer to our considerations? When someones changes to the yearly plan, we schedule the change just upon finish of the current monthly? Similarly with double renew of the monthly payment, it will be just prolonged one the active period finishes?

bpuig commented 3 years ago

Why would you create another plan for the yearly subscription? I'd rather go with the changePlan().

Because a plan only has one kind of period: monthly, yearly... This is some issue I know it's there but I haven't faced yet in my own projects; that you should be able to buy a plan for a full year with a discount, but subscription features should still be renewed monthly. Actually there is no way to pay in advance for more months.

don't know yet https://bpuig.github.io/laravel-subby-schedule/ but maybe this project is just the answer to our considerations? When someones changes to the yearly plan, we schedule the change just upon finish of the current monthly? Similarly with double renew of the monthly payment, it will be just prolonged one the active period finishes?

That package solves one part of your question. With that plan you can schedule a change at the end of the current period, but it's not solving the issue of paying a year with monthly feature renewal.

boryn commented 3 years ago

Wait... I've always thought that I can have a yearly plan with a feature set to '1' resettable_period and 'month' resettable_interval? The features usages seem to work properly as far as I looked into the code, mainly in recordFeatureUsage()

boryn commented 3 years ago

You probably meant invoice_interval at plan_subscriptions? But on the other hand we have $syncInvoicing so maybe we are covered?

bpuig commented 3 years ago

You are partially right. I found that you can record feature usage without issue and it gets renewed automatically if it hasExpired. Buuuuuut, if you check it beforehand with canUseFeature, you will be denied usage because it hasExpired.

This has to be redone so all usage functions are more "connected". I don't want to talk bad about the original package but... man, who uses that on production? Look at all we found. :confused:

boryn commented 3 years ago

Yes, the original package had a good idea, and maybe it was more stable at the beginning? Because now it's just unusable. I quickly disovered it when I got new slugs like main-1, main-2, main-3 all the time :)