#Gkiokan-subscription-invoice-on-update

1 messages Β· Page 1 of 1 (latest)

unborn geode
#

Hello πŸ‘‹
Give me a moment to read through this

#

can you share the example subscription ID that you're working with here?

limber jolt
#

Sure, gimme 1 sec

#

sub_1L5Sr0Ha5WPIKK5IE3P2qKox

#

You can see that the first subscription with quantity 1 is paid as expected. But if he changes the quantity (each quantity reflects one user license) it will calculated for the next invoice. This is correct per se but as I said, the problem is that we want to charge asap for the upgrade.

unborn geode
#

Can you walk me through the subscription creation and changes so that I'm on the same page?

limber jolt
#

I have it only in german but data is the same

#

Look at the Rechnungen part.
First subscription is paid at 31.05 for one quantity

But on the upper part with "anstehende Rechnungen" means upcomming invoice -> the user gets charged for the changed quantity in this case for 378 EUR

#

But as it says stripe will charge the customer next year at 31.05.2023

#

I can give you also the customer ID if you want?

#

Customer ID cus_Ln2wSKNNdbzysO

sand lynx
#

Hello, hanzo is a bit busy so I am checking in to this. Did you also set proratation_behavior => always_invoice when updating the subscription?

limber jolt
#

Yup

#

I can try to create a new cusotmer and go though the subscription process if you want

sand lynx
#

Gotcha. Do you have the request ID from when you made this request (req_123) from when you did that?

limber jolt
#

not right now as my tester did this some hours ago it should be associated with the customer (if they have a relation)

#

If you want I can create quickly a new customer account and make a clean new subscription. Gimme 3 minutes

sand lynx
#

Yes that would be helpful thank you

#

Still looking at the one you sent in the meantime

limber jolt
#

cus_LnC32n54AX2Lq2

#

new customer and just upgraded to a new tier

#

sub_1L5bfaHa5WPIKK5Ip2zg4RMU

#

this subscription is made with this params

             'proration_behavior'  => 
'always_invoice',
'metadata' => [
   'user_id' => $user->id,
   'org_id'  => $org->id,
   'tier'    => $r->tier,
              ]
