#cm5061_basil-replace-forever-coupons
steady shardBOT
👋 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/1463991662350172317
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hazy pulsar
Hi 👋
Quick question to start. Why don't you use the trial_end or trial_period_days parameters to create an actual trial period instead of using Coupons?
Or are you combining the trial and coupon usage?
scarlet ingot
Sorry if it was unclear, but we are (combining them). Use case is:
- User subscribes to a monthly plan with an initial payment
- We give their Subscription a trial period for N months
- We used to apply forever / amount_off coupons to these Subscriptions to give them a discount in perpetuity
Specifically, I'm trying to figure out how the new repeating / amount_off's coupon duration does or doesn't respect trial periods and the like.
Like if we were to try to approximate the "discount in perpetuity" thing with repeating coupons, should we just choose some arbitrarily large number (discounting the weirdness in the checkout UI)? Or could we choose something more reasonable, i.e. the amount of monthly payments we expect the user to make on their Subscription?
Maybe important to note that we are kind of treating these monthly Subscriptions as installment plans, with a fixed length / duration.
hazy pulsar
Okay, so you've got a trial period and then you want the coupon to be applied. May I ask why you aren't just using a Price amount that mtaches the amount you want to charge?
scarlet ingot
That's a great question, we've internally talked about that several times in the past and it's not 100% out of the question for us to do/support that.
That said it's predominantly because we have many products and many different tiers of coupons, so for (one of) our monthly subscription products, we'd have something like 25 distinct prices.
Not that that's any better than having 25 distinct coupons, I suppose. But at least those 25 distinct coupons can, and do, get applied to all products, not just one.
Also (I think) management likes the display of the discount itself in the checkout, invoices, etc.
hazy pulsar
Okay so let's go back to the "using subscriptions as installments" set up. Do you know at the time of creation the exact number of billing periods?
scarlet ingot
Okay so let's go back to the "using subscriptions as installments" set up. Do you know at the time of creation the exact number of billing periods?
Yes, we do
We offer the following payment options: onetime, annual (two payments, 50% upfront, 50% a year later, and then monthly (variable depending on the product, but we do know upfront).
steady shardBOT
hazy pulsar
In that case, could you try coding a simulation where you create the coupon with a fixed duration for the number of billing periods you expect? You can make use of our Test Clocks to simulate the entire lifecycle of the Subscription.
steady shardBOT
cm5061_basil-replace-forever-coupons