samwiser_unexpected

[still lava]

👋 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/1308972204360204391

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[surreal sparrow]

I think that's the timezone. Subscription are always attempted by UTC time, +3 then +5 then +7 days. Did you see it is attempted at exactly +3days3hours after the renewal in UTC?

If you can share an example Invoice, we can look closer

[silver lichen]

will try hunt this down, gimme it bit here

[silver lichen]

Invoice: in_1QDMNXGZAJzYwAuyZrCCMZpi

Bit better - you can see the retry time get later and later on each failed payment

I am in New Zealand timezone btw

daylight savings was Sun, 29 Sept 2024, which went to GMT+13 ( instead of +12 )

First failed payment: UTC 8:26 AM, Oct 24, 2024
Last failed payment: UTC 2:59 PM, Nov 8, 2024

So like 7 hours later.

That third attempt pushed it over to a new day in my time zone.
UTC 12:37 PM Nov 1, 2024
NZDT • Your account 1:37 AM Nov 2, 2024

[surreal sparrow]

Thanks, can you paste those 4 events (evt_xxx) here in text?

[silver lichen]

evt_3QDMNaGZAJzYwAuy0lb517nU
evt_3QDMNaGZAJzYwAuy0Ke5FUqH
evt_3QDMNaGZAJzYwAuy06Wj89Ve
evt_3QDMNaGZAJzYwAuy0P0szLud

An attempt to fulfill the payment pi_3QDMNaGZAJzYwAuy0mmhXB0Y for $167.65 NZD failed evt_3QDMNaGZAJzYwAuy0lb517nU 11/9/24, 3:59:25 AM
An attempt to fulfill the payment pi_3QDMNaGZAJzYwAuy0mmhXB0Y for $167.65 NZD failed evt_3QDMNaGZAJzYwAuy0Ke5FUqH 11/2/24, 1:37:24 AM
An attempt to fulfill the payment pi_3QDMNaGZAJzYwAuy0mmhXB0Y for $167.65 NZD failed evt_3QDMNaGZAJzYwAuy06Wj89Ve 10/27/24, 10:37:28 PM
An attempt to fulfill the payment pi_3QDMNaGZAJzYwAuy0mmhXB0Y for $167.65 NZD failed evt_3QDMNaGZAJzYwAuy0P0szLud 10/24/24, 9:26:52 PM

I get that smart-retries would change the time it attempts to bill the card, but I would have expected manual retries to retry at the original sub time.

[surreal sparrow]

Okie so, first let's look at the corresponding Invoice events, to each of those, for example,
evt_1QDMNdGZAJzYwAuySLzJ2x1R
evt_1QESudGZAJzYwAuybye2Zptx
evt_1QGK6UGZAJzYwAuyAiN63d6l
evt_1QItekGZAJzYwAuyBPTnaYaJ

each of those invoice.payment_failed has a field next_payment_attempt, point the exactly next Invoice in chain timestamp

So we did modify the schedule, based on our learning and predictation for successful, but we provide that beforehand in the Invoice events

[silver lichen]

Yeah I get that there is next_payment_attempt , can I not prevent it from adding hours to the retry schedule ?

As we tell clients up-front that its 15 days to retry up-front. but then in some cases that pushes over

I know it seems like knitpicking, but that's not "retry 3 days and 1-3 hours after the previous attempt"

Because it's already manual retry schedule, why start trying to change the time of payment?

[surreal sparrow]

Sorry in a MTG, will be back soon

[silver lichen]

all good man, no rush here

[surreal sparrow]

So... the general answer would be please listen to the next_payment_attempt and notify your customer based on the exact timing here, to avoid their confusion.

But I hear you that you want it to be the exact time. I believe we do some adjustment, but we can dig deeper on why those timing has been dragged apart for a few hours

Do you have some more recent examples? Or do you see it happen consistently, or just that one?

[silver lichen]

yeah it's happening more and more. It's not super common, because to happen:
The sub needs to originally be signed up later in the day ( although we already have limited time to start the sub due to UTC )
It then needs to fail, likely more than once.

However, as our subscriber counts go up, this edge case is less edgy.

This is an example of the incorrect information we are providing. Because the top date is accurate based on days, but the bottom date is the next attempt at. Since stripe changes the retry time, it can invalidate the top date, but that's not always the case, as I am not 100% sure on the lag of the retry payments

