#bfitz_1992
1 messages ยท Page 1 of 1 (latest)
HI ๐
How are you applying the coupon? Can you share an API request ID for this? It will start with req_
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Thanks, taking a look
For that one, we kept the current trial phase intact, then inserted the gift phase with coupon: Vg1aBLwr, then moved back to the original schedule, which was $49/year to $70/year
(originally it was trial -> $49 for first year -> $70 every year after that)
If the user were to redeem another gift, we would try to update the schedule like:
trial -> new gift -> old gift -> $49 -> $70
Okay I see the coupon being applied in Phase 2 but it doesn't show up in the later phases. Is the discount being applied incorrectly here?
Hm not sure I understand - we don't want the coupon in the later phases
Right, and I don't see it applying in the later phases
We just want it to apply to the gift phase so it's free
Hm well at least in test mode, when I fast forwarded to check the future phases, their invoice was still $0.00
For this test customer: cus_OpvsTsG0B3pq8f
Oh that's odd. When I look at the current state of the subscription I see a coupon applied to phases 2 & 3
Is that the problem then? I applied it to both phases so both were free...
to simulate this user redeeming multiple gifts
Correct. If you look at the request body here: https://dashboard.stripe.com/test/logs/req_ajA9z4i3w1BRUH
You will see two phases where the same coupon is passed in
This coupon can be applied forever so there is no limit to the number of times the customer (or you) can apply it
So should I not apply it on the second gift phase?
I'm still checking the billing cycles with the. most recent invoice for this subscription
okay thanks
Put another way, the flow I tried was:
- User starts off with a schedule like
trial -> $49 -> $70 - User redeems a gift, so their schedule becomes
trial -> gift phase with 100% coupon -> $49 -> $70 - User redeems another gift, so their schedule becomes
trial -> gift phase with 100% coupon -> gift phase with 100% coupon -> $49 -> $70
In part 3, it was that future $49 phase that generated a $0.00 invoice
I see. Do you have have that last request ID so I can review it?
hm lemme check
sorry still looking for that specific request
Ah this one req_ajA9z4i3w1BRUH
Okay so we have the trial phase, 2 gift phases ($0), and then we get to the $49 phase
right
But you are saying that when you advance the test clock to generate the invoice that should be covered in that 4th phase (2025-11-17 - 2026-11-18), you do not see an amount being charged
Yes invoice in_1O2GSvEjLMO6STxRTPrjVIjY. Though I'm now seeing that it thought it was still for the gift price (47.88 - our editors made some weird prices haha), not $49
You can see over this user's invoice history that they went from
- $1 for the trial (we do paid trials)
- First gift phase a month later for $0
- Second gift phase a year later for $0 again (gifts last a year)
- Then a third $0 invoice a year after that. That's the one that should be for $49
Hm and I just noticed that that customer's next invoice is kinda wonky, trying to add $47.87 to $49
Oh wait, that sounds like there was some odd proration mismatch.
๐ค
i did notice you have a price that bills on an annual frequency
But your phases appear to be for 366 days
hmmmm interesting
I bet it's because we're explicitly setting the start_date and end_date on each phase instead of relying on iterations.
Question though - is there an easy way to see how many iterations an existing phase was created with? When looping through them, all I see is the start_date and end_date
If you specify both start_date and end_date then the phase will not use iterations.
For iterations to work with the way you are using prices, you would need to create a monthly recurring price so that iterations: 1 would map to a one month billing cycle
And then go to your annual prices
That's what we normally do...except I recently discovered that someone could go into the Stripe Dashboard and create a single phase of 3 monthly prices. In which case iterations would be 3
(like if a customer writes in complaining about something and we want to comp them 3 free months)
Okay, and what is the issue there?
Was wondering, when I push the future phases out to make room for the inserted gift phase, if there's an easy way to check how many iterations that pre-existing phase had. So I don't have to do date math that is clearly breaking something haha
(Also not completely necessary for the current discussion. More interested in - if I get the start and end dates right, if that might fix the issue)
Hmmm... let me test that out quickly
I'll also try with setting iterations instead of manually setting the future phase's start and end dates.
Okay so, when using the API, the behavior for updating subscription schedules is that all phases are replaced by the incoming phases. So if you wanted to insert a gift phase I would recommend you retrieve the Schedule via the API, copy the array of phases to a variable, and insert the new phase data in the corresponding location (e.g. after the trial phase). The future phases will still have their iteration values set when you POST the update
Oh really? I don't have to explicitly set iterations or start/end_date for those phases?
Not if they already exist.
interesting okay giving that a shot. Because the API behavior you described is exacltly what I'm doing... except setting start/end dates to make room for the gift phase
If you are using iterations they should just bump down. But if you do have specified start_date and end_date then you would need to update those.
You can copy the values from the existing phases
testing this out
Hm still running into a few issues: Phase 0 is invalid. Each phase must specify either iterations(recommended) orend_date (advanced). So I do have to transform the existing phases somewhat to set either iterations or the start/end dates
oh but I can set start/end on the initial phase, then iterations on all subsequent phases
ACK: Right I was just trying this out myself and realize you need to copy the end_date from the previous phase into the start_date of the next phase
I was doing something like that before, which lead to that bug where my calculated gift phase duration was 366 days.
However, this seemed to work: req_OtK0bn62fAqDjh
Now I'm going to try that with a second redeemed gift phase
Okay also seemed to work with req_2pc0l7VOtARmpy
(the thing I was asking before though - with these requests, I am hard coding iterations: 1 for those future phases. Because when I retrieve the existing phases, I don't see a property specifying how many iterations that phase has. All I see is the start/end date.)
Going to fast forward this user now to see how the invoices pan out
oh crud I used a once coupon
Got it. Right using the iterations defers the calculation of the end_dates to Stripe. But then, if you want to insert a new phase, you can use the calculated end_date value as the new start_date for your next phase
THink the problem was, my calculated end_date was different from Stripes. Using luxon with plus({year: 1}), so perhaps need to be more explicit
Hmmm...yeah I could see that leading to some gaps where the coupon was applied for 1 day longer than the billing cycle, resulting in odd prorations. So when the next invoice was cut, the 100% off coupon still applied but only for that day.
Then when you got the next Invoice, it included a proration for the other 364 days
hence the $98ish invoice
Yup
So seems like relying on iterations is the most reliable way forward. I just need to find a way to see how many iterations a pre-existing phase had without doing more date math...
Also, not sure if we've set a record for thread length here, so if you need to bounce, totally understand
Well you can always check the length of billing cycle relative to start/end dates. I know it's. not as clean as iterations: 3 but that's how we calculate end_date from interations
hm I don't see billing_cycle on the phase object though - which object is that on?
Sorry I meant the recurring interval for the Price object
But that's just an enum right? Meaning I'd still need to translate year into some number of seconds (which I guess luxon defines differently than y'all)
Yes that is true. I mostly integrate using Python and so I use timedelta(years=1).total_seconds() to get a duration like that.
I do need to step away ๐ but my colleague @molten blaze will be available to assist you if you need further advice on this.
I really appreciate all your help!!
Happy to do it ๐ , it's why we're here
And hi @molten blaze - I'm testing out setting iterations right now instead of start/end dates
Sounds good -- please let me know if you have any questions about that. I do prefer using iterations myself, too
Nice yep confirmed that the coupon was removed after the second gift phase, seeing the correct invoice amounts now. So now I just need to find a way to see how many iterations an existing phase had, most likely through checking the phase's price's interval and seeing when its end_date is like Snufkin described
I need to grab some lunch, but thank y'all so much for chatting for so long!