#Coherence-Billing

1 messages · Page 1 of 1 (latest)

languid zodiac
acoustic mulch
#

Yes, we did. It works great when customers upgrade from a lower priced product to a higher priced product. But we are not able to figure how to use prorations within a tiered priced/metered billing product. Simply speaking we want to make sure we charge the customer for the number of days they used their number of licenses

languid zodiac
#

I see what you mean, can you specify your current Pricing model? You have a Metered Tiered Pricing right? Volume based or graduated?

acoustic mulch
#

Yes, metered tiered pricing. Volume based product. Example: licenses 1-10 - $20, 11-19 - $15 and so on

languid zodiac
#

Okie I will take this example

#

Example: A customer buys 10licenses on Sept 20, and 5 licenses on Sept 25, we want the customer billing on Sept 30 to show 10licesnses charge for 10days only, similarly for 5 licenses for 5days only.

#

Okie so For Metered billing, the amount is calculated based on Usage reporting, so Proration won't work. You would have to control over the Usage report to achieve the calculation. For example

#
  1. Create Subscription Item for 10 licenses on Sep 20
  2. Create another Subscription Item for 5 licenses on Sep 25
  3. Report them separately
acoustic mulch
#

Okay, in this example the same customer buy 10 and then 5, so by reporting them separately how do we calculate the price for each license bought. Using the volume pricing above, for both 10 and 5 licenses the price will be $20 each = $300. But in totality, total licenses are 15 so each license price will be $15 = $225

#

As the total number of licenses increases the pricing goes down, so the final billing should be based on the $ amount for the tier in which total licenses fall

languid zodiac
#

Oh you need the total quantities to be considered

#

hmm let me think

acoustic mulch
#

Thanks. In a nutshell, we want to charge customer based on number of licenses they bought (price would based on the tier the license quantity falls) and the usage (number of days). Full month usage with no upgrades/downgrades is easy to bill. But any changes in middle of the billing cycle is difficult to figure out on our side

languid zodiac
#

Hmm I am not sure if using usage's quantity as number of days is a good idea 🤔 As you will set quantity as the days of the months, and unit_amount to the price splitted to daily?

#

Was that what you meant?

#

Sorry if I misunderstood

#

The ideal usage is quantity as the number of licenses, and you had a Volumn-based Metered Pricing model already

#

the problem is, we haven't figured it out how to "pro-rate" it by the days number

acoustic mulch
#

Ahh I see. But in the current situation, if a customer adds an additional license just a day before end of billing, they will be charged full. Is that correct understanding?

languid zodiac
#

Yes, for current situation

acoustic mulch
#

Hmm. Do you have any recommendations on how do we do this?

languid zodiac
#

Let me ask my colleagues

acoustic mulch
#

Also, it does not work for us. If a customer uses 10licenses, but downgrades to 9 a day before billing date, we will get $ for only 9 customers

reef sand
#

heya @acoustic mulch, stepping in on behalf of orakaro.. Give me a while to get caught up on your use case

acoustic mulch
#

Sure

reef sand
#

so as orakaro had mentioned before : prorations are not generated for metered subscription updates because they’re billed at the end of the period, not at the start like with licensed subscriptions.

Unfortunately, we don't really have any features to handle mid-cycle changes and there isn't any good way to deal with it on a tiered volume pricing model

#

if you really want to though, you would have to implement your own logic. What comes to mind for me is to immediately bill the customer for their current usage and calculate how much you should refund/prorate, and either apply the difference to the customer's balance or create a refund to their credit card. Then immediately subscribe them again based on the new quantity.

Does this all make sense?

acoustic mulch
#

Somewhat. I am digesting this . Makes sense a bit

reef sand
#

tl;dr : you have to calculate and implement your own prorations

acoustic mulch
#

Okay, makes sense

#

Just curious, is Stripe plan to have these uses cases built in your product?

reef sand
#

hmmm, i haven't heard anything about this in our roadmap but i'll pass it on as feedback to our product team

acoustic mulch
#

I am sure all SaaS products face this issue

reef sand
#

it is a valid use case and i'd imagine many other users would have the same ask too

acoustic mulch
#

It would be good to have it built in Stripe and not built in our code/logic

reef sand
#

definitely agree with that.

acoustic mulch
#

Thanks

reef sand
#

try it out and feel free to reach out in case you run into any issues 🙂

#

i deleted a message about cancelling the subscription cause that wasn't necc. in case you read it, ignore it

acoustic mulch
#

Hehe, thanks. I read it and was scratching my head trying to figure out