I think this has cropped up 4 times in the last month / month and a half, so it's on the increase.

I would like to understand more on why the time is getting dragged out, as it makes it much harder to reason with.

[surreal sparrow]

Wait, so you use the top date or the bottom date from next_payment_attempt? I see next_payment_attempt was accurate on each of the events on chain:
evt_1QDMNdGZAJzYwAuySLzJ2x1R says 1730021847 = Oct 27 9:37 UTC
evt_1QESudGZAJzYwAuybye2Zptx says 1730464642 = Nov 1 12:37 UTC
evt_1QGK6UGZAJzYwAuyAiN63d6l says 1731077963 = Nov 8 14:58 UTC
evt_1QItekGZAJzYwAuyBPTnaYaJ says null, because it won't be retried

[silver lichen]

I use the bottom date for next_payment_attempt

The top one was a basic + 15 days from payment failed date.

But our clients gets this failed payment email each time the payment fails, and it's pretty weird if the original auto-cancelling date changes after the second failed payment

[surreal sparrow]

Ah I see, so you are calculating the sum of all retries days and make that auto-cancelling

[silver lichen]

Plus all our support copy is the same as

But more like - you have 15 days before it auto lapses

[surreal sparrow]

Could you provide some other example, when it went exactly UTC time and time? It would help us on comparison and investigation

[silver lichen]

can do

[silver lichen]

Hey,

Does this work ?

https://dashboard.stripe.com/invoices/in_1QDMNXGZAJzYwAuyZrCCMZpi
[e-mail]'s payment for an invoice for $167.65 NZD failed evt_1QItekGZAJzYwAuyBPTnaYaJ
NZDT 11/9/24, 3:59:25 AM
UTC 2:59 PM Nov 8, 2024

[e-mail]'s payment for an invoice for $167.65 NZD failed evt_1QGK6UGZAJzYwAuyAiN63d6l
NZDT 11/2/24, 1:37:25 AM
UTC 12:37 PM Nov 1, 2024

[e-mail]'s payment for an invoice for $167.65 NZD failed evt_1QESudGZAJzYwAuybye2Zptx
NZDT 10/27/24, 10:37:30 PM
UTC 9:37 AM Oct 27, 2024

[e-mail]'s payment for an invoice for $167.65 NZD failed evt_1QDMNdGZAJzYwAuySLzJ2x1R
NZDT 10/24/24, 9:26:53 PM
UTC 8:26 AM Oct 24, 2024

https://dashboard.stripe.com/invoices/in_1QDLniGZAJzYwAuyoks1n3PZ
[e-mail]'s payment for an invoice for $288.91 NZD failed evt_1QGK8IGZAJzYwAuyEFcVoZ9k
NZDT 11/2/24, 1:39:18 AM
UTC 12:39 PM Nov 1, 2024

[e-mail]'s payment for an invoice for $288.91 NZD failed evt_1QETmcGZAJzYwAuydipilJ0s
NZDT 10/27/24, 11:33:18 PM
UTC 10:33 AM Oct 27, 2024

[e-mail]'s payment for an invoice for $288.91 NZD failed evt_1QDLnpGZAJzYwAuyfh0AZj5s
NZDT 10/24/24, 8:49:53 PM
UTC 7:49 AM Oct 24, 2024

https://dashboard.stripe.com/invoices/in_1QDNC8GZAJzYwAuyIFLeRebp
[e-mail]'s payment for an invoice for $299.41 NZD failed evt_1QIwtPGZAJzYwAuyYAepReU4
NZDT 11/9/24, 7:26:46 AM

UTC 6:26 PM Nov 8, 2024

[e-mail]'s payment for an invoice for $299.41 NZD failed evt_1QGNCtGZAJzYwAuyHAxcn2mU
NZDT 11/2/24, 4:56:15 AM

UTC 3:56 PM Nov 1, 2024

[e-mail]'s payment for an invoice for $299.41 NZD failed evt_1QEVTtGZAJzYwAuyXsY01rO2
NZDT 10/28/24, 1:22:04 AM
UTC 12:22 PM Oct 27, 2024

