#kamon_price-catalog
open gazelleBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1245857934781579306
đ Have more to share? Add details, code, screenshots, videos, etc. below.
covert surge
Ooh, digging the new bot Justin made to help organize Discord questions :). Bet this is helping a lot!
rough comet
Hi there!
covert surge
Howdy howdy! How's it goin' today?
rough comet
Going well!
covert surge
That's great to hear!
rough comet
So let me make sure we're on the same page. You have a platform with connected accounts. You also want the connected accounts to be able to create their own Subscriptions. Is the blocker here the fact that you want to be able to be able to create Prices on the fly?
covert surge
Correct!
As it seems subscriptions are tied to a Stripe price and aren't as malleable with pricing as a PI or Order
rough comet
That's right, but you could use price_data to create inline Prices: https://docs.stripe.com/api/subscriptions/create#create_subscription-items-price_data
We'll create a Price (and/or Product) object on the fly in this case and automatically archive them so no other Subscriptions can be created with those IDs, but that would allow you to customize the amount a bit
covert surge
HOW DID I MISS THIS
So, if I'm following correctly, I shouldn't need to be creating prices either in the Dashboard or via the API, I can just utilize the price_data field?
Do these prices should up in the Dashboard, or do they not and that's what 'inline' implies?
Also, if a user updates their subscription's pricing via the price_data field, how does that change effect users subscribed to them?
rough comet
You can just use price_data, if your intent is to create a Price and a Subscription at the same time and not re-use that newly-created Price. You can search for the Price in the Dashboard (and retrieve it via the API) since you will have a Price object ID but it won't show up in the Dashboard when you're looking at all the prices of a particular product
rough comet
Also, if a user updates their subscription's pricing via the `price_data` field,...
I don't quite follow this question. Can you clarify?
covert surge
You *can* just use `price_data`, if your intent is to create a Price and a Subsc...
Perfect, thank you!
rough comet
This shouldn't be any different compared to updating a Subscription using a Price
covert surge
I don't quite follow this question. Can you clarify?
Sorry, wasn't very clear.
I guess in general, when updating a price, what happens? Is the user immediately charged/refunded the difference, or does it only apply to the next billing cycle?
rough comet
It depends how you handle the upgrade
I recommend reviewing this: https://docs.stripe.com/billing/subscriptions/upgrade-downgrade
and paying close attention to prorations: https://docs.stripe.com/billing/subscriptions/prorations
You could also schedule a price change using Subscription Schedules: https://docs.stripe.com/billing/subscriptions/subscription-schedules/use-cases
covert surge
Wonderful, thank you for that!
One last thing, if you don't mind:
In your opinion, if users are create a small grouping of subscription types for folks to subscribe to, would it generally be better to create the price inline per user-to-user subscription or create instead create the price object via the API for each of those subscription types?
I know we just spoke about price_data but, then I got to thinking about managing price changes on those subscriptions and I'm wondering if it's be cleaned & easier to just create prices instead.
rough comet
I guess I went down the price_data route because I assumed one of your earlier messages meant that amounts for these prices would be variable across customers and also across potential future updates. So, like, if you never plan on reusing those prices, price_data would be the way to go. Otherwise, if you have a set of constant prices (e.g. 5 customers will subscribe at the same $20/month, 10 customers will subscribe at the same $400/year), then creating Prices makes sense
open gazelleBOT
cursive blaze
kamon_price-catalog
covert surge
The initial assumption is correct, but they will be reused.
Let me better explain the scenario.
- User A creates a subscription type on our platform. This gives users who subscribe to them a variety of benefits from him. The price for this can whatever the user wants.
- User A also can create any number of subscription types following these rules. Most cases, this will only be 1-3, but could be more (which we may artifically limit).
- User B can then subscribe to any of the subscription types that User A has created, or any other user who also has created subscriptions.
cursive blaze
Then creating explicit Products and Prices seems like the right design for you
covert surge
Howdy Koopajah, been a minute since we last spoke, hope you've been well!
So, basically, each subscribee will effectively be creating their own products and prices, correct?
cursive blaze
yes
covert surge
Would it be reasonable and viable to create a single product, i.e 'User Subscription', and just use it for all prices that users create?
I've done this before for other use cases, but because I'm newer to utilizing subscriptions, want to make sure I'm not shooting myself in the foot.
cursive blaze
It works but then you're better off doing price_data every time after all really.
You need to decide if you want to build on top of our Products and Prices APIs with all the features that come from it, or if you just store the info in your own database and create the Product/Price on demand each time.
covert surge
Gotcha!
- Am I able to create products on demand when creating a subscription? It seems like
price_datarequires a product. - Creating everything on demand, though, would mean if a user wants to update pricing, every subscription attached to them would also have to be updated, correct? As opposed to just needing to update the price and having the subscriptions attached to it automatically update (unless if that doesn't happen).
cursive blaze
You have to create a Product and then pass price_data on Subscription
to just needing to update the price
it's impossible to change the amount of a Price
covert surge
Oh, gotcha! So there isn't a ton of benefit there really.
So, if the amount needs to change, a new price object needs to be created anywho, and subscriptions need to be updated w/ that price.
If I'm using price_data to create prices on the fly, then using a single generic product like I mentioned previously should be fine then, correct? Any cons of doing this?
cursive blaze
it'll make absolutely no sense in reporting, in the Dashboard, etc. It'll be impossible to add the ability to do Coupons/PromotionCodes that only work with certain of your users and not others (as the filtering/restriction is on the Product id).
covert surge
No sense as-in everything would be under User Subscription or w/e the product is titled, correct?
cursive blaze
yes