Gkiokan-prorations

[lost vale]

Hi 👋 if you use cancel_at_period_end then you can configure the subscription to cancel at the end of the current period instead of renewing. If you want to then allow your customer to subscribe again, you'll need to create a new subscription.

@frozen arrow and @whole hamlet just want to flag that I created a thread for this topic.

[whole hamlet]

Did you check if you can set a period start time? You could set it if possible or make it the other way around save the subscription in your backend and subscribe when the current period ends (as a workaround)

[frozen arrow]

actually, I saved it in DB for start_period and end_period

@lost vale we can use the same stripe customer object for create new subscription right?

[whole hamlet]

yea you can

What backend are you using?

I solved it to save the first paymentMethod as the defaultPaymentMethod.

After that you can swap and do whatever you want with the subscription

If the user want another subscription or changes his prices or tier you can make a new subscription based on that for the user with the saved defaultPaymentMethod. I do the same and it works but in your case you just have to watch for the period_end time I guess and trigger the subscription

[lost vale]

To confirm, yes you can reuse existing Customer objects.

[whole hamlet]

@lost vale can I ask you to check this subscription?

sub_1L5Sr0Ha5WPIKK5IE3P2qKox

From the invoices api I get the invoice (in_1L5SzoHa5WPIKK5IrXbfIXjV) as paid. But on the upcomming for the customer (cus_Ln2wSKNNdbzysO) invoice it is listed as unsued for the paid period but still get calculated to the upcomming invoice

Here is a rendered screenshot of the invoices response for the customer

[frozen arrow]

NodeJS & Mongodb

Thank you so much everyone

Let me implement it first

[lost vale]

@whole hamlet apologies, will take a look in a moment.

Looking at that subscription, it looks like there was an update that triggered the creation of the invoice that you referenced. Then, a couple minutes later, another update was made with prorations, but that update didn't immediately create a new invoice so the proration calculations are going to be on the upcoming invoice.

[whole hamlet]

Can I trigger an invoice after the quantity has been changed?

[whole hamlet]

np mate, yw gl on your implementation

[lost vale]

If you set proration_behavior to always_invoice when updating a subscription then any update will trigger the creation of a new invoice.

[whole hamlet]

Quantity will be updated as the users order a new user license on their subscription tier. (I use quantity to determine the use per seat feature)

[whole hamlet]

So it won't get into the "upcomming invoice"? Lemme try that

[lost vale]

Gkiokan-prorations

[whole hamlet]

Still let's me the question why the invoices api gives me a postive amount for the "unsued" time as you can see on the screenshot (first card with first item)

shouldn#t that amound be a negative number then?

because this period is paid on a invoice before

[lost vale]

I'm not sure why that number isn't displayed as a negative amount, but looking at the subtotal it does appear to be getting subtracted rather than added.

[whole hamlet]

The updated quantity is from 1 to 2 so the total subtotal should be 378

[lost vale]

No, because it will include the prorated price in addition to the price for the next billing period.

So that's 378 for the next billing period + 378 for the new amount for this period - 189 for the credit for the unused time paid on the previous invoice.

[whole hamlet]

Aaaah I see okay the upcomming invoice shows the items for the next year (2022-2023) and (2023-2034) yea you are right.

I need to figure out why the first unsued item is not shown as negative.

Is it possible to limit the upcomming invoie to the next payment interval instead of the next + next one?

in case of the screenshot only for 2022-2023 without 2023-2024

[lost vale]

Retrieving the upcoming invoice is already limited to only the next invoice. Our subscriptions always bill at the beginning of the new billing period, and the default behavior for prorations is that they are added to the next invoice, which is why the next invoice is containing both the cost of the next period and the prorations. You would need to step through the lines of the invoice to see which ones are part of a proration, and which one corresponds to the next billing period.

[whole hamlet]

I see