#kazsla
1 messages ยท Page 1 of 1 (latest)
Hello ๐
Can you share the example subscription you're working with and what response you get with the Upcoming invoice API when you have a trial/don't have a trial?
sure give me one min
This is for non trial subscription
customer - cus_OP0AcewKfsAKLp
subscription - sub_1NcCBLGsLQTSpl5GM9bRXcjm
and this is for trial subscription
customer - cus_OOzrmOYIVIydhs
subscription - sub_1NcC5RGsLQTSpl5G1qSSRgtQ
Thanks, server is a bit busy so need a few minutes to look into it.
Appreciate your patience
No problem thanks for your time
Hey there sorry for the delay here
Stepping in to give hanzo a hand
Can you clarify, this addon product, is it one-time or also a recurring product/serivce?
It's a recurring product
So the main issue here is that the trialing status applies to the entire subscription, it doesnt operate per item
So we have to address what you'd expect to happen to the other subscription item when this addon is added
Let me make sure I understand the scenario correctly, too:
1/ User subscribes to Base Plan for say $50/mo on Aug 1, and its on trial until Sept 1 renewal
2/ User has options to add Extra Plan addon for another $20/mo, and is evaluating it on say Aug 15 (mid cycle)
3/ You want to be able to get a proration that shows what? $10 for half the addon? 35$ fr half the addon + half the base plan?
I'm not clear on the result you want/expect for the previewed proration
Are 1 & 2 correct understandings of your case or is it something different?
1-2 are right on the case and yes on 3 on getting $10 for half the addon in the middle of the month
We're using the add_invoice_item to add the initial invoice item due to the trialing being on the whole subscription but this would be the flat $20.
We're thinking about manually handling the prorated invoice through add_invoice_item ourself through the one-time stripe product.
We just want to check if through the upcoming invoice api if we could also get the prorated amount and create an invoice manually that way
No as long as the subscription is on trial, the mount would end up being 0
What you could do instead is use upcoming invoice without the existing subscription, providing the same customer and just the add on subscription item with suitable parameters to get the prorated amount, then add it yourself as you say
Other alternatives would be replacing the base plan trial with a "free" ($0/mo) equivalent, then adding the addon would work as a normal proration
but you'd need to manage swapping that free base plan out for the paid version for the next billing cycle, perhaps using a subscription schedule
I think I have tried the upcoming invoice for the customer without the trial subscription set but it stills comes back as the full $20. Did try with setting subscription_billing_cycle_anchor and other params but doesn't seem to be go on that one also
the last alternative i can think of would be ending the trial, but applying a one-time discount via coupon for the base plan prorated amount to the end of the cycle
Can you share the upcoming invoice request params you used for that add-on only pattern to get the prorated amount to the end of the current cycle?
curl --location --globoff 'https://api.stripe.com//v1/invoices/upcoming?customer=cus_OP0AcewKfsAKLp&subscription=sub_1NcCBLGsLQTSpl5GM9bRXcjm&subscription_items[0][price]=price_1N6aZJGsLQTSpl5G0f3DDzym&subscription_proration_behavior=always_invoice' \
This is again for the customer with a non trial subscription (in a test clock advanced a week)
On the alternative if we handled this through add_invoice_item .
We could create an inline Price object for the invoice and set the unit amount to something like baseprice * (days remaining / sub billing cycle end)
Would the inline Prices be re-usable or would there be any issues in doing this (I.e. too many StripePrices for a StripeProduct / Duplicate Stripe Price for unit amount) ?
This is including the subscription=sub_1NcCBLGsLQTSpl5GM9bRXcjm though, for a non trial based on what you say. What did you try for this in the trial scenario without the subscription? You mentioned above you did and were getting the full add on amount instead of the proration you expected.
Yep, you can do that with your own proration, and honestly might be the simplest solution here
Would the inline Prices be re-usable or would there be any issues in doing this (I.e. too many StripePrices for a StripeProduct / Duplicate Stripe Price for unit amount) ?
If you mean usingprice_datathose are automatically archived so not re-usable, but there's no issue creating "too many" prices this way
There's no operational limit to how many prices/products you can have
(beyond eg, API rate limits creating them)
This would be for the customer with just the trial subscription but not passing in the trial subscription
curl --location --globoff 'https://api.stripe.com//v1/invoices/upcoming?customer=cus_OOzrmOYIVIydhs&subscription_items[0][price]=price_1N6aZJGsLQTSpl5G0f3DDzym&subscription_proration_behavior=always_invoice' \
Ok, yea, so no part of that is indicating any period to use for the proration, it's just going to create a new subscription starting ~now and it would be the full amount
Setting the subscription_billing_cycle_anchor to match the renewal of the existing subscription should allow you to inspect the prorated amount
https://stripe.com/docs/api/invoices/upcoming?lang=curl#upcoming_invoice-subscription_billing_cycle_anchor
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Got it. Sounds like doing setting the subscription_start_date and subscription_billing_cycle_anchor appropriately would be a way to get the prorated invoice amount from Stripe.
I tried this out for this subscription that is a week in
For the example below:
- start date to the subscription current period start
- billing_cycle_anchor to a date after the start date
curl --location --globoff 'https://api.stripe.com//v1/invoices/upcoming?customer=cus_OOzrmOYIVIydhs&subscription_items[0][price]=price_1N6aZJGsLQTSpl5G0f3DDzym&subscription_proration_behavior=always_invoice&subscription_start_date=1691373132&subscription_billing_cycle_anchor=1693180800' \
Assuming to you want to preview the proration from ~now the start date shouldn't be necessary, but for another date (backdating or a future change) then yea you can use that
I'd use the context of the start being when the prorated item is added and the cycle anchor being the existing sub period end (renewal) but you can use whatever gets the value you're looking for
That makes sense and sounds right. I just was editing my comment to make sure I didn't give the wrong formula to anyone that had the same issue in the future
I did try your suggestion out and the proration does look to be right as well
I think this puts us in a great place for our use case scenario.
Thanks for all the time, help, and suggestions to help us figure out some answers