#solidjs
errant dawn
hi, thinking...
have you considered using a SubscriptionSchedule to set up that the Subscription itself will only be created at a certain time?
https://stripe.com/docs/billing/subscriptions/subscription-schedules
quartz flower
I don't think I have no. We are using the checkout api in fact
Would you think it would be a lot of changes?
errant dawn
it would, since Checkout doesn't support creating SubscriptionSchedules
quartz flower
I think the webhooks we work with would also need changes since there would be different events
errant dawn
you could use Checkout in mode:setup to just collect the payment information like the card, and then create a Schedule in the backend, but it will have the issue of the Checkout page not being entirely clear that a Subscription will be created, so you'd need to carefully message this on your page before and after Checkout
quartz flower
they were wondering if we could just change the text stripe shows on the checkout page instead but I don't think that is possible
also. how different would the checkout page be with subscriptionSchedules ?
because what we have atm is in fact working as intended except the text on the checkout page
it would be pretty costly time/development wise to migrate to that I imagine
errant dawn
well if using mode:setup the Checkout page will not mention Subscriptions or recurring billing dates or anything, it's just a generic way to accept the card details, the messaging about recurring payments has to happen outside of Checkout on your pages.
Or as you say, maybe stick with using a trial period, or trying to change your overall model (maybe don't allow customers to create a subscription more than 7 days in the future, so you can keep using the billing_cycle_anchor) approach. Or use Schedules and build a csutom payment page.
There's not perfect solution here unfortuantely.
quartz flower
have you considered using a SubscriptionSchedule to set up that the Subscription...
this solution
wouldn't be perfect? apart from the time/development it takes
not mode:setup but completely migrating to that approach
would there be any issues
devout pineBOT
quartz flower
my bad if I'm asking many questions
errant dawn
it's all good, but I'm not clear exactly what you're referring to.
quartz flower
without needing a custom payment page
managing to have orders from up to 30 days before at the same time as having the checkout page not confusing to this context
should we offer a migration to SubscriptionSchedules
quartz flower
it's all good, but I'm not clear exactly what you're referring to.
thank you
errant dawn
still not sure what specifically you're asking. I mentioned a few different approaches , none of them are perfect. Happy to try to elaborate or dig deeper into something!
quartz flower
why aren't they perfect
quartz flower
have you considered using a SubscriptionSchedule to set up that the Subscription...
is there any issue with this method
in this case
errant dawn
why aren't they perfect
because we don't live in a perfect world where the Stripe subscriptions product fits every use case unfortunately , there are always going to be edge cases but we can try to weigh the options and find the best existing solution 🙂
quartz flower
thank you so much
errant dawn
is there any issue with this method
the main issue is that there's no native support for Schedules in Checkout, so it requires an approach like using mode:setup for setting up the card and then creating the Schedule on the backend, and like I said : "well if using mode:setup the Checkout page will not mention Subscriptions or recurring billing dates or anything, it's just a generic way to accept the card details, the messaging about recurring payments has to happen outside of Checkout on your pages."
quartz flower
what if we don't use checkout
errant dawn
then you can build a custom payment page where you build all the logic and UI for displaying the billing dates and other context and just use Elements to collect the card details, and create a Schedule on the backend.