#rene_unexpected
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/1420316940047614004
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi! Do you have the subscription ID?
sub_1SAmsZLzRUyRj4fLVyM379VO
Thanks! To confirm your question is why is the subscription not showing at active ?
Yes. For some time now, the status is no longer shown as active, but always as โtrials end.โ
hi there! I'm taking over from my colleague and just getting caught up on this thread
hi. all right. take your time
it's expected behaviour for a subscription to have status: 'trialing' during a trial period, as the active status generally refers to a paid subscription in good standing: https://docs.stripe.com/billing/subscriptions/overview#subscription-statuses
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
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
thanks! taking a look
and this is another behavior with the same request body:
sub_1S8hh9LzRUyRj4fLAAmwe2Lb
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
apologies, I send the wrong Price ID/link above (though the explanation still applies)
this was the Price object used to create the subscription: https://dashboard.stripe.com/acct_1FJelZLzRUyRj4fL/test/prices/price_1Rq9SULzRUyRj4fLIc3VOqXz
sub_1S8hh9LzRUyRj4fLAAmwe2Lb on the other hand was created with a trial, as the associated Price object does have a trial_period_days value set (though this legacy feature is no longer recommended)
you can see that the subscription had status: 'trialing' on creation
https://dashboard.stripe.com/test/logs/req_jIzHEfh1nTUWn7
https://dashboard.stripe.com/acct_1FJelZLzRUyRj4fL/test/prices/price_1JLOjBLzRUyRj4fL2FSa5bew
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?
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
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.
of course, happy to help ๐
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.
sounds like duplicate API requests being sent by your code most likely
the solution we generally recommend is implementing idempotency: https://docs.stripe.com/api/idempotent_requests
that said, I'd be glad to take a look at your code as well if you'd like!
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.
glad to hear!
Thank you very much for your help, time, and clarification.
you're very welcome of course -- if you come across further questions as implementing changes, we're here to help