We've moved discussions to Discord

How do I set the name in subscriptions?

Jamie Crone
I have 3 plans and all three of the plans come over as name: 'default', I have been looking through the doc for something and cant find anything. Anyhelp would be appreciated?

Also I can't use the current_account.subcribed?(plan: 'xxx') I have to use processor_plan: 'xxx' I want to be able to use name instead of processor_plan so I dont have to replace all these going into production

  Pay::Subscription Load (0.4ms)  SELECT "pay_subscriptions".* FROM "pay_subscriptions" WHERE "pay_subscriptions"."owner_id" = $1 AND "pay_subscriptions"."name" = $2 ORDER BY "pay_subscriptions"."id" DESC LIMIT $3  [["owner_id", 47], ["name", "default"], ["LIMIT", 1]]
=> #<Pay::Subscription:0x000055b628d30f20
 id: 5,
 owner_id: 47,
 name: "default",
 processor: "stripe",
 processor_id: "sub_JdVZaKUD",
 processor_plan: "price_1IsKAXsuS6uO",
 quantity: 1,
 trial_ends_at: nil,
 ends_at: nil,
 created_at: Tue, 08 Jun 2021 23:42:14 UTC +00:00,
 updated_at: Tue, 08 Jun 2021 23:58:09 UTC +00:00,
 status: "active",
 owner_type: "Account",
 prorate: true>
Jamie Crone
Ok got it, I just add name: @plan.name  to my subscritptions controller
current_account.subscribe(name: @plan.name, plan: processor_id, trial_period_days: @plan.trial_period_days)

Jamie Crone
Once I add this name, my billing page no longer functions correctly.

Since I will go back to using the Plan id do you know why (plan: "price_XXX") does not work I have to use processor_plan
ArgumentError: unknown keyword: :plan

[28] pry(main)>account.subscribed?(plan: "price_XXX")
ArgumentError: unknown keyword: :plan
from /home/jc/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0/gems/pay-2.1.3/lib/pay/billable.rb:83:in `subscribed?'
[29] pry(main)> account.subscribed?(processor_plan: "price_XXX")
  Pay::Subscription Load (0.8ms)  SELECT "pay_subscriptions".* FROM "pay_subscriptions" WHERE "pay_subscriptions"."owner_id" = $1 AND "pay_subscriptions"."name" = $2 ORDER BY "pay_subscriptions"."id" DESC LIMIT $3  [["owner_id", 44], ["name", "default"], ["LIMIT", 1]]
=> false

John Quarto-vonTivadar
these are just ideas + guesses which might help
I *think* you need to use processor_plan because that is the generic delegate name across all three of the billing systems (Stripe for example calls it a sub_ or a prod_ or  price_ etc depending on what it is, as opposed to whatever Braintree calls it. Then the Pay gem can use one word to delegate to whatever your billing provider service needs instead of writing conditional logic "if Stripe then this and if Braintree then that). Kinda like you might use 'postal_code' to stand for "zip code" in the US and "postal code" elsewhere else.

Also another *think*: I think the only thing that matter is the processor's code for it, and the name in your DB is just what you want to call it on your site (regardless of its name over in Stripe).   That should be easy to experiment with.  JSP also lets you set plans to not visible, so they can be in your DB and not be on your site's pricing page.
John Quarto-vonTivadar
Jamie Crone   back to your solution of what you added to `subscriptions_controller` but it didn't work:   did you also remember to add `name` to the list of permitted parameters ?  if it's not there, I'm not sure if you're allowed to pass it in:

`def subscription_params
    params.require(:account).permit(:card_token, :plan, :processor, :extra_billing_info)
  end`

the above is the out of the box `subscription_params` method.   You might have to add `:name` to the list

John Quarto-vonTivadar
I can confirm that although that will indeed set the name of plan (from your app's DB) into the account's subscription, it will cause some glitch with Stripe and the subscription won't actually take. Normally after a subscription is charged you can see it reflected as an active subscription as soon as Stripe's calls your app's webhook. In this case, the addition of that name field to `current_account.subscribe` upsets Stripe.

Maybe there's an argument that this shouldn't be persisted until Stripe returns to the webhook with a success event (and that Stripe has no need to know the name of the Plan only the processor_plan code.....true). But I'm not familiar enough with how to customize something that fires off when a success_event comes back via the webhook. 

I'm hoping Chris Oliver will know what to do for such a simple(?) thing.  IIRC, he mentioned it at some point that the 'default' name was out of the box behavior but that it was easy to change to the plan's actual name (or plan_id would be helpful too)

If there's a use case to be made for it, this is one I can think of: Chris recently had a GoRails video about Roles, (usually combined with an authorization scheme like Pundit).   If an Account had access to certain functionality of the site (or access to certain features or certain instances of a given model) based on the Account's subscription, then you can see how having the name or ID of the Plan in the PaySubscriptions table would be a way for an Account with a Bronze plan to have a different set of permissions than an Account with a Silver plan. 
Jamie Crone
John Quarto-vonTivadar  
I did a work around and would find the plan name using helpers it was something like this

  def vendor_subscribed?    
   (current_account.subscribed? && current_account.subscription.plan.name == "Vendor") ||      
   premium_subscribed?  
  end

John Quarto-vonTivadar
do note that some of this changed in the newest JSP + Pay v3. So be prepared for modification when/if you upgrade.  for example in what you quoted above you need to change `current_account` to `current_account.payment_processor` in order to get the rest to work.

Will Read
Jamie Crone does your snippet work for `vendor_subscribed?` ? It seems like the first check, `current_account.subscribed?` will look for a subscription with a name of "default". I'm looking at Pay::Customer#subscribed? where the default value for the name argument is Pay.default_product_name, which is "default" out of the box. cc John Quarto-vonTivadar  
Notifications
You’re not receiving notifications from this thread.