☒ You want to be careful with your plan_type. You are accepting the user input. They could type anything in the plan parameter and cause problems in your app. The PLAN array is just a list of the plans that you have created over in Stripe. If the plan_type doesn't find a matching plan, you should catch that and redirect the user.

In this episode, we update the user's attribute subscription_id. So, you could check this subscription_id if the user is subscribed.

def subscribed?
  subscription_id.present?
end

You would of course need to handle the subscription cancelled in a similar fashion via the webhooks and clear the subscription_id.

I think that there is a follow up episode warranted to explore handling webhooks more. For example, on Drifting Ruby, we handle a few different events. 

The last two are the trickiest. If a user payment fails, what should happen? This basically means that they have a subscription, but are not current with their payments. On Drifting Ruby, they still have their subscription where they can update their credit card information, but have been locked out of viewing the Pro Videos.

When a user cancels their subscription, no refund is given, but the subscription_id is also not removed. Instead, the expires_at attribute is updated to the end of their billing cycle which then will remove their subscription and access to the Pro videos.