#brayden-support

1 messages · Page 1 of 1 (latest)

old zenith
#

👋 hello
sure thing! what's up?

rain vortex
#

Hey, I was able to grab a couple of invoices that we have from the past when we've cancelled a customer's subscription.

#

Was wondering if you could tell me why we have so many line items on our cancellation subs now?

#

The new way that these invoices are being generated is causing us all sorts of headaches and I can't understand why it's behaving the way that it is. Can you confirm that something has changed in the way that the subscription delete invoices are created?

old zenith
#

huh that is a lot of line items yes

rain vortex
#

None of them make any sense to me..

#

Except for the very last one, which is the only one that I would expect to get on that invoice.

#

Same as the way that the old invoice is showing.

final scaffold
#

looking

#

seems like you updated that subscription a lot and every time you did it generated proration, that's just the default/normal behaviour

rain vortex
#

Did you look at the old one?

#

Because we did the same thing there.

final scaffold
#

I didn't, but that is mostly what I just said

#

it's all test mode, if you keep touching/updating the subscription it will create proration items over and over

#

and those don't get invoiced automatically so when you cancel they all get grouped in the invoice

rain vortex
#

We're seeing this in our live subscriptions though..

final scaffold
#

But it's the same

rain vortex
#

Perhaps I'm misunderstanding you?

#

and this subscription was also updated several times before deleted.. so why only one charge?

final scaffold
#

yeah you're likely misunderstanding

#

Let me explain

#

let's say you create a Subscription on Price A. Then the next day you change the quantity to 2 -> this creates 2 proration items that are pending for the quantity change. Then the next day you move to quantity 4 -> same thing, now you have 4 pending invoice items. Then the next day you move to Price B => you now have 6 pending invoice items. Nothing is invoiced, it just waits for the next cycle. Then the next day you cancel the subscription entirely, that will invoice for any of those pending invoice items and they all get bundled/grouped together

rain vortex
#

We're actually invoicing when we change the price on the subscription though so how are these items pending?

final scaffold
#

I mean you clearly weren't in some of those cases

rain vortex
#

Everytime that we want a new price for our subscription, we update the subscription with new price data.

final scaffold
rain vortex
#

Ah, interesting. This is us trying to update our subscription schedule.

#

Perhaps this is the crux of the problem..

#

Does creating a subscription schedule for a subscription that does not have a current schedule cause proration?

final scaffold
#

it depends what the update does really

#

if you are changing the current phase then yes it would

rain vortex
#

Our aim when creating the schedule is to keep the current phase the same, and to add a new phase to the end of the schedule. This is how we manage renewals for the subscriptions.

#

We use the schedules because our price tends to increase upon renewal so this was the way that we sought to automatically charge our customer more at the end of their current sub period

final scaffold
#

Then you need to make sure that the first phase in phases matches exactly what is in the Schedule right now

#

It's a really annoying API design sadly because you can't just add a phase you have to pass the current one

#

And so it causes confusion like yours

#

We're trying to design a new flow that works a lot better but it not easy to abstract the complexity away sadly

rain vortex
final scaffold
#

So my advice is to quickly test this on a brand new customer and subscription that way after your call you can see immediately if pending items were created or not

rain vortex
#

Where would I find those pending items?

final scaffold
#

on the Customer page in the Dashboard

rain vortex
#

I can do that really quickly.. let me send you one and see what you think.

final scaffold
#

yeah just make sure to do a new one otherwise it's confusing

rain vortex
#

Okay there's the sub

#

Oh yaaaaa I see them now..

#

I wonder what is different there?

#

Here's how we build our schedule each time.. we release any schedule that currently exists, then create a new one from the subscription itself.

#

I would assume that the first phase there is the possible culprit?

final scaffold
#

Likely, it's hard to say unfortunately. I'd recommend cleanly printing out the exact schedule and its phase(s) first after its creation

#

I also recommend basically using what is in phases[0] to "re-pass the same thing" in the update

#

you are "guessing" from the subscription itself right now and that might be off

rain vortex
#

Subscriptions are not initially created with a schedule though, right?

#

Ah, but on the first go, we create a schedule from the subscription and then immediately update it and we could be updating it with different data.

#

I think I get it. Let me give this a go and see what happens.

rain vortex
final scaffold
#

looking

#

oh boy

#

I'd recommend never doing JSON.parse(sched.phases[0].to_json),

#

Explicitly pass the exact information you need/care about instead

rain vortex
#

Ah, is all of the information in the phase necessary?

final scaffold
#

no

#

and you're clearly passing things where you're just lucky it works

#

https://dashboard.stripe.com/test/logs/req_QMXGq8xv7IQqrb
like you pass plans: { 0: { plan: "price_1LLDYOALivADE4JrBlV3hltC", price: "price_1LLDYOALivADE4JrBlV3hltC", quantity: "1" } }, prorate: "true", proration_behavior: "create_prorations", and both of those are duplicate of each other

