#bmizerany1234

1 messages ยท Page 1 of 1 (latest)

hushed sleetBOT
tawdry raft
eager sentinel
#

I shared a request ID

#

req_7uptK2NWwNviv5

#

I'm not sure what document you are referring too.

#

The steps I took are above

#

DISREGARD. I'll open a new one.

#

with all of the request IDs and some extra info

tawdry raft
#

Please keep everything in this thread

#

Subscribed a customer to a metered price with request ID: req_j8167xn0Xzhnbf.
Created a usage record for that price's subscription item as indicated in the subscription with request ID: req_fydWv8EspPUTfu.
Waited for over 10 minutes (actual time, no test clock was utilized).
Subscribed the customer to a different price with request ID: req_9CE6zeYs5Tq0Ap.
Created a usage record for the new price's subscription item within the same subscription using request ID: req_7uptK2NWwNviv5.

#

Quoting here for context

eager sentinel
#

k

#

Don't mean to muddy things, just wanted to reformat that so we can easily read it as we go along:

  1. Subscribed a customer to a metered price with request ID: req_j8167xn0Xzhnbf.
  2. Created a usage record for that price's subscription item as indicated in the subscription with request ID: req_fydWv8EspPUTfu.
  3. Waited for over 10 minutes (actual time, no test clock was utilized).
  4. Subscribed the customer to a different price with request ID: req_9CE6zeYs5Tq0Ap.
  5. Created a usage record for the new price's subscription item within the same subscription using request ID: req_7uptK2NWwNviv5.
tawdry raft
#

And what is the behavior you expect after step 5?

eager sentinel
#

I expect to see an invoice for the usage accumulated while subscribed to the price from step 1

#

I do see an upcoming invoice for the sub in step 3 and usage in 4.

#

It is if the sub and usage in 1 and 2 never happened.

tawdry raft
#

You are putting a lot of prices in the intitial subscription. Can you try with just 1 so it's easier to track?

eager sentinel
#

That's going to take awhile

#

I'll do that

#

however, it will not be representitive of what is happening in production

#

I'm waiting 10 minutes to change the subscription

tawdry raft
#

You aren ot upadting the Subscirption directly, you are using a Subscription Schedule

#

In which case this whole approach is odd

eager sentinel
#

I don't see it as odd. It's documented to be able to handle this

tawdry raft
#

If you are using Subscription schedules why wouldn't you just create a new phase to represent the different items

eager sentinel
#

Because you can only append so many phasens

#

I've ran into many problems with that approach

#

After much research, including discussions in here, updating the current phase was considered the correct approach

#

The documentation suggests it is also

tawdry raft
eager sentinel
#

The default is "prorate"

#

correct?

tawdry raft
#

Is it intended that you want to create prorations?

eager sentinel
#

Yes.

#

The default is create_prorations according to the docs

tawdry raft
#

Looking at the history of this Subscription I see the initial invoice being created and an invoice being generated

#

But no invoice after that

eager sentinel
#

Okay. Same sequence using a single price: req_QFaiwaNbvP6Mvo, req_lCz9DLk5gx4Bqw, req_9PzgPWgc2p5uNr, req_ZMh78i6fsfJ6D4

#

No initial invoice

tawdry raft
#

Yes there is. The first request resulted in this subscription sub_1NfWeuCmsTHMBvm3O8ZlnJNO which has a latest invoice of in_1NfWeuCmsTHMBvm3AoM2FZX8

eager sentinel
#

GTN. Thank you. Is that showing up in the other screens? If so, where? I'm def missing something I think

#

Showing up == Invoice Shown

tawdry raft
#

I'm not sure what screens you are referring to but the API returns the Susbcription Schedule with a subscrption proprety which is the ID for the underlying Subscription. That Subscription has a latest_invoice property which has the ID for that invoice

eager sentinel
#

In the dashboard I mean

tawdry raft
#

You seem to be using the CLI to create these. I would recommend you also use stripe listen to listen for webhook events related to these actions. https://stripe.com/docs/cli/listen

#

We're not super familiar with the Dashboard here since we are focused on the APIs but it shouldbe visible in the Subscription

eager sentinel
#

or am I looking for the wrong thing?

tawdry raft
#

I can't look at your dashboard, that link is useless to me

#

But the Invoice is in a draft status anyway so you wouldn't see it as finalized.

eager sentinel
tawdry raft
#

It's right there

eager sentinel
#

The invoice is for $0

#

The usage is not accounted for

#

There was 10000 units reported to stripe for the first vesion of the sub

tawdry raft
#

That invoice was created before you created any usage records

eager sentinel
#

I see that

tawdry raft
eager sentinel
#

however why is it not being updated with the usage reported during the time before I changed the subscription?

tawdry raft
#

I see the update request too

#

The existing invoice will not be updated

#

That usage will show up on the next invoice

eager sentinel
#

Where did the 10000 units of usage go?

tawdry raft
#

It will be present on the next invoice

eager sentinel
#

I report 10000, change the sub, then report 20000

tawdry raft
#

Your report of the 10000 occurred after the initial invoice.

#

When you say you changed the sub, did you remove the prices associated with the earlier usage?

eager sentinel
#

