#kazsla

1 messages ยท Page 1 of 1 (latest)

torpid burrowBOT
frigid cipher
#

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?

golden cloud
#

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

frigid cipher
#

Thanks, server is a bit busy so need a few minutes to look into it.

#

Appreciate your patience

golden cloud
#

No problem thanks for your time

white coral
#

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?

golden cloud
#

It's a recurring product

white coral
#

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?

golden cloud
#

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

white coral
#

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

golden cloud
#

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

white coral
#

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?

golden cloud
#
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) ?

white coral
white coral
# golden cloud On the alternative if we handled this through `add_invoice_item` . We could cre...

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 using price_data those 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)

torpid burrowBOT
golden cloud
#

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' \
white coral
#

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

golden cloud
#

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' \
white coral
#

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

golden cloud
#

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