#kakos_api

1 messages ¡ Page 1 of 1 (latest)

vestal karmaBOT
#

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

📝 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.

stiff wing
#

Hello can you send me the ID of the subscription? (sub_1234)

sly skiff
#

sub_1QgtBIC4wSV3tjamIaG9fdg0

#

its in a sandbox enviroment

#

do I need to include any more Ids due to the sandbox enviroment?

#

relevant priceId price_1QgtAFC4wSV3tjamu2D96WfF

stiff wing
#

Nope, that ID is enough to look it up. Though now I do see this blurb in our docs, so it does sound like it is expected behavior for it to take some time for it to be reflected in the dashboard:

Stripe processes meter events asynchronously, so aggregated usage in meter event summaries and on upcoming invoices might not immediately reflect recently received meter events.
https://docs.stripe.com/billing/subscriptions/usage-based/recording-usage#record-usage

sly skiff
#

I have advanced it 3 days with the time clock

#

so thats why I was worried I did something wrong

#

I just advanced it 1 more week and still is 0,
did I set up correctly the price with the meter?

#

or maybe I have missed something

stiff wing
#

It may not be recency in test clock time, this may come down to real world clock time. I will see what I can find on this

sly skiff
#

thank you!!!

#

hmmm since its the same as the v1 in terms of code, I mean if we can not simulate the future if I swithc back to the v1 just for testing and then back to v2 I should be fine? just a follow up question if nothing can be done about the async events.

#

the first one just arrived, seems is indeed in real time clock

stiff wing
#

Ah there we go! Yeah we try as best we can to simulate everything that happens during the test clock advancement but considering how high volume that API can be I can see why that happens like that now

sly skiff
#

hmm I see, so do you recommend for dev puproses I switch to v1 and then once I have completed the feature to switch back to v2

#

so i will not have to wait the real time clock while developing it?

#

or its just a bad idea overall to do so?

sly skiff
#

also a follow u question that just came accross my mind. What will happen if lets say 1 seconds before the end of the subscription there was a trigger to increase the usage unit. Since they async event takes time it will not be included in the invoice to be paid for this cycle of the subscription?

#

or such edge case are not able to be created?

stiff wing
#

Good question, my guess is that it would be applied to the next invoice if there is one but I will double check

sly skiff
#

Thank you!!!

#

yes if there will not be a next invoice. I am curious to what happens next? does it say uncollective? since the customer stated to end the subscription at the end of the cycle ?

#

so in theory they still legally own money towards the business? etc

#

just some edge cases I am worried about

stiff wing
#

Oh wait, I just remembered that invoices have a one hour draft period. I am still looking but my guess is that it would be captured and added to the invoice during that time.

sly skiff
#

ohhh I seee

#

thank you for helping me! I will be awaiting your response!

stiff wing
#

Okay I think we get at this question albeit a bit indirectly in this doc on grace periods. Basically you can give yourself a longer grace period to report usage by extending how long invoices are in a draft state. We say that usage reported with a timestamp that is during the subscription's period but before the draft invoice was created will get added to the current invoice. Usage with timestamps after the invoice was created will get added to the next invoice.
https://docs.stripe.com/billing/subscriptions/usage-based/configure-grace-period#add-usage-to-draft-invoices

#

Though I guess that kind of just pushes back the problem of what you are talking about. Like what if you reported usage during that time period but right before the invoice finalized

sly skiff
#

yea that is still grey area I guess?

#

well its super edge case to be honest

#

so I dont think it will be an issue

#

like the usage of a unit exactly few seconds before the finlization

#

Thank you so much for helping me out!!!

sly skiff
stiff wing
#

Apologies I missed that. That is an interesting idea. So from what you've seen we do aggregate this synchronously in v1 but not v2? That sounds like it would make test clock testing much easier but I am not as familiar with v2, will look into if there are any differences that may trip you up here

sly skiff
#

No worries, no need for an apology! I have not tested it to be honest the v1 with clock testing, I was curious if it will fasten the dev process if you happen to know

#

to be honest I have gotten only 1 out of the 2 usages so I am not sure how long it will take for the second one to show up

#

I am referring to the v2 I have used in my current case scenario

stiff wing
#

As far as I can see, v1 would have the same lag. So I think for now you would basically need to poll the metered event summaries endpoint until it updates with the usage you just reported and then advance the test clock. That will definitely add some time to the tests but at least that would let you have this be completely automated

sly skiff
#

I see thank you so much for your time and your help!!!

stiff wing
#

Of course! And thanks for the kind words, will absolutely pass on the test clock love to the team that makes them