#niceone_unexpected
earnest patioBOT
đ 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/1417168758241497259
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
steady flower
this is the event Stripe received: https://dashboard.stripe.com/acct_1HMaNtL7qyU6wPqu/logs/req_qB3dXqNlDKfNXb there you can see there is a info about trial which ends on 18th August,
and this is what the user claimed to see:
visual pilot
Have you been able to reproduce this yourself when testing? Unfortuantely this server doesn't have much context on how UI like this is rendered, so I'm not sure at what point we say 2 days instead of 3 here. One thing that may help is that we do have a trial period days param which should always set that timestamp far enough out
https://docs.stripe.com/api/checkout/sessions/create?api-version=2025-08-27.basil#create_checkout_session-subscription_data-trial_period_days
steady flower
but isn't is so that this page is rendered by Stripe?
visual pilot
It is, but unfortunately the team on this server doesn't know much about how our UI is rendered. If you can consistently reproduce this behavior, then that is definitely something you can raise to our support team and they can file with the team that builds that UI
steady flower
ok I'll try
but this one is not enough?
https://dashboard.stripe.com/acct_1HMaNtL7qyU6wPqu/logs/req_qB3dXqNlDKfNXb
visual pilot
Like I think the best way to report this would be to say "I created cs_test_123 at x time with a trial_end date of y which is 3 days later"
steady flower
here you have information what we are sending to you
btw. we are sending "trial_end": "1755533741"
not trial_period_days
(as it could be that the customer will set trial duration in our system like 2days and 3hours etc.)
how to raise the issue to the support team?
visual pilot
Have you tested this yourself in test mode and consistently seen the same behavior? Testing myself now
steady flower
no, I can try it tomorrow if needed (for now, the user of our client tested it on production :))
visual pilot
Should be able to test in a sec
earnest patioBOT
steady flower
any luck with test?
visual pilot
Yep, I can actually reproduce this. It looks like we start rendering it as "2 days" when the trial_end timestamp that is passed just under 72 hours away. Like I need to set the trial_end to 72 hours + 3 minutes to get it to show "3 days" initially but if I reload a minute or two later it says "2 days" again
visual pilot
Yep I can file something, though unfortunately I can't promise when/if this will be addressed. I am seeing the UI say 3 days for much longer so that parameter could help as a workaround in the special cases where you are using day increments but I get if that isn't viable for your usecase
steady flower
hm I'm not sure if I got it: "I am seeing the UI say 3 days for much longer so that parameter could help as a workaround in the special cases where you are using day increments but I get if that isn't viable for your usecase"
you mean it works better if 'trial_period_days' is used instead of 'trial_end' ?
visual pilot
Exactly, using trial_period_days seems to work differently than setting a timestamp three days out.
steady flower
yes but we need to allow our client to define trials also with hours
digital steeple
Hi there, I'll be taking over for Pompey here, who needs to step away