☒ Great content easy to follow. What is the process of creating multiple plans and how to to create different checkout buttons for each plan? 
I see you have something like  on your website

subscription/new?annual=true

I know you are passing in a param to the checkout button or something like that 

How did you achieve that?
How to know what plan each customer is subscribed to in your application
Thanks

 ☒ in the subscriptions_controller.rb you can create a method to look up the plan.  Something like

def selected_plan
  plan = Plan.find(params[:plan])
  plan.plan_code
end

And plan_code would be pro, annual, or whatever else that matches the plan ID within Stripe.

Then in the controller action, you would reference this selected_plan method in place of where 'pro' is in the episode.

Since Stripe has the list of plans, you need to have some awareness of what these plan ids are. Typically they will be fairly static within your application. So, you could set a global variable with an array of the plans. Something like

PLAN = [
  { slug: 'pro', name: 'Pro', price: 1500 },
  { slug: 'student', name: 'Student', price: 900 },
]

And wherever you need to loop over your available plans, then you can reference this global variable. This does limit you to having to deploy and make code changes for any new plans, but that could be a non-issue.

 ☒ 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.

 ☒ I finally made it work. I created a new attribute in the user table called plan_price and update it when the customer is created with the amount_total from the session object. So the price will determine your subscription plan. I don't know if there are any security concerns with this approach. I am just a Newbie  with ruby on rails 

Has anyone had any luck when you want to update a subscription but you get "subscription_payment_intent_requires_action" as an exception because it wants you to authenticate again?