#rene_unexpected

1 messages ยท Page 1 of 1 (latest)

dry roseBOT
#

๐Ÿ‘‹ 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/1420316940047614004

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

wind zephyr
#

Hi! Do you have the subscription ID?

sudden stag
#

sub_1SAmsZLzRUyRj4fLVyM379VO

wind zephyr
#

Thanks! To confirm your question is why is the subscription not showing at active ?

sudden stag
#

Yes. For some time now, the status is no longer shown as active, but always as โ€œtrials end.โ€

dry roseBOT
hollow flare
#

hi there! I'm taking over from my colleague and just getting caught up on this thread

sudden stag
#

hi. all right. take your time

hollow flare
#

if you have any examples of subscriptions following the other behaviour you described (active during a trial period), I'd be happy to take a closer look at those to see what happened

sudden stag
#

One moment, please. I'll find a customer. It's been a while since the status behavior changed.

#

Here is a sub ID from our test mode that shows the status as active and reflects exactly the behavior I mentioned. During the trial period, a sub is connected, the status is active, but the next invoice will only be issued after the trial period has expired: sub_1S8gP6LzRUyRj4fLZqOiSYA2

hollow flare
#

thanks! taking a look

sudden stag
#

and this is another behavior with the same request body:
sub_1S8hh9LzRUyRj4fLAAmwe2Lb

hollow flare
#

hmm, looks like there was no trial actually applied to that subscription, but I think I see the confusion

looking at the Create Subscription request, no trial was set (i.e. no trial_end or trial_period_days parameters were passed)
https://docs.stripe.com/billing/subscriptions/trials
https://dashboard.stripe.com/acct_1FJelZLzRUyRj4fL/test/logs/req_ZH4cQZigaMLkLJ

you can see this reflected in how the first invoice was not for โ‚ฌ0, and the customer was actually charged at the beginning of the subscription
https://dashboard.stripe.com/acct_1FJelZLzRUyRj4fL/test/invoices/in_1S8gP7LzRUyRj4fLYeexEc9w

but the request does contain a trial_from_plan parameter, which is a legacy field related to now-deprecated Plan objects (i.e. it used to be possible to create subscriptions and have the subscription inherit the trial_period_days from the Plan object
https://docs.stripe.com/api/plans/object#plan_object-trial_period_days
https://docs.stripe.com/api/subscriptions/create#create_subscription-trial_from_plan

however, this subscription was not creating using Plan objects -- instead a Price object was used (which is the current replacement for Plan objects). Price objects do not support trial periods, so you can see that no trial exists on the Price
https://docs.stripe.com/api/prices/object
https://dashboard.stripe.com/acct_1FJelZLzRUyRj4fL/test/prices/price_1OTN12LzRUyRj4fL4n9hFvcb

as such, no trial was applied to the subscription, which is why it had an active status

sudden stag
#

So it has something to do with the 30 trial period days that are stored. We have also entered these trial period days in our live environment.

#

But let's get to the heart of the matter ๐Ÿ™‚ Once the first invoice is created, is the status then automatically set to active? In other words, is the current behavior with the status correct?

hollow flare
#

yes exactyl! if a subscription is created with a valid trial, the status should be trialing, but if the customer is immediately charged then the status should be active

sudden stag
#

Ok. So I don't need to worry about the status and everything is working as it should. Thank you very much for your help. I have another question, if I may.

hollow flare
#

of course, happy to help ๐Ÿ™‚

sudden stag
#

I noticed something today: when a customer registers with us for the first time, they are created in Stripe after onboarding. Recently, however, it has been happening repeatedly that the customer is created multiple times in the exact same second, 2-10 times. Do you have any idea what could be causing this? The code hasn't been changed in a long time.

#

It doesn't always happen. Every now and then, from time to time.

hollow flare
#

that said, I'd be glad to take a look at your code as well if you'd like!

sudden stag
#

So, from what I can see at a glance, my former colleague did not use an IdempotencyKey when creating a customer. Only in a method that writes the Stripe request to the log.

#

Thanks for the explanation. That helps me a lot. I'll take a look at the code and implement the changes.

hollow flare
#

glad to hear!

dry roseBOT
sudden stag
#

Thank you very much for your help, time, and clarification.

hollow flare
#

you're very welcome of course -- if you come across further questions as implementing changes, we're here to help