#stephenhuey
leaden moat
full sparrow
What field specifically are you changing? What are you actually trying to do?
hardy ore
Stripe::SubscriptionItem.update(stripe_subscription_item_id, { plan: plan_number } )
@full sparrow -^ That's the code I ended up with after upgrading from the very old API to the new API.
For many years with the old API we were able to simply get a Stripe::Customer and call update_subscription(:plan => plan_number, :prorate => true)
And you can't do it through Customer anymore, and I tried to change the plan by updating Subscription but it didn't work and Stripe support told me to modify the SubscriptionItem, and I'm fine with that unless it is not recommended.
The only weird thing is that in the Stripe dashboard under Recent Activity it no longer tells you the name of the plan that it changed to. It only says the number of the plan, not the name like it used to, and the application owner is a little annoyed about that, but Stripe support said they'd pass that feedback on to the dev team - I imagine the Recent Activity section is just not surfacing that from farther down the hierarchy.
full sparrow
Hmmm... again, I think this depends on what you're actually trying to do when updating the Subscription Item.
hardy ore
@full sparrow Just changing the plan.
I'm using the plan terminology instead of price because these plans have been out there for about a decade. 🙂
full sparrow
Okay, so you meant to say you want to update the Price to do X. Is that correct? If that's the case, what is X in this context? Are you adding/removing a trial? Are you adjusting the amount? Are you adding another Price?
hardy ore
@full sparrow Essentially they're able to change their subscription level for more or fewer features. So it corresponds to a different product with a different price in Stripe. I'm not sure if I'm confusing the issue with the words being used because the legacy term was plan, and I know it's still supported but it seems like the terminology has changed to price over time.
But I know that passing the number with the plan attribute correctly changes it in the Stripe dashboard.
full sparrow
Plans and Prices are different things, but they do a lot of the same stuff, so unfortunately it's complicated to talk about them. Sorry if I'm asking a lot. Mostly I don't want to get tangled up in verbiage.
From our API docs (see here: https://stripe.com/docs/api/plans) on Plans:
You can now model subscriptions more flexibly using the Prices API. It replaces the Plans API and is backwards compatible to simplify your migration.
But I know that passing the number with the plan attribute correctly changes it in the Stripe dashboard.
Are you trying to change something via the Dashboard or the API?
hardy ore
API
And we have the modified code in production in our Rails app and it seems to be changing the user to the correct plan when we verify in the Stripe dashboard.
Of course when I look in the Stripe dashboard now, I only see Products, but the API ID for the product still corresponds to the legacy plan number which we saved in our database and use to change the user's plan.
full sparrow
If you click on the Product, it should take you to the view where the Price or Plan ID exists
hardy ore
It no longer says anything about plan there but it has a Pricing section for the product.
full sparrow
I assumed that was expected. Is there a reason you would be expecting a Plan instead of a Price after upgrading the API and creating Prices instead of Plans?
hardy ore
We have never created a Price before. Whatever is in Stripe is what was created there many years ago. After we upgraded the backend from the 2012 to the 2022 API version last month, we were still able to use the old customer create method we had used for all those years that allowed us to call Stripe::Customer.create and pass a plan and a card and when we do that, it automagically still creates both a Customer and a Subscription even those neither of those parameters are documented for the current API online! 🙂
The only reason I realized there might be an issue is when Subscription.update no longer changed the plan the way we expected and support told me to update the SubscriptionItem (and that we could still pass plan to that and it should work as expected).
Now we're in the process of trying to upgrade our ancient front-end to use the latest StripeJS with PaymentIntent, so we can't use that legacy Customer.create anymore, but that's a separate matter. 😄
full sparrow
Oof, that's a tall order! Well, we're happy to help you through your upgrade and advise on next steps, so let me know if there are any outstanding questions I've missed or if I'm overlooking something I should have clarified previously.
hardy ore
@full sparrow Well, it seems to work to change the customer's "subscription level" the way we expect if we continue calling update on the SubscriptionItem. It's just weird that now under Recent Activity in the dashboard, it says changed from num_x to num_y instead of name_x to name_y but we can probably live with that. I'm just wondering if Stripe would recommend we cancel/delete the Subscription and start a new one instead of updating the SubscriptionItem.
full sparrow
If updating the Subscription Item is yielding the desired behavior, then I'd be hesitant to create new Subscriptions. Are you building any net-new functionality beyond this? Is your question about how updating a Subscription Item might affect the Subscription's behavior?
Re. all of the above: you might be interested in using Test Clocks to test different scenarios with Subscription behavior, now that you've upgraded to Prices. Test Clocks let you essentially create a scenario and fast-forward through time to see what a Subscription might do when you take an action on it (like updating a Subscription Item)
hardy ore
@full sparrow No new functionality yet (we thought of using Coupon later). We're just trying to use the latest APIs in the correct way to maintain expected functionality.
Thanks for the tip about test clocks - I was already thinking I could use something like that.
Yes, could you tell me how updating the Subscription Item might affect the Subscription's behavior? I mean, should this be fine or is there anything I might really need to watch out for?
full sparrow
Each of the fields you can update on the Subscription Item are included here in the API docs: https://stripe.com/docs/api/subscription_items/update
They all have a description of what they do. I would pay close attention to proration_behavior and payment_behavior if you're concerned about what happens when these fields are modified. Other than that, updating Subscription Items could be useful, but it depends on what you are actually trying to do with the Subscription.