#hutch_best-practices
1 messages ¡ Page 1 of 1 (latest)
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1235721336467357767
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
@naive crane can you share your exact code with clear example object ids I can look at?
Yes preparing
customer: stripeCustomer.value.data.id,
client_reference_id: authUser.user.id,
line_items: [
{
price: portalPassPrice.value?.id,
quantity: 1,
},
],
mode: 'subscription',
subscription_data: {
billing_cycle_anchor: Math.floor(getNextJanuaryFirst().getTime() / 1000), // Anchor billing cycle to next January 1
proration_behavior: 'none', // Disable proration, otherwise it will try to chartge them less than the full amount since there is less than a year left until the billing anchor
},
success_url: `${config.public.baseUrl}/confirmation/subscription`,
// return_url: `${config.public.baseUrl}/my-account?checkout_action=return`,
cancel_url: `${config.public.baseUrl}/sign-up`,
};```
This gets posted to the create checkout sessions endpoint
Here's a checkoput session I complete that only charged $0.00, when it was intended to be the full cost of the subscription
cs_test_a1XHf7a0Y3LOZ52qlzx1Ez9CWcaxqATDxEUCyZjNrtvvORoe5YaR2bEVEI
Okay so that's expected. You're explicitly telling us to defer the Subscription to start on January 1st here and you tell us "don't prorate for the partial time between now and January 1". That means nothing is charged.
It's impossible with Checkout to start a Subscription now for the full Price but have it anchored to Jan 1st.
Only thing you can do is start the Subscription for the year now (no billing_cycle_anchor) and after that update the Subscription to make sure it resets back to a full year on January 1st. But that would be a bit confusing in the UI unfortunately
OK, thanks a ton for clarifying how that works. When you say:
update the Subscription to make sure it resets back to a full year on January 1st
Can this be done programmatically through the API or would this require action through the Stripe dashboard? Either way, what would this process involve?
yes after the Checkout Session completes you can use the SubscriptionSchedules API https://docs.stripe.com/billing/subscriptions/subscription-schedules and plan the next phase to reset on January 1st
OK, and if I were to do this through the UI, what is the correct process for this?
I imagine we will end up taking the UI route in the short term
This is going to be tough because the Stripe Checkout UI will lead the user to believe that they are subscribing for a full year, not until Dec 31.
yeah I really wouldn't do that if I were you, I just told you how to do it if you really wanted to
Wouldnt the checkout page still show a misleading date since the subscription schedules request would get made after checkout completes?
Sounds like there's no way around that
yes that's why I would never do this if I were you
OK. Thank you for the advice
I am considering a path where I make this new price point a one-off product, and subscribe them to our existing subscription price, but for free.... Does that sound like a bad idea?
Just want to avoid misleading them in any way possible
yeah that works too but that's another hack, the UI will not make sense to them if you do that
The new price point includes all the features from the price point I would give them for free -- if I went down this route what is the best way to make that subscription free?
set trial_start to the same January 1st timestamp and add an extra line item for the one-off price
I see what you mean they would get the trial messaging in the checkout in that case right?
It feels like ultimately this new price point belongs as as a one-off product independent of subscription.... would you agree?
My system just needs to deny access after January 1 and we can add another one-off at that point... Does that sound like a good path forward?
that's up to you really. I'm sorry you're trying to fit an uncommon payment flow onto Checkout that doens't really support it
the workarounds I gave you work but each come with downsides. You can test it all in Test mode
OK. TY