#draesia.
1 messages · Page 1 of 1 (latest)
For a subscription invoice, you mean?
Instead of trying to modify the invoice, you should update the quantity on the subscription item
Yes for a subscription invoice
Can you share an example invoice ID you're trying to modify?
in_1NwDAzHB8baf644Pr03OCdvT
There is an issue i'm currently trying to fix with our software, it seems we're not updating it correctly. It would be most ideal to update it on invoice.created, however I wasn't quite sure if I'm supposed to edit the invoice item, the plan, or the subscription item.
If I just do
SubscriptionItem::update($subscription_item->id, [
'quantity' => $quantity,
before I finalize the invoice, should that work?
I wasn't sure if updating the subscription item, after the invoice has already been created, would do much
No you need to update that before the invoice is generated, if you want to have it include the change
with or without prorations, at your discretion
The issue is that right now we do that on invoice.upcoming, however the few days delay can often cause issues in pricing.
(also does invoice.upcoming fire when the trial ends and is charged for first time? Or do you have to use trial_ending ? )
The API docs mention that the invoice is fully editable after it's created, so does this mean we just have to update the plan/price/subscription item itself before we finalize?
Hi taking over here
Can you tell us a bit about your integration and how everything works
What your product is, etc
Just need to know your usecase for updating quantity on invoice creation
If we understand exactly what your product, integration, etc is then we can provide a better recommendation
I just did a quick test with the following and it seemed to work ok:
$stripe->invoiceItems->update($ii->id, ['quantity' => 10], ['stripe_account' => 'acct_xxxx']);
Essentially this is an edge case in our platform where users are paying for an amount of lessons at the start of each month. However the amount of lessons could change up until the invoice is created.
Any changes to number of lessons into that period after invoice creation takes extra payments / refunds
But given the delay that we had between invoice.upcoming and the money being taken, it caused some issues among other things.
We are planning to change the whole system to be more consistent as we are aware that it was poorly implemented to begin with; however, right now we need to fix it using the architecture we have.
I see ok
Well glad the above worked
When you do change the whole system, I recommend looking into usage based pricing: https://stripe.com/docs/products-prices/pricing-models#usage-based-pricing
We are considering just handling the subscriptions ourselves and using mandates to create the payment intents manually.