```
#

You can see on the subscription object the upcomming invoice that is on due date 31.05.2023

#

lemme check meantime the link you send

#

Can you tell me how you filtered the request? I try to find the latest post request but can't see it

sand lynx
#

To be clear, that setting is per request, not per subscription. Even if you create the subscription with that proration behavior, you will want to set that on every subsequent subscription update request.

limber jolt
#

Ouh that could be a needle. I actually run only the updateQuantity request

#

Lemme check if I can update that value on the update qt piece, too

sand lynx
limber jolt
#

Ah there. Okay good to know. I searched it in the developer logs

sand lynx
#

You can also do that, you can specify an "API Endpoint" filter of /v1/subscriptions/sub_12345 to see all updates to specifically sub_12345

limber jolt
#

On the docs for update a subscription it says invoice the customer to collect payment.

I guess that would result in the same thing?

sand lynx
#

Which section of our docs is that?

#

From my understanding create_prorations will only create invoice items, so I think that that "invoice the customer" link is trying to tell you to create a new invoice after making that call

limber jolt
sand lynx
#

always_invoice is the proration behavior that creates the items and creates the invoice

#

Thank you, I was looking somewhere slightly different

limber jolt
#

I think the result is the same on both ?

sand lynx
#

The proration_behavior section clarifies this a bit better https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior

Determines how to handle prorations when the billing cycle changes (e.g., when switching plans, resetting billing_cycle_anchor=now, or starting a trial), or if an item’s quantity changes. Valid values are create_prorations, none, or always_invoice.
Passing create_prorations will cause proration invoice items to be created when applicable. These proration items will only be invoiced immediately under certain conditions. In order to always invoice immediately for prorations, pass always_invoice.

Prorations can be disabled by passing none.

limber jolt
#

I see. Yea it makes it clear that the invoice will be generated automatically when create_prorotations is always_invoice

#

But that prorations is confusing a bit. I think technically this is correct but for the customer as he pays "license per user" this is maybe a wrong approach for me?

#

Should I add prices instead of upgrading the quantity of the product?

#

There is also another Problem if I use the always_invoice options.

My app is a facility management with employees (each employee must have a license).

If the company adds 2 users, he will get 2 invoices then.

If he need to add 15 users, 1 user per request, he will get 15 invoices. Like create user -> update quantity -> invoice -> add another user -> update quantity -> another invoice -> and so on

#

All of them with the proration of the "old" invoice. Results in a bit messy InvoiceItems list. What would you suggest?

sand lynx
#

If the quantity here actually relates to the number of seats related to this subscription, I think it still makes sense to keep this as one price but changing the quantity. If you make this a bunch of different prices, they will still have a lot of proration line items, the only thing that that would change is what the line items specifically say

limber jolt
#

Maybe if I have each user license as seperate price and use no proration this could be cleaner

sand lynx
#

If you do send out one invoice per update, I think each invoice should only have the two line items per invoice. Are you seeing them with more now that you have changed to using always_invoice?

limber jolt
#

I actually used the first method I found with the "invocie customer" instead of the always_invoice prop. I couldn't set it as quick as I thought (using laravel cashier overlay and the update Quantity method was already there)

#

But actually no, see that last screenshot. That happend when I update each user. So it creates a prorotation line + a new line for the current period*

sand lynx
#

Is that a Laravel related UI? Unfortunately I am unfamiliar with it

limber jolt
#

Nah Laravel Cashier. It is a SDK wrapper for Stripe but I can use also the Stripe SDK directly with it. The UI is custom made for my dashboard of the customer.

#

that view actually just renders the /invoices list

sand lynx
#

Gotcha. So I think that that screenshot is a result of create_prorations being used instead of always_invoice, it might be worth checking with Laravel to see if you can pass in always_invoice here somehow or if you can just create an invoice for those items to go on to after updating your subscription.

limber jolt
#

See here. I downgraded from 4 licenes to 3 licenses and then from 3 to 2. I get 2 invoices with proroation items

limber jolt
#

So I have only thoose 2 options but in both cases when a prorotation does exist it will create that additional used blabla item + remaining blabla item

#

If I add a price instead, would that be like

position 1 started 31.05
position 2 started 01.06
etc.?

sand lynx
#

It would still be a similar format, would just say something like

Unused time 1x Price A
Remaining time 1x Price B

#

I don't think there is a way to clean it up past that at the moment even if you are invoicing per update.

limber jolt
#

You are right. It doesn't matter if I downgrade or upgrade. In both cases I get 2 Invoice Item lines

#

Puuh that is more complicatd then I thing.

#

There is no other way right now. I will call it a day for now and tackle this with a clear mind tomorrow.

#

And try that option that you suggested earlier

#

I just noticed when I use to invoice the customer, the payment stays still as unpaid

sand lynx
#

Sounds good. Yeah, unfortunately I think this will need to be two line items one way or another.

#

Which payment is staying as unpaid?

limber jolt
#

the last invoice items that I have generated for the customer after updated Quantity. Offen means invoice.paid == false

#

Maybe I can do something completely different

#

I could start a custom subscription per user itself instead for the customer. Multiple subscriptions are possible and each of them would be for one user per each. But then again I will have x times user invoices per customer

sand lynx
#

Do you have a default payment method set up for this Customer? How are these invoices typically paid?

limber jolt
#

Yes. When the customer selects a tier, I save the paymentMethod as default payment and can swap around do whatever I want with the subscriptions*

sand lynx
#

If you have the ID of one of those invoices, I can check in to why it wasn't paid. But we can also pause if you want to look in to that tomorrow as well

limber jolt
#

cus_LnC32n54AX2Lq2

#

This is the customer I was testing right now

#

you can see the last invoices are on draft actually

#

I had just the same Idea to check why they are on draft

#

here is an example invoice in_1L5cNFHa5WPIKK5ItJn5a65x

#

Doesn't this charge the customer automatically on the changed items ?

#

The invoice says something like draft invoice created

sand lynx
limber jolt
sand lynx
limber jolt
#

When I use auto_advance it have a due date 1 hour later lol

#

But I think in general it works now. At least that issue is fixed

#

Yea well. Let's call it a day. My Brain is like a china soup. Was trying to fix that workflow for the whole day now. I need to find another "clean" solution.

#

Thank you for your help, it directed me to the correct way at least to get it working as I thought it may will.