#Gkiokan - Subscriptions

1 messages · Page 1 of 1 (latest)

ripe nova
#

Hello! Taking a look...

deep gale
#

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

ripe nova
#

Yep, this is expected and normal. The amount difference is due to the proration for the unused time before you modified the Subscription.

deep gale
#

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?

ripe nova
#

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

deep gale
#

If I stop the prorotation the customer would just pay another additional 189 EUR right?

ripe nova
#

What do you mean by "stop the proration" exactly?

deep gale
#

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?

ripe nova
#

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?

deep gale
#

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

ripe nova
#

Are you sure the proration isn't what you want though?

deep gale
#

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

ripe nova
#

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?

#

If you do that does it behave how you want?

deep gale
#

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

ripe nova
#

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 ?

deep gale
#

to get charged another 10$

ripe nova
#

So I'm paying $10 for 30 days for two widgets and $10 for 25 days?

deep gale
#

The whole price for the period undepended on the date when he upgrades

ripe nova
#

What do you mean?

deep gale
#

I mean while in the period, the quantity should not count the days but the whole period.

ripe nova
#

That's not how Stripe Subscriptions work.

deep gale
#

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

ripe nova
#

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.

deep gale
#

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.

ripe nova
#

Happy to help! Let me know if you have questions about what happens when proration is disabled.

deep gale
#

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

ripe nova
#

Yeah, I was afraid of that.

#

Let's back up a bit.

deep gale
#

I would assume that it charges the difference now in this case only another 189 EUR

ripe nova
#

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?

deep gale
#

20$ for both as the quantity would be 2 for the next period

ripe nova
#

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?

deep gale
#

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.

ripe nova
#

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.

deep gale
ripe nova
#

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.

deep gale
#

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.

novel kelp
#

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?

deep gale
#

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?

deep gale
#

Or what should I set to have that happens without double charging the customer on one period?

novel kelp
#

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

deep gale
#

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)

novel kelp
#

I'm confused. Aren't you wanting to charge twice the price if the customer updates to twice the quantity?

deep gale
#

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

novel kelp
#

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?

deep gale
#

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

novel kelp
#

It's not how Subscriptions work by default. You would have to simulate the behavior with extra coding on your end.

deep gale
#

KK. I have noted that sofar as response for the department.

novel kelp
#

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

deep gale
#

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