#ibgoldbergs
waxen tapirBOT
Hello! We'll be with you shortly. 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.
- ibgoldbergs, 2 days ago, 15 messages
- ibgoldbergs-subscriptions, 2 days ago, 28 messages
robust prawn
Hi there 👋 apologies for the delay, took a little bit to digest the scenario.
stable wraith
👋 All good. Let me know if you have clarifying questions
robust prawn
Hm, that is tricky, because our system does assume that a trial period is expected to progress to an active Subscription afterwards.
One approach is to put the trial in Stripe until you're confident it will lead to payments, allowing you to manage the state of those on your end giving you full control of the logic you implement.
But if you'd rather continue doing this in Stripe, that should be possible too.
I'm not sure offhand if cancel_at_period_end will end at the end of a trial period, or if it will cause the Subscription to be canceled at the end of the next billing period. You can test that using test clocks to make see exactly how it would behave:
https://stripe.com/docs/billing/testing/test-clocks
You should also be able to check cancel_at once you set cancel_at_period_end to see when the Subscription is scheduled to cancel:
https://stripe.com/docs/api/subscriptions/object#subscription_object-cancel_at
one more approach coming, but juggling a lot so may take me a second to type out
stable wraith
Yeah we definitely want to use Trials within Stripe. We had built a system outside of Stripe prior to this but Trials give us so many benefits that its worth us trying to find a solution.
robust prawn
The other approach that comes to mind is to use Subscription Schedules. They wrap Subscription objects so that you can schedule future changes for those Subscriptions that will automatically occur. Those Subscription Schedules are built on the concept of phases. My thinking is that you could create a single-phase Subscription Schedule, that has the entire phase set to be a trial:
https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-phases-trial
and an end_behavior of cancel
https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-end_behavior
So if nothing changes, the Subscription is cancelled at the end of the Schedule's phase.
If your customer decides they'd like to continue to a paid Subscription, then you can add another phase to the Subscription Schedule, that will start when the first phase ends. You can also change the end_behavior at that point to release so the Subscription is released from the schedule (rather than being canceled) at the end of the Subscription Schedule's phases.
stable wraith
Hmm its interesting because we already wrap the trial in a phase today... and when the client signs up, we just enter a new phase at trial end.
Basically we could create logic where IF the only phase === Trialing phase, set the end behavior to cancel. ELSE continue to the next phase.
Just one more idea, that I'd like your opinion on...
When we create the trial subscription, maybe we can do so without attaching the default payment method. This way, at the end of the trial, Stripe won't have a payment method to charge automatically? I'm unsure if the subscription will charge the default payment method on the customer if its not set on the subscription itself.
Once the customer provides explicit consent through our UI to continue with a paid subscription, can we then update the subscription to attach the default payment method or ask the customer to provide a new one?
robust prawn
Oh, sorry, I didn't even think to ask if you were already using Subscription Schedules, could you share an example of one of those so I could take a closer look?
stable wraith
can I send you a test customer ID?
or whats the best way to share?
Maybe this helps
robust prawn
If you have the ID of the Subscription Schedule that'd be best.
Yup that one, thank you!
stable wraith
Here's the event of when the customer gives explicit approval to charge after trial: evt_1OIePKFNVbYFceRMWu78lRSl
robust prawn
Hm, so there it looks like the Subscription was created first with a trial period, so the resulting Subscription Schedule was created with two phases, one for the trial and one for the rest of the Subscription.
Are you able to update that Subscription Schedule, mostly changing phases to try to delete the second phase? You'll need to pass the contents of the current phase that you don't want to adjust as part of that request (if you omit them, the API will try to unset the values for the current phase) but only provide a single phase.
stable wraith
Well the event I sent is when the customer gives explicit consent to bill them at trial end.
It seems like today we are not actually creating a schedule when the trial is first created. We are just creating the subscription with a trial.
Perhaps what you are saying is... when we first create the subscription. wrap the trial in a phase, and set it to cancel at the end of the phase... BUT when a customer gives consent, continue to do what we are doing today in that event.
Does that track?
waxen tapirBOT
robust prawn
Oh, I think part of this just clicked for me. When you say customers can explicitly decide whether they want to continue with a paid subscription, is that something they have to decide when signing up for the trial, or is it a decision they can also make afterwards?
stable wraith
Well we actually put them on the trial on our end. It's not something the customer initiates themselves. They then sign up via our UI, which should give the explicit decision to continue with a paid subscription
robust prawn
If they can't choose to continue to a paid subscription in the middle of the trial period, then setting up Subscription Schedules for that may not offer much benefit. I was thinking of them because they have the flexibility of being more adjustable.
stable wraith
They can choose during the trial, which is why we create the paid phase to start after the trialing phase IF they explicitly sign up
But it does sound like we should...
- Wrap the initial trial in a phase on the schedule, with end behavior to cancel
- When the client signs up via our UI, we overwrite the schedule so that it no longer cancels at trial end, but instead moves into a paid phase
Does that make sense?
robust prawn
Wrap the initial trial in a phase on the schedule, with end behavior to cancel
For this to work, it will need to be a single-phase Subscription Schedule. Theend_behaviorcontrols what happens at the end of the Subscription Schedule's full list of phases, not at the end of the current period. So if there are multiple phases (like a trial and paid phase) andend_behavioris set tocancel, it is expected for the Subscription to fully progress through all phases before cancelling the associated Subscription.
stable wraith
Yeah it makes sense. Basically this is how we would set it up:
- When we create the trialing subscription initially, we wrap the trial in a phase, and end behavior is to cancel. There are no phases afterward
- IF the customer signs up during the trial, we will overwrite the existing schedule with a new schedule with two phase. First phase to continue the trial until trial end, and at trial end, we start the second phase to put the customer on the price they signed up for, charging the default payment method
That seems like it would work?
robust prawn
For the second part, I'd update the existing Subscription Schedule rather than creating a new one, but what you described should work as well.
I'm going to spend a couple minutes running a quick test just to make sure you're able to create a schedule with only a single trialing phase (I don't think I've personally tested that recently).
stable wraith
Yeah that's what I meant by "overwriting the existing schedule". Makes sense to use the schedule that we already created.
Let me know what you find, I appreciate it.
you've been a solid thought partner on this complex logic
robust prawn
Glad I could help! I just created a Subscription Schedule with a single phase, where trial is true so the whole phase is a trial period, and set end_behavior to cancel. I'm seeing that the Subscription that created is scheduled to end at the end of the trial period, so that all looks the way I was hoping/expecting.