Have you tried adding a new or replacement card to an existing customer? The Session in 'setup' mode could collect the card details however wonder if taking the payment from one customer and adding it to another would be allowed.
It is strange, I know that you can update a card, but it doesn't go through the 3D Secure 2 steps. I believe you would have to use their payment intents to do that, but that could have its own issues around just updating a card instead of creating a new payment. I'd imagine that they will be updating their APIs to fully support updating cards with checkouts.
I try to follow all the video, but I just trying to implement a simple one time charge, and I can't make it works can you pleas make a video on how to make it works with a single payment? this is the information from stripe that I'm following https://stripe.com/docs/payments/checkout/migration#api-products-after
☒ 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
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.
When the user subscription is successful
When a subscribed user is charged
When a subscribed user payment fails
When a subscribed user cancels
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
I see you have something like on your website
How to know what plan each customer is subscribed to in your application
Thanks
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.
In this episode, we update the user's attribute subscription_id. So, you could check this subscription_id if the user is subscribed.
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.