#multy-customer-definition

1 messages · Page 1 of 1 (latest)

weary lavaBOT
cerulean dome
#

I was storing customer id's on my app users and then I realized that doesn't work if they make multiple orders

slate hare
#

@cerulean dome I don't believe that is a fair representation at all really. A Customer represents "an entity paying for something". And a Customer can have zero, one or many PaymentMethods which represents the payment instrument that can be used for a payment.

#

Now, yes it's possible to an integration to have no tracking at all of Customers and treat them as "single use" sure. But that's mostly because you wrote code that didn't take Customers into account at all. Though in that case we usually recommend not saving Customers at all

#

multy-customer-definition

cerulean dome
#

ok, reviewing my code to find the particular issue I was having

slate hare
#

happy to help if you share a bit more details or an example

cerulean dome
#

I think it all stemmed from my notion that a Customer could be used by anyone, and that users could have multiple Customers
Which is true but the app just needs to lock down the ids.
It became fuzzy between yesterday and today 🙂

TMI for you but putting it anyway:
I have a join table of subscriptions and was keeping only the Stripe sub id, and looking up:
app subs with user id -> Stripe subs with sub id -> app users that matched the Stripe sub customer key
But I can just store the Stripe sub id AND Stripe customer id on the app subscription

And I guess that's what hung me up, because if I have one Customer associated with the user record, and one with the subscription record, it's possible they could be different and things can get weird. So it's up to me to make sure a user never uses multiple Customers