|
From experience, associating an account directly to their current plan in this was adds some complexity in being able to have a history of plan changes (downgrades/upgrades etc). You might be accommodating for this in other ways, but a typical setup I've seen is to add a "subscriptions" table between account and plan. The account has many subscriptions, only one of which can be the current. The subscription is linked to a plan. When a customer upgrades, the current subscription ends, and is replaced by a new one. Tracking start and end dates helps with churn and upgrade/downgrade metrics reports, such as time on premium before downgrade etc. I've also been stung before by checking for a specific plan, as opposed to checking for the abilities or attributes of the current plan. In your example you're checking if the plan name is "trial" to determine if they should have trial limitations put upon them. This becomes tricky if you need to introduce a new trial option, named differently in the future, that needs to co-exist with your current single trial plan set up. I'd prefer to be checking "is the current plan a trial" or ideally link them to a real plan, but check if it is "in trial" (via dates, boolean etc). I've seen (but not done myself) products that let you move up and down between plans during trial so you can really assess the impact of not having feature available on higher plans. Doing this is impossible with a single plan called "trial". Subscription billing, dunning, pro-rated upgrade, taxes, discounts etc is a ridiculously complex set of functionality. |
Also ProfitWell plugs in to Stripe and does a pretty good job with analytics for that for free too.
Of course if you're using multiple payment providers you'll want to roll your own abstraction as the above comment describes.