#aileen-sub-pending-updates

1 messages ยท Page 1 of 1 (latest)

thick gust
earnest yew
#

It's this one req_LO1kToXTRne6ZK

thick gust
#

Thanks, taking a look

earnest yew
#

How would this work as a pending update usage? Wouldn't that mean that I delete the item for good, no matter the pending update outcome?

thick gust
#

Right, got it. Oversight on my part. Looking at this some more

earnest yew
#

I just had a go and tried with setting the quantity to 0, which seem to work but it's not an ideal solution imo. (see req_3oXdfcABv2KhpJ)

thick gust
#

Got it, how is that reflected on the resulting Invoice?

earnest yew
#

It's just being prorated. If there's no other way, I'd imagine to actually delete the item once the pending update is applied. But it's a weird workaround. Deleting the item just like it's possible when receiving upcoming invoices or updating the subscription with other payment behaviours would be much better.

#

The idea of pending updates is great and would be fantastic for our use case, but that workaround seems a bit dodgy.... ๐Ÿค”

#

Got it, how is that reflected on the resulting Invoice?
Just saw that it also created a pending invoice item, which we want to avoid as well.

thick gust
#

The only immediate solution I can think of is to update the subscription as you have (quantity: 0) and then delete the item following the successful pending update

#

Let me check and see if there's a better solution

#

To be clear, do you want the deleted items to be prorated on the resulting invoice?

earnest yew
#

Yes, that is correct

#

It e. g. applies to adding and removing additional add ons to products. And in general we use proration for all changes

thick gust
#

i.e the item where you set quantity: 0 has gone

earnest yew
thick gust
#

Is it though? In your call your set the item to update to price_1Jk8beF2yKngx0eUblOPiKW4, which is the only Price object on the result Invoice object

earnest yew
thick gust
#

Well there is proration there, no?

#

For the one where the quantity was set to 0

#

I realise it's not deleted, but at least the proration is working as needed

earnest yew
#

That's true. Well, I think the only way forward is either that Stripe allows the deletion of subscription items when using pending updates, or we have to use the workaround of using quantity and deleting after the pending update got applied. Would be cool if you could communicate this use case internally. Maybe it'll be changed someday ๐Ÿ˜Š
Thanks for your help!

thick gust
#

Let me check to see if there's another way

thick gust
#

Thanks for your patience here. This is indeed not supported currently.

#

One other potential workaround is just to omit the subscription item that you want to delete from the update call

#

However that is heavily reliant on the ordering of the subscription items array

#

i.e. it only really works if you're deleting and switching the price of an existing item

earnest yew
#

Yeah, that's another approach. But that will fail when the subscription update also includes a billing cycle update, afaik

#

e. g. can't have one sub item with a monthly recurring and the other one is yearly

#

which is one of the main reasons why we have to use delete

thick gust
earnest yew
#

catch-22 ๐Ÿ˜†