Update a subscription with a previous coupon applied

[Alexis Martínez Chacón]

Hi,

We are currently facing some problems when a customer makes a subscription update and a discount has been applied on the initial purchase.

For example:

- The customer buys a 1 seat x 100€/year subscription with a once use 50% coupon = 1 x 100 € / 2(50%discount) = 50€
- 6 months later the customer wants to buy one more seat and the expected scenario for us should be

1. Unused time on 1 seat = 1 * 50€ / 2(half of billing cycle) = -25€
2. Unused discount(50% off) = 50€/2(half of billing cycle) = -25€
3. Remaining time on 2 seats = 2 x 100/ 2(half of billing cycle) = 100€

So the customer will have to pay 50€ for the 6 remaining months of the second seat. However, we have the following scenario on stripe proration:

1. Unused time on 1 seat = 1 * 50€ / 2(half of billing cycle) = -25€
2. Remaining time on 2 seats = 2 x 100/ 2(half of billing cycle) = 100€

So the customer will have to pay 75€ for the 6 remaining months of the second seat which is not correct because it is charging the prorated discount applied at the start of this billing cycle. Therefore, I would be paying 25€ more for 1 seat which was discounted already.

How can we handle this scenario properly? Could you help with this please?

Thank you

[Remi J.]

Hey Alexis,

If I take your example, your customer paid 50€ for the year. Mid-year, they decide to change the subscription so we calculate how much you owe them for the time they paid already but won't use. They paid 50€ so you owe 25€ in credit at that point. Then they switch to a quantity of 2 mid-year which means they owe you 100€ (100€/year * 2 * 1/2). 100€ - 25€ is 75€ as expected.

I don't fully understand your math overall here and why you want a double credit in this case. You have to look at how much they paid (half price) and how much they have left that they won't use (half a year). If you credit them 50€ back then it's like they didn't pay the first 6 months at all.

There isn't a way for proration to not take the discount into account on our end at least so in that case you would have to do the math yourself instead.

Hope this clarifies the situation but if you have more questions, please make sure to reach out to our support team instead for help and with a clear example of a Subscription where this happened: https://support.stripe.com/contact

Best,

Remi

--
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Alexis Martínez Chacón]

Hello Remi,

Thank you for your answer. 

All right, We understand your point and your solution but we disagree. In our opinion is not correct that the user have to pay the amount of money which we discounted in their first purchase(50%) because they just want to add one more seat for 6 months or whatever time they want if if it is in the same billing cycle which the discount was applied. So what is the purpose of apply a discount if when they try to update(in the same billing cycle) the subscription we are going to charge that amount discounted before?  We are charging in the previous example 75€ for the remaining 6 months which is not correct if we think that we already paid for 1 seat(with a 50% discounted) before and 1 more seat it costs 100/year, so the 50%(Mid-year) of 100 is 50€, not 75€.

This is a problem for us in our current flow with our customers because they are complaining with this behaviour.

Whatever, this reply is just to try to clarify our point of view but we already understand that stripe is no supporting this and will not do soon at all.

Thank you again.

Regards

[Remi J.]

Hello Alexis,

I do think that what you described in your reply is conceptually quite different to what you described earlier. This time, you're making a different point where what you want is mostly to increase the quantity from 1 to 2 where you don't want to change anything about quantity 1, it's already paid and will continue to be used, but you want to charge for an extra quantity. And you want that payment to be in full (no discount applied). In that case, yes the math adds up to 50€ since it's an extra quantity for half a year and no discount, but it's not the same as how you counted the refunded discount before.

Unfortunately, with products like Billing, there are a lot of business models and ways to charge customers. And one problem is that "the right behaviour" depends on which business model you follow. At first you might think that there's one correct way to react to an event, but it's often biased by that decision in the first place. If you're a business that doesn't refund on cancellation, you want the default behaviour to keep the Subscription active until the end of the already paid period. If you refund by default though you'd want the cancellation to be immediate and the customer to be refunded immediately.

Over the years, I've explained Billing to many developers and the way I frame this problem is that the "right default" is rarely what your intuition assumes at first. There are often so many different edge-cases that Billing will sometimes appear to choose the "wrong" default where in fact it makes a lot more sense once you take all those edge-cases and complex alternatives into account.

The real issue here is not that it's wrong or the wrong default and more that we don't offer a way to model that specific behaviour easily unless you do the math yourself. We do hope that one day we can offer an option to make a quantity increase behave by only prorating the extra quantities you're adding without touching (refunding) what has already been paid. It's something we're definitely aware of but it's unfortunately not something we can fix for now.

Best,

Remi