#.brolala
1 messages · Page 1 of 1 (latest)
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.
- .brolala, 5 days ago, 18 messages
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.
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
do you have more technical context on that?
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 ?
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?
Each week we deliver some goods to customers and the following week, the customer should be billed of the total price of delivered goods
why not use usage-based billing that bills in arrears? https://docs.stripe.com/billing/subscriptions/usage-based
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
}
}
In case we use usage-based, won't the error be the same ? Free price then updated each monday morning with the previous week usage then next_invoice date updated to monday morning and create some error ?
ok, that should only reset the billing anchor if the previous price was for $0 or you're moving from e.g. a Price that was recurring:day to recurring:week etc
https://docs.stripe.com/billing/subscriptions/upgrade-downgrade#immediate-payment
Yes, so if I'm correct should a free_trial with a non-zero price wont reset the billing anchor ?
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
Maybe take a look at sub_1OfQZ5FotBUbrdlcqs2JIJHF
don't see how? a usage based-subscription would just bill every Monday. If you reported usage before the billing anchor, an Invoice is generated that charges for that previously-reported usage. If you don't report anything, there's a $0 invoice instead and the subscription just continues. Don't see why you need this whole trial/pause stuff
and when exactly did the change that you weren't expecting happen, which day in February?
on the 12th?
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
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
Yes so in my case usage-based will fix everything ?
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
Yes