#TonyS
crimson viper
Can you share the req_xxx?
old geyser
Sure : req_FDPjfCz0LCRXkU
crimson viper
Can you share the JSON response here? We don't log those unfortunately
I suspect there's multiple invoice items for unused time on certain subscription items (i.e. proration)
old geyser
Ok this is an issue with the customer is that what you are saying?
Is this ok if I remove the JSON response since there is personnal info in there?
old geyser
Do you have more info?
crimson viper
It's because of the subscription_proration_date you're passing
old geyser
What should I do?
crimson viper
Well, what is it you're trying to do? Do you want to prorate for unused time when upgrading?
old geyser
In this particuliar case I would like the user to pay 30$ - 14.55$ (unused basic) = 15.45$
crimson viper
Then I'd recommend removing the subscription_proration_date parameter. The upgrade/downgrade will force a new billing cycle anchor, at which point the new plan starts for $30 and the unused time on the old plan should be credited
topaz reefBOT
old geyser
Mmm that does not seem to work by removing subscription_proration_date I still get a total of 41,81$ and not 14,55$
analog pond
Hi! I'm taking over this thread.
old geyser
Hello soma! Sure! Thank you
analog pond
Mmm that does not seem to work by removing subscription_proration_date I still get a total of 41,81$ and not 14,55$
Can you share the request ID, the response you got, and what you were expecting to see instead?
old geyser
sure
req_ysu0A9x2zEAjlr
the response
In this particular case I would like to simulate the fact that the user will have to pay 30$ - 14.55$ (unused basic) = 15.45$ to upgrade his subscription
analog pond
Thanks! Give me a few minutes to look into this.
old geyser
Sure! Many thanks for your help
warm grotto
so in that request it calculates proration as if you made the change now. So it's calculating a refund of the existing $14.90 plan from now until April 21 (which prorates to $14.53 since it's most of the month) and a prorated charge on the new $30 plan from now until April 21(which prorates to $29.25 as it's most of the month). Those items are included in the invoice. So the next invoice is for $30(April 21 -> May 21), minus $14.53, plus $29.25
That's how our proration works.
you can't just have the amount be "new price total amount minus the old price total amount", that's not how our product does things, we prorate by the second. It's designed from the perspective that the customer should not over/under pay for what they actually use
if that's what you want, it's best to just calculate that amount yourself, add it as an InvoiceItem, and do the upgrade with proration_behavior:none to disable our own calculations.
old geyser
Ok so what you are saying is that the user will upgrade now but will be charged for current upgrade plus next month at the next invoice. Is that correct?
warm grotto
if they upgrade now they
- get a credit(minus amount) of what they had already paid at the start of the month for their existing plan, prorated for the time remaining in the month(the prorated $14.52)
- get a charge(positive amount) of the cost of the new plan, prorated for the time remaining in the month(the prorated $29.25)
those items are added to the next invoice for the subscription(and the next invoice charges for the upcoming month too, at whatever the current plan is($30 here since it's after the upgrade).
old geyser
This is very close do what we want to achieve. I'll try to explain what would be the best case for us
1 - The user want to upgrade from BASIC to PRO
2 - We do a proration on unused days on his basic subscription (in this case 14,52$)
3 - The PRO subscription cost 30$, so the user pays 30$ - 14,52$ and have now a pro subscription with a paying anchor at the date of the change
What's unclear in the case your detailed is that the user will be shown paying a total of 44$ for a product that cost 30$ which is weird for him no?
warm grotto
Yeah basically you want to only calculate the proration of the unused time on the existing plan, but not include the prorated remaining time. We don't support that, if you use our proration we calculate both those invoice items. You'd have to use proration_behavior:none and add the invoice item amounts manually if you want to do this.
warm grotto
What's unclear in the case your detailed is that the user will be shown paying a...
depends how you look at it.
The next Invoice is April 21. It's $30 for April 21->May 21 for the Pro plan.
But you were also on the Pro plan from March 22nd->April 21(the time you did the upgrade)
So you also need to pay "29 days of the Pro plan", which is where the "Remaining time on..." invoice item comes in.
old geyser
Yes I understand the logic but from a customer POV this seems more complex to understand and to show a higher price and the "normal" price of the product seems counterintuitive in my humble opinion
We can redo the calculation from the upcoming invoice informations though and work from there
warm grotto
yep lots of people think that. Our proration product just works the way it does for a certain opinionated view of how subscriptions work, there is lot of feedback about how that fits/doesn't fit for certain businesses but unfortunately for now it is what it is .
old geyser
I understand, thank you very much for your help and clarity