#b33fb0n3_error
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/1281174946948841496
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- b33fb0n3_event-plan, 14 hours ago, 47 messages
hi! can you share the full code and the request ID req_xxx from the error message?
Sure, the full code is:
const newSubscription = await stripe.subscriptions.create({
customer: stripeCustomerId,
backdate_start_date: Math.round(currentPeriod.startDate.getTime() / 1000),
trial_end: setTrialEnd(currentPeriod.endDate),
items: [
{
price: process.env.NEXT_PUBLIC_BASIC_SUBSCRIPTION_PRICE_ID,
},
],
trial_settings: {
end_behavior: {
missing_payment_method: 'pause',
},
},
metadata: {
siteId: siteId,
planId: id
}
});
And the request id is: req_AYkWVXr9xJQl5B
but basically it would be because you used backdate_start_date , which generates proration, and that is still charged upfront regardless of the trial , AFAIK, so then payment is required
can't I remove the payment stuff, when it's a trial?
I think the best solution is either
- don't use
backdate_start_date - pass a one-time 100% coupon as well to gurantee no payment required
I just checked the logs again and saw that the same request with the same customer id worked fine (without error): req_nIKMGAreJRZHp0
it's not the same request though, is it? in the first one, trial_end was "now", in that one, it's a date in the future
so actually yeah trial_end:"now" is what caused the payment in the first one, I think. I missed that in the actual request log.
ah that makes sense. But I set the end_behaivor to pause. So it shouldn't collect payments, right?
I don't think so(and you tested it and it didn't)
that's weird...
to me trial_end:"now" on creation of a sub is just pointless and is the same as not using a trial, so you get the normal behavior of requiring payment
I assume it just 'short-circuits' and ignores the other parameter
oh ok. Yea, I wanted to set the trial end to the past, but that doesnt work as well (if the trial of the customer is already done). It's part of a migration process
I guess you expect that backdate_start_date + trial_end:now can somehow model "this subscription already existed and was on a trial that just ended now", but I think backdate_start_date is a very limited-use param purely for calculating proration and doesn't really let you model this, and it's impossible to do this in the product today
ok, I just tested to set the date to unix now (like instead of now the unix timestamp from now) and that works when the api is fast enought. I just added a buffer of 10 seconds, so this should be fine