#ab_api
1 messages ¡ Page 1 of 1 (latest)
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1379477672614301786
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hello, yes the subscriptions API can take an array of discounts to apply https://docs.stripe.com/api/subscriptions/create?api-version=2024-10-28.acacia#create_subscription-discounts
But that array can have only one active discount right .?
other will be in-active discounts.?
I mean at a time only one discount is applied on subscription
Not as far as I know, we used to have that restriction but I thought I've been able to apply multiple when testing recently. Are you getting an error when you try to test this?
And when the one discount restriction was in place we only allowed one discount on the object at all, the distinction between active and inactive didn't really happen there
One of my developer is working on a project. we have all of our subscription and its managment in our system the subscription plan and its prices and all that stuff. Now what he has done is that he creating the subscriptions and prices on stripe as well. Btw I totally disagree with this approch if you subscription managment in your own system then use stripe just for payment what do you say in this.?
by usign this approch we need to make changes on both side in our own system and as well on stripe .
At last we need to add discount on candidate level on same subscription that's I have asked can we add multiple discounts on one susbcription of same type
That design decision is up to you all but I do agree with the general philosophy of not having to duplicate data/logic here. If you can simplify that and just use one or the other as the source of truth that may make things easier. Though also it may make sense to duplicate them as that may make things like our invoice UI clearer if you are using that.
When you say "candidate level" are you talking about customers? Or are your candidates represented by something else in our system?
Candidate is a type of customer i have three types of customer Candidate referee and organization
Gotcha, so unfortunately starting with our latest API version we are depricating customer-level discounts. So that would likely be something that you have to model on your side and then apply to individual subscriptions. You can still use customer-level discounts for however long you are on your current API version, but if you upgrade to Basil or later it won't be supported by the API unfortunately.