#alexisadeveloper
turbid hawk
Struggling to recreate this right now for some reason. 😅 I'm gonna keep trying because this has pretty much been happening on every test except today. In the meantime just to explain it: I need to add a price to a subscription whenever some threshhold in our application has been crossed. How I do this can be seen in the picture. Ideally both the current price of the subscription and the new price Id I add would be on the same invoice but they aren't.
inland raptor
in the next phase you're only putting one price
turbid hawk
Yes, because the price is only supposed to be added for 1 month
inland raptor
I'm not sure i follow
turbid hawk
Basically once someone crosses the threshhold for their billing cycle, they get metered price added to their subscription. The next month only the standard price of the subscription remains and if they cross the threshold again, the metered price will be added again
But by default it is removed after the current billing cycle
inland raptor
ok, do you have an Invoice ID where this issue was happening?
turbid hawk
sub_1NRBhJEwHpTUe8W7Hw6XM7sc
finally got the subscription
As you can see it is still runnning and the only upcoming invoice that is showing is the one from the metered price
leaden trailBOT
willow yew
you have a schedule set up to delete the other price though, right?
that's why it's not there, you're removing non-metered price at the end of this period, so it's not going to be charged upfront in the invoice at the start of the next period(which is the upcoming invoice).
turbid hawk
The price that I add for the next subscription phase is the same one that the user has to begin with.
So it shouldn't be removed
willow yew
well remember that phases are declarative
so if you don't include the price in every phase, it's implied to be removed
e.g. if you do phases[0][items]=[priceA,priceB] and then phases[1][items]=[priceC], you're not adding C, you're actually removing A and B and saying that now it's only C
turbid hawk
But I'm doing phases[0][items]=[priceA,priceB] and then phases[1][items]=[priceA]
willow yew
so that removes B
willow yew
maybe you have a mistake and you're removing the one you didn't want to remove
maybe for testing create a new Product with a different description and do one-price-per-product instead so it's easier to look at your dashboard and see what's happening(it's hard for you and I to debug this when everything is called Fuxam Premium Plan S)
turbid hawk
That seems impossible to me because the user will still get charged for priceA at the end beginning of the new cycle
willow yew
That seems impossible to me because the user will still get charged for priceA ...
well remember usage based pricing works differently from licenced
turbid hawk
yes but the user gets charged for both
willow yew
the licensed Price(7/month) is charged in advance(start of the month), usage based(7/unit/month) is charged in arrears(end of the month)
turbid hawk
yes but they still line up to happen at the same time due to my schedule.
and the usage based for the current month is charged at the end of the cycle, which is approximately when the charge for the next cycle of priceA comes in
willow yew
sounds good
my suggestion is to repeat the tests but use a different Product just so the descriptions are more readable, and debug from there using your dashboard and API logs. Sorry, this is really in-depth for us to try to help with right now
my assumption is you are accidentally removing not the Price you intend
leaden trailBOT
turbid hawk
If that was the case then the amount that the user actually ends up paying would be wrong and it isnt. I can't change all my products to be 1 price per product now and if that's the recommended approach for subscriptions that have various pricing mechanisms, then I don't really understand why you should be able to add a second price to a product. All I was asking for is if there is a way to retrieve upcoming invoices depending on the price, I guess thats not the case. Thank you for your help.
willow yew
I'm only saying to do that for testing
only so that it's easier for you to debug what's happening(since you can see in the dashboard the description of the different Prices/Products easier that way as they'll have different names, and that makes it easier for you to track down any potential issues in code).
You can of course have multiple Prices per the same Product in reality. Just for now it might make it easier to develop and debug the code in test mode doing it a different way.
remote prawn
Hey, taking over here. Let me know if there's any follow-up Qs I can answer!
turbid hawk
I don't understand why Names are relevant? Nothing iny my code is based on the name and I dont use them to debug anything either. I based that off of IDs. My code is also fine because the user is paying the right amount , its really just the upcoming invoices that are split up and so only 1 of them shows when calling retrieveUpcomingInvoice, but the user still pays that one (I just tested it with a test clock once again). Switching my products would be a huge effort.
Clearly stripe knows that both payments are upcoming (because the update happens sometime in the middle of the cycle) and both get charged on the same (usage charge from the current cycle and the charge for the standard price of the subscription)
remote prawn
Can you please summarize the latest follow up question?
turbid hawk
Is there a way to fetch more than 1 upcoming invoice?
remote prawn
No.