#ibrahim menem-update-subscription
1 messages ยท Page 1 of 1 (latest)
Hi ๐ can you provide the ID(s) of the request(s) that you're making to update a Subscription?
sure: these are some
req_WdLtpdiEKi9Jkb
req_kvpyGVFWA7YpST
Thank you, and apologies for the delay, I'm working on reviewing those requests.
thank you!
Apologies, that took longer than expected to parse through. What I think is happening is that you're duplicating part of the process by using two different approaches. I see that you created a new Subscription Item for the Subscription, but (if I'm following the timing of these requests correctly) that happened in an order that led your Subscription update requests to not make any changes to the Subscription and therefore not trigger any prorations.
Can you try setting proration_behavior when you create the new Subscription Item?
https://stripe.com/docs/api/subscription_items/create#create_subscription_item-proration_behavior
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Yup
that worked ๐ ๐ฅณ
thank you toby, you rock ๐ช
any recommendation on the overall approach?
Hi ๐ I"m stepping in for @haughty mulch as they need to go.
I'll elaborate about it
my approach could require 2 subscriptions.update calls which is not ideal. is there a better way to avoid it?
the main reason I don't do it in one call is because the change may include changing billing periods, for that case I need to update prod1 in subscription to the new billing cycle, then create the subscription items (then call update again with he updated items). if I try to create subscription items (for prod2 or prod3) before updating existing prod1 that will fail.
Hmmm... ๐ค
I guess if I delete the subscription and create a full new one, that would not count as upgrade and proroation will not work etc right?
You can't delete the subscription. You can cancel it but you should read the couple paragraphs here about that: https://stripe.com/docs/api/subscriptions/cancel
I'm not sure but it sounds like it would not work as expected. I think the way is via modifying the existing subscription which looks to be working now (but with mutiple api calls)
is it possible to create a kind of group of calls in a transaction?
so if one fails at the end of the operation, all are rolledback
Yeah I think, because of the billing cycle and price changes the two API calls are still your best bet.
We do not currently have any batching functionality for API calls but some sort atomicity like what you are describing would be a great feature
ok, thank you for your help both you and toby
I have another simpler (best practice) question, should I post again to the channel or continue here?
Here would be better (it keeps the main channel more clean and cuts down on the number of threads we have to track)
right now we are sharing the development credentials between staging and local development, which is not ideal because we have a lot of noise (events sent to the other environment):
- I couldn't find a way to generate multiple development credentials
- or add a custom special header so we can detect the target environment
what is the best practice here?
Okay so it's due to the webhook events? We don't really have a good approach for separating staging and local development in that case.
My best recommendation would be for local developers to either A) create their own account (which could diverge from production/staging so that's somewhat problematic)
or B) Add custom metadata to their Stripe objects and filter the webhook events on that metadata
option B sounds good, metadata can be added to all calls we make to api, even checkout and customer portal session creation, right?
should we return 400 for those webhook event reaching the other environment ?
Not unless getting your endpoint disabled is part of the design. You should respond with a 200 once you know it's a valid POST from Stripe.
haha I see #dev-help message asking almost the same question
There are a few of them today ๐
thank you, we will give the metadata approach a try
I hope it works out for you ๐