I'm working on an application that has multiple subscriptions per user. I've been using Cashier 5 until now and I'm working right now to switch it to Cashier 6. I have it set up so that the Product is actually the customer in Cashier 5 because of the multiple subscription issue. Now in Cashier 6 I want to change the User to be the customer and the Product to be the Stripe Customer. My initial thought was to extend the Cashier subscription model but that would involve extending a lot of Cashier files and changing the implementation (e.g. SubscriptionBuilder). Another approach is to create a separate Subscription model and keep the Product model a separate thing entirely.
Does anyone have experience with either method? Are there things to know about them or problems that came up during implementation?
For your case in point I have set up a separate table for cashier subscriptions. This holds the user id and specific subscription data. So a user has many subscriptions.
You could set permissions or role to a user if they have a certain plan. Run a cron nightly to update as subscriptions expire, fail payment or are canceled.
Another possibility is to use a plan as permission for access. Set up a middleware that accepts a plan slug or id and perform a check for access (same as you normally would for roles and/or permissions).
@jekinney Regarding your current setup: that's also an option but I would rather keep the model name to mean something more comprehensive rather than 'Subscription', which kinda says nothing imho.
Also I don't think permissions are an issue here. The decision I'm pondering is simply whether to extend the Cashier::Subscription model or link it with another object via foreign key. That has nothing to do with plans or whatever (unless I completely misunderstand your remark)
