#Becca
1 messages · Page 1 of 1 (latest)
hello, to clarify, what are you expecting to see instead?
so from the upgrade, I've got this:
"period": {
"end": 1676320381, // Monday, February 13, 2023 8:33:01 PM
"start": 1673642297 // Friday, January 13, 2023 8:38:17 PM
},
// remaining
"period": {
"end": 1676320381, // Monday, February 13, 2023 8:33:01 PM
"start": 1673642297 // Friday, January 13, 2023 8:38:17 PM
},
// invoice
"period_end": 1673642297, // Friday, January 13, 2023 8:38:17 PM
"period_start": 1673641981, // Friday, January 13, 2023 8:33:01 PM```
shouldn't the top-level invoice period_end be Feb 13?
same for the invoice for the subscription creation, shouldn't start and end be a month apart (for a monthly price)?
subscription creation: 1/13 8:33pm
subscription upgrade: 1/13 8:38pm
monthly renewal: 2/13 8:33pm
The Invoice's top period_start and period_end always represents the "previous" period, so it's expected to see Jan 13 8:33 to Jan 13 8:38, while the line_items you see (unused and remaining) will always display the "next period", which is from Jan 13 8:38 to Feb 13 8:33
huh, that feels really misleading haha
The first Invoice ever is an exception when it doesn't have the "previous" or "past" period, so both properties point to an identical starting date
yeah that makes sense given that period_start/end refer to the previous period, I'd just never expect period_start/end to mean previous, that's the confusing part to me. the lack of a qualifier on it implies "current" to me 🤷♀️
another invoice object question: with a prorated invoice event like above, for figuring out which items are "new" (aka to mark a user's current subscription level on our side), do you just have to look at the line items that have a positive amount? is there a better way to identity that?
Yes it's to look at the line item, or more specifically the Invoice Item. ie in your event it's ii_1MPu0zJvPV2PodcL6OpLDo8s . You can compare its price id price_1M9ygFJvPV2PodcLGpfS0S7Q to be sure it's new
ah yeah sorry, the array property is called "lines" and docs use line items, but yes invoice items there. is it bad to filter on the amount? filtering on the amount means I can avoid a db query to get the user's current (internal primary key in our system used as a foreign key on the user) id and join to get the stripe price id
Um but it could be problematic if you have multiple prices
Like you can have 2 positive prices and 1 negative price. I feel it's a bit risky to just rely on the sign
You can have additional extra Invoice Items that's has been added somewhere, but not necessary the prorated one
hmm ok