okay here is the real question I guess: Do prorations show up in the dashboard in invoices before the invoice is finalized? (I'm aware they show up in the API)

tawdry raft
#

Once the invoice is created, new usage records and the charges they incur will show up on the next invoice.

#

And once again, I'm not certain about what the Dashboard will display as we are focused on the APIs on this server

#

I'm trying to follow and see where the usage is going

eager sentinel
#

yeah okay. The dashboard not showing all the information is confusing as all heck. Thank you for your help. I'll look at prod to with the API to see if the prorations are there

tawdry raft
#

Because I see you use the "sum" aggregation method

eager sentinel
#

Each change to the sub starts a new billing period AFIK and so that means the first period/sub is sum(10000) and the next is sum(20000)

#

two diff invoices/bills/prorations

#

I expect the current invoice to show 20000 units, so that works as intended.

#

It's the previous usage records I can't find (in the dash)

#

hrm

tawdry raft
#

THe issue I am seeing is that the subscription item the earlier usage record is associated with (si_OSRYA7dFvwSQ9G) is getting overwritten by the new one (si_OSRfLk98FyJMIA).

eager sentinel
#

stripe invoices upcoming --stripe-account=acct_1NfVzZCmsTHMBvm3 \ --customer=cus_OSRX1agCqxdReD

tawdry raft
#

But I don't see any usage record being written for the old Subscription item

tawdry raft
#

Subscription Schedules don't merge their phases data (like Subscriptions do), the overwrite

eager sentinel
#

Right, but that should behave the same as updating the current subscription directly, right?

tawdry raft
#

that should behave the same as updating the current subscription directly
Nope, opposite

eager sentinel
#

I badly want to drop one million F-bombs right now

tawdry raft
#

I get that, I really do

eager sentinel
#

That is not what I was told, and what I'm able to see in test mode

#

using test clocks

tawdry raft
#

Test clocks shouldn't have anything to do with it

hushed sleetBOT
tawdry raft
#

What I do I my code when updating subscription schedules is to extract the existing phases array, add my new items to the current phase so the items proprety has both, and then use that in my /update call

eager sentinel
#

That is what should be happening here

#

ugh

placid jetty
#

๐Ÿ‘‹ Taking over this thread, catching up now

eager sentinel
#

It's POST /v1/sub_sched/:id

#

hi @placid jetty welcome to the subscription schedule jungle

eager sentinel
#

I've seen in the past that subscription items kind of get "released" if we update a schedule to quickly (e.g. withing 5 minutes), but 3 months?

#

It seems something has changed on Stripe's end over the months.

#

I would not be surprised, it isn't the first time.

placid jetty
#

POST /v1/sub_sched/:id is the API to update the subscription schedule. Depending on the SDK you used, the function can be named as .update()

#

Can you summarise what your latest problem is?

eager sentinel
#

I can:

#

I'm encountering an issue with Stripe. Here's the sequence of actions I took:

  1. Subscribed a customer to a metered price with request ID: req_j8167xn0Xzhnbf.
  2. Created a usage record for that price's subscription item as indicated in the subscription with request ID: req_fydWv8EspPUTfu.
  3. Waited for over 10 minutes (actual time, no test clock was utilized).
  4. Subscribed the customer to a different price with request ID: req_9CE6zeYs5Tq0Ap.
  5. Created a usage record for the new price's subscription item within the same subscription using request ID: req_7uptK2NWwNviv5.

I now would expect to see an invoice or prorations applied to the next invoice for the initial usage of 10000 units, but I do not.

#

I'm creating and managing subscriptions via schedules in the API

#

When I change a subscription, I do so by updating the current phase in the schedule

#

That creates new sub_items for reporting usage with

#

I report usage using those si_ IDs

#

The first usage report in step 2 goes "missing" though

#

The second usage report in step 4 is in the upcoming invoice as expected, but the prorations for the initial 10000 are not

placid jetty
#

As mentioned by Snufkin that Subscription Schedule will overwrite the existing phase. It's either you add the new price to the phase 0 instead of replacing the old price; or create a new phase with new set of prices and end existing phase now.

Why don't you use Subscription directly, but Subscription Schedule? Subscription Schedule is meant to be used for future changes. The example requests here were all the immediate changes as of the time when the request was made.

eager sentinel
#

We use this tool to experiment with pricing, and we use 2+ phases at times depending on customers. This tool should be general purpose and needs to accommodate those scenarios, and since subscription schedules are just another way to update subscriptions, we didn't want to design two paths for updating subscriptions

#

Why would not replace the item? It is not longer intended to be on the invoice and part of their phase.

#

So the answer here is: When the current phase of a schedule is updated such that a price, with associated usage, is removed from the items list, that prices usage is silently discarded.

#

Is that correct?

placid jetty
#

Yup, replacing the item will overwrite the price and usage in Subscription Schedule

#

Two options here: (1) Add new price as new item instead of replacing it; (2) End existing phase now and add a new phase with new set of prices

eager sentinel
#

Dope. May I suggest calling out this behavior in the docs. We're loosing revenue over this

#

Thank you for you time @placid jetty and @tawdry raft

placid jetty
#

Thanks for sharing the feedback. We will forward to the team

eager sentinel
#

Also: Maybe log that usage was dropped with all caps in the event log instead of being silent ๐Ÿ™‚

#

It would be better if dropped usage was opt-in, but that is a long shot of a change