Proposed changes to payment_processor.subscription

[deanpcmad]

If you have a number of different plans, it can be hard to grab the subscription for a customer.

You can't just do @user.payment_processor.subscription to grab that user's subscription, as it checks by the name.

In the billing code I currently use in one of my apps, which I'm hoping to migrate to Pay, I have a default boolean and then in the account model it's just a has_one association.

has_one :subscription, -> { where(default: true) }, class_name: "Billing::Subscription"

Thoughts?

[excid3]

Do you have a more thorough example? You can pass a plan to the subscription method to filter by the plan ID too.

[deanpcmad]

Oops, I forgot Discussions were a thing on GitHub.

I saw that but if I just wanted to grab their subscription, I would have to go through each plan and check if a subscription exists for that plan. This causes a load of extra database queries.

An example would be checking if an account has a subscription, to give them access to a feature

[deanpcmad]

Thoughts on this @excid3? Or could you share how you check a user has a subscription, without checking every plan?

It's one of the stoppers of me moving to Pay tbh as my current billing code makes this much simpler

[excid3]

We use @user.payment_processor.subscriptions.active.any? for this. Does that work for your case?