#eirik-upcoming-invoice
last rover
Can you share a request id where you did this?
woven trench
Sure: req_LgQ8R2XoqbkZAJ
Actually hold on there are two requests that I do, let me make sure I get the correct one
Sorry this one is the relevant one: req_iCPdnF0M9e2Vah
last rover
Ah so I think what's happening is you're being returned the prorated invoice rather than the next cycle's invoice since you change billing cycle anchor
Can you share the response object? I can't see get request responses
woven trench
Sure, let me see...
So I actually do both kinds of previews, one to see the immediate prorated invoice, and one to simulate future recurring invoices
in both cases period_start = period_end in the returned invoice
(i put the responses for both in the attached file, with the request ID in each)
primal canyonBOT
last rover
So I think the issue here is you're passing subscription_proration_behavior: "always_invoice", so the upcoming invoice is just the prorated invoice
which doesn't show the upcoming billing period
But taking a closer look at those requests now
fast gulch
I'll take over @last rover you can leave to me
@woven trench what my colleague said is correct. If you pass proration_behavior: 'always_invoice' then an Invoice would be cut immediately for the proration and that's what the Retrieve Upcoming Invoice API would preview
eirik-upcoming-invoice
woven trench
let me try without, for the recurring preview
same result:
unless it's by default
fast gulch
Okay so what exactly is not working? Can you explain in 2 sentences with the exact line(s) that you are confused about in that huge raw JSON you shared?
woven trench
the problem is period_end = period_start
fast gulch
Also that request you just did 100% still has always_invoice
fast gulch
if you change the billing cycle then it immediately cuts an Invoice and the period will be equal, that's efinitely expected
yes that request you passed always_invoice
I guess let's take a step back and ignore everything
are you simply asking "why is the first Invoice on a Subscription showing period_end = period_start = created"?
woven trench
(hang on, i want to make sure I have my "refreshed" question accurate...)
so, I have an invoice preview request req_U7HU8nG6wDRy45, which (unlike other requests in the log) does not define subscription_billing_cycle_anchor, subscription, nor subscription_proration_behavior. Why is period_end = period_start = created in this case?
fast gulch
yeah okay so that was your question. The first Invoice on a Subscription will always have the period_start = period_end = Subscription's created. It's by designed.
woven trench
OK, great! Now how can I get the prospective end of the period?
(It should really just be a month from today or a year from today, depending on the prices involved.)
fast gulch
Look at the Subscription's current_period_start and current_period_end. Or look at the individual line items on that Invoice and they have their own period like "period": { "end": 1713733380, "start": 1711054980 }, in your earlier request
woven trench
well the subscription has not been updated with the new billing cycle anchor yet, so current_period_end from the Subscription object will not be the new period end after the subscription is updated
fast gulch
hum
So there's an existing Subscription here? Sorry that might be obvious in your mind but you never passed a Subscription id sub_123. Are you just defaulting to the one on the Customer?
I thought you were simulating a brand new Subscription
woven trench
sorry, confusing--in the process of previewing what an update to a subscription would look like, i end up having to do two invoice-preview request: one with the subscription ID and one without (because I want to preview both the "invoice today" and "recurring invoice in the future" to the customer, like in the Customer Portal but done in my own code)
it sounds like i just have to calculate the next full invoice date myself...
fast gulch
If you don't pass the Subscription id we just use the most recent one on the Customer if it has one. Sorry I still worry we're talking a bit past each other 😅
fast gulch
not that I know of.
Look at the subscription: 'sub_123' in the response, it likely is the same
see the docstring here https://docs.stripe.com/api/invoices/upcoming#upcoming_invoice-subscription
woven trench
no, it seems to be a new freshly created suscription ID
fast gulch
That seems impossible to me unless your Customer does not have an existing Subscription
woven trench
it's kind of what i expected though
in the dashboard, the subscription ID returned does not return any results (in test mode as expected here)
not to take too much of your time, just one more question
fast gulch
I mean sure but that's definitely not what the docs say so I'm confused and it feels like potentially a misunderstanding
woven trench
"you will retrieve the next upcoming invoice from among the customer’s subscriptions." seems a bit ambigous
when you said " The first Invoice on a Subscription will always have the period_start = period_end = Subscription's created. It's by designed.", could you explain the rationale here? Why would the first invoice be for a period of zero length?
fast gulch
This means that if you have a monthly Subscription on the 1st of the month, the invoice on the 1st of November will be for the 1st of October until the 1st of November while the Invoice's line for the Subscription will be for 1st of November to the 1st of December.
There is an exception which is for the first Invoice. Since there is no "past" for the invoice, period_start and period_end will be equal in that situation and correspond to the date the Subscription was created.```this is how we explain it internally when people ask, does that help?