#Miguel Cruz

1 messages · Page 1 of 1 (latest)

tough thunderBOT
grave tree
#

Hi 👋

We don't have a published formula for how to calculate prorations. Our best option is to pass the potential changes to the subscription to the Upcoming Invoices API and display the results.

thin thunder
#

I understand that using the Upcoming Invoices API is the recommended approach for calculating prorations. However, it is important for our customers to have visibility into the calculation process and understand the details of how the prorated price is determined. Is there any way we can display this information to the customer, so that it doesn't remain a mystery and they can see the breakdown of the calculations that led to the final amount? It's essential for us to provide transparency and ensure our customers have a clear understanding of the pricing changes.

grave tree
#

As I said, we don't have a formula I can share with you. There are some odd details when you add in discounts on prorations that get very strange.

#

The basic approach is that we don't calculate a difference and charge/credit the difference.

#

In the event a customer changes a price, we refund the remaining time on the old price and charge the remaining time on the new price.

#

But that does not take into account other changes

thin thunder
#

Ok I get you, sorry for the questions jaja, btw could you please clarify which specific changes are not accounted for in the basic approach? I want to ensure that we have a comprehensive understanding of the limitations and any potential scenarios that may not be covered.

#

If it is possible that share, if not no problem

tough thunderBOT
thin thunder
#

Or I would like to inquire if there is a way to adjust the infrastructure in Stripe to calculate prorations based on full days instead of hours or fractions of days. This would simplify the calculation process. Are there any configuration options available in the subscription settings that allow for billing solely on complete days? I understand that this might impact the precision of prorations in certain cases, but I would appreciate any guidance or insights on how to adapt the infrastructure to accommodate this requirement.

coarse plaza
#

Hello! I'm taking over and catching up...

#

Correct me if I'm wrong, but I think we talked about this before, right?

thin thunder
#

Yes

#

That's correct

coarse plaza
#

Why are you coming back and asking the same question multiple times?

thin thunder
#

I want to know "the odd details" that impact in the result of prorate

coarse plaza
#

As I told you before, it's not possible to know every single detail of this. That's why the upcoming Invoice API exists.

#

To accurately replicate every single nuance and get 100% accuraccy you would need to have a copy of our internal code on your side.

thin thunder
#

Ok no problem, but are there a way to chage this in infraestructure

#

?

#

Is there a way to change the billing system to charge on a per-day basis instead of calculating prorations based on hours or fractions of a day? I'm curious if it's possible to modify the billing infrastructure to simplify the calculation process and bill customers for complete days only.

coarse plaza
#

No, it's not. You can work around that by scheduling changes to happen on day boundaries you specify with Subscirption Schedules though.