hakan_-subscription

[quartz chasm]

Hi 👋 I'm not sure what you're trying to say, could you try clarifying?

[wispy echo]

So there is 1 client having a subscription over 1 project = 19.99€.

Now, I wanted to increase the amount of projects to 2 = 39.98€ , but when I do that over the dashboar it shows me that the client get charged next month for "59,88€" ?

@quartz chasm

I would love to post a screenshot but there is sensitive data to it.

ok edited. why there is 59.88€ for 2 projects? I am so confused

[quartz chasm]

Can you share the ID of the Subscription?

[wispy echo]

sub_1LUp20KiFdFiKVXCqlzB7VjD

[quartz chasm]

Thanks, pulling that up

Sorry, I'm having a little bit of trouble parsing this, is it correct that you made another update after taking that screenshot?

[wispy echo]

no

I just increased amount from 1 to 2

and the update was before the screenshot

so, i am woundering why a 59€ charge is there this is wrong

[quartz chasm]

I'm seeing another request was made to change the quantity from 2 to 3

[wispy echo]

stripe should charge 39€ next month because of 2 projects

[wispy echo]

Super weird I did not changed anything

[quartz chasm]

This is the request I'm seeing:
https://dashboard.stripe.com/logs/req_DEM5k7Eir6XumL

[wispy echo]

then client have added one project himself, and 3x 19.99 = 59€ , not 99

so still wrong calculation

[quartz chasm]

Since the quantity is being updated mid-cycle, the system is also calculating a prorated amount to add to the next invoice for the time of the current billing cycle where they have a higher license count. If you want to avoid this then you can specify the proration_behavior when making the update.
https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior

[wispy echo]

so what this means?

the system is also calculating a prorated amount to add to the next invoice for the time of the current billing cycle where they have a higher license count

[quartz chasm]

Since Stripe Subscriptions bill forwards, when the Customer updates their subscription mid-cycle they're making changes to a cycle that they've already paid for. To account for this we have proration behavior to calculate prorations and add them to the next invoice. You can read more about it here:
https://stripe.com/docs/billing/subscriptions/billing-cycle#prorations

[wispy echo]

can I disable that ?

i mean, what can I archieve that the client gets charged at next invoice only for 2 amounts

[quartz chasm]

Yes, using the parameter that I linked you to previously.

https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior

[wispy echo]

but when I disable that, what happens then when there is a new amount?

is there a example I can see with the new behaviour?

[quartz chasm]

I'm not sure I understand the question here. If you set proration_behavior to none when updating a Subscription, then no prorations are calculated and added to the next invoice.

For testing Subscriptions, I recommend using our Test Clocks. It allows you to create Subscriptions inside of sandboxes where you can advance time, allowing you to test Subscription behavior quickly.
https://stripe.com/docs/billing/testing/test-clocks

[wispy echo]

I still dont understand why there was for 2 amounts originally 39€ the amount 59€ on stripe

please clarify

[quartz chasm]

On Aug 9 your Customer started their Subscription and at that time they paid for the first month. They paid for the period stretching from Aug 9 to Sep 9, for a quantity of 1.

Then later on Aug 9 the Subscription was updated and the quantity was adjusted from 1 to 2. The Customer had already paid for the Aug-Sep billing period, but only for a quantity of 1 so a proration is calculated for the remainder of the Aug-Sep billing period where the Customer has a higher quantity than what they previously paid for. That proration is then added to the next invoice. This is why the next Invoice is showing 39.98 for the next billing period (Sep - Oct), and 39.79-19.89 for the remainder of the Aug-Sep billing period.

[wispy echo]

Got it, my software don't removes a quantity automatically when deleting projects so that I still can charge the client for the project 1 month even it was created 5 minutes and then deleted for testing or similar.

What if I implement this into stripe? Will stripe only charge the prorotation and next month though not the full project?

[quartz chasm]

We will always charge for the next month when a Subscription moves to the next billing period.

[wispy echo]

so what that means

when a quantity is added and then removed will stripe charge that still?

that prorotation or stripe will be as same as before

[quartz chasm]

If prorations are not disabled for the updates, then prorations will be calculated and added to the next invoice.

[wispy echo]

ah so I should remove quantity from stripe subscriptions when projects are removed right?

but still the prorotation will be applied right?

[quartz chasm]

Sorry, I'm not following, could you explain the behavior that you're hoping to achieve?

[wispy echo]

I mean, should I remove one quantity from stripe when people remove a project?

[quartz chasm]

That depends, what is the behavior that you're trying to build?

[wispy echo]

right now projects will not be removed from stripe when clients delete it from my app

thats why the amount is now at 99€ with 3 projects

so when I implement that, people will only get charged for prorotation at least BUT if they keep the project they will get charged for prooration + next month

get me?

[quartz chasm]

