#Gkiokan-subscription-invoice-on-update
1 messages Β· Page 1 of 1 (latest)
Hello π
Give me a moment to read through this
can you share the example subscription ID that you're working with here?
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.
Can you walk me through the subscription creation and changes so that I'm on the same page?
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
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?
Yup
I can try to create a new cusotmer and go though the subscription process if you want
Gotcha. Do you have the request ID from when you made this request (req_123) from when you did that?
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
Yes that would be helpful thank you
Still looking at the one you sent in the meantime
Actually, I found the API request that updating this subscription and it uses "proration_behavior": "create_prorations" https://dashboard.stripe.com/test/logs/req_tcngGmdDcp1YzG
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
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
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.
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
Your subscription's page on the dashboard has a "Logs" section at the bottom of its page https://dashboard.stripe.com/test/subscriptions/sub_1L5Sr0Ha5WPIKK5IE3P2qKox
Ah there. Okay good to know. I searched it in the developer logs
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
On the docs for update a subscription it says invoice the customer to collect payment.
I guess that would result in the same thing?
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
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
always_invoice is the proration behavior that creates the items and creates the invoice
Thank you, I was looking somewhere slightly different
I think the result is the same on both ?
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, oralways_invoice.
Passingcreate_prorationswill 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, passalways_invoice.Prorations can be disabled by passing none.
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
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?
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
Maybe if I have each user license as seperate price and use no proration this could be cleaner
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?
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*
Is that a Laravel related UI? Unfortunately I am unfamiliar with it
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
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.
See here. I downgraded from 4 licenes to 3 licenses and then from 3 to 2. I get 2 invoices with proroation items
Yea I will give that a shot now.
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.?
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.
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
Sounds good. Yeah, unfortunately I think this will need to be two line items one way or another.
Which payment is staying as unpaid?
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
Do you have a default payment method set up for this Customer? How are these invoices typically paid?
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*
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
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
You will want to set auto_advance to true when creating the invoice yourself https://stripe.com/docs/api/invoices/object#invoice_object-auto_advance
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
which references to this here. But it says collection_method is carge_automatically by default
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
lemme check
Or otherwise make the call to finalize those invoices https://stripe.com/docs/api/invoices/finalize
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
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.