#luffysenchou9488

1 messages · Page 1 of 1 (latest)

hidden oasisBOT
#

Hello! We'll be with you shortly. 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.

dire pulsar
#

👋 happy to help

oak stone
#

Hi Tarzan

dire pulsar
#

it doesn't really make sense to open a credit note for an invoice that hasn't been created yet

#

let's forget about the implementation for a second

#

could you please elaborate on the business use-case first?

oak stone
#

the business use case is to charge the subscription on a prorated basis. But since the proration is not supported for a usage based billing, audit team asked us to look into credit notes. So, I have two options:

  • Either issue a credit note after the invoice is paid, but in this case the credit note will either be a refund or a deduction in the next month's invoice
  • To reduce the charge of the subscription by manually adding discount after calculating the proration
#

Since in the first option, the customer will not know that they're issued a credit note until the next month's invoice, the audit team wants to look into the second option: which is to discount the invoice proactively by adding a credit-note to the first invoice that will be collected on the first billing cycle end

dire pulsar
#

I think we've discussed this issue together last time right?

oak stone
#

yes, I'm looking for alternatives for what we discussed.

dire pulsar
#

the reason why we don't prorate usage-records is because regardless of what the billing_period is, the usage happened

#

so basically you can't prorate something that was used

#

let's go with a simple example

oak stone
#

Why can't this be an usecase: the usage that was recorded was for a partial period of the month: hence, he shouldn't be charged completely

#

If I'm offering a service to a customer, the service will have a charge per unit per month. Not just uni-dimensional i.e just per unit.

#

This is a limitation on Stripe's end for which I'm trying to figure out a solution that satisfies all the financial regulations held by our accounting team🤕

dire pulsar
#

let me give an example though

oak stone
#

sure

dire pulsar
#

let's say you are selling a subscription for a gym with a flat fee of 10$ per month and each time you visit the gym you pay an extra 1$

#

the customer went 5 times and decided to cancel the membership after 15days

#

you can prorate the monthly fee and say you will only charge 5$

#

but you can't say that the customer went 2.5 times to the gym

#

so you can't prorate the usage

oak stone
#

this example is kind of one-dimensional in a way

#

let me give one more example just for the sake of understanding all the customer use cases

dire pulsar
#

yes sure

#

I think I get where you're going with this

#

basically it's more like a rental type of thing

#

let's say you have a bike rental, where you have a membership fee and an extra fee for each bike you rent

hidden oasisBOT
oak stone
#

Let's say there is a gym which offers you services of multiple categories: but these services are charged per month and for any additional requirement you have will be charged extra which is where the usage billing comes in. In this case, If i subscribe to a gym on 28th of the month, Gym can't expect me to pay the full 30 days for just 2 days of the services I consumed

#

Hence, the billing model should cater to both the per unit cost and per month cost into account.

dire pulsar
#

but can someone ask for access in the middle of the month?

#

like why the need of the metered-prices in that case

#

why not just update the subscription and add other prices

oak stone
#

yes, business cant mandate the customers to join only on the start of the month as it will hamper their business.
The need for metered-prices is that: service for a month is calculated by how many requirements he add across a period of the billing cycle

#

if I join on 15th of the month, have 5 requirements to be serviced, i will have to pay 5* unitprice * (31-15/31)

#

from the next month onwards, it is straight forward anyways

dire pulsar
#

there is no easy, straightforward way of achieving this

#

but I'm not sure it will fit your needs

oak stone
#

sure, let me check this out. If we can add a customer credit before the first billing cycle ends, it fits my bill