stripe_connect_platform-plans-prices | Stripe Developers | Page 1

shadow gull Feb 9, 2022, 5:18 PM

#

Hello! Go right ahead 👍

#

@hard ravine koopajah isn't online right now, but I can help

hard ravine Feb 9, 2022, 5:21 PM

#

@hollow veldt - how about this for a proposed solution for the issue of importing existing subscriptions and not being able to tell if a Subscription object was created with a plan or a price. Can we just make an API call to Stripe::Plan and add metadata of type:'plan' and then make an API call to Stripe::Price to add metadata of type:'price' and then we can differentiate when we pull in the Subscriptions? If you have Price and Plan as the same model, do you prevent a Plan with ID of "abc" and a Price of "abc" being created since it is a duplicate ID in the same livemode? If yes, and the Price/Plan ID is unique, then this would work yes?

#

OK

#

What do you think of pulling only Plans with a Stripe::Plan API call and adding metadata?

#

and the same for price.

shadow gull Feb 9, 2022, 5:24 PM

#

I think I'm missing the original context here - what's the issue you're trying to solve?

hard ravine Feb 9, 2022, 5:24 PM

#

Then pulling a standard Stripe accounts Subscriptions and stripping the ID of the unknown Plan/Price and looking up the metadata on it to see if it really was a legacy "Plan" or a new "Price".

#

A long, long time ago.......

#

There was a Stripe SKU and a Stripe Plan.

#

And we had models for those

#

Then you added Price and we had a lot of work to do on our end. We added a new Price model

#

We stored Plans in the Plan model and Prices in the Price model.

#

Now we have a customer with many subscriptions and we need to pull them into our app and we are pulling the Stripe::Subscription.

#

On that Subscription object there is a record of what the person bought but due to your backwards compatibility and the issue of a custom id like "custom-123", and not "plan_xxx" or "price_xxx" when we pull in a Subscription with someone who bought "custom-123" we cannot tell if it was really a Plan or really a Price. So.........That is the issue.

#

Do you prevent a Stripe::Price livemode:true with id "custom-123" if there exists a Stripe::Plan livemode:true with id "custom-123" since the ID is not unique? Or do you allow that?

shadow gull Feb 9, 2022, 5:28 PM

#

Ah, I think I see - so in your own databases you store plans and prices separately, which is a problem because when you retrieve a subscription you don't know where in your database to check. Is that right?

hard ravine Feb 9, 2022, 5:28 PM

#

Yup! That's the issue.

#

We didn't get much direction from Stripe when Price was created

#

So that's how we did it

#

And this I cannot change

#

So my mind came up with the ID of making a Stripe::Plan API call which should not return Stripe::Prices, correct?

#

So if we list all the Stripe::Plans, loop, and tag them with metadata, if it is true that you don't allow duplicate ids in a Stripe::Price that already exist in a Stripe::Plan, I think that would work. So asking if this would work before we code it.

#

Or if you see any other issues that would prevent this? I have many emails on this and the end result was that there is no way to tell if a Sub was created with a Price or a Plan without pulling the original request. So we were stuck for a few weeks and this is my proposed solution.

#

Problem: We have a Sub with a Price/Plan with ID of "custom-123". How can we tell if it was really a legacy Plan or a new Price that was the thing the customer purchased when creating the Sub? I imagine the Price/Plan data on the Sub has the plan

#

has the plan's metadata yes? If yes, it should work OR if IDs are unique scoped to livemode for Price/Plans

#

Can you confirm that IDs are unique scoped to livemode for Price/Plans

#

Or that the Price/Plan metadata is available on the sub and making a Stripe::Plan API call will allow us to bifiurcate Plans only without Prices.

shadow gull Feb 9, 2022, 5:35 PM

#

Well the big problem here is that from a quick test on my end it looks like listing plans also return prices

hard ravine Feb 9, 2022, 5:35 PM

#

On an older API version API call??

#

I think we can pick an older API version for the call to prevent that no?

shadow gull Feb 9, 2022, 5:38 PM

#

That's a good point, I tested this out with on a more recent version - give me one second

hard ravine Feb 9, 2022, 5:39 PM

#

I hate adding metadata but seems like the only way that I have figured out given the constraints

#

Also if standard Stripe Account owner John was using Platform X to create 10000 subscriptions but now he likes our platform better. We want him to be able to import those 10000 subscriptions and for us to store the sub ID and get webhooks to our platform from those subs. Are you going to be forcing him to stay with Platform X forever by blocking webhooks to us? I am unclear about the whole single-platform-webhooks thing you were/are considering as a new structure. Can you confirm that standard Stripe account holders will be able to deauthorize Platform X and move to us, Platform Y, and we can pick up webhooks even though the original platform that created those 10000 subs was Platform X?

shadow gull Feb 9, 2022, 5:43 PM

#

Even on an older API version (2014-03-13) I'm still getting back some price objects when I list out plans

hard ravine Feb 9, 2022, 5:43 PM

#

*I get that we can't get the integrated application/platform fee but we can deal with that issue.

#

really. hmmmm.

#

Um, I know we solved that issue. Let me check the code.

#

I think we do this and it works:
response = Stripe::Plan.list({:limit => 100}, {:stripe_account => "#{stripe_account_id}"})

#

STRIPE_API_VERSION: '2016-03-07'

#

No?

hollow veldt Feb 9, 2022, 5:51 PM

#

@hard ravine that should work no matter the API version really

hard ravine Feb 9, 2022, 5:56 PM

#

OK, and John on platform X will have no problem deauthorizing Platform X and authorizing us? And we can get webhooks from his existing subs?

hollow veldt Feb 9, 2022, 6:00 PM

#

I can't tell you, you'll have to have them try. It depends on the type of connection they have with Platform X really

hard ravine Feb 9, 2022, 6:03 PM

#

OK, can you clarify so I can let customers know? If they connected in what way is it not allowed? Most everyone will just be a standard account using Stripe Connect. If yes, can they always deauthorize an re-authorize with a different platform? I don't want them to go through the work of importing unless I know we can receive webhooks? What can we tell our customers to check to confirm that they can work with a new platform? Or is there something we can check on the import flow and just give them a message that import failed due to____?

hollow veldt Feb 9, 2022, 6:05 PM

#

We made changes to OAuth last year which I think we discussed before (but sorry if not, I talk to a lot of people every day here)
Our docs: https://stripe.com/docs/connect/oauth-changes-for-standard-platforms

When you connect to an OAuth platform nowadays, if you already have a Stripe account it will default to create a brand new account specific to that platform. That platform is called the "controlling platform" and that connection can't be revoked.

hard ravine Feb 9, 2022, 6:06 PM

#

OK, sound like if they have a controlling platform, they cannot even Oauth to our platform, correct? If yes, that is good since they will know really early on and cannot import anyway since they have not yet connected.

#

Thank you!

hollow veldt Feb 9, 2022, 6:11 PM

#

Some platforms are allowed to OAuth into controlled accounts. Can you give me your account id? I can double check if that's the case for you

hard ravine Feb 9, 2022, 7:31 PM

#

Cool. Thank you.
acct_183tJHHnzkM7EAuH

hollow veldt Feb 9, 2022, 7:51 PM

#

okay you have the setting that would let you connect to any Stripe account, even if they are controlled, so you shouldn't see any issue

hard ravine Feb 9, 2022, 8:30 PM

#

Awesome! Thank you for checking that!

#stripe_connect_platform-plans-prices