#frallain

1 messages · Page 1 of 1 (latest)

cobalt deltaBOT
sinful kayak
#

Hi! Let me help you with this.

ivory torrent
#

Yes, I am using stripe.Subscription.modify to modify the sub

#

alas I've tried: even with proration_behavior="always_invoice" the X usage does not get invoiced.
It is to note that the stripe.Subscription.modify also has the sub item with clear_usage=True

sinful kayak
#

Does clear_usage=True clear the old usage too?
Maybe you could do it in a separate call.

ivory torrent
#

Yes clear_usage=True clears the old usage, and without it I've got an error message saying that it's not possible to delete a sub item for a metered price that has some usage

sinful kayak
#

I see. Could you please try adding the other sub item and setting always invoice. In the subsequent call, you can remove the old item. Please try and let me know if this works for you.

sinful kayak
#

Please, let me know if you have any other questions.

ivory torrent
#

Yes OK, trying it now

#

So:

  • 1st stripe.Subscription.modify with price B to create + "always_invoice" as proration behavior : it did create the price B, but did not invoice anything
#
  • 2nd call with clear_usage did remove the price A, thus losing its usage (not invoiced)
#

Through the Stripe UI, I found a way to invoice the current usage by resetting the billing cycle (since it generate an invoice immediately) but I don't want to reset the billing cycle

sinful kayak
#

You can do it temporary, and then reset it again, when the "real" billing period ends.

cobalt deltaBOT
sinful kayak
#

Please let me know if this works for you.

vital plover
#

@ivory torrent What's the question?

ivory torrent
#

Hi @vital plover , if, in the 2nd call, I reset the billing cycle anchor to the initial value, I get the following error :
'Invalid timestamp: must be an integer Unix timestamp in the future.'

frail estuary
ivory torrent
#

sure, 2sec

#

Request req_B4itLDlbyODmOY: Invalid timestamp: must be an integer Unix timestamp in the future.

#
{'error': {'message': 'Invalid timestamp: must be an integer Unix timestamp in the future.', 'param': 'billing_cycle_anchor', 'request_log_url': 'https://dashboard.stripe.com/test/logs/req_B4itLDlbyODmOY?t=1683719718', 'type': 'invalid_request_error'}}
frail estuary
#

You've passed a timestamp in the past (2023-05-10 11:55:05 UTC) you need to pass a timestamp in the future.

ivory torrent
#

OK, but it was the initial billing_cycle_anchor of the subscription. So I guess I need to pass a timestamp of the end of the initial current cycle (subscription.current_period_end)?

frail estuary
#

If you want to pass the initial date then don't pass any think, why you want to update the billing_cycle_anchor if you are passing the initial value ?

ivory torrent
#

Hehe yes indeed... It is because resetting the billing cycle seems to be the only way to invoice the current usage of a metered price in the middle of the cycle

frail estuary
#

In all cases, you need to provide a future timestamp if you want to update the billing_cycle_anchor

ivory torrent
#

OK so I provided a future timestamp, but now I've got :

{'error': {'message': "When updating an existing subscription, billing_cycle_anchor must be either unset, 'now', or 'unchanged'", 'param': 'billing_cycle_anchor', 'request_log_url': 'https://dashboard.stripe.com/test/logs/req_57ek8YWl2L1u5c?t=1683722405', 'type': 'invalid_request_error'}}
frail estuary
#

What you are trying to achieve is not possible.

ivory torrent
#

Yes indeed, and that is counter-intuitive : upgrading from a metered price to another for a product while invoicing the usage so far seems a classic use-case