#jscheel

1 messages · Page 1 of 1 (latest)

outer slateBOT
exotic sphinx
#

Hello! Can you provide more specific details? Where are you looking? What are you seeing vs. what do you expect to see?

boreal yarrow
#

Hi @exotic sphinx! Sure thing:

# 
// Starting subscription schedule phases:

phases: [
  {
    // current phase
    plan: 'inbox-v7-pro-annual',
    quantity: 3,
  },
  {
    // future phase (represents a downgrade from annual to monthly)
    plan: 'inbox-v7-pro',
    quantity: 3,
  },
]

// ---

// After a quantity change with prorate true:

phases: [
  {
    // current phase
    plan: 'inbox-v7-pro-annual',
    quantity: 4,
  },
  {
    // future phase (represents a downgrade from annual to monthly)
    plan: 'inbox-v7-pro',
    quantity: 4,
  },
]

// This showed an upcoming invoice at the end of the annual phase that
// included the prorated charge for the increased quantity, as well as the
// first monthly phases items. I then created an invoice, and now the prorated
// charges are completely gone. And I don't see the invoice.
exotic sphinx
#

What did you do to create an Invoice?

boreal yarrow
#

I would have expected the prorated quantity change to create a difference in the cost... which it did, but then I would have expected creating an invoice to have billed for that difference

#

the ruby stripe gem

#

oh, hmmm

#

I see it in the draft invoices on the customer dashboard

#

in_0NAgFMCOzreAJaTWiPuZEgKm

#

interesting, so that makes sense I think, it just disappeared from the subscription dashboard, with no indication that there was a draft invoice

exotic sphinx
#

Why did you create the Invoice manually?

boreal yarrow
#

because stripe set the upcoming invoice for the end of the yearly phase

#

but this is an immediate change

#

the scenario is a customer is on an annual plan. Halfway through the plan, they want to downgrade to the monthly plan. So we add a phase in a schedule to handle that at the end of the yearly plan they have already paid for. Then, sometime later, before the scheduled phase starts, the customer adds a seat (quantity). We want to immediately make that seat available to them, so we update the quantity on both the current phase and the future phase, with prorate true. Then issue an invoice so the customer pays for that seat immediately and can use it immediately. Does that make sense?

exotic sphinx
#

Yep, that makes sense.

boreal yarrow
#

whew, ok, thought you were gonna tell me I was totally wrong 😅

#

not yet, I'm preparing to though. Was introduced to them earlier today.

exotic sphinx
#

I think that might work better; that will allow you to advance time and accumulate realistic proration amounts vs. trying to test in realtime.

boreal yarrow
#

so, was I wrong in understanding what it was going to do with the upcoming invoice? Because the stripe dashboard said it wouldn't invoice until the end of the current phase.

exotic sphinx
#

Well, let's back up a bit, actually. You have phases in place to represent a downgrade, and you're making updates to the quantity. Is the scheduled downgrade going to be something that actually happens in production, or are you doing that for testing?

boreal yarrow
#

no, this is all for production use cases

#

if a customer wants to switch from annual to monthly, that should only happen at the end of the annual phase

exotic sphinx
#

Okay, so what flow are you trying to test exactly? Just in plain English?

boreal yarrow
#

customer is on an annual plan for 3 seats. They schedule a change to a monthly plan (still 3 seats). Then, before that scheduled change happens, they add a seat.

#

so, we want to charge immediately for the added seat, so they can immediately start using it. It should be prorated against the annual plan the customer is currently on. So, let's say they make the change halfway through the annual plan, we want to charge them for half a year for one additional seat

exotic sphinx
#

Okay, so you're updating the quantity for both phases, right? But you're not seeing the behavior you expect?

boreal yarrow
#

ok, so, lemme set up a subscription that's in the state that seemed weird to me, so you can see what I see

#

ok, @exotic sphinx, sorry, was fixing up a caching issue. So, here's the subscription: sub_0NAh34COzreAJaTWlFCzKpVx

exotic sphinx
#

Okay, so what are you seeing on this Subscription and how does it differ from what you expect?

boreal yarrow
#

that is the first step, a normal, annual sub

#

ok, so now I'm going to schedule the switch to monthly

#

@exotic sphinx so, now if you look, you will see that the switch to monthly is scheduled for May 22, 2024

#

next step is for me to change the quantity from 3 to 4

#

I am sending this with prorate true

#

ok, now it's in a state that seems weird to me

#

you can see that it is showing the proration for the current annual sub currently being set to be invoiced 1 year from now

#

($420 of prorated charges + $160 for a monthly charge)

#

instead, I need that prorated amount to get charged immediately

#

hence me creating an invoice

exotic sphinx
#

You're looking at the upcoming Invoice there though, that's showing you what it will look like when it Invoices next, not what it looks like if you Invoiced now.

boreal yarrow
#

yes, I know

#

so I should create an invoice, which will invoice for those top items

#

the ones that are dated MAY 22, 2023 - MAY 22, 2024

#

which is the proration

#

correct?

