Can a subscription be attached to a model other than User?

[scottward]

Our app enables multiple users to be a part of a single organization. We'd like to use Pay to set up a organization.subscription with different quantities depending on how many users they add.

It looks like the standard approach is user.subscription, but that isn't quite right in this case.

How can we associate a subscription with Organization instead of User?

Or, am I missing an easy workaround? What's the best practice in this case?

[excid3]

Sure can. The Pay::Customer model is polymorphic so you can use any model you want.

For example, with JumpstartRails.com apps our model is Account.

[excid3]

Depends upon the API. Braintree has a first_name & last_name field, but Stripe has just name so we combine them.

I'd probably alias first_name to the Org name and an empty string for last_name. Or you could use the Org owner's name. Up to you.

[scottward]

Bingo. That's perfect. We'll be using Stripe. Thanks a lot!

[feliperaul]

@excid3 Chris, how do you deal with the email field on the Account model? By the way, our Account model has_many :admins that can create/update/destroy the subscription, so which e-mail do you provide?

[excid3]

@feliperaul either use the account owner's email, or add a billing email email field to the Account

[feliperaul]

@excid3 Chris, how would you approach the scenario where the Account has many owners/admins, each one capable of managing the Account's subscription?

I won't be using the gem nor Stripe for sending any e-mails/receipts.

So would you create a fake e-mail address for the account, something like "account-#{self.id}@myapp.com", or you would persist the e-mail address of the first user that is an admin of the organization? (this would create the need for syncing that e-mail when that specific admin updates his e-mail, or even elect a new admin e-mail if the previous one is removed from the Account).

I'm inclined to go with the fake e-mail address for the account, but would love to hear your thoughts.