We’re a POS system integrating Square terminal. Our system is distributed client/server, NOT cloud-based. Reading through the OAuth docs, the API seems to require a server to process and retrieve the authorization code to obtain a token… If every workstation would have its own IP address, I don’t see how I can put a redirect URL in our developer application profile that would resolve for all of them. Isn’t there a way to retrieve an authorization code without installing a webserver somewhere to parse the response? Why can’t Square simply display an authorization code for the user to copy into our program? Or an endpoint to query for an authorization code from a specific merchant ID?
Hi @Rick_Computerworks, welcome to the forums!
Not sure I’m understanding about the IP address situation - technically you will only have one OAuth redirect url for all your merchant clients. There is no way around this at this time unfortunately, and this is the only way to retrieve the authorization code (via a url parameter).
The issue isn’t the need for more than one redirect URL. The issue is that there isn’t a way to access/retrieve an authorization code from a desktop/laptop without a redirect URL and server somewhere. There should be an endpoint where the desktop app requesting an authorization code can perform a request authorization code after one has been issued without checking a redirect page to nowhere.
Got it, appreciate the feedback. I’ll update this to be a feature request for now, but it currently is not possible.
Given that you have a distributed client/server setup, why not just proxy this through one of the servers? The client could request an authorization token through one of your local servers. Ultimately, you need the bearer token to access the Square service from the client.
We install our system at our customers sites, but do not control or own their equipment, etc. So the customers would have to know enough about webservers and such, or we would have to support and maintain their webserver, which our tech support isn’t going to do, not to mention that some of our customers are colleges and universities that absolutely would object to us setting up a webserver… So things like utilizing the webhooks, or setting up a server that only handles the authorization redirect, are not practical.
We got around this issue by putting a generic page on our company’s website that simply responds to the redirect, and we grab the code from the redirect URL from an internal webbrowser window… At least we’re not sending our customers to a non-existent page, and we can make it look professional.