#morunas

1 messages · Page 1 of 1 (latest)

odd fernBOT
sleek valley
#

That's simply not supported, according to the link you've shared. One workaround, I think is to create a price including the discount as a final amount

dull knoll
#

The price workaround as I understand, would not use the Coupons features, like duration and max_redemptions.

But isn't there another flow? E.g.

  • Create new subscription with coupon, then after, upon payment confirmation, delete old subscription? (the issue here being proration I guess...)
  • Or what about applying the coupon first in one update, and then do the update with new prices and proration using pending_updates?
#

On the second workaround, if the payment does fail, I should rollback the coupon on the respective web hook... and the coupon would not have been used, since payment did fail?

sleek valley
dull knoll
#

I can also see a coupon can be applied to the Customer instead of a Subscription. We are a SaaS platform where our clients have at most 1 active subscription. Should I go that way instead?

#

Thank you for sharing the test-clocks.

However, what I am after is understand the best way to provide enable this capability to give existing paying customers a Coupon they can use to upgrade

sleek valley
#

All of these are workarounds so the best way is to do tests and judge what is the best option to your businesss needs.

dull knoll
sleek valley
#

there is no mention for default_incomplete onthe upgrade-downgrade guide, default_incomplete is usually used onyl when creating the Subscription not for the updates

dull knoll
#

Correct, but it does say

To bill a customer immediately for a change to a subscription on the same billing cycle, set proration_behavior to always_invoice. This calculates the proration, then immediately generates an invoice after making the switch. Combine this setting with pending updates so the subscription doesn’t update unless payment succeeds on the new invoice.

And pending updates is used by setting payment_behavior to pending_if_incomplete.

What I understand is that pending_if_incomplete will not update the subscription until the payment is fulfilled. And if I'd instead use "default_incomplete" on the update, as described here https://stripe.com/docs/api/subscriptions/update#update_subscription-payment_behavior then the subscription is updated regardless of payment succeeding... so I guess a possible flow from here would be:

  1. assume the payment will succeed and apply new plan to customer account
  2. if payment later fails (web hook), revoke the plan

Does that make sense?

final sparrow
#

Yes, you'd need to manually downgrade the Subscription back to the previous plan if the payment fails

#

We're working on improving pending_if_incomplete to support additional parameters

dull knoll
#

Hi Ynnoj, will that include applying Coupons? Can I have a rough non-binding deadline? like Q2/24?

final sparrow
#

No I can't share a timelime I'm afraid

dull knoll
#

Fair enough. But is Coupons on the horizon? the info helps my company to allocate resources appropriately

final sparrow
#

I believe so yes

dull knoll
#

Alright. One last thing, I also tried asking your "Docs AI" and this is what I got.

I guess it's not very sharp yet, right? Because it tells me to create instead of update, without a delete, to use discounts, instead of coupon... or am I missing something?

final sparrow
#

Yeah I mean that works too but there's obviously trades-offs. Equally the manual rollback if the payment fails is a significant trade-off too, there's no happy path right now for what you want

discounts is a beta parameter so yeah that shouldn't be highlighted here (unless you're in the beta I guess)

#

Will share internally!

dull knoll
#

Alright. Thank you so much for your time! 🙂 cheers!