#TJ - product information
arctic bridge
Honestly it depends entirely on your needs. Anything from "Stripe storing all of your information" to "you storing all of your information" might work".
It is fairly common to do some kind of hybrid. Very often users will store product and price IDs + any other information that they don't want to wait to look up from us often.
haughty gate
We like the idea of Stripe helping with subscriptions and invoicing as that is one less block of code we have to manage. Our products are fairly complex digital products that can have their own unique methods for provisioning, etc.
arctic bridge
Gotcha. Is there anything specific at the moment that you aren't sure how to store or represent in Stripe?
haughty gate
So in your example, the source of product info would still be stored in Stripe but the customers would cache some or all of that info on their end so that it can be readily utilized?
We're just trying to determine what kind of solution we'll go with for our new store frontend, and if that solution needs to have product information management as a part of its functionality.
I think our most legitimate concern was the constant querying of product data from Stripe.
arctic bridge
Let me know if I am going off base here but yes you should probably not need to query your stripe product/price data very often, especially not on every page load of your storefront.
Do you know roughly how you are going to represent what you are selling with our products and prices?
haughty gate
I think so, though I haven't quite gotten to setting a product up to try it out. We have about 5 different types of products, and I imagine each product type could have its own template for product information stored within the product object's metadata. We do need to offer these products at different prices depending on the type of customer, so we'd (assumptions here) set up multiple prices for each product based on the variations that we need to support.
arctic bridge
That sounds like our recommended way of structuring it so far. Will you have to add new prices to your products often?
haughty gate
Not often. Sometimes we may need to provide a special discount on a product or we may need to adjust the current price of a product.
arctic bridge
Stripe Price objects actually can't be updated after you have made them. You would likely be creating a new Price for that (or maybe a Coupon/Promo code).
Or rather, Prices can be updated, but the underlying amount of money it refers to cannot be changed. We have a list of the params that can be updated here https://stripe.com/docs/api/prices/update?lang=curl
Is this answering your questions so far?
haughty gate
Oh, interesting and good to know.
If we have customers with subscriptions, how would a change in price by adding a new price object get set up to take effect with the subscriptions billing?
arctic bridge
Basically you will make an update call to each subscription that you want to change to the new price
haughty gate
I just got one example from the team on what information could be problematic if stored in product metadata. As trivial as it may seem, the concept of a "category" to put the product in could be complicated if we're storing category assignments in the metadata. Is there maybe a better approach that could do proper validation for product categories, return full list of existing categories, etc.?
arctic bridge
Up to you, but that is often a thing that might make more sense to store on your side. Like you will likely have some records of these products yourself right?
You would be able to recompile a list by pulling all of your products and prices and looking through the metadata for each. And you could pull products by metadata using our search API https://stripe.com/docs/search-beta . But also it might just make sense to have that data more on hand yourself.
haughty gate
Thanks, this insight has been very helpful. We have been trying to determine how much of this information we need to store on our end and which end should be the truth.