I’m using KioskPro to make a kiosk of my website. It acts as a normal browser, but locked to one site. I’d like the POS app to return to it, as opposed to opening Safari. They have a registered URL schema. But the developer console doesn’t want anything other than https. Is there a way to have the POS API return to where it was called from, hopefully passing an URL?
Also the documentation says that the callback URL is called as a POST transaction. It needs to be corrected, because it does not. On both Android and iOS it seems to open the callback URL with the default browser, which then makes an ordinary GET request of it. This could be a potential problem since GET requests are subject to caching. Devs need to be aware of this.
I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
Additional Documentation
Point of Sale API and POS Integration Tools
Build on iOS: Point of Sale API
Mobile Web Technical Reference
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
To address your first concern, the Square Point of Sale API requires the callback URL to be an HTTPS URL, which is a standard security measure. This means that the callback URL must be a secure web address, and it cannot be a custom URL scheme like those used by some applications to handle deep linking. Unfortunately, this limitation means that the POS API cannot directly return to a custom URL scheme like the one used by KioskPro. The callback will open in the default browser, which is typically Safari on iOS devices.
Regarding your second point, you are correct that the documentation should clarify the behavior of the callback URL. The Square Point of Sale application does indeed open the callback URL in the default browser, resulting in a GET request rather than a POST request. This behavior can lead to issues with caching, as GET requests are more susceptible to being cached by browsers. Developers should be aware of this and design their callback handling accordingly, ensuring that any sensitive data or actions are not solely reliant on the GET request parameters.
This answer was reviewed by @Bryan-Square.
Classic AI: quote some technically accurate data scavenged from someplace, while being totally unhelpful. I miss good ole human tech support from the '90s where NI (Natural Intelligences) knew their stuff and could provide answers.
I suppose my real question at this point is: Is this Square’s final answer?
I do review every response before it posts. 
So, you are confirming that Square will not let a callback call back to an app of my choosing on my iPad?
If this is a web app you’ll need to have it be https. Otherwise you can configure it to go back to your app if it’s an actual iOS app.
Well… that removes a lot of the usefulness of the mobile-web API. I confess I was expecting to work like most other API calls, like a subroutine. I call it. It takes the money and returns the data to me, the caller. I suppose this works in a co-pilot scenario. But not a situation where there isn’t a person to walk the buyer through the purchase. Bummer.
The Point of Sale API was never designed to be an unattended checkout point. It was designed to be attended at all times. If you’d like to build an unattended experience we recommend using our Mobile Payments SDK.
Thanks. So close… ::sigh::