How do I set the name in subscriptions?
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
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 productionPay::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>
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
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
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.
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.
`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
the above is the out of the box `subscription_params` method. You might have to add `:name` to the list
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.
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
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.
Notifications
You’re not receiving notifications from this thread.