#Min.K

1 messages ยท Page 1 of 1 (latest)

torpid anchorBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

  • Min.K, 3 hours ago, 7 messages
  • Min.K, 5 hours ago, 3 messages
  • Min.K, 6 hours ago, 3 messages
  • Min.K, 23 hours ago, 21 messages
  • Min.K, 1 day ago, 4 messages
  • Min.K, 4 days ago, 4 messages
    and 4 more
devout belfry
#

๐Ÿ‘‹ happy to help

warm jasper
#

Hi

#

We know that we can't call the upcoming invoice API if the subscription's status is canceled.

However, if I schedule a cancel, I still get an error when I call the upcoming invoice API.

devout belfry
#

taking a look at the request please give me a minute, I'll get back to you

warm jasper
#

ok

devout belfry
warm jasper
#

@ใ……

#

@devout belfry
I know.

Background.

  • I'm calling the Upcoming Invoice API when I get the Subscription Update Completed webhook to tell the user what the next payment will be.

Therefore, I would like to know under what circumstances in a subscription I should not call the Upcoming Invoice API.

devout belfry
#

which event are you listening to?

#

customer.subscription.updated?

warm jasper
#

yes

devout belfry
#

when these values are set

cancel_at: 1702371399,
    cancel_at_period_end: true,
    canceled_at: 1701770944,
    cancellation_details: {
      comment: null,
      feedback: null,
      reason: "cancellation_requested"
    },
warm jasper
#

That's a lot, can I just check cancel_at?
Or should we check canceled_at as well?

devout belfry
#

the most important one is cancel_at

warm jasper
#

So, if i only need to check one, why not just check cancel_at?

devout belfry
#

if the cancel_at is not null and greater than current_period_end you could still have an upcoming invoice

warm jasper
#

So, if i only need to check one, why not just check cancel_at? Right?

devout belfry
#

you need to check cancel_at and compare it to current_period_end when it's not null

warm jasper
#

I want to make this clear.

Is that right ?

if (cancel_at != null && canceled_at <= current_period_end) {
// There are no upcoming invoices
} else {
// There are upcoming invoices exist
}

devout belfry
#

cancel_at not canceled_at

warm jasper
#

Sorry my mistake

devout belfry
#

no worries

warm jasper
#

I want to make this clear.

Is that right ?

if (cancel_at != null && cancel_at <= current_period_end) {
// There are no upcoming invoices
} else {
// There are upcoming invoices exist
}

devout belfry
#

yes

#

I think so

warm jasper
#

Thank you!

atomic agate
#

Hi! I'm taking over this thread.

#

To achieve this I would recommend to rely on the Invoice Upcoming endpoind:

  • If you call it and it returns an error, then you know there are no upcoming Invoices
  • If you call it and it returns an Invoice, then you know there will be an upcoming invoice
#

This feels like the more robust solution

warm jasper
#

Hi

#

I use the Upcoming Invoice API. However, I am getting an error when calling the API, so I am asking how to avoid this error.

atomic agate
#

You can call the endpoint in a try/catch, and handle the case when there's an error.

warm jasper
#
You can call the endpoint in a try/catch, and handle the case when there's an error.

But this is unclear.

If the error codes in the Stripe API were clearly defined so that it was clear that there were no upcoming invoices, it would be usable.

However, the Stripe API doesn't give a clear error code that there are no such upcoming invoices.

#

Oh, i find error code

#

invoice_upcoming_none

atomic agate
#

yes exactly, you can use that error code

warm jasper
#

Okay, I'll use this, but it's not very good.

#

@atomic agate
Hi, Would it be okay to use the method below?

if (cancel_at != null && cancel_at <= current_period_end) {
// There are no upcoming invoices
} else {
// There are upcoming invoices exist
}

atomic agate
#

I don't think this covers all possible cases. That's I recommend using the upcoming invoice endpoint. It will be more reliable.

warm jasper
#

Very good point.
Thank you!