#Gkiokan - Subscriptions
1 messages · Page 1 of 1 (latest)
Thanks mate. Looking forward for your results. I would assume that even if the quantity is updated, the proration should match the remaining time until the subscriptions end date.
Example on a simple yearly price of 120 EUR (my assumtion)
User subscribe at Jan and get charged 120 EUR.
On Feb he update quantity and would be charged by additional 110 EUR?
Assuming the subscription ends on Dez the same year
Yep, this is expected and normal. The amount difference is due to the proration for the unused time before you modified the Subscription.
How can I explain this to my customer? He gets kinda a "credit" for his previous quantity and gets charged again with* the new quantity with the difference then?
The unused time amounted to -€755.94 which was credited as a negative line item, and the new line item following your update amounted to €945.00, which means the total is those two values added together, which is €189.06
If I stop the prorotation the customer would just pay another additional 189 EUR right?
What do you mean by "stop the proration" exactly?
The current invoice have that "unsued" invoice item currently which is caused by the prorotation as we have a difference between the 2 invoices.
Can I just get a straight Invoice Item* without counting the already paid and used amount?
Yes, it's worth giving it a try to see if it works for your use case. Although I'm curious, why are you creating the Subscription and then updating it like this shortly after?
I am using the quantity for the product as the value for license per user that the user have on my platform
So if the user adds a new employee he upgrades his quantity and get charged for the new employee asap
in_1L5yHHHa5WPIKK5I3PbntXdM
Are you sure the proration isn't what you want though?
You can see on this invoice it is exactly charging 189 EUR for the new quantities
I am not sure I need to discuss that with the department. Because I think if i disable the proration, the customer will get charged for the whole period of his interval without getting that credit thing. But if he have a yearly subscription and adds a employee on the last 3 months, he still would pay the full price for the whole year, right?
Which value do I need to set to disable the prorotations on my update request? none?
to none i mean, in combination with billing_cycle_anchor to now to generate a invoice asap
You're explicitly asking for proration in your request with proration_behavior: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
To clarify, you want them to pay immediately but you don't want to prorate? Can you clarify how that would work with a simplified example?
You can set proration_behavior to none for example: https://stripe.com/docs/api/subscription_items/update#update_subscription_item-proration_behavior
If you do that does it behave how you want?
Yes the user should pay immediately after the update. I want that the user pays the amount of the quantity that he orders without calculating the used or remaining paid amount from the previous quantity. Does that make sense?
lemme try to implement the non parameter and check how it behaves
So if your widgets cost $10/month each and I have a Subscription for two of them that starts on the 1st, what do you want to happen if a third widget is added to the Subscription on the 5th of ?
to get charged another 10$
So I'm paying $10 for 30 days for two widgets and $10 for 25 days?
The whole price for the period undepended on the date when he upgrades
What do you mean?
I mean while in the period, the quantity should not count the days but the whole period.
That's not how Stripe Subscriptions work.
A simple example: If you have a monthly subscription and you have 2 qt on Januar 1 - 20 but add on the 21th of Januar another one, you pay the full price for him, too. From the docs I have understand this would be the case if i don't prorate items
If you add a widget partway through a period you only pay for the remaining time on the period, not the full price, at least not by default. Disabling prorations as described above may do what you want, but I recommend testing it to see if it's what you expect.
I see
Yea the default subscription way would charge the customer for the "remaining time until end of period" thats fine. I just need to present both solutios to the department.
I will test the options with disabling the prorations and see what happens.
Thanks so far.
Happy to help! Let me know if you have questions about what happens when proration is disabled.
Sure 🙂
ouch, the none value does something completely differnet than I thought
It charges the new price * quantity amount on top of the previous invoice
That was not intendet
I would assume that it charges the difference now in this case only another 189 EUR
Going back to the $10/month widget scenario, let's say I Subscribe to one widget on the 1st of the month, then I add a second widget on the 15th. That means you want me to pay $10 on the 1st and $10 on the 15th, right? But what happens when the next Invoice on the 1st comes along, how much should that Invoice be for?
20$ for both as the quantity would be 2 for the next period
To clarify, what if I added the second widget on the 31st? I'd have paid $20 for the first month even though I only had a single day's access to the second widget? And then I have to pay $20 again the next month? Wouldn't it make more sense for me to wait and add the second widget on the 1st so I don't get charged double for it?
Actually yes but task is "as long the customer is on the period he would get charged for that month for each quantity"
I know it sounds dumb. I agree on that what you say. The problem is that the department decided to evaluate both scenarios and I should present both use cases how they would generated and what the final invoices would be for the customer.
At the source issue they got annoyed with the re-calculations on the invoice when it have the "remaining" and "used" Invoice Items on each change. So therefore I need to try it at least to see how they decide afterwards.
Back to your 31th example. Even if, the user would be on the first period, so customer should still pay for 10$ for the 1 day.
What you're describing isn't really how Stripe Subscriptions are designed to work.
Another option you might want to explore is creating a second Subscription rather than updating the quantity on the existing Subscription.
I tried that yesterday already. The problem here is that the customer has one invoice per subscription and it is not possible to collect them all into one together.
So on the 1st when I subscribe to the first widget I pay $10. Then on the 15th I subscribe to the second widget with a second Subscription and pay another $10. Then I'm billed $10 on the 1st for the first Subscription and $10 on the 15th for the second Subscription.
Yeah, but do you want them together on the same Invoice? You said you don't want the proration, which makes it sound like you want separate Invoices with separate billing periods.
That won't work. If the customer have 50 users he would have each month 50 invoices.
I think the real userfriendly and out of the box working way would be to stick back to the always_invoice and have the prorations activated as it is by default. That makes it userfriendly for the customer and everything is on one invoice at all.
As I have understand, the default behavior will only add the remaining days as charge like add on 25th and stripe will charge until 31th only.
If you have no other Idea on how I can get all on one invoice with the scenario i described then the department have to bite into the apple. So easy. I don#t want to make things more complicated even if they are not designed to work like this.
Hi there. Stepping in for Rubeus.
I read through the thread and I'm relatively up-to-speed on the conversation. It sounds like Rubeus gave a solution already. Are there any outstanding questions?
Thanks for joining by. No I think I have all I want for now. Thanks for the check though.
Actually he just clarified that it is not how the subscriptions work but I am curious if that scenario would be still do able?
this one
Or what should I set to have that happens without double charging the customer on one period?
Can you elaborate on what scenario you're talking about? Hard to gauge what you are/aren't wanting to do based on the thread
Sure lemme show you
If user updates quantity -> he should pay for the whole period with the price * quantity
I think this describes it as simplest
Sub example 10$ per quantity/month
- 1st Jun start a subscription
- 15th add another quantity
total pay for the Januar 20$
But in my Example (I tried with proration_behavior = none on the update Quantity) it charged the customer double the price.
1st invoice (bottom one) 189 (charged)
2nd invoice (upper one) 378 (charged again)
I mean by charge the subtotal price (which is the netto field on my screenshot)
I'm confused. Aren't you wanting to charge twice the price if the customer updates to twice the quantity?
Correct
But I want to charge the customer asap
When I use this as parameters it will charge the full price * quantity on update instead of the difference for the new quantity
So the Customer creates subscription on January 1st and gets charged $10, then updates the subscription on January 15th to add another $10 to their monthly charges. You want them to be charged for $10 on January 15th, then $20 on February 1st (for both Subscription items), correct?
correct
Is this even possible? Rubeus stated thats not the way how the subscriptions work but technically this should be possible
In my example it is possible but it is charging to much
It's not how Subscriptions work by default. You would have to simulate the behavior with extra coding on your end.
KK. I have noted that sofar as response for the department.
And there would be no way to get all the items on the same invoice. You could try creating a one-time charge for the first month, then update quantity for subsequent months, but that still doesn't put everything on the same invoice
There are a couple ways that I have in mind to tackle this but not sure what the outcome will be. Need to test this.
I could maybe cancel the subscription and create a new subscription based on the previous data (like period end etc.)
But this would be a very very very hacky solution
Let's keep it simple. It's not possible what they want. I will stick to the default subscription workflow as it is designed.
The department have to take the bite for that.
Thank you for the investigation and killing your nerfes for that. Good job on the sub