exotic sphinx
boreal yarrow
#

because the bottom items MAY 22 - JUN 22, 2024 are part of the next phase of the schedule

#

@exotic sphinx hehe, so... we have been using an old version of the api I think (I inherited our billing mess)

#

so I've been setting prorate: true

keen spade
#

👋 hopping in here since rubeus has to head out soon - give me a minute to catch up

boreal yarrow
#

hi @keen spade

exotic sphinx
#

@keen spade is way better at this than I am, so you're in great hands here. 🙂

boreal yarrow
#

@exotic sphinx thanks for all the help

keen spade
#

Just making sure I understand - your issue is that you have a current subscription schedule that will make a change at the end of the current phase. However, you'd like to also make an immediate change to the subscription now (mid-cycle) and invoice for those prorations immediately and you're not seeing that Invoice have the expected proration line items

boreal yarrow
#

@keen spade essentially, yes

#

if you take a look at sub_0NAh34COzreAJaTWlFCzKpVx, you should see why it's a bit confusing for me

keen spade
#

Is the latest invoice (in_0NAh35COzreAJaTWb8a5IeZO) the one that's not what you expect?

boreal yarrow
#

that one was fine. That was issued when the customer started the annual plan with 3 seats

keen spade
#

Gotcha, so which one is the Invoice that you don't expect? (or is it an upcoming one that you're previewing so there's no real invoice yet)

boreal yarrow
#

here you go

#

so, you can see at the top, that stripe says an invoice will be generated on may 22, 2024

#

I've highlighted the relevant parts

#

that middle part (about the mid-cycle quantity change) is what is confusing to me

#

and I think it's just because I need to manually issue an invoice

#

or, I'm guessing, set the proration_behavior to always_invoice instead of setting prorate to true

#

because we should not wait until 2024 for that middle part

#

that middle part needs to be invoiced immediately, when that quantity change happens

keen spade
#

I see - your confusion is that after making request https://dashboard.stripe.com/test/logs/req_NFAplbfNFRdsss you expected the Invoice to be generated immediately for the proration changes. But instead you're seeing no immediate invoice and just pending invoice items that'll be rolled into the next Invoice

boreal yarrow
#

yes, exactly

keen spade
#

yeah, I'm guessing the issue is with your usage of prorate: true - is there a reason you're using that? Is it just because that's what you had when you first integrated?

boreal yarrow
#

do you mean, vs using proration_behavior?

#

I can happily switch to proration_behavior if I need to, if that makes this work 😆

#

so, in the past we have allowed people to downgrade and change plans immediately

#

we are stopping that, using schedules

#

so some of this is new code on top of legacy code

#

so, if prorate: true is not the same as proration_behavior: always_invoice, that may be why I am confused

#

in the past, we would make subscription changes with prorate true, then generate an invoice ourselves

keen spade
#

Do you happen to have one of those past changes on hand as an example?

#

I believe prorate: true is more similar to proration_behavior: create_prorations, but I'd want to double check your examples just to be sure

boreal yarrow
#

hmm, gimme a sec to find one

#

ok, so here you can see this customer went from 13 to 11

#

and prorate technically wasn't set

#

so it defaulted to the default behavior

#

oh, one other interesting question

#

do I even need to be specifying the proration_behavior in the phases?

#

or is that just for chanigng the default behavior of the subscription?

keen spade
#

Let me start by talking about that other subscription you sent over - that one also didn't generate a new Invoice as part of that update request. You created it manually by creating an Invoice for the Customer and it pulled in all the pending proration line items. https://dashboard.stripe.com/logs/req_0MeXkerlOVkthm

boreal yarrow
#

yes, exactly

#

so, in our old code

#

we call Stripe::Invoice.create(customer_id)

#

24 hours after a change on an annual plan

#

ahhhh

#

here we go

#

so, I just rewrote my code to use proration_behavior

#

sub_0NAhsaCOzreAJaTWzddf78Kx

#

now, that worked the way I would expect

#

so, the customer pays for the annual plan

#

then schedules the change to the monthly plan

#

then adds another seat

#

invoice was paid for the initial annual plan

#

phase going to monthly plan was scheduled

#

then a new draft invoice was generated for the prorated amount from the quantity change

#

that's way clearer

#

and the draft invoice will be finalized in 1 hour

#

👌

#

that's perfect

#

so, lol, tech debt is killing me 😆

#

I think the only outstanding question, then, would be my q about needing to set proration_behavior on each phase as well. Is that just for setting the subscription's default proration behavior once that phase activates? Meaning, do I really just need to set it on the schedule object that's updated if I'm just trying to calculate prorate changes for the change I'm currently making?

keen spade
#

You only need to set proration_behavior on the phase if you want the behavior there to not default to create_prorations for any updates

#

proration_behavior is something you have to set with EVERY update to the subscription, so if you want every change to be invoiced immediately you'll need to pass in proration_behavior: always_invoice for each phase

boreal yarrow
#

ah, ok, so I have to set it on the schedule update and on each phase in the schedule update?

keen spade
#

Yup!