I have created an app and an (additional) sandbox test account.
I have gone through the OAuth authorize code flow (non-PKCE method), requested a refresh token and an access token successfully.
I have even used that refresh token and access token to refresh the access token.
BUT under the app dev console :: “Locations”, the console reports:
“This application hasn’t been authorized and given permissions to access <the test account>. To create or renew an access token, visit the OAuth page.”
Clearly the app is authorized, since I was given access and refresh tokens that can at least refresh the access token.
What am I missing? How do I get the location ID?
BTW: I’m ultimately trying to use the “payment-links” API, which apparently requires the location ID. Works with the personal access token and location ID, but that is a security nightmare I’d rather not leave open.
The dev console for the app shows conflicting information:
Under OAuth:: Test account authorizations, the test account is listed, but the Access Token field is empty (reminder: I am able to receive access tokens, I promise.) Authorization Details even shows the correct permissions that were requested.
So the authorization definitely took place and is known, at least on some level, to Square servers. Something feels broken.
I’ve added MERCHANT_PROFILE_READ to the OAuth authorization request.
I’ve verified under Authorization details that the MERCHANT_PROFILE_READ is checked.
Locations for the test account that has granted the app Oauth authorization still does not show locations in square developer console. It continues to show:
“This application hasn’t been authorized and given permissions to access <test account>. To create or renew an access token, visit the OAuth page.”
This seems like very fundamental functionality. I seem to have followed the Square documentation to the letter. Please advise what else to try.
Note: the “Access token” and “Expires” fields under “Test account authorizations” also do not show anything for the test account (although the test account is listed). This does not feel like an OAuth permissions issue.
I was finally able to get the default sandbox location ID by CURLing the locations API manually. It seems to be working, but who knows what other surprises are lurking around the corners.
Your developer console, therefore, is seriously broken.
It does not show location IDs properly
It does not show access token information properly.
I seriously regret the time I’ve wasted testing and debugging your software.
Since I do not need to retrieve the location ID programmatically (or wouldn’t if your web software worked as advertised.) I now have extraneous permissions set. This is really disappointing.
I only hope the production workflow functions more reasonably and without added security issues.
Those test accounts are designed to represent and entirely different Square account for OAuth testing. That is why the location is not made available in the UI because with OAuth applications have to call the Locations API to get the full list of locations for the account.
If your building a custom application that no other sellers are going to use we recommend using the Default Test Account. Those credentials are the ones in the UI of the application.
This exactly contradicts what the square documentation says:
“The Sandbox location ID is listed on the Locations page for each application in the Developer Console. You can also retrieve the location ID programmatically by calling ListLocations with a Sandbox access token.”
There’s no mention that this only applies to the default sandbox.
Furthermore, the dev console UI has a dropdown to select all of the sandbox accounts specifically for location. If the dev console is not meant to show non-default sandbox account locations, why does the dev console UI have a dropdown option to select non-default sandbox accounts?
And why does it erroneously display an error message that the App has not been authorized for the sandbox account?
Absolutely nothing in the documentation or the dev console UI is indicative of what you’re saying.
By the way, when using the default sandbox account to obtain refresh and access tokens with OAuth:
Upon successfully authorizing and receiving an access token, the dev console::OAuth::“Test account authorizations” section does NOT show the newly acquired access token and expiration in the table.
It just displays an additional, identical row in the table for the default sandbox test account with the same access token (the default “personal” token) and no expiration. Which is NOT what is returned in the OAuth flow (thankfully). What is the point of displaying multiple, identical rows while omitting the useful information of the OAuth acquired access tokens?
This must be yet another bug. Or at least I can’t imagine that is the intended behavior.
The information about the test accounts is in the OAuth section.
With the Default test account there is no need to get a refresh token. You can use the access token from the credentials. That token won’t expire. You don’t have to OAuth with that token.
Nothing here addresses any of the issues, erroneous behavior, bugs, or contradicting information that has been discussed in this topic thread.
As I mentioned in my very first post of this topic thread, the problem with using the default access token, and not using OAuth, is that the default access token is fully privileged with all permissions.
With all due respect, this thread is starting to feel like a conversation with a poorly trained LLM.
I am having the exact same problem. I created the “Test Seller Account” as recommended in the documentation, so I could test my OAuth code in the sandbox. It is recommended in this thread to use the personal sandbox access token, but that approach does not test my OAuth code. The developer console does not let me access the location ID for this test account, so I can’t make any requests.
I have had a very frustrating day trying to figure this out.
What I eventually figured out is that you have two choices:
You actually can use the default sandbox test account for OAuth. (Just ignore the default access token for the default sandbox test account.) That will let you use the location ID shown in the dev console for the default sandbox test account. BUT since you can’t just delete the default sandbox test account, it’s not great for development IMHO. You can revoke access tokens, sure, but who knows what state is hanging around on the square side (the dev console shows all kinds of weirdnesses that are apparently inexplicable, as I’ve described in this thread.)
You can use the additional sandbox test accounts and get the location IDs using the API: https://developer.squareup.com/reference/square/locations-api/list-locations
You can try to use the square API explorer to do this, but honestly, I recommend just curling it yourself manually on CLI or in a script. This is nice since you can delete these sandbox test accounts with (at least more) certainty that things are being cleaned up.
Nothing in the square documentation or the behavior of the square dev console (or basic common sense) would make one think either of these options is the correct path, but it does seem to be the only two options as far as I’ve been able to tell.
