#eirikbakke

1 messages · Page 1 of 1 (latest)

faint compassBOT
ember linden
#

Hello! Generally speaking a Customer should represent the entity paying. The most common case is a single person paying, which is what the Customer object is focused on, but a Customer can also represent something like a business or an organization.

#

For your use case who's paying?

neon ermine
#

It's a land-and-expand type business model, so initially I expect it to be individual users, either paying out-of-pocket, getting reimbursed by employer, or paying with a company card. But the intention is to later get these individual licenses to advocate for the buying of a team license, which is more likely paid for with a company card.

ember linden
#

I think you probably want the initial part to be a Customer object that represents the individual, then later switch to a different Subscription with a different Customer that represents the business.

faint compassBOT
neon ermine
#

Thanks! Now, each Customer is supposed to be associated with an email address, right? So even if it's logically associated with a whole team or company, it does need to be associated with a single user (email address) for contact purposes?

grizzled jolt
#

Yes each Customer can only have one email associated with it (at least as far as the email that Stripe uses, you could technically store some as metadata or something)

neon ermine
#

That's a useful constraint to know about. Now, is there any way to "transfer" a Subscription from one Customer to another Customer, or is a Subscription always locked to the Customer that created it?

grizzled jolt
#

Locked to the customer that created it unfortunately, so you would likely have to do something like recreate the subscription from customer A on customer B

neon ermine
#

No problem, I'm at the database design stage, so these are just useful constraints to know about.

#

If a user starts out paying with their personal credit card, but then wants to switch to their company credit card that has their name on it, does that require a change in the Customer object, or is it merely a new PaymentMethod?

grizzled jolt
#

Just a new payment method, Customers can have any number of payment methods (or at least we don't explicitly force a limit that I am aware of)

neon ermine
#

Great--thank you!