#morunas
1 messages · Page 1 of 1 (latest)
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
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?
Yes you can test those using test clock :
https://stripe.com/docs/billing/testing/test-clocks
Yes I thinkg so too.
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
All of these are workarounds so the best way is to do tests and judge what is the best option to your businesss needs.
I understand, and I am trying to make my due diligence, my fear is not understanding enough to make the right choice.
I am wondering, for example, why not just use "default_incomplete". It's not clear to me by what is written here https://stripe.com/docs/api/subscriptions/update#update_subscription-payment_behavior or here https://stripe.com/docs/billing/subscriptions/upgrade-downgrade why I should chose one over the other
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
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:
- assume the payment will succeed and apply new plan to customer account
- if payment later fails (web hook), revoke the plan
Does that make sense?
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
Hi Ynnoj, will that include applying Coupons? Can I have a rough non-binding deadline? like Q2/24?
No I can't share a timelime I'm afraid
Fair enough. But is Coupons on the horizon? the info helps my company to allocate resources appropriately
I believe so yes
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?
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!
Alright. Thank you so much for your time! 🙂 cheers!