#nick-metered-upcoming

1 messages · Page 1 of 1 (latest)

tulip juniper
#

I would expect the same, that the upcoming invoice returns $0

last solar
#

Trying to GET from the Stripe API returns error along the lines of:

InvalidRequestError(message='No upcoming invoices for customer: cus_L2Fwu0fveVbMKt', param=None, code='invoice_upcoming_none', http_status=404, request_id='req_gLMjQVEpvXfPUu')
stripe.error.InvalidRequestError: Request req_gLMjQVEpvXfPUu: No upcoming invoices for customer: cus_L2Fwu0fveVbMKt
tulip juniper
#

so sorry I completely missed you reply, looking

#

that subscription is marked to cancel at the end of the current period, so there won't be a new invoice right @last solar ?

last solar
#

Theoretically, unless they add a credit card, at which point we will wipe the cancel_at_period_end parameter

#

But wouldn't a metered subscription still need the upcoming invoice, to charge at the time it cancels?

#

Like basically just because you set the subscription to cancel doesn't necessarily mean there won't be any further usage accrued until the time of cancellation... So would reporting said usage bring the upcoming invoice back?

tulip juniper
#

Hmmm that's a good point. Does the upcoming invoice work if you add usage records?

last solar
#

Testing right now

#

Hmmmm, it doesn't create the upcoming invoice

crystal prairie
#

Does it change the result of the GET request from the upcoming invoice API?

last solar
#

Trying that now

# 
stripe invoices upcoming --customer cus_L8Lqq3tvIojlbG --subscription sub_1KS59hI67GP2qpb4GlM0OZKY
{
  "error": {
    "code": "invoice_upcoming_none",
    "doc_url": "https://stripe.com/docs/error-codes/invoice-upcoming-none",
    "message": "No upcoming invoices for customer: cus_L8Lqq3tvIojlbG",
    "type": "invalid_request_error"
  }
}
#

So no, AFAICT

crystal prairie
#

Interesting, alright. Let me spin up my own reproduction of this.

last solar
#

I'm going to wipe the cancel_at_period_end to see if that brings back the invoice

#

Yeah so when I ran stripe subscriptions update sub_1KS59hI67GP2qpb4GlM0OZKY -d "cancel_at_period_end"=false and refreshed the dashboard, the upcoming invoice exists now

#

And then setting cancel_at_period_end back to true, the upcoming invoice remains...

crystal prairie
#

I suspect it only considers the renewal invoice, and not the final invoice added for clearing out accrued metered usage

last solar
#

renewal invoice being what was generated when I "un-canceled" it?

#

This "bug" (for lack of a better term rn) makes me think Stripe is handling this subscription like a licensed one, where it's paid up front, so Stripe determines that there's no need for an upcoming invoice since the period has been paid for and it's canceling the sub at the end of the period

#

OH, it's probably worth mentioning that these subscriptions that are having this issue were at one point in time a licensed subscription. They've been converted to a metered one - but like I said earlier, I converted around 8500 subscriptions from licensed to metered, and only around 210 had this issue

crystal prairie
#

Interesting, this is not happening with all such subscriptions?

last solar
#

Which kind of fits my hunch of Stripe still treating it as a licensed invoice I think?

crystal prairie
#

@last solar earlier you mentioned specifically cancel_at_period_end but in my testing that didnt cause any issue

#

I was able to reproduce this with an explicit cancel_at prior to the end of the period

last solar
#

Yeah sorry I kind of use them interchangeably:
When the trial expires, we set the subscription to cancel 14 days after the expiry utilizing the cancel_at parameter, since the period end may not be 14 days away. (therefore you have a 14 day trial, and then we lock your access to the product - but keep their data around for 14 days in case they add a credit card)
If they add a credit card, we un-set the cancel_at time - only way to do that with the API is by passing cancel_at_period_end=false, since the API doesn't accept null or 0 for updating the cancel_at time

#

So for the subscriptions you're looking at, they're in the state of trial expired, cancel_at time was set explicitly to 14 days in the future, and we're just waiting for them to either add their card or for the subscription to cancel

crystal prairie
#

You should be able to send an empty string to clear cancel_at

#

I just tested this to confirm

last solar
#

Ah, didn't try that way back when I built the lifecycle. Good tip.

crystal prairie
#

(but that's unrelated to the bug)

last solar
#

I've been thinking about this and I'm pretty sure I can make it work as-is. If the customer doesn't have a credit card, we won't be able to bill them anyways so no point in trying to invoice them. Since cancel_at_period_end=false brings back the upcoming invoice, we'll just keep doing that when they add the card and we can bill accordingly from that point

#

Also, I don't expect this migration to have to ever happen again so as these cancel out, the problem will fade away

#

But definitely some weird behaviour. Hopefully I didn't send you deep down the rabbit hole on a Friday at 4 lol

crystal prairie
#

I'm writing this up to file the bug, and in my testing I'm finding the upcoming invoice works as intended with cancel_at_period_end=true so you might be able to switch to that to keep the pending cancellation in place

crystal prairie
#

@last solar Do you want to email in and mentioned my username so I can keep in touch that way while we work on this?

last solar
#

Yeah I can do that

#

Where do I send the email

unique pulsar
last solar
#

Great. I'll send it over soon

#

Do you need me to provide any context in the email? Or will your bug report include everything?

unique pulsar
#

We have all the information on our end so no need to rewrite all the context

last solar
#

Awesome. Sent it off. Thanks all!

crystal prairie
#

Got it, thanks!