Feedback: How are you using Laraplans?
gerardojbaez opened this issue · 18 comments
Let use this thread for feedback and suggestions!
Feel free to share how you are using Laraplans package, what features you liked more or what you think is missing!
Please note: Keep this thread for feedback only. Please open a New Issue for bugs reports, feature requests, or anything not related to this thread.
{ "message": "Unresolvable dependency resolving [Parameter #0 [ $user ]] in class Gerardojbaez\Laraplans\SubscriptionBuilder", "exception": "Illuminate\
error in laravel 5.5
@pay2all, this thread is for feedback only. Please open a new issue (if you haven't opened one already) to report the issue.
Pull Requests are welcome if you want to fix/add functionalities.
Thanks!
@gerardojbaez could you please create an updating guide for a new version (2.1.0)? Because I'm facing with breaking changes and now I should explore whole project to determine which of the files you have updated (for migrations, and for using in my project).
@siarheipashkevich, there is no breaking change in version 2.1.0 besides adding the canceled_immediately column to plan_subscriptions table; this change is not automatically applied to your app migrations, you have to add it manually. Please refer to the Changelogs file for a list of changes.
If you want to continue the discussion of this issue, please create a new Issue; this thread is for feedback only.
This package works great. But I suggest this package to have more power in terms of trial and not trial subscriptions.
Also, please add way to terminate the trial (just in case the user wants to end the trial and subscribe to a new plan).
@josteph, Thank you for the feedback!
What do you mean exactly with "more power in terms of trial and not trial subscriptions"? Any example or use case?
The trial termination is a must-have; I will keep this in mind for the next release, thanks!
@gerardojbaez Sorry, I wasn't being clear before.
I misunderstood the concept of subscription. If the user is on trial and wants to subscribe on a new plan with payment, it's better to end the trial subscription and create new subscription with skipTrial method.
But anyway, thank you for your hard work, really appreciate it!
@josteph, That's another good solution!
You're welcome! I'm glad that Laraplans helps you and your project. :)
Is this package maintained?
Hello,
A few things that IMHO would need to be added or refined:
1- A way to have a subscription run until it is manually canceled, so no interval_count.
2- Less important but maybe a way to have intervals as multiple of the interval. For instance instead of monthly be able to set it to every 3 months.
3- The ability to reset features for each period is a pretty good one, you should add it to your docs (the examples don't show that)
4- The possibility to get future information about a subscription (next period start for instance)
5- Important: Renewing a subscription should not set the new start date to the time of renewal, it should be set to the end of the current subscription
6- This one might be difficult and I know there are ways around it but it would be interesting to allow plans to have more than one payment option. For instance, if I want the same plan to have different prices depending on whether payment is made monthly or yearly instead of having to create 2 different plans for the same result.
7- It is not always desirable when a plan is modified that all subscriptions automatically start using the new plan parameters. Say I decided to increase the price but it should only apply to new subscribers or upon renewal but not to current subscribers with active subscriptions, right now I can't and I have to create a new plan. This would require saving the plan's parameters (price, interval, features...) with the subscription along with the plan ID, not just the plan ID, and update those parameters on renewal or new subscription.
I have to say your Laraplans is awesomely well built and thought of. My comments above are based on my experience with membership websites and what can come really handy.
Thank you.
@Yahav, of course! I'm working on a medium size project at this moment, this is the main reason why I haven't been active lately.
@mnakalay, Thanks for your suggestions and your time! I will take note! For the point 2, you mean a configurable interval count at the moment of creating the subscription? Laraplans allow frequencies like the one in your example (i.e., every 3 months); you just have to set the interval and interval_count to the appropriate values (e.g., interval=month and interval_count=3 will result in an "every 3 months" billing frequency).
@gerardojbaez Thank you for your answer. I am a bit confused though. At first, when I looked at the doc I wasn't sure what interval_count really did. I didn't know if interval=month and interval_count=3 meant one cycle is 3 months so do what you have to do once every 3 months indefinitely. Or if it meant the cycle is 1 month long so do whatever you have to do every month and stop after 3 months.
After going through your code my understanding is the latter is correct: it's a monthly cycle with an end date in 3 months. That's how you calculate the ends_at value when creating a subscription.
Am I getting that wrong? If I am wrong please explain how to do it because I'm lost.
If on the other hand, I am correct then maybe giving subscriptions their own interval_count could work. the Plan's interval_count would indicate the duration of the cycle and the subscription interval_count would indicate how many cycles to run.
Looking forward to reading your thoughts on this.
Hi @mnakalay, sorry for the delay. Both ways you have mentioned are correct depending on your implementation. For recurring plans, the interval and interval_count attributes are for each billing cycle duration; for one-time plans, the interval and interval_countattributes can be used to specify the plan/subscription duration. See the following examples:
Examples of recurring plans:
| Plan description | Price | Interval | Interval count |
|---|---|---|---|
| $5.00 monthly | $5.00 | month |
1 |
| $5.00 every 3 month | $5.00 | month |
3 |
These plans are renewed each time the plan reaches the end of each period.
There's no way at this moment to specify the total cycles (e.g., the total payments) of a subscription.
Examples of one-time plans:
| Plan description | Price | Interval | Interval count |
|---|---|---|---|
| $5.00 1 month duration | $5.00 | month |
1 |
| $5.00 3 months duration | $5.00 | month |
3 |
In this case, the user pays only once and the plan is active for the duration you specify.
If you want to support both types of plans (i.e., recurring and one-time), you will have to add a new column/attribute to the Plan model that differentiates each (you may call the attribute "billing type" or "plan type") and use the interval and interval_count accordingly.
Hope this helps. I will try to update the documentation so is easier to understand.
Your implementation reminds me of the MYSQL DATE_ADD/DATE_SUB handling of changes.
DATE_ADD(now(), INTERVAL 1 MONTH);
Hi @Acen, is that a good thing or a bad thing?
@gerardojbaez thank you for answering I know you're pretty busy.
I must be a bit daft because I don't get it. Both examples you give use the exact same settings but you say they behave differently depending on my implementation.
How?
For the recurring example, you say "These plans are renewed each time the plan reaches the end of each period." Is this default behavior or should I deal with the renewing myself? Or is there a setting to indicate that the plan is recurring and should keep going on?
Or is it in the other situation, non-recurring plan, that I have to tell it to stop after one cycle? Is that default behavior?
I'm sorry if I'm not making sense, I just can't figure out how much is taken care of by the system and how much I have to deal with myself.
Updating the documentation would be lovely, thank you for offering to do so.
Hi @mnakalay, thanks for the understanding. I've been full of work.
Don't worry, feel free to ask as much as you'd like.
Laraplans doesn't provide autorenewal, that's something you handle base on your requirements and payments flow. The interval and interval_count are used by Laraplans to set each cycle duration (the start date and end date of a subscription); Laraplans doesn't take care of anything else; this is why I said that the use of interval and interval_count attributes depends on your implementation; you are in control of the subscription renewal process (if there's any). For example, if a one-time plan has a 1-month interval, the subscription will last 1 month; if in another hand the plan has interval=month and interval_count=3 (1 cycle of 3 months duration in the one-time plan context), the subscription will last for 3 months. One-time plans work almost the same as recurring plans, with the difference of one-time plans not having renewable periods.
Following the examples I've provided, for the recurring plans, you will call $subscription->renew() (more in the docs) each time a payment is received. For one-time plans, you don't need to call this method because there's no renewal, just a fixed period.
So, answering your exact questions:
Q: should I deal with the renewing myself?
A: Yes, the renewal process is handled by you based on your requirements.
Q: non-recurring plan, that I have to tell it to stop after one cycle? Is that default behavior?
A: You don't need to tell it to stop after one cycle; the cycle is ended once the ends_at date is reached. Once a subscription is created and active, it will be active until the ends_at date is reached. When the subscription is ended (you don't renew it manually), the subscription status will change to ended and the user won't be able to use any of the plan features.
Please keep in mind that a "cycle" in Laraplans context is simply one starts_at and ends_at period (those attributes are available in the PlanSubscription model); just the way Stripe works.
@gerardojbaez thank you for your explanation I get it now.
I'm seeing potential problems, especially with Stripe since you mention them.
For instance, in case of failed payment for subscriptions, Stripe can keep trying a number of times for a number of days. But with Laraplans, once a subscription is ended, it can't be renewed so there's probably going to be a conflict there.
Also, let's say a user subscribes at time t and pays through Stripe for a subscription plan. The plan will be subscribed in Stripe at the same time t. Relying on payments in Stripe to renew the subscription before it expires is probably going to be difficult.
I think the usual way of doing it would be to rely on Stripe events to decide whether to cancel the subscription or not. But with Laraplans, cancellation happens automatically and it's up t us to act before it's canceled which is not always possible.
if on the other I decide to not use Stripe's subscription plans and use fixed amounts every cycle then I can decide to check all subscriptions that will end tomorrow and charge them and renew so I don't have that deadline problem. But on the other hand, if I decide to change the price of my plan, all subscribers will automatically start paying the new price which is not necessarily desirable.
So either I use Stripe ability to automatically collect payments and I'm probably not going to be able to renew Laraplans subscriptions on time, or I use Stripe to make payments myself one at a time and I lose flexibility (and I am not sure Stripe is not going to frown at this kind of monthly payment without asking for renewed agreement from the subscriber)
Lastly, something that could be helpful is the ability to have a feature that lasts for the duration of the subscription. Right now a feature's availability is reset every cycle. But if I could have a feature that is not reset unless I reset it myself, it could be helpful to keep track of how many cycles I ran. Say I want a monthly cycle that runs 6 months, I could say feature "number of cycles" = 6, decrease it after each renewal and when it's depleted I know my subscription should end.
I don't know if I'm making any sense?