#nukesforbreakfast_subscription-credits-prorations
vivid larkBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1415470704689811580
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- rcc_schedule-update, 2 hours ago, 84 messages
- nukesforbreakfast_api, 15 hours ago, 33 messages
- nukesforbreakfast_best-practices, 19 hours ago, 30 messages
- nukesforbreakfast_api, 5 days ago, 11 messages
blazing sand
Hi 👋
This sounds like expected behavior to me.
Do you have the example Subscripton IDs
blazing sand
And have you reviewed this doc?
Also, why arey ou creating Subscription Schedules if you aren't using phases to schedule changes but instead attempting to change the existing phase?
brave locust
And have you reviewed [this doc](<https://docs.stripe.com/billing/subscriptions/...
I have reviewed the doc
brave locust
Also, why arey ou creating Subscription Schedules if you aren't using phases to ...
Because I can't use the subscription schedule's API to backdate a proration on a phase.
but based on this kind of thing I'm thinking it's better to manually issue credit notes for this case.
blazing sand
Okay so which specific request are you referring to here? You are explicitly passing proration_behavior: "create_prorations", for each update so we would just create prorations for any changes you make to the existing phase
brave locust
let me get the request ID
blazing sand
Can you step back and tell me what you are trying to achieve from the Customer's perspective?
brave locust
req_q9LpEUbIv8Rj1k
yes, one second
So, here's the scenario:
I have a concept of a permit fee that renews annually at a lower rate than the initial permit fee cost. Let's assume this is a Commercial permit fee of $50 for the first year and $25 every year thereafter. There is also a Residential permit fee of $25 and $15 every year thereafter.
Now assume that the administrator sets this up based on a permit application received, but accidentally selects "Commercial" when it should have been "Residential". Say a month goes by before someone recognizes the mistake. I now need to update both phases to use the lower price and credit the permit holder for the difference.
Since updating the phases would cause an incorrect proration on the current active phase, I have to do one of the following:
- Update both phases but turn off prorations. Then credit the user manually outside of stripe automatic prorations.
- Update only the second phase to the correct price, but leave the first phase unchanged. Then use the subscriptions API to backdate the proration to the lower price while it is still attached to the schedule, getting the schedule and the subscription out of sync on the first phase. I believe the second phase transition will still happen normally.
I'm not sure of the full implications of the second option. I'm actively testing this in my sandbox today.
blazing sand
Oof and then you are trying to modify the Subscription Item in place while the Subscription is controlled by a Schedule? That's a bad pattern
brave locust
I was testing the case where the end user has not yet paid for the subscription invoice to see Stripe's behavior on the proration.
brave locust
Oof and then you are trying to modify the Subscription Item in place while the S...
yes I know, but I asked about adding a feature request for specifying proration_date on a subscription schedule update, but was told that wasn't going to happen.
blazing sand
So you are refunding the Customer for their mistake?
brave locust
Our mistake, but I was planning on crediting them the amount overpaid so they reduce future invoices.
So either a credit note or negative invoice item.
blazing sand
Ah, okay. A credit note is probably the most straight-forward here. It's more declarative, since the very type of object implies you are offering a credit for something.
brave locust
yes, and since other one off invoices for accrued fines during the life of the permit may be interspersed between the subscription invoices, a credit note probably works better given it can add to the customer's credit balance to apply to future invoices.
blazing sand
But I don't think this situation matches well with our proration calculations. Since we assume the price you initially set was the correct amount to charge and you are updating to relfect the rest of the billing cycle
brave locust
got it, so it's built more for someone changing their mind mid cycle and upgrading/downgrading.
blazing sand
Yup
brave locust
versus using it to resolve an error.
blazing sand
Yeah resolving errors is more what credit notes are designed for
blazing sand
Great 🎉 Happy to help 🙂
vivid larkBOT
brave locust
is there a way to find all invoices and/or invoice items generated by a subscription?
nevermind, I think this is it: https://docs.stripe.com/api/invoices/list#list_invoices-subscription
blazing sand
Yup, there you go.