#stripe_connect_platform

1 messages · Page 1 of 1 (latest)

rugged birchBOT
misty hemlock
#

This sub:
sub_1LhJvlGkntF0z1iAKEToyE9X
for example:
Bought this price_id which is still in the format
plan_LvqKgcteOBhNJj

#

this boggles my mind

solid magnet
#

sorry for the delay, catching up here

#

Plan objects can still be used with subscriptions, even though the latest object type to use is Price

misty hemlock
#

the issue is about importing subscription that can go back 10 years

#

or 7 years

#

actually

#

I am confused

#

is that a remnant from the past....or because we are using an old Stripe.api_version?

#

Subscription.list
Then we are importing
And I need to look on the sub for the thing they bought and save it in our db.

solid magnet
#

Plans were an older way of working with subscriptions, yes

misty hemlock
#

Is it always on sub.plan.id? whether it is in the old plan_xxxxxxx or price_xxxxx format? and there will always be a Price for it in the account even if the Price id is in the old format sometimes?

#

In the sub obj, I am confused and concerned by the id being on the sub.plan and no existence of a sub.price

#

is that due to our old API version or is that just the way it is

#

Our code is like this:
price_id = sub.try(:plan).try(:id)
Seems confusing

solid magnet
#

Getting some help from a colleague!

misty hemlock
#

yeah I'm a difficult case

glacial lichen
#

Hello

#

What's the exact question here @misty hemlock? As noted, Plans are legacy but still functional. If used they will appear in the subscription item as both the data.plan.id and data.price.id.

misty hemlock
#

Not coming that way

#

