#stripe_connect_platform-
inland walrus
which subscriptions statuses would it make sense to update? ['active','trialing','past_due'] - is there anything in that array that would fail? Any others we should include?
That depends on which invoice you want the application fee to be charged on. If you update the subscription, the next invoice that is created will have an application fee.
waxen echo
all
it just seems like it doesn't make sense to update an applcation fee on:
unpaid
canceled
incomplete
Also, we make some API calls on '2016-03-07' and some on '2020-08-27'. What is the best way to just get all the subscriptions that we would want to update. Happy to use either of those versions of the API.
But it would be cool if we don't have to make a separate API call for each status
inland walrus
Okay, let's focus on one question at a time.
waxen echo
We are doing a results = Stripe::Subscription.list({ limit: 100, starting_after: starting_after and looping with starting_after to push all the subs into an array. But have one loop for each status. Is there an easier way to get all the subscription that are updatable for an application_fee_percent?
inland walrus
It's difficult to bounce around to different questions about different things all at once.
waxen echo
hm
Step One: Get all the Subscriptions
Step Two: Update all the updatable subscriptions
Step One. What is the best API call to get all the subscriptions of statuses that make sense for an update call to update the application fee percent on a connected account's subscription to his/her customer.
inland walrus
Step One: Get all the Subscriptions
There are a lot of ways to do this. There are both dashboard solutions and an API solution. If you want to download a CSV of all subscriptions and pare down to justactiveandtrialingthen you can do that here: https://dashboard.stripe.com/subscriptions
Otherwise, you can make a list all call to the API and filter out results that you don't want.
inland walrus
Does that make sense? Are you able to confirm that works before we tackle the next questions?
waxen echo
list all on new api version or that old api version. it works differently as i recall
the new version of the api on a list api call gives back all subs of all statuses?
inland walrus
When it comes to just getting the statuses, it shouldn't matter which version you use. The changes between versions (if I recall correctly) had to do with fields related to plans/prices and products
waxen echo
it used to only return active
i think but can't recall 100%
OK, so you get all statuses in the api call
ok, which statuses would it make sense to filter out if we are going to update an application fee>
Possible values are incomplete, incomplete_expired, trialing, active, past_due, canceled, or unpaid.
if ['canceled'].include?(sub.status)
Anything that would return an error if we tried to update the application_fee basically
?
I think you can now "uncancel" no? So maybe we should update the applicaiton fee on cancelled too just in case they "un-cancel"
Basically I am asking for Stripe's engineering advice here.
inland walrus
You can't uncancel subscriptions, so I wouldn't worry about that
waxen echo
Should we filter out any statuses for this API call to update the application fee?
inland walrus
All those statuses except for cancelled should have the application fee updated, as all non-active statuses (aside from cancelled) are capable of transitioning back to active
waxen echo
Perfect! That is what i needed 😉
inland walrus
Amazing! Do you want to give that a go in test-mode first? Or do you have more questions?
waxen echo
We will have to do a lot of testing.
Any gotchas here. I am hesitant to update existing subscriptions.
inland walrus
I wouldn't update existing subscriptions until you do this in test-mode to make sure you're fully aware of how everything works. Prototyping in production seems like a really bad progression.
No gotchas that I can think of. In terms of edge-cases, I'm trying to think of some, but nothing is coming to mind