rain vortex
#

Ah, so maybe maintain the various phase attributes we had, but just fill them with the phase[0] data?

final scaffold
#

Basically I would explicitly pass the exact list of params

rain vortex
#

Hmm okay that came straight from the phases json data

final scaffold
#

yeah because you're mixing up a resource with properties and a request with parameters

# 
phases: [
  {
    automatic_tax: {
      enabled: "false"
    },
    end_date: sched.phases[0].end_date,
    plans: [
      {
        price: "price_1LLDYOALivADE4JrBlV3hltC",
        quantity: "1"
      }
    ],
    proration_behavior: "create_prorations",
    start_date: sched.phases[0].start_date
  },```
#

what does this do?

rain vortex
#

Makes sense. Let me try this, one second.

final scaffold
#

But you seem to pass the exact timestamps so I don't get why. I wonder if proration_behavior: "create_prorations", is just incorrectly forcing a proration

rain vortex
#

Let me try this real quick, one second.

#

yeah, same thing

final scaffold
#

okay now try with proration_behavior: 'none'

rain vortex
#

Still created em

#

Oh, looks like this might need to be at the same level as phases though?

#

Maybe that's why it's being disregarded..

#

Oh no, I see it as an argument inside of phases as well.

final scaffold
#

okay let me dig

rain vortex
#

Appreciate your help, feels like we're getting close.

final scaffold
#

yeah I think I got it, let me test a few options end to end

final scaffold
#

I'm really confused, I tried many things and I never get proration

rain vortex
#

haha like you can't reproduce my situation you're saying?

#

and you're using the Ruby SDK, right?

final scaffold
#

the SDK doesn't matter here, but I seem to be making the exact same calls

#

the only difference is how you create the subscription which in itself is super weird (backdate and no proration and such) but I tried some of that, no proration at all still

rain vortex
#

Yeah, we have to backdate the thing because it's an insurance policy so it needs to start at 12:01 AM on the day the policy is taken out.

#

sometimes due to underwriting, we are creating the subscription several days after the customer actually opened the policy so we backdate it.

final scaffold
#

Yeah I feel like the whole issue is the really strange sequence of calls you are making

#

you have a really complex subscription creation, then a schedule that you for some reason release then recreate then re-update and it must be messing something up

rain vortex
#

I inherited this project, and the original engineer has moved on.. so I am not advocating for any of this logic to remain.

#

the sole goal of the schedules is to be able to renew policies at different prices than the current period. If there's a better way to do that, I'm all ears on what that would be.

#

Like, do you think it would help if we did not release the schedule?

#

and we just updated it? We're never intending to update the current phase of the schedule, only future phases.

final scaffold
#

It is worth a try since it's all test mode

#

at least it'd confirm if that's the issue, can you try that one option quickly?

rain vortex
#

Yup, one second.

final scaffold
#

Something is still bugged here though so I'll have the product team investigate further too. I see the credit calculation and why, but t's just wrong, it looks at the wrong second or something

#

(also you don't need to pass end_date at all in that one

#

you can pass iterations: 1 instead

rain vortex
#

Yeah, no change there

#

The only thing that I see different between phase[0] before the schedule update, and phase[0] after the update is the prorate and proration_behavior fields.

final scaffold
#

yeah same

#

Try passing proration_behavior: 'none' top-level

rain vortex
#

bingo

final scaffold
#

cool so at least that unblocks you

#

but it really shouldn't be prorating

rain vortex
#

Yeah, sounds like this is probably exactly what we need.

#

Is there any way we can be notified once you find out more information from product about what we've been seeing?

final scaffold
#

I'll follow up in a bit if I find something

#

I'm pairing with someone and digging into the code :p

#

it's bothering me enough I won't let go 😂

rain vortex
#

haha I've been there!

#

Greatly appreciate your help.

#

I've spent probably 20 hours trying to figure this out with some of the other Stripe guys, so I really appreciate you hanging in there and helping me get to at least a temporary solution.

final scaffold
#

Sure! Schedules are a pain 😅

#

they are powerful but so hard for edge-cases

rain vortex
#

No doubt.

#

Oh, one more question. So we've likely got quite a few customers out there with pending invoice items from this situation. Is there any way to remove those pending items?

#

Can I do that with the API?

final scaffold
#

no better way unfortunately

#

And we couldn't figure out what's causing this unfortunately, so we'll have to dig further but will take a while to get to the bottom of it so won't be able to follow up here.
I'd recommend writing in to support https://support.stripe.com/contact and mention you talked to me and that it's a bug we're filing and they can follow up with you and keep you updated

rain vortex
#

Great, will do!

#

Okay I sent an email to support. Thanks again!