#jessa_best-practices
honest surgeBOT
👋 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/1281317386972172384
📝 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.
- jessa_webhooks, 6 days ago, 11 messages
ornate scarab
Hi 👋
Our billing engine performs asynchronous billing and there may be seconds or minutes (or even hour long) delays so relying on timestamps down to the minute may not be feasible.
It's a little difficult to discuss this in abstract. Can you share a Subscription ID so we can review an example?
fierce badger
Sure, let me get one
@ornate scarab sub_1Op031HWIVnaCUOBeaXkkwoJ -- when the payment on July 29 was made, the period_end was 1722222758 - Aug 28 23:12:38 (local time)
The next payment was made at 1724904831 which is Aug 29 00:13:51 (local time)
So the subscription period ended at 11:12pm and was not paid again until 12:13am the next day.
We have a cron job that expires memberships each night at 11:59pm if the payment has not been made for the next period, so these are causing issues.
ornate scarab
These are the events I'm seeing for this Sub. FYI all our times are reported in UTC
invoice.paid- 2024-07-29 04:14:58invoice.paid- 2024-08-29 04:13:55
The 1m 3s delay between the two is normal and your integration should take this into account.
I do see that the Sub's previons current_period_end was 2024-08-29 03:12:38
Which is more significant
But still within expected bounds
fierce badger
yes, was just typing that -- thats our issue
ornate scarab
I'm curious what the scenario you are guarding against is. I would focus on whether or not the Invoice has been generated (the customer has an opportunity to pay) and has not been paid.
fierce badger
when a subscription period is paid for, we need to set the end date of that subscription in our backend so we can stop providing member benefits after that date. we'll then extend the end date when the next payment is made.
when we receive the invoice.paid event, we set the end date to 11:59pm on the current_period_end value specified by stripe. when the payment is then made over an hour later than the period_end, the membership has already expired on our side, which is triggering emails to the customer, etc.
I think an easy fix would be if we can add X hours to the period_end specified by stripe, before calculating the end date. What's a reasonable max differential between period_end and the next invoice.paid event? 3 hours? 4 hours?
ornate scarab
3 hours should be sufficient. We rarely do have scenarios where recurring billing goes over that but we usually show a downgraded status here: https://status.stripe.com/ when that occurs
fierce badger
Ok great, thank you! I might make it 4 to be safe.. appreciate the help.
FWIW We'd been (reasonably) assuming that the next payment will be charged a short time before the period has ended to provide uninterrupted subscription periods. The fact that the payment is charged after the period has ended wasn't apparent until this issue popped up -- you may want to mention that in the docs (if it's already there, my bad for missing it).