#stripe_connect_platform - plans and prices

1 messages ยท Page 1 of 1 (latest)

proud gale
#

hey again, want to continue in the other thread?

lilac topaz
#

hey I know @cursive jackal is aware of this issue. No its fine here.

#

Shouldn't we be able to tag Plans as plans with metadata and Prices and prices with metadata for our ease of reference?

proud gale
#

What are you stuck on, exactly

lilac topaz
#

I came up with a plan (no pun intended) to make a Stripe::Plan API call to list the plans. We seem to only get Plans (not prices) and then just call update to add metadata to tag them as plans.

#

Long story but we do have Plans and Prices in different tables currently and the problem is with importing of existing subscriptions created with another platform and listing the Subscriptions and then figuring out a way to deteremine if the thing purchased to create the Susbcription was a legacy Plan or Price since we have two different attributes on our records and they are assoicated with different tables so we need to figure out which one they are.....or totally restructure our db.

#

In general where is there an issue. Can we make a legacy payment button with a Price? And can we make a new Checkout button with a legacy Plan? Any issue with either of those?

proud gale
#

What problems are you encountering when doing any of that?

lilac topaz
#

My dev tried this in the morning. He says when you update a Price you override the metadata on the plan.

proud gale
#

Can you share a specific example of this?

lilac topaz
#

The main issue is this. We pull an accounts Subscriptions and you did such a good job with backwards compatibility that we cannot tell if the Sub was created with a Plan or a Price. I am trying to work around that.

#

And we have Plans and Prices in different tables in our db. So we have a record with a member and a stripe_plan_id and a stripe_price_id and we have to figure out which attr to save.

#

We basically are just saving the subscription ID but we also need to list the Plan/Price ID and show in the view what the person purchased. That is causing an issue.

#

I think we should maybe leave our Plan table alone but do what you do and pull both Prices and Plans into our Price table.

#

Can a Plan and a Price have the same ID?

#

in the same livemode? Can you have livemode:true Plan id of 'abc' and livemode:true Price id of 'abc'? If so, how are you putting them in the same model/table?

#

Is Stripe's ID unique on the Price model? If yes, that would help us I think.

#

The only example I can share is pulling an accounts entire list of subscriptions, some of which were created with Plans and some of which were created with Prices. But that is hard to share.

#

This is for accounts that have been around for a few years crossing your old and new way of doing Plans/Prices.

proud gale
#

Well the public API doesnt support custom price ids, and the generated ones are expected to be unique yes

lilac topaz
#

The customers who we tried to import have tons of custom ids

#

The dashboard makes it easy to create a Price with a custom id. ๐Ÿ˜ญ

#

That's why i tried to list all Plans and tag them with metadata of model:'plan' and then list all Prices and tag them with metadata of model:'price' but this failed.

proud gale
#

It's there for similar backwards compatibility reasons for accounts that used it before with plans

lilac topaz
#

Rather than guessing form the format of the id

proud gale
#

You should be able to set the metadata, i'd be curious to see what you described

vernal pulsar
#

๐Ÿ‘‹ I'm also hopping in to catch up since @proud gale has to head out

lilac topaz
#

I think if we made a plan it makes a price and when me add metadata to the price if overwrites the existing metadata on the plan tagging it as a plan. My dev did it this am. I can do it and get you req_ids

#

I might be giving up for today

#

I think I will need to give you some specific request ids. I was trying to get a solution in general before setting up this to send you req_ids

vernal pulsar
#

Yeah seeing the exact request IDs would help - I just did a quick test on my end where I added metadata to a price using the Plans API, added different metadata using the Prices API and I'm not seeing the same overriding behavior you're describing

lilac topaz
#

Let me ask this

#

If in 2016 I had 100 Plans and didn't add any.

#

If I woke up in 2022 and made a Stripe::Price.list API call, would I get back [] or would I get back 100 results?

vernal pulsar
#

I would expect you to get back 100 results

lilac topaz
#

OK and if I called Stripe::Plan.list I would also get 100 results?

#

And now if I create a new price with Stripe::Price, and called Stripe::Price.list, I would get back 101 results?

#

And Stripe::Plan would give me back 100? Or 101?

#

I am asking what is the difference on your end between
1.) Stripe::Plan.list
2.) Stripe::Price.list

#

Did you guys make a duplicate of every Plan and turn it into a Price object?

vernal pulsar
#

I would expect you to get 100 from the Plans API before adding any, and after adding an additional price I'd expect you to get 101 from both the prices and plans api

lilac topaz
#

So there is no difference between Stripe::Plan results and Stripe::Price results???

#

The part that is hard for me is Stripe's side is a black box and I am confused what you are doing on your end so it is causing confusion I am trying to clear up since there are no docs on this - or if there are, can you send!

#

Last question, is there any way when I look at a single record in the Stripe dashboard to tell if it was a legacy plan or a new price? I am trying to confirm if our app is migrating correctly or not and am not sure how to test an individual record and confirm.

#

Sorry, the problem is my not fully getting something on how you made Plans backwards compatible exactly. It is my lack of understanding that is causing the issue.

#

If you can suggest some better means than tagging with metadata, please let me know. I suggested it and someone on your team thought it would work. I will try again and send specific request ids

vernal pulsar
#

Yes, my understanding is that the plan and price results would be the same. I don't think we have any specific docs that cover this other than the migration docs for Plans -> Prices, which don't go into detail about the backwards compatibility aspect you're curious about

And I do believe your metadata suggestion would work fine - you'd do a one-time script where you go through every DB record you have in your plans table and add update the plan/price with the metadata you want to signal which table it's coming from