#bfitz_1992

1 messages ยท Page 1 of 1 (latest)

compact zincBOT
scarlet kiln
#

HI ๐Ÿ‘‹

toxic beacon
#

I'll check for the id

#

Here's an example: req_abZl7m9x8tlrUv

scarlet kiln
#

Thanks, taking a look

toxic beacon
#

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

scarlet kiln
#

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?

toxic beacon
#

Hm not sure I understand - we don't want the coupon in the later phases

scarlet kiln
#

Right, and I don't see it applying in the later phases

toxic beacon
#

We just want it to apply to the gift phase so it's free

scarlet kiln
#

So I don't see a problem here

#

In the later phases the coupon property is null

toxic beacon
#

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

scarlet kiln
#

Oh that's odd. When I look at the current state of the subscription I see a coupon applied to phases 2 & 3

toxic beacon
#

Is that the problem then? I applied it to both phases so both were free...

#

to simulate this user redeeming multiple gifts

scarlet kiln
#

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

toxic beacon
#

So should I not apply it on the second gift phase?

scarlet kiln
#

I'm still checking the billing cycles with the. most recent invoice for this subscription

toxic beacon
#

okay thanks

#

Put another way, the flow I tried was:

  1. User starts off with a schedule like trial -> $49 -> $70
  2. User redeems a gift, so their schedule becomes trial -> gift phase with 100% coupon -> $49 -> $70
  3. 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

scarlet kiln
#

I see. Do you have have that last request ID so I can review it?

toxic beacon
#

hm lemme check

#

sorry still looking for that specific request

#

Ah this one req_ajA9z4i3w1BRUH

scarlet kiln
#

Okay so we have the trial phase, 2 gift phases ($0), and then we get to the $49 phase

toxic beacon
#

right

scarlet kiln
#

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

toxic beacon
#

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. $1 for the trial (we do paid trials)
  2. First gift phase a month later for $0
  3. Second gift phase a year later for $0 again (gifts last a year)
  4. 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

scarlet kiln
#

Oh wait, that sounds like there was some odd proration mismatch.

toxic beacon
#

๐Ÿค”

scarlet kiln
#

i did notice you have a price that bills on an annual frequency

#

But your phases appear to be for 366 days

toxic beacon
#

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

scarlet kiln
#

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

toxic beacon
#

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)

scarlet kiln
#

Okay, and what is the issue there?

toxic beacon
#

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)

scarlet kiln
#

Hmmm... let me test that out quickly

toxic beacon
#

I'll also try with setting iterations instead of manually setting the future phase's start and end dates.

scarlet kiln
#

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

toxic beacon
#

Oh really? I don't have to explicitly set iterations or start/end_date for those phases?

scarlet kiln
#

Not if they already exist.

toxic beacon
#

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

scarlet kiln
#

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.

compact zincBOT
scarlet kiln
#

You can copy the values from the existing phases

toxic beacon
#

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

scarlet kiln
#

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

toxic beacon
#

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

scarlet kiln
#

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

toxic beacon
#

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

scarlet kiln
#

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

toxic beacon
#

hence the $98ish invoice

scarlet kiln
#

Yup

toxic beacon
#

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

scarlet kiln
#

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

toxic beacon
#

hm I don't see billing_cycle on the phase object though - which object is that on?

scarlet kiln
#

Sorry I meant the recurring interval for the Price object

toxic beacon
#

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)

scarlet kiln
#

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.

toxic beacon
#

I really appreciate all your help!!

scarlet kiln
#

Happy to do it ๐Ÿ™‚ , it's why we're here

toxic beacon
#

And hi @molten blaze - I'm testing out setting iterations right now instead of start/end dates

molten blaze
#

Sounds good -- please let me know if you have any questions about that. I do prefer using iterations myself, too

toxic beacon
#

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!