Preventing Discount Clawbacks on Mid-Cycle Upgrades in Stripe

[Gopi Vetrivel]

Hi team,

We're currently encountering an issue with Stripe's proration behavior related to our subscription model and one-time promotional discounts.

Context:
Our platform offers two monthly subscription products:

• Mailbox Slot – $3/unit

• Warmup Slot – $6/unit

Users can subscribe to any quantity, and we offer a 50% discount on the first purchase of Mailbox Slots only. Users may upgrade (add slots) at any time, and we retain a fixed monthly billing anchor for simplicity and consistency.

The Problem:
When a user upgrades mid-cycle, Stripe’s proration logic claws back the initial discount if it’s no longer applicable, leading to unexpectedly high charges. For example:

• On May 8, a user purchases 30 Mailbox Slots ($90 with 50% discount = $45) and 10 Warmup Slots ($60), totaling $105.

• The user adds 30 more Mailbox Slots later the same day.

• Stripe’s proration charges ~$135, rather than the expected ~$90, due to clawback of the unused portion of the original discount.

What We Need:
A way to ensure mid-cycle upgrades only charge the full price for the additional units, without impacting the already-discounted portion of the original subscription. Specifically:

• Preserve the original billing cycle,

• Maintain the one-time discount eligibility only on the initial purchase,

• Avoid any clawback of the initial discount during proration.

We don’t want to disable proration, since it's essential for syncing upgrades with the billing anchor.

Are there any recommended approaches, product configurations, or workarounds within Stripe to achieve this?

Thanks,
Gopi

[Remi J.]

Hello Gopi,

First, thank you for the thorough write up, you made it really easy to grasp what you were trying to fix!

Unfortunately, the behavior you are experiencing is by design today. When you change the quantity from X to Y on a Subscription we calculate proration by first crediting back the amount paid for X for the remaining time that won't be used and then we charge for the quantity Y for the remaining time. We don't calculate the credit or amount owed just for the difference between X and Y. Because we approach proration that way, the discount only applied to the quantity X and is refunded back when we credit. Since the discount is not applied anymore it doesn't count for the calculation for Y.

This can definitely surprise developers though and you're not the first person confused by this. It's something I really want us to improve on by offering different "modes" of proration to suit different types of businesses so your email will help us revisit that design in the future.

In the meantime though there isn't really a workaround in this situation that I can offer unfortunately. This is the way proration always works. You could reapply the original Coupon during the upgrade or add a new one that gives you the specific amount discount you were looking for otherwise but it's not easy to make this work in the right order especially if you invoice immediately for the price difference.

I hope this clarifies the confusion though about what is happening.

Best,

Remi

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