#t0dd_unexpected
glacial willowBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1248584532937150556
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
low vale
Here is an affected customer: cus_OWVA5SaYwgxYbR
Our Stripe account: acct_1MWobYLVMiFmGBXg
viral agate
hi! that customer has a ton of activity, could you maybe scope it down for me a bit? what's an example invoice in_xxx with an item that you didn't expect?
We emailed our representative and they said that our billing cycle anchor changed when we confirmed that was not the case.
if you're already in touch with someone maybe they can help directly?
but like for example, https://dashboard.stripe.com/logs/req_AUJVx8URFravEb
that did change the billing cycle, since it moved from an interval:day Price to an interval:week one
low vale
But the billing cycle anchor before the update was the same no?
Or is the only difference that we moved from days to weeks?
Sorry, wrong screenshot. This is before the subscription update:
We migrated subscriptions at 5/14 this is as 5/8 event showing same billing cycle anchor
viral agate
maybe I'm wrong then. So to go back to it, can you give a more specific example of an invoice + invoice item you didn't expect?
low vale
Sure, this is the one we didn't expect pi_3POgEeLVMiFmGBXg0Marin9T
Actual invoice sent at the same time pi_3POSu6LVMiFmGBXg0w7iXcer
viral agate
what don't you expect, the invoice item for Unused time on FreebieFlow after 06 Jun 2024 ?
low vale
If we had a payment go through on 06 Jun 2024 shouldn't the charge be a month later?
What unused time can there be after a subscription just starts
viral agate
well you did do this : https://dashboard.stripe.com/logs/req_udZEU3iF6yoL0A , which is where that specific line item I mentioned got created
low vale
Right, but it replaced the old item and there was a subscription charge with the same item on 06 Jun no?
low vale
well you did do this : https://dashboard.stripe.com/logs/req_udZEU3iF6yoL0A , wh...
Huh
We didn't manually do this
What could cause the billing cycle anchor to be reset?
Never mind. I see now
viral agate
What unused time can there be after a subscription just starts
you reset the anchor to the current time a few seconds after the subscription started, so the amount just paid gets refunded, and then a new period is started and is charged for
low vale
So this has nothing to do with the subscription update?
viral agate
sorry, not a few seconds, three days
low vale
Hmm, forgot why I wrote the logic initially for updating the billing cycle anchor
I assume it's because of failed payments and stuff
If a user fails on Jun 5th and then pays on Jun 8th we update the billing cycle anchor
This could cause confusion though
Maybe we should update to 5 days or something
Do you think that's a good idea?
viral agate
I'm not sure, I don't follow the use case
low vale
Yeah this might just be redundant. I think the use case is that if a person pays a subscription later than one hour we make sure to charge for the amount of time in between the payments.
And so that their new payment is in 4 weeks not in 3 weeks if they only paid the invoice after a week
Wondering what would be the better way to handle something like this
Since we just charged the $1.1 for the day in between this I think
viral agate
I don't think we have a specific answer there, it's not our model for how subscriptions work. When a new period starts, the customer immediately owes the amount for that new period and we charge them for it. Then there can be some retries if that payment failed. We wouln't really expect you consider that unpaid time or try to shift billing dates because of it, that just isn't the model. It's why for example we say in https://docs.stripe.com/billing/subscriptions/webhooks#active-subscriptions that your code for handling payments on an invoice should "[update] the customer’s access expiration date in your database to the appropriate date in the future (plus a day or two for leeway)."
low vale
49(sub price) / (28*24)/12(hours in between charges) = 1.14
So makes sense
Thank you for your input. I think we will just disable this part of the logic.
You can close the ticket now. Thanks again for the help.
viral agate
happy to help!