#captainyarb - deleting items
hidden jackal
Hello! Just starting a thread for you -- I'll review and respond as soon as I can 🙂
supple steeple
Yay! Thanks for your help!
supple steeple
Sure: req_mlcHSsejZxNCHJ
This request is removing all of the items from si_Lq6PtGPSFnRs8Q and adding 8 for price price_0J5cdXF23R9jbzPTp7fSqC2a
Our use case is: addon quantities. We removed all of one quantity and added 8 of another
hidden jackal
Hmmm can you try a workaround
supple steeple
Apparently setting quantity: 0 works, but leaves the subscription item... with 0 quantity.
hidden jackal
instead of using deleted=true set the quantity=0 during the invoices proration
yea
supple steeple
haha great minds think alike
hidden jackal
that's what i was going to suggest
then, once the invoice succeeds/pays, you can do a second request to delete the item
(with no payment impact)
so you can omit the pending if incomplete
supple steeple
uuuuugghhh
hidden jackal
is the issue he pending if incomplete or the always invoice?
supple steeple
I'm not 100%, but as I undestand it we need both for our use case.
We need payment_behavior: 'pending_if_incomplete', so that the user must pay first before changes take effect.
We need proration_behavior: 'always_invoice', to ensure the user gets credit for time unused and invoiced for expenses on the change.
Is my assumption wrong here?
Also, this is 9 API requests in one userland request. We're going to run into API limits T_T
#1 get Customer (to validate user session context)
#2 get Subscription (to validate user ownership of session)
#3 get Products (to validate seleceted plan pricing_ids)
#4 update Subscription #1 (to change quantity and prorate)
#5 update Subscription #2 (to delete quantity 0)
extended: if customer has a scheduled change:
#6 get Subscription Schedule
#7 release Subscription Schedule
#8 create new Subscription Schedule
#9 update new Subscription Schedule with reflected changes
We have promotional deals where users can buy 3 months for the price of 2, where we put them back on a monthy subscription afterwards. We noticed that updating the Subscription required us to rebuild that change to reflect the new updates.
hidden jackal
Let me review
supple steeple
we're going to move it to the webhook, but that's about best we have
hidden jackal
You can consolidate 1+2+3 with expansion:
https://stripe.com/docs/api/expanding_objects
ie, request the subscriptions included for that customer retrieval
and yes 6-9 re complex due to your use of schedules, which is a complex use cae
but that doesnt have the same invoicing proration/pending effects
so its different complexity
supple steeple
1 & 2, yes we plan to try to reduce this down to 1. #3 is required to get the full list of plans they are also switching to as they have limits defined on metadata for quantity and plan requirements.
#3 will be cached on our end as much as possible anyway 🙂
hidden jackal
OK then yes, this will involve a number of requests to cover those cases