chris_api | Stripe Developers | Page 1

barren furnaceBOT Oct 30, 2025, 12:04 PM

#

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

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

#

random vapor Oct 30, 2025, 12:15 PM

#

👋 Hi there, just taking a look now

#

Looks like in the specific request above, there was just a second between the meter event and the test clock advancement. Test clock advancements are asynchronous, so this is probably what's the leading to the behaviour you're seeing. The best practice is to listen for test_helpers.test_clock.ready events, rather than relying on 200 responses, or waiting arbitrary amounts of time. See this doc for details: https://docs.stripe.com/billing/testing/test-clocks/api-advanced-usage?dashboard-or-api=api&locale=en-GB#monitor-changes

barren furnaceBOT Oct 30, 2025, 12:53 PM

#

waxen spruce Oct 30, 2025, 1:09 PM

#

Thanks! But to make sure the TestClock is ready, I'm using this snippet:

    for {
        clock, err := testclock.Get(clockID, &stripe.TestHelpersTestClockParams{})
        if err != nil {
            return err
        }

        if strings.ToLower(string(clock.Status)) == "ready" {
            break
        }

        time.Sleep(time.Second * 2)
    }

This should make sure the TestClock is ready. Or am I mistaken?

grand pendant Oct 30, 2025, 1:11 PM

#

hi there, I'm taking over for my colleague, one sec while I catch up

#

ok, so you're seeing the meter event tracked in the dashboard, but not in the Invoice, correct? can you give me an example subscription ID where you're noticing this behavior?

waxen spruce Oct 30, 2025, 1:15 PM

#

Hi, I just restarted the test after a "small" change. Let me see if the problem still exists. It might be a brain error on my side.

#

Okay, the change didn''t have the desired effect. Here's a subscription ID of the Test Customer: sub_1SNvgO4aHJZ0vXfWpRueFCy7

grand pendant Oct 30, 2025, 1:21 PM

#

thanks, looking now

#

can you show me an example of how you're generating the meter event? like what parameters you're passing

waxen spruce Oct 30, 2025, 1:25 PM

#

Sure. It's not much though:

    params := &stripe.BillingMeterEventParams{
        EventName: stripe.String(PlayerMeterID),
        Payload: map[string]string{
            "value":              fmt.Sprintf("%d", amount),
            "stripe_customer_id": customerID,
        },
    }

    _, err := meterevent.New(params)
    if err != nil {
        slog.Warn("failed to create meter event", "err", err)
        return err
    }

grand pendant Oct 30, 2025, 1:35 PM

#

thanks, just wanted to check if you were using a custom timestamp property or something. so the events never appear? just out of curiosity have you tried a preview invoice on one you sent awhile ago?

waxen spruce Oct 30, 2025, 1:43 PM

#

Last I checked it says the meter will be in the "upcoming" invoice. But I'm sure it should be part of the current invoice.
We have a "mixed" subscription:

Base price (Fixed, at the start of a month)
Additional resources (Metered; at the end of the month)
This alone already tripped us up. We thought everything would be at the end, but figured you have to it this way.
So we expect the following result:
January 1st: 0 € (trial)
February 1st: 21,60 € (base for February; trial for resources)
March 1st: 34,40 € (base for March; price for resources)

But March 1st shows 21,60 € instead. Even though we triggered meters during January and March.

#

Strangely enough, the invoice for April 1st shows the 34,40 €.

grand pendant Oct 30, 2025, 1:55 PM

#

so usage-based billing bills in arrears, meaning the next Invoice after the events are sent will have the charges for those events

waxen spruce Oct 30, 2025, 1:55 PM

#

Sorry, I missed the part of the preview invoice. My bad!
We check if we have an upcoming invoice. We need this info for our billing process. For this, we create a preview invoice.
And about the custom timestamp: We tried. But in some cases it returned a "can't be in the future". So we decided to leave it.

waxen spruce Oct 30, 2025, 1:57 PM

#

grand pendant so usage-based billing bills in arrears, meaning the next Invoice after the even...

Yeah, that's what we expect to happen. But the result we see is different.

grand pendant Oct 30, 2025, 1:59 PM

#

for the 34,40 euro Invoice for April, what test clock time were those events sent?

waxen spruce Oct 30, 2025, 2:00 PM

#

March 1st, 01:00

grand pendant Oct 30, 2025, 2:03 PM

#

ok, so the billing cycle anchor for the subscription is anchored at 2025-02-01 00:00:00. so events that are sent on March 1st at 01:00 would appear on the April invoice. any event before the first of the month will appear on that month's invoice

waxen spruce Oct 30, 2025, 2:06 PM

#

So ...

Subscription starts at 2025-01-01 00:00:00
Trial ends at 2025-01-31 00:00:00 (events during this time don't "count")
Events during 2025-02-01 :00:00:00 and 2025-02-28 23:59:59 are counted for February and should appear on the invoice for March 1st.
Events during 2025-03-01 :00:00:00 and 2025-03-31 23:59:59 are counted for March and should appear on the invoice for April 1st.

Is this correct?

grand pendant Oct 30, 2025, 2:07 PM

#

yes

waxen spruce Oct 30, 2025, 2:09 PM

#

Okay. But we send a Meter Event on 2025-02-21 00:00:00
I'd expect it to appear on the invoice for March 1st.
But it's missing.

grand pendant Oct 30, 2025, 2:13 PM

#

interesting. let me do some digging...

#

can you give me the event_name and customer for that event?

barren furnaceBOT Oct 30, 2025, 2:14 PM

#

upbeat skiff Oct 30, 2025, 2:16 PM

#

Hi there 👋 jumping in as my teammate needs to step away soon.

Meter Events and Test Clocks can be finicky when used together. You'll want to wait until the Meter Event has been aggregated (which happens asynchronously) before advancing the Test Clock's frozen time, so don't advance the clock until you see the usage recorded. But let me know if you still don't see the desired behavior with that!

waxen spruce Oct 30, 2025, 2:17 PM

#

The event name send is "prod_player_usage" and the customer is "cus_TKasnLWnb1f3KM".

And how do I wait for the meter to be processed?

upbeat skiff Oct 30, 2025, 2:21 PM

#

Just sort of wait. If you advance the Test Clock before the aggregation is completed, the usage is dropped.

waxen spruce Oct 30, 2025, 2:23 PM

#

So there is no other way? Like a webhook or pull for the current status? If not, how long is advised to wait?

upbeat skiff Oct 30, 2025, 2:27 PM

#

There isn't a set prescribed time, since the jobs are async and the duration can fluctuate (even moreso in sandboxes and testmode). You could poll the Meter Summary, poll creating a new Preview Invoice, or monitor the dashboard until you see the usage reflected and can then advance the Test Clock.

waxen spruce Oct 30, 2025, 2:30 PM

#

Since the tests should run automatically, monitoring the dashboard doesn't seem like an ideal solution for us.
But listing retrieving the Meter Summary sounds like a solution. Thanks!

#chris_api