#stripe_connect_platform-subscription

1 messages · Page 1 of 1 (latest)

honest granite
sacred whale
#

We have a lot of errors. Confused by the params data format for invoice.payment.succeeded vs. the Subscription object. Is the Subscription object 100% of the time in the same exact format? Issue with plan: null when everything used to be in plan and if subscription["items"]["data"][0]["plan"].present? is that needed for older subscription objects or is everything now subscription["items"]["data"][0]["price"].present?

#

We need code that always strips the interval and interval count from the Subscription object but we have people on Subscriptions created 5+ years ago

#

And people on Subscriptions created today

#

So do we need something wonky like:

#

if subscription["items"]["data"][0]["plan"].present?
interval = subscription["items"]["data"][0]["plan"]["interval"] #"year"
interval_count = subscription["items"]["data"][0]["plan"]["interval_count"] #1
elsif subscription["items"]["data"][0]["price"].present?
interval = subscription["items"]["data"][0]["price"]["interval"] #"year"
interval_count = subscription["items"]["data"][0]["price"]["interval_count"] #1
end

#

Our code was originally doing this:

#

stripe_plan_id = subscription["plan"]["id"] #4

# interval = subscription["plan"]["interval"] #"year"
# interval_count = subscription["plan"]["interval_count"]
#

That was pretty simple. But now the Subscription.plan is null!!!!!! Eek!

#

And the docs have "price" not "plan".

#

So again we have subscriptions created any time in the last 5 years that are renewing and the code needs to also work moving forward, so what is the best way to get the Subscription object and pull:
(A) id of the "plan" or "price"
(B) interval of the "plan" or "price" assuming of type recurring
(C) interval count of the "plan" or "price" assuming recurring

cursive swift
#

Hey, sorry I missed this initially. Catching up now.

#

Do you have the id of a subscription where plan is null like this (sub_123)

sacred whale
#

Let me check but i have this email from Stripe explaining it

#

Hi Adam,

Apologies, that’s correct — the data will be sent based on your Platform account’s API version.

The behavior here is still due to the deprecation of the plan property in recent API versions, however. Specifically, when we deprecated the plan property, we introduced the ability to have more than one plan per subscription. When this is the case, as with your connected account’s subscription, we can’t surface more than one top-level subscription.plan and so we return null with the plan details being nested under items instead. This is the case even with older API versions.

In other words, when there is more than one plan on the subscription it’s expected that the subscription.plan field will return null, and so it’s best to rely on pulling this information from the items list instead.

Best,
Dave

#

"so it’s best to rely on pulling this information from the items list instead."

#

But do you have 2 different key values for the Subscription object?

#

Is it sometimes "price" and sometimes "plan" or ALWAY 100% "price"

#

Even for subs created 5 years ago

#

Question:
How to always get the correct Subscription.
(A) id
(B) interval
(C) interval_count
From the Subscription object under all circumstances regardless of the created_at date on the Subcritption being Time.now - 5 years, Time.now or Time.now + 5.years in the future. 🙂

cursive swift
#

Ah thank you I see.

#

And so what is the current behavior you are seeing? Are you seeing these under "price" or "plan" for the subscription items?

#

And do you have the id of a subscription where plan is null like this (sub_123

sacred whale
#

We are getting cannot find subcription.plan so I am asking what is the best way to do this now that you have moved to prices from plans but we have plans renewing and prices renewing.

#

I can dig for an error but the question is just where are these things now?

#

We are now getting the Subscription object

#

So question is, on your subscription object is it dynamic like sometimes you hide the id of the sub under "plan" and sometimes under "price" or alway under "price"??????

#

We need this not just for one failing sub but to write it so it works for all subs. That is my question.

sacred whale
#

Heres one that failed

#

"subscription": "sub_JGhbFImME7ndvz",

#

NoMethodError: undefined method `[]' for nil:NilClass

#

Here is the line that failed:
6:
interval = subscription["plan"]["interval"] #"year"

#

This was due to sub.plan now moved by Stripe and replaced with null 😦

#

So where do we find this data?

#

In items is it ALWAYS under "price"? Or do you ever put "plan" in for "price" ?????

#

On the Sub object

#

1.) Can we look at the Sub object in the dashboard somehow or do we need to make an API call?
2.) Do you have documentation on the format of webhooks? For example, can we look at docs on the data format of invoice.payment.succeeded or do we just need to make an API call to get this data structure?
Our confusion is with changes to the data structure. We thought since the API version on our platform account defines the data structure for webhooks, we thought it would also define the data structure on responses to get objects like the Subscription object? Is that true or false? Are Stripe responses to objects different based on API call Stripe.api_version or always the same? ie. if we update our Stripe.api_version are you moving the Sub plan/price from "plan" to "price" or is the Sub object returned when we retrieve a sub always static format?

gleaming idol
#

@sacred whale plan on Subscription top-level has been deprecated since 2017 when we introduced the ability to have multiple plans per subscription. You should never rely on it. Instead you should look at the items collection in the response

#

Since you're a platform, you should always look at items.data[0].price

sacred whale
#

OK, items.data[0].price is always items.data[0].price even for subs created 5 years ago with a plan? Can you confirm that?

#

Does Subscription.retrieve response change with different API versions or will it always be the same format even if we are on a 2016 API version?

#

or update to a 2020 Stripe api_version

gleaming idol
#

OK, items.data[0].price is always items.data[0].price even for subs created 5 years ago with a plan? Can you confirm that?
it should yes
Does Subscription.retrieve response change with different API versions or will it always be the same format even if we are on a 2016 API version?
API version is here on purpose to change the shape. So the API version you use will alter the response yes, that's how it was built.
Now the API version of the connected account, or of the request to create the subscription doesn't matter. What matters is the API version your code uses when making the API request

sacred whale
#

Right, that is what confused us.
If we use Stripe API version STRIPE_API_VERSION: '2016-03-07'

#

Shouldn't the sub.plan still have data on it?

#

rather than be plan:null and the plan now in the items[0].price?

gleaming idol
#

not always, for example if a Subscription has 2 plans, then sub.plan is always null, it's been true for many years and it isn't really an API version change. It just wouldn't make sense to return one plan id in there when the subscription has 2 (or 20)

#

Do you have a subscription with just one Price on it and still plan is null? If so do you have a subscription id?

sacred whale
#

hmm. OK that helps. We are going to try to fix this now. Thank you!