#.brolala

1 messages · Page 1 of 1 (latest)

next stagBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

wary geyser
#

hi!
for the first question, the trial ends and the billing happens on exactly the timestamp you pass as trial_end.

for the second question, not overall sure but maybe if you want a free subscription it's best to just subscribe to a $0 Price instead of the pause feature.

bleak hawk
#

Yes, but I'm having trouble while creating free subscription because when my internal cron_task update the subscription on the following week, it reset the billing time to the cron_task schedule time and create some bill mistakes

wary geyser
#

do you have more technical context on that?

bleak hawk
#

Maybe I should introduce you my use case in order to understand my problem.
My use case :
Each week we deliver some goods to customers and the following week, the customer should be billed of the total price of delivered goods. So internally we setup a subscription for the first week with stripe in free_trial then next week we update the subscription with the price of the previous week delivered goods. If the customer wants he can pause his subscription at anytime if he wants.

I know about SubscriptionSchedule, but they're not fitting with the pause anytime feature.

My problem :
We currently have a bug due to free price, when they're changed each monday morning, because the first time the price is changed, it move the next_invoice date to each monday morning, so our customer are charged before the charge amount of the previous week is updated. How should we process to avoid moving the next_invoice date ?

wary geyser
#

because the first time the price is changed, it move the next_invoice date to each monday morning
any code you can share for how do that update?

bleak hawk
#
def edit_sub(self):
        i = 0
        for k in self.subs:
            try:
                sub_stripe = stripe.Subscription.retrieve(k)
                si = sub_stripe["items"]["data"][0]
                stripe.Price.modify(si.price.id, active=False)
                new_price = stripe.Price.create(
                    currency="eur",
                    unit_amount_decimal=self.subs[k]["price"],
                    recurring={"interval": "week"},
                    product=si.price.product,
                    metadata={"order_id": self.subs[k]["order_id"]},
                )
                stripe.SubscriptionItem.modify(
                    si.id, price=new_price.id, proration_behavior="none"
                )
                # Protect stripe Ratelimit
                i += 1
                if i % 10 == 0:
                    sleep(1)
            except Exception as e:
                print(e)

where self.subs is an Dictionnary like this one:

self.subs = {
  "sub_xxxxxx": {
      "price": 17.23 # range (0 - 999),
      "order_id": "XXXXXX" # Internal id for our systems
   }
}
bleak hawk
wary geyser
bleak hawk
#

Yes, so if I'm correct should a free_trial with a non-zero price wont reset the billing anchor ?

wary geyser
#

don't think so, if it's doing that then give me an example like the request ID req_xxx of the update call or the Subscription ID sub_xxx where that happened

bleak hawk
#

Maybe take a look at sub_1OfQZ5FotBUbrdlcqs2JIJHF

wary geyser
wary geyser
bleak hawk
#

At 2 AM subscription was updated but at 3AM it was charged with the old amount

wary geyser
#

on the 12th?

bleak hawk
#

19th

#

For me the error was created the 12th and the bug occured the 19th

#
  • The billing anchor was reset the 12th and the cron_task can't update at time the 19th
wary geyser
#

on the 12th you changed from a $0 plan to a $19 plan, and that does reset the billing cycle yes like I mentioned above

#

on the 19th you moved from one $19 plan to a different $19 plan

bleak hawk
#

Yes so in my case usage-based will fix everything ?

wary geyser
#

might do, you can test it out and read about it and see

#

seems to make more sense to me than all the complexity in the current implementation

bleak hawk
#

Yes