#damenz - subscription
dusk siren
You can create these prices, and it's fine to do so, but its also important that the Product represents a unique thing being sold
ie, if you added on an extra, thats really another product being added in
Prices should generally be used to reflect currency/interval options
Using multiple prices for the same currency & interval is fine for custom integrations (which sounds like what you're doing) but will limit your ability to eg use the Customer Portal to manage subscriptions.
You can also use the price_data during subscription creation to define ad-hoc pricing as you go
Note that this will create a price object to be used for that subscription
vague yoke
Im on the phone, will check this as soon as I am done and come back to you ! Thanks !
dusk siren
NP!
vague yoke
Ok back.
This is a UNIQUE product, its just that since we have a profit margin, the sales team can play with it to close the deal, therefore that same product can be sold at many different prices
I understand that prices are mostly designed for interval / currencies
Its just sad that the price cannot be changed on the go
and is "Stuck" at that price
What do you mean by "Ad-hoc" pricing ?
dusk siren
with the parameter i linked to, you can reference a product but define a custom price amount for the subscription
If the product is the same for everyone, then this would make sense (vs custom products for each customer)
vague yoke
But if I understand that would create a new permanent "Pricing" for that product?
There is no way we can just create a "on-demand" custom price for that product without actually creating a new "Pricing" that can be reused? (I dont want that custom pricing to be reused as much as possible to make sure we dont end up having 60 different pricing for that product)
dusk siren
It will create a Price object which uses that Product, yes. That's necessary for the functionality of the subscription.
And yes you will end up with many Prices for that Products, but there's no problem with this, aside from making the dashboard less usable. You'd need to implement your own UI for your team to review these prices by customer etc.
vague yoke
The prices are gonna be BY customer ? ¯
"for your team to review these prices by customer etc." what do you mean here?
You linked the subscriptions API, but is this true for scheduled_subscriptions as well? (price_data)?
white sluice
👋 @dusk siren had to head out, but I can help! Give me a minute to catch up
vague yoke
Sure!
white sluice
for your team to review these prices by customer etc
I think what they meant here is that in our API we don't tie a specific Price to a customer, so if your team needs this in their UI it would have to be something you implement yourself. To be more specific, if your team was expecting a customer ID right next to a price ID in the UI that would not be something our dashboard currently reflects
vague yoke
Oh no ! I dont really care to know its linked to which customer
I just need my team (via my custom ui in my internal systems) to be able to specify a custom price if the default one not what they need
I tried creating a price_data for a scheduled_subscriptions, but I dont see the new pricing i did on the product page
Is that what the price_data does ? (A new pricing on the fly JUST for this subscription?)
If thats the case its perfect ! I didnt actually wanted the price to be re-usable via the UI
white sluice
Yes, the new pricing should JUST be able to be used for that specific subscription - it wouldn't be reusable