#simmonson-oauth-accesstokens
rain pike
hello, so side stepping the actual question for a second
why use access tokens? why not use Stripe-Account header which is way better and the recommended approach
late temple
I'm looking at an example like this:
curl https://api.stripe.com/v1/accounts/{{CONNECTED_STRIPE_ACCOUNT_ID}} \
-u {{PLATFORM_SECRET_KEY}}:
My assumption here is PLATFORM_SECRET_KEY is the secret key of the account to which other Stripe accounts connect.
CONNECTED_STRIPE_ACCOUNT_ID is the same as stripe_user_id that is part of the response of successful OAuth connection
rain pike
no
PLATFORM_SECRET_KEY is what it says, the Platform account's secret key
not the access token key you get back in OAuth
and yes to the second part stripe_user_id like acct_123
late temple
Yes, to clarify, Platform account is the account to which other Stripe accounts connect
rain pike
yep!
ah sorry just re-read your statement
so yes you were originally sayign the same thign I was
My assumption here is PLATFORM_SECRET_KEY is the secret key of the account to which other Stripe accounts connect.
you and I said the same thing, sorry for the confusion
so with that said
the approach you just mentioned is the recommended approach
but earlier you mentioned the "legacy" approach i.e.
However, upon successful OAuth connection, when making an GET authorized request with the access token that we have to /v1/products,
using the OAuth AccessToken is the legacy approach which I is not recommended
and this is recommended
#917469186937208862 message
late temple
Right. Do you have an example of a GET request for retrieving a list of products? Doing something like below will try to get a specific product based on the pathname that comes after /products, so I'm unsure where to pass in CONNECTED_STRIPE_ACCOUNT_ID in this case to test this out
curl https://api.stripe.com/v1/products/{{CONNECTED_STRIPE_ACCOUNT_ID}} \
-u {{PLATFORM_SECRET_KEY}}:
are you using a Stripe library like stripe-node or something? or just curl
ah you need this doc, sorry I realize you haven't seen this one probably
that has what you need
late temple
For testing I'm just trying via curl or postman. I saw the Stripe SDK, where you can instantiate a Stripe class with the CONNECTED_STRIPE_ACCOUNT_ID
rain pike
you need to pass the Stripe-Account header, which that doc explains
late temple
so it's not possible via typical requests, it has to be done via the SDK?
rain pike
no it is possible via Postman
just pass a header
called Stripe-Account with an Account ID as the value
late temple
Thanks for that. I can definitely change up our flow to use the Stripe-Account header rather than the legacy way.
The result of using the recommended way, however, still results in a response like this:
products: { object: 'list', data: [], has_more: false, url: '/v1/products' }
the list of data is still empty. I verified that there are products in the account for the Stripe-Account, and tried making a simple request with the account's api key (not the Stripe Connect platform way), and that returns a list of products.
What is even more strange to me is that /prices return a list of prices for each product. But the /products endpoint doesn't seem to return a list of products. As I can understand it, in order to retrieve both product name, description, and pricing, I need to make a discrete call, one to /prices and another to /products
rain pike
gotcha so
now that we are using the right approach, now we can dive into the original question on why you're seeing zero products
let's start here
what is the request ID for that API request you made? should be returned in the response headers in your request from Postman/curl
late temple
req_PO0bp9bsxdrXlp
stuck pebble
👋 I'm just hopping in since @rain pike has to head out soon, give me a minute to get caught up
I think I know what the issue is, but just so I can confirm - can you try making the request again but set the Stripe-Version header to 2020-08-27?
stuck pebble
Try one more thing as well - remove the Stripe-Version header and set type: service in the request
late temple
added type: service in the Header, and returns a populated list of data as well
^ false
I removed the Stripe-Version header, and adding type: service in the header did not work
stuck pebble
not in the header - you should be adding type: service just as a parameter
late temple
Ah sorry, realized it wasn't a header param. Added it to the query param and that worked as well
stuck pebble
Yeah so the issue here is that before API version 2018-02-05 (https://stripe.com/docs/upgrades#2018-02-05) there was a change to Products so that they were created with type:service by default (which is what the Products for this account were created with). If you're on an API version that is BEFORE 2018-02-05, you need to specify type:service to retrieve them since it won't return those types of Products by default
late temple
Ah - so we have to know before making the request whether the type is service or good
based on the latest API updates for v1
stuck pebble
If you're not working with our super legacy Orders API I think you can assume that the products you'll be working with should be of type:service but let me check something
late temple
our application is making a request on behalf of other Stripe accounts, so I'm not sure if there is a way to differentiate it for each account. They could have created products via a legacy API perhaps...?
stuck pebble
Well, how specifically are you using the Products that you retrieve?
late temple
Specifically, product image(s), name, price, and SKU (although I see that the SKU endpoints are legacy at this point)
However, the query parameter specification for type is the unblocker, so that is super helpful. The other stuff is quite minor and something I can deal with internally
stuck pebble
I ask because if your intention is to use the Product with Orders, those will only work with type:good Products so there's no reason to retrieve the type: service Products
late temple
I want to say no, but I'm not 100% sure I am correct in saying no
The plan is that we want to show a list of products on behalf of the user with the product details I mentioned. Then, we want to be able to have a page visitor go through the stripe checkout flow (using the prebuilt checkout via the Stripe SDK). At this point, I understand that we need to use the checkout sessions part of the SDK or API to generate a session unique to the visitor/customer, and use the session.url to redirect to Stripe's domain of the checkout flow
I don't think the above UX/flow requires using Products with Orders
stuck pebble
If you're worried, I'd suggest making two API calls to retrieve products for both types (one for goods and one for services) so you can show them an exhaustive list of available Products
late temple
Absolutely, that was the easy backup plan
I have a sort-of related question about Stripe OAuth in general, should I ask that as a new question in the channel or continue via this thread?
stuck pebble
You can continue here - I need to head out, buy @gentle crest should be able to help!
late temple
Hi @gentle crest , my question about Stripe OAuth is that it seems to only be for connecting Stripe accounts together.
The OAuth flow, upon connecting accounts, shows copy about how the Account to which you are connecting will have access to payment and payout history, etc.
I am wondering if there is a way to make authorized requests on behalf of Stripe accounts that only require product and price data (read only, to show that data, and later create a checkout session). It feels overkill to use OAuth and have accounts/payments/etc data accessible when it is not required
gentle crest
Catching up here one moment...
Unfortunately I am not aware of a read-only way to connect accounts like that.
And what kind of Connect are you using?
late temple
I'm not sure what kind of Connect as I can only find 1 kind, but have been following this: https://stripe.com/docs/connect/oauth-reference
I suppose our use case isn't very common for Stripe API consumers...
gentle crest
Thanks for the clarification, I missed the detail earlier that these are pre-existing accounts.
So yes, either method of connecting will have read-write access if you want to create Checkout Sessions for them
Unfortunately as far as I can see, the permissions do not get more granular than that at the moment.
late temple
Thanks for that explanation. I've been spending a lot of time in the Stripe docs to see whether there is a solution. Just clarifying, there is no way to approach what I'm trying to do, even outside the the Stripe Connect feature?
rain pike
the ideal way is to use Connect but you're right in that there's no way to granulate "only give access to X, Y, Z endpoints"
an alternative is using Restricted Keys, where say I'm a Connect account, I connect to your Platform, then I go to my Stripe Dashboard at https://dashboard.stripe.com/test/apikeys/create and create "Restricted Keys" for "Products" and "CheckoutSessions" and I copy-paste that over to you.
Granted, it is more non-user friendly/includes user friction and is more error prone (copy paste issues) or users incorrectly creating restricted keys (and giving you more/less permissions)
for now my recommendation would just be to use Connect really
late temple
The 2 approaches are the only ways that I was able to figure out based on what I've read in the docs as well. I was hesitant on the restricted key generation and access because a lot of our users are not technical friendly or may not have permissions to generate a restricted key.
The downside of using Connect is that I am creating an unnecessary vector for malicious hacks, especially when I'm not using any account/payment/payouts data in the application/server side code. I suppose this is more of a legal consultation and not appropriate for this channel?
Thanks for this explanation though, I have more confidence with the 2 approaches after your confirmation.
rain pike
I suppose this is more of a legal consultation and not appropriate for this channel?
haha yep I don't really have anything to add
but I've helped plenty of Platforms integrate what you're integrating and Connect is the right way to go for now (albeit the caveat for "lack of perm granularity)
late temple
ok thanks for all the help from 3 Stripe devs! Thank you very much, I think we can consider this thread to be resolved