#panda-subscription-proration

1 messages · Page 1 of 1 (latest)

marsh flickerBOT
quaint violet
#

panda-subscription-proration

naive cargo
#

@quaint violet Hi, any idea?

quaint violet
#

sorry, there are 20+ people asking for help in real time

#

I don't fully get what you want to do that we don't do. We mostly already do that right? you paid for 10, we refund you and now charge you for 20

#

Are you saying you want the extra 10 seats to be paid in full?

naive cargo
#

Stripe takes Time to consideration also. If a user cancel a subscription in mid way of the month, Stripe calculate 50% of the price. Isn't it?

#

For example, if a user has already consumed 50% of their subscription quantity and wants to purchase an additional 10 units, the prorated fee would be calculated based on the remaining 50% of their subscription quantity, plus the 10 units they wish to purchase.

quaint violet
#

yes because that's what makes the most sense

#

No one wants to pay for 10 extra seats full price 1 minute before the next Invoice for example

naive cargo
#

I think I could not make you understand my query properly. 😦

quaint violet
#

totally possible. The easiest is to take a concrete example, that's my advice. Like customer pays $X on March 1st for quantity Y, then on March 15 the change quantity to Z and I want them to pay <explain>

naive cargo
#

Sure, let's modify the example to illustrate prorating a subscription based on API query limits.

Let's say you have a subscription plan for an API service that charges $10 per month for 1000 API queries. A customer subscribes to this plan on March 1st and pays the full amount of $10. However, they have only made 500 API queries by March 15th, and they want to increase their API query limit to 1500 for the remainder of the month.

To prorate the subscription based on quantity only, you can calculate the prorated fee for the additional 500 API queries based on the remaining quantity for the month. The customer has already used up 50% of their monthly API query limit, so the remaining quantity is 500 API queries.

To calculate the prorated fee for the additional 500 API queries, you can divide the cost of the remaining 500 API queries ($5) by the remaining quantity (500). This gives you a prorated fee of $0.01 per API query.

quaint violet
#

To prorate the subscription based on quantity only, you can calculate the prorated fee for the additional 500 API queries based on the remaining quantity for the month. The customer has already used up 50% of their monthly API query limit, so the remaining quantity is 500 API queries
I don't really get that. They had 1000 queries and they want 1500 queries, so they just want +500. It doesn't matter how much they have left right?

#

I don't really get your example and why you prorate by usage, and not by what you're paying/paid for

clever ermine
#

I think there's confusion with the "1000 per month" (which is actually just a quantity, 1000), and "per month", which is a time-based charge.

naive cargo
#

"It doesn't matter how much they have left right?"

Yes, it matters how much queries left?

Purchased = 1000 units
Consumed = 500 units
Left = 500 units

They need extra 2000 now,
They will pay for only 2000 - 500 = 1500 units irrespective time.

#

Stripe calculates this taking both quality used and number of days used. But I want to exclude time for the calculation.

quaint violet
#

Ah gotcha, so the extra 2000 is something they ask you and then you do the math for how much more to charge them for right?

#

So what happens if someone wants an extra 2000 at the last hour of the month?

#

You just charge them full price for it and too bad for them if they lose those extra 2000

clever ermine
#

(i.e. do the quantities accumulate, or expire?)

quaint violet
#

because most customers would expect that extra quantity to roll over to next month

clever ermine
#

If they accumulate, this sounds more usage-based than time-based

naive cargo
quaint violet
#

ah okay so you're kind of "abusing" our Billing product because you pay for service in March but it might be used in May

#

And the problem is basically that you want "upfront payment" for usage based pricing

naive cargo
quaint violet
#

usually businesses like yours you use 3.5k API requests in March and then on April 1st you pay for it

naive cargo
quaint violet
#

But what if he realizes this on March 30

#

that seems such a brutal way to do pricing and a near certain escalation when your user realizes he overpaid

clever ermine
#

Were I running this structure, I would pre-pay a monthly allotment (i.e. credit on usage-based), and POST-pay on usage above the credit in the next monthly subscription, with an option to UPGRADE to a higher-tier pre-pay

naive cargo
clever ermine
#

somewhat - base credit pre-paid; higher per-unit for the POST-pay overage; option to pre-pay a LARGER # of credits.

#

2 "unit" prices - lower as a pre-pay monthly; higher as per-unit POST. Really, it a single unit price, but you can pre-pay "credits" at a lower bulk price.

#

But that's business advice from someone NOT employed by Stripe (a fellow user who stalks the Discord)

#

As a general customer-relation structure, letting them go over at will, see the higher unit price (post) and upgrade to a higher tier will very likely end up with your customers more-or-less blaming themselves for any overage, upgrading to a higher tier, then almost never going back down when they don't use the allotment.

naive cargo
#

@quaint violet @clever ermine I am trying to rethink about your feedback. Thank you for your patience. I may come with some more queries.

quaint violet
#

sounds good

#

ultimately my recommendation about proration_date should just work

naive cargo
quaint violet
#

Nothing changes with what you already have. All you do is pass the right proration_date so that we don't do a time based proration and charge for the full amount