(byebug) sub.data
*** NoMethodError Exception: undefined method `data' for #Stripe::Subscription:0x00007fdc4df98018

nil
(byebug) sub.plan
#<Stripe::Plan:0x3fee19098138 id=plan_LvqKgcteOBhNJj> JSON: {
"id": "plan_LvqKgcteOBhNJj",
"object": "plan",
"active": true,
"aggregate_usage": null,
"amount": 10000,
"amount_decimal": "10000",
"billing_scheme": "per_unit",
"created": 1656023801,
"currency": "usd",
"interval": "month",
"interval_count": 1,
"livemode": false,
"metadata": {},
"name": "Amazing Plan",
"nickname": null,
"product": "prod_LvqKHdrdEDw3Ln",
"statement_descriptor": null,
"tiers": null,
"tiers_mode": null,
"transform_usage": null,
"trial_period_days": null,
"usage_type": "licensed"
}
(byebug)

#

sub.data is null

#

sub.plan is there

#

sub.price is not there

#

sub.data.plan is not there

glacial lichen
#

What Sub is that?

#

The one above?

misty hemlock
#

sub.data.price is that

#

The first one I get when importing subs

#

one sec

#

Do we have to do an import with a newer API version?

#

That is question #1.

glacial lichen
#

Let's back up

#

What are you trying to accomplish

misty hemlock
#

i couldn't even explain really

#

but basically you own a standard Stripe account and you have been using it for 7 years before you guys switched from Plan to Price so you have 100,000 subscriptions that were made over the last 7 years. You want to use our app so you want to import those subscriptions into our app. We are making an API call to Stripe after Oauth Connect to pull in your subs. Then we need to store relevant data like the thing the person purchased and have it associated with the Plan or Price or whatever you want to call it (now "Price")

#

Back in the day, we have a TestPlan table and a Plan table - worst mistake of my life.

#

Now we hae a Price table with a livemode attr

#

I am trying to see if we can just store everything in the Price table and disregard the old Plan and TestPlan tables......

#

I'm trying to code it so no matter what the subscription is or when it was created, that we pull the plan_or_price_id_xxxxxxxxxxxxxx

#

Sorry, this change totally messed with our app and it is hard to deal with the legacy app that was created when you all had Plans

#

I think I am just going to treat everything like a price

#

my guess is we are using an old api version - is that why the sub has no sub.data perhaps????

#

We are doing that b/c you made yet another change in listing subs

glacial lichen
#

So yeah, you should be able to treat Prices and Plans the same. Shouldn't really matter here for Subs that have already been created.

misty hemlock
#

We only want ['active','past_due','trialing''

glacial lichen
#

Don't think the API version should matter upon retrieval

#

But let me check

misty hemlock
#

And you used to list one way and now list another so switching the API version means I need to re-write the listing of subs too

glacial lichen
#

Not sure what you mean by that

misty hemlock
#

I think you used to like not return a sub if it was not active or something?

#

like if you retrieved a sub and it was not active you returned nil or you now have to explicitly put the status you want to retrieve, or something...i don't remember, I have to check but I think status was assumed and now has to be explicit or vice versa

#

We are doing this now:
results = Stripe::Subscription.list({ limit: 100, starting_after: starting_after, expand: ['data.customer'], status: 'active'}, :stripe_account => site.stripe_user_id )

glacial lichen
#

No the only real change was that we stopped returning Subs by default when retrieving Customers

misty hemlock
#

hmm

#

Can we get active, trialing and past_due in one API call?
results = Stripe::Subscription.list({ limit: 100, starting_after: starting_after, expand: ['data.customer'], status: 'active'}, :stripe_account => site.stripe_user_id )

#

instead of just active?

#

Then just trialing:
results = Stripe::Subscription.list({ limit: 100, starting_after: starting_after, expand: ['data.customer'], status: 'trialing'}, :stripe_account => site.stripe_user_id )

#

etc.

glacial lichen
#

Yes

misty hemlock
#

status ['active','trialing','past_due']

glacial lichen
#

As you are doing

#

You can set to all or you can specify

misty hemlock
#

Can you pass an array?

#

not all

#

only ['active','trialing','past_due']

glacial lichen
#

No

misty hemlock
#

right, that's the issue

#

So we have to do it as we are doing

glacial lichen
#

You can set 1 of the enums, you can set all, or you can leave blank which will return all except for canceled.

misty hemlock
#

right so to get ['active','trialing','past_due'] we have to do it 3 times

#

ok, that is the same in new API versions?

glacial lichen
#

Yes

misty hemlock
#

ok

#

so anyway, yes so why do you say to look at the sub.data.id when sub.data is nil?

#

everything is in plan:
"pending_setup_intent": null,
"pending_update": null,
"plan": {"id":"plan_LvqKgcteOBhNJj","object":"plan","active":true,"aggregate_usage":null,"amount":10000,"amount_decimal":"10000","billing_scheme":"per_unit","created":1656023801,"currency":"usd","interval":"month","interval_count":1,"livemode":false,"metadata":{},"name":"Amazing Plan","nickname":null,"product":"prod_LvqKHdrdEDw3Ln","statement_descriptor":null,"tiers":null,"tiers_mode":null,"transform_usage":null,"trial_period_days":null,"usage_type":"licensed"},
"quantity": 1,

#

sub.plan

glacial lichen
#

Yeah checking on that. That may be due to old API version retrieval

misty hemlock
#

which is weird since its now a price

glacial lichen
#

Try listing with newest (2022-08-01)

misty hemlock
#

OK, so just checking

#

given the scenario of someone who has a stripe account that has been gathering subs for like 7 years, nothing will be lost using Subscription.list with the new API version?

glacial lichen
misty hemlock
#

Are you listing and you have sub.data?

glacial lichen
#

Yes, but mine weren't created with an old API version

#

That's what I still need to check on

misty hemlock
#

oh

#

yeah, i am not getting that .data

#

we definitely don't want to corrupt the import and only get subs created with the new API versions.

glacial lichen
#

Did you test listing with the new version?

#

For that same sub?

misty hemlock
#

ye

#

yes

#

just did

glacial lichen
#

And the Subscription item data is under plan

misty hemlock
#

yes sir

glacial lichen
#

What is your exact log?

misty hemlock
#

the problem with us is we need to always deal with lots of edge cases like subs created over the last 7 years and need to know where to look in the object for the right data no matter the edge case

glacial lichen
#

No sorry, I mean what exactly are you logging out? Like subscriptions.data[0].items.data?

misty hemlock
#

?

#

subscriptions is an array of subscriptions we pulled from stripe

#

i am in one subscription stored as a sub

#

sub.data fails

#

with a NoMethodError

#

there is no subscriptions.data....It's an array of subscriptions

#

i am going to need to take a break for my sanity

#

thank you for trying

glacial lichen
#

You stated you were listing Subs.

#

So that is a disconnect.

#

Now you say you are retrieving an individual sub