mikeburgess | Stripe Developers | Page 1

fiery gulchBOT Oct 25, 2023, 11:21 AM

#

soft pawn Oct 25, 2023, 11:22 AM

#

If a trial ends and the subscription does not have a payment method set up, the subscription moves into past_due . Let’s say this happens at 15:00 UTC, if I then try to write a usage record with that timestamp (15:00 UTCon the current date), I get the following error, despite this being on or after the current_period_start .

We continue to see this error for around 2hrs after that, then the issue goes away. But ultimately this means we’re unable to recording usage data for the current period for that ~2hr period of time.

Cannot create the usage record with this timestamp because timestamps must be after the subscription's last invoice period (or current period start time).

hushed scroll Oct 25, 2023, 11:22 AM

#

do you have a request ID req_xxx where you got that error?

soft pawn Oct 25, 2023, 11:23 AM

#

Sure, 1 second...

#

req_pS15dnkQzrzILA

#

In this example the UTC rollover time from trial to past_due was Tuesday, October 10, 2023 8:40:30 PM and that is also the timestamp provided in the request - so the request is on or after the current_period_start?

hushed scroll Oct 25, 2023, 11:27 AM

#

ok so just talking out loud.

The subscription moved to the new cycle after the trial at 1696970430 20:40 UTC
you make that API call at 21:45
in that call you pass the timestamp 1696970430 20:40

#

I guess I don't understand why you'd pass a timestamp at all, I would just report the usage at the current time

#

but looking at the validation that leads to the error message, it's seemingly related to the Invoice for the last period still being in status:draft

#

also I think the docs are wrong and it can't be equal to the time, like not the exact timestamp, in the code we do something like api_call_timestamp < inclusive_lower_bound not <= . So I'd probably not use the exact timestamp and give it a few seconds extra.

soft pawn Oct 25, 2023, 11:33 AM

#

There may be a better way (open to suggestions!), but I write out a daily usage record for midnight UTC to midnight UTC by doing a "set" each time and I set the timestamp to be midnight UTC at the start of that day.

But the only exception is when we're on the first day of a subscription where midnight UTC at the start of the day would be before the current_period_start, so I use the current_period_start value for my record on that first day of the cycle.

soft pawn Oct 25, 2023, 11:34 AM

#

hushed scroll also I think the docs are wrong and it can't be _equal_ to the time, like not th...

also I think the docs are wrong and it can't be equal to the time

It seems to work OK on the first day of a trial - is that because the invoice is immediately "paid" at $0.00?

#

also I think the docs are wrong and it can't be equal to the time, like not the exact timestamp, in the code we do something like api_call_timestamp < inclusive_lower_bound not <= . So I'd probably not use the exact timestamp and give it a few seconds extra.

So if I did that, would I still face an issue though due to the invoice status:draft? What options do we have there?

hushed scroll Oct 25, 2023, 11:38 AM

#

honestly, not sure. sorry, this is pretty deep, I'd suggest writing to https://support.stripe.com/?contact=true as this feels like an edge case I'm not going to have the ability to dig deeply enough into in a quick Discord conversation

soft pawn Oct 25, 2023, 11:41 AM

#

@hushed scroll understood - this has been useful though and gives me a good grounding to go into a convo with the support team. Thanks 👍

#mikeburgess