#jamesdahlen.nwi - trial and invoice
sturdy mountain
great!
grizzled ferry
I can see it is because of the customer credit on that subscription's customer and that the customer got that credit from a call to update the subscription, but I am not immediately sure why that is. Still looking. https://dashboard.stripe.com/test/logs/req_tPnSGQyoIDx8SH
sturdy mountain
ok, hope you can find a reason! that sounds suspicious
i am updating the subscription after initial invoice as suggested by bismark
grizzled ferry
Yep yep, I am curious as to why myself. As one of my colleagues says, our Billing can often seem to do something counterintuitive but then you look deeper and see why it had to work that way
Will look in to your thread with bismark in a moment as well. Basically what is the end goal of making this subscription update after the invoice?
sturdy mountain
customers wish to pre-pay for a subscription that starts later in the year
instead of using SubscriptionSchedules, he suggested an alternative using Trials
i need the subscription to recur yearly in August
but allow pre-payment
grizzled ferry
I am still a little bit stumped on this one. Will ask my colleagues and get back to you
sturdy mountain
ok
grizzled ferry
I see what it is now. So the default proration behavior of an update like this is to create prorations. So this update credited the user for the unused time in the year (which was all of it)
So, in future, just pass proration_behavior: none in your call that creates this trial and the user won't be credited