[e-mail]'s payment for an invoice for $299.41 NZD failed evt_1QDNCFGZAJzYwAuyoVYOq3ZA
NZDT 10/24/24, 10:19:11 PM
UTC 9:19 AM Oct 24, 2024

What's the process from here?

[surreal sparrow]

Um all of these examples has the delays of a few hours, correct?

[silver lichen]

yeah correct, these have delays, and push our nz time into the next day

I can find more examples if need be

sorry, the ordering is hard

[surreal sparrow]

I would like example that didn't have delay

[silver lichen]

I think everything has a delay right?

[surreal sparrow]

Sorry, I know there is a lot of hassle to pick them

[silver lichen]

its just that these subs get effected by the delay to push into the next day

I will double check this, just leaving to go home, then I will update this thread.

[surreal sparrow]

Sure. We may close the thread after an amount and inactive time, but feel free to create a new one and my team can reference to this past thread

[silver lichen]

Sorry, just got home. Yeah from my understanding, every failed payment gets an increased lag per failed payment ( for the same invoice )

Is that your understanding too ?

[surreal sparrow]

Yes, and if you have proof of failed payment was on nearly exact timestamp before, but changed recently, it would be easier to investigate

[silver lichen]

Yeah I am not saying they are on the exact timestamp, I am saying they never are, which is the problem.

[e-mail]'s payment for an invoice for $233.90 NZD failed
evt_1QNAtaGZAJzYwAuyC9w11fyY
11/20/24, 11:12:25 PM

[e-mail]'s payment for an invoice for $233.90 NZD failed
evt_1QLKD3GZAJzYwAuykKEcTzCN
11/15/24, 8:44:53 PM

[e-mail]'s payment for an invoice for $233.90 NZD failed
evt_1QKCGLGZAJzYwAuyWaUx3dgQ
11/12/24, 6:03:36 PM

This is a recent failed payment, and its a couple hours each time after

which looks to be about standard. But what I am after is preventing that lag per failed payment. Because it knocks over into the next day based on my timezone.

[surreal sparrow]

Thanks. My colleague is catching up and we will continue to assist

[versed surge]

Hello! To clarify, at a high level, Stripe has a queue for automatically processing subscription charges. I understand that you’re experiencing increasing latency, but unfortunately, we cannot guarantee a specific time for when a customer will be charged.

You can reach out to Stripe Support (https://support.stripe.com/contact) to report the increase in latency you’re noticing, and we can flag it to the relevant team. However, there's no guarantee that we can make any changes in the near future such that the timing of the charge is more specific.

I recommend communicating with your customers about the potential for delays, that payment attempts may extend into the following day.

[silver lichen]

Thanks for the response @versed surge .

I guess what I am really trying to understand is, what is the business logic for adding successive delay to each failed payment ( incrementing 1-3 hours each time).

I understand adding the payment to the queue, but should it not base that retry off the original payment failed timestamp ? ( this would prevent the majority of the failed payments falling into another day )

[versed surge]

I don't know the exact logic off the top of my head, but if you write in to Stripe Support - https://support.stripe.com/contact, they'll look into it and get back to you on that

[silver lichen]

yeah kk, thanks. Just seems wild to me that you even add the delay to scheduled retries.
It's just turning into a bit of a pain-point for us and I am getting pretty frustrated as it seems out of my ability to control, and confusing to our end client.

I do appreciate your help in trying to resolve it.

[versed surge]

If things don't work out and you really need it to occur at a more specific time, maybe you can consider implementing your cron job to retry instead. You can call https://docs.stripe.com/api/invoices/pay

[silver lichen]

Interesting, would that increment the retry count and still auto-cancel if it fails after x retires ?

[versed surge]

manually attempting payment won't increment the retry count. You'll want to adjust your subscription settings too to account for this. In case you haven't seen this yet, you can use test clocks to mimic the passing of time : https://stripe.com/docs/billing/testing/test-clocks and test to see how things work

to answer your question, if you don't set automatic retries, and you set the subscription to auto-cancel after all retries fail, it should immediately cancel after the first attempt fails

[silver lichen]

hmmm. yeah cool, I think I am going to have to work some how tell clients that it's not always 15 days, as that seems like a rather drastic alternative 😐

thanks for your help.

[versed surge]

you're welcome!