#ecila_vip
1 messages · Page 1 of 1 (latest)
Tried with a test clock.
cus_OUubx6pokQEykU
Ok taking a look
Can you share the exact subscription id where this happened?
I see a couple
The same operation was performed on different dates. But you only need to look at sub_1NhumyJrgt3ZD9jfR6HpNqiN.
So in that example it looks like you set cancellation to the 10th and disabled prorations, but you still are getting charged a prorated invoice?
That's the issue, right?
Yes
Are you seeing this issue when not using test clocks?
Trying to see if this is only an issue w/ test clocks
It also happens without test_clock. A similar operation on Subscription sub_1NfeXeJrgt3ZD9jfHHWC3ywo also results in a prorated Invoice.
Interesting. Ok looking
Talking with a colleague. Will get back to you soon
So apparently setting cancel_at to a time before the end of the billing period always creates a proration
And there's no way to disable it
This could be clearer in our docs, so flagging it to the team
ok, thank you very much.
Does this mean that cancel_at and proration_behavior cannot be used at the same time for operations via the API as well as the dashboard?
So to clarify, the description for cancel_at here is what's accurate: https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at. Setting cancel_at in the current period allows you to enable/disable prorations. But since you're setting it for the upcoming period, prorations will always be created (as described in that api spec).