If you don't want to calculate prorations, then you set proration_behavior to none when updating the Subscription. If you do want prorations calculated then you don't do that.

Sorry, but I'm struggling to understand what behavior you're trying to set up, so I'm not sure what advice to give you. Do you want prorations to be calculated, or not?

[wispy echo]

I want to calculate protations, but I want to ensure clients dont get charged twice like now

[quartz chasm]

They aren't getting charged twice

[wispy echo]

I needed to remove one amount

I think yeah, my task is do implement that amounts get reduced so people will only get charged for prorotations but not for deleted projects next month full amount

Sorry, but I'm struggling to understand what behavior you're trying to set up, so I'm not sure what advice to give you
im just try explaining all the time 😦

[dapper pivot]

@wispy echo did you have any follow up questions?

[wispy echo]

seems when I lower the quantity when people delete projects stripe wont charge at all...

[wispy echo]

.

how can I prorotate the charge only partially for projects but not for the next invoice month?

I ask what happens when people lower the quantity within a month, how stripe does work with it?

[dapper pivot]

Did you read our docs?

Sorry to keep saying this but there are so many words in this thread for something we cover in details in
https://stripe.com/docs/billing/subscriptions/upgrade-downgrade
https://stripe.com/docs/billing/subscriptions/prorations

[wispy echo]

ok just for testing, when I disable this and save and come back its still active...

the prorotation

below left

[dapper pivot]

yes because that setting is per update. It's not a global setting. Every time you upgrade or downgrade a subscription you have to decide if you want proration or not

[wispy echo]

i dont see a part in the docs when people lower the quantity within a subscription.

When I for example have 1 project in my subscription, I add 1 another = 2. I decide to delete the project (5 minutes later), what stripe will charge the client?

[dapper pivot]

We prorate everything up to the second. Upgrades or downgrades work the same.

I'm not trying to be cryptic, but I'm also unclear what is blocking you unfortunately. Especially since you can try all of this in a few seconds in the Dashboard and the API and get a definitive answer of the exact behaviour and how proration_behavior behaves

[wispy echo]

you making it very hard for me to be honest. I am trying it all the time but i am confused about stripes behaviour.

[dapper pivot]

That's fair, but you have been asking dozens of questions at this point on the server, repeating the same thing many times to get the same answer. It is crucial that you take the time to debug things on your own, read our docs and then clearly outline your questions with a concrete example of what you don't understand

[wispy echo]

😕

[dapper pivot]

We do want to help, but you have to do your part too. This server has thousands of people, we help 10 to 20 people in parallel most of the time. As a developer you can self serve the majority of those questions.

[wispy echo]

i am like this: 😖

confused

[dapper pivot]

If you have real and specific questions, please feel free to ask them. Try to summarize the exact question in one message with all the info inline in that message. If you are confused about a part of the doc, link that doc, quote the text that confuses you, give an example Subscription id where the behaviour is different, etc. But you can't just ask us to explain our entire product and APIs when 90% of what you are asking is covered in details in all our docs.

[wispy echo]

all of my questions are real why they should not

[dapper pivot]

I just explained this to you. You are asking things that we cover heavily in our docs and that you can test in seconds in our API or Dashboard. As a developer, you have to try to self serve. We can not explain the entire product and API to you personally over the next few weeks. I'm sorry but that is just not going to be possible and it can't scale.
We know there are a lot of corner cases and exceptions, and we're here to help clarify those and give you advice on how to work around them. But we can't just explain some of the basics of our APIs, not until you have at least read our docs carefully and shown what part is confusing you

[wispy echo]

You are asking things that we cover heavily in our docs
Then, guide me where I can find the exact information about what happens when people decide to add a quantity and then lower a quantity within a month. super simple question.

my tests here show that stripe dont charges the client at all, but stripe should charge at least the prorate for this month but not for next month full invoice

a voice chat would be helpful I guess in general for this server

[wispy echo]

if you say its the links above, just say it

i will read again through them

[dapper pivot]

it's the links above yes. They explain how we do proration, why we defer to the next invoice and many other import things related to it.

[wispy echo]

when I update the quantity of a subscription over API the default behaviour is create_prorations `?

[white juniper]

This is also covered in our docs

Found by searching for key-words default , prorations and Stripe on google https://stripe.com/docs/billing/subscriptions/billing-cycle#api-now

"With this approach, you most likely want the default behavior of setting proration_behavior to create_prorations—as in the code sample—so the customer isn’t overcharged for unused time in the previous cycle."

[wispy echo]

guys, this is the way of upsetting customers like me. I myself sell software and there are "stupid" clients I need to serve daily dont know how to setup different things and they rather ask one more question than less and this here is a way you should not go into. I may be a hard client and all those things are super new for (like stripe and its all functions) , this message clearly shows you want to upset people, you should stop doing it.