#si
vivid flint
If the product is always the same product, it may be tidier to create a Product object and then pass its ID in to price_date.product for all of these sessions. I actually don't think you can unarchive the temporary products made with product_data.
Can you tell me more about what you are looking to do with these IDs later?
Also when you say subscription key are you talking about the subscription's ID (sub_123)? Or something else?
dry plank
(yes to the subscriptions, basically users are able to subscribe to other users (like patreon) or purchase products from them)
I don't really have anything specifically in mind. But I can imagine for example wanting to look up and revert a bunch of purchases via Stripe because I'm unlikely to implement that UI while it's available in Stripe, for example. And in that case it might be useful to find all transactions related to the same product?
This could very well be a case of "don't cross that bridge until it's a problem" so if it's not something that you all at Stripe are like "that seems like a really good idea to do" then I might put it off
vivid flint
Gotcha, so to be clear, will these be a combination or subscriptions and one time products?
dry plank
yeah
vivid flint
That listing charges use case definitely makes sense. Trying to think of the best way to structure prices and products to do that
So the way we recommend modeling things in Stripe is that each different thing you are selling is its own product and prices are just different ways to pay for that thing. So for example if I have a Silver plan and a Gold plan those are two separate products but then their monthly price vs yearly price are each Price objects associated with that product
So the way I would initially think to model what you are describing is to have a Product for each user that people can subscribe to and probably also different Products for each one-time thing they sell.
I forget how looking up individual transactions would work though. Checking in to that and will get back to you
dry plank
Awesome thanks. That makes a lot of sense. Also took all of 15 minutes to implement courtesy of y'alls great library! (well the one time purchases thing anyway)
vivid flint
Nice! I do like how quickly some things can take to spin up with our API
So I'm not really seeing a way to do this with product IDs themselves in the API. Subscriptions let you filter by the price ID but not products. https://stripe.com/docs/api/subscriptions/list#list_subscriptions-price
Checkout Sessions don't have a filter for products and for one time purchases they will generate PaymentIntent objects which don't have product data on them at all.
coarse sparrowBOT
vivid flint
One thing I am thinking of that could be helpful is metadata. You can set metadata on the resulting subscription or intent by setting payment_intent_data.metadata or subscription_data.metadata respectively and then our search API lets you query on metadata for both.
https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data
https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-subscription_data
https://stripe.com/docs/api/payment_intents/search
https://stripe.com/docs/api/subscriptions/search