#captainnoyaux_docs

1 messages · Page 1 of 1 (latest)

hollow pythonBOT
sinful marlinBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

hollow pythonBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1260231909854941365

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

gentle aspen
#

Hello, I'm trying to implement a minimum commitment period in stripe. To do so when a customer subscribe I create a subscription schedule from the subscription, I add 1 phase that last X iterations (e.g. X == 3) and another phase that lasts forever.
How do I handle gracefully that a user wants to cancel before the end of the first phase ?
ideally I'd want to update the subscription schedule to remove the second phase so that the subscription schedule ends whenever the first phase is reached. Is that correct ?

#

it seems that I can't update the phases once they are created, is that so ?

#

I tried that
String scheduleId = stripeClient.subscriptions().retrieve(toto.getId()).getSchedule();
SubscriptionSchedule scheduleToUpdate = stripeClient.subscriptionSchedules().retrieve(scheduleId);
List<SubscriptionSchedule.Phase> phases = scheduleToUpdate.getPhases();
phases.remove(1); // TODO check that getPhases.size == 2 at least

                    scheduleToUpdate.setPhases(phases);

but it doesn't want I have to call scheduleToUpdate.update()

warm tundra
#

How do I remove the phase of a subscription schedule ?
What exactly do you mean?

#

Oh, missed the above message, just a sec

gentle aspen
#

Thanks !

warm tundra
#

How do I handle gracefully that a user wants to cancel before the end of the first phase ?
ideally I'd want to update the subscription schedule to remove the second phase so that the subscription schedule ends whenever the first phase is reached. Is that correct ?
That sounds correct, to remove the additional/second phase.

What is not working for you when you try this?

gentle aspen
#

if I set the phases on the SubscriptionSchedule object it doesn't update the schedule

#

the update is done when you call .update() and .update takes some parameters that can only add phases not remove them

#

(or I am wrong and I missed it)

#

or maybe I create a a Param with the first phase and calls update on my schedule subscription

warm tundra
gentle aspen
#

but they are not of the same type 😩

#

I did that
String scheduleId = stripeClient.subscriptions().retrieve(subscription.getId()).getSchedule();
SubscriptionSchedule scheduleToUpdate = stripeClient.subscriptionSchedules().retrieve(scheduleId);
List<SubscriptionSchedule.Phase> phases = scheduleToUpdate.getPhases();
phases.remove(1); // TODO check that getPhases.size == 2 at least
scheduleToUpdate.setPhases(phases);
but it doesn't do anything

warm tundra
#

What you need to send is a new phases array that includes the current/active phase, but you can drop the second phase

gentle aspen
#

I need to construct it myself then because this doesn't compile

image.png
#

I'll try to do that, does it sound like the correct way to handle a minimum commitment period using subscription schedules ?

warm tundra
#

Rather than using the entire phase object from the retrieval

gentle aspen
#

well in java it's sounds horrendous to do

warm tundra
#

I agree, an unfortunate side effect of the strict types

gentle aspen
#

Well seems like bad types to me but yeah I get it

warm tundra
#

The object types and the request param types are necessarily different

#

Not all object attributes are valid params, for example

gentle aspen
#

isn't there another way to do it ? sounds really error prone to do it that way :/

glacial bison
#

Hi there 👋 jumping in as my teammate needs to step away soon. No, the approach they described is the right one for adjusting the phases on Subscription Schedule. I'll be sure to capture your feedback for our teams that this is something you'd be interested in seeing made easier in the future.

gentle aspen
#

yeah I don't doubt the approach on adjusting the phase. I'm wondering if it's the right approach for doing a commitment period

glacial bison
#

Can you elaborate a bit on what you mean by commitement period? If you're hoping to create Subscriptions, and then have those automatically adjust at points in the future, such as ending the Subscription, then leveraging Subscription Schedules is the right approach. Unless you want to build that future logic on your end.

gentle aspen
#

I want a minimum commitment period when a user subscribe

#

for instance I want my subscription to last 1 year with at least a 3 month commitment

#

if my users want to cancel their subscription, I need them to stay active and charged until the 3 months have passed

glacial bison
#

Gotcha. Then yes, I would recommend using Subscription Schedules to schedule those cancellations at the end of a phase.

We don't have prebuilt functionality for forcing a Subscription to remain in place like that, that would be up to your code to check and enforce. You could do this without Subscription Schedules by using the cancel_at parameter on the Subscription object:
https://docs.stripe.com/api/subscriptions/update#update_subscription-cancel_at
but if you go that route you'll need to make sure the timestamp you provide there exactly aligns with the end of the Subscription's billing period, or else you'll end up with prorations for the cancelation.

gentle aspen
#

Yeah I was looking at cancel_at but ended up not using it due to what you say on the prorations

#

Well I'll try with the subscription schedule then but that'd be awesome to have that kind of feature natively

#

It's odd that it isn't actually since it's quite a common use case

#

Thank you for your time and help