x

Major Suggestions for Overhaul of Square POS Web API

Hello. Allow me to walk you through a transaction using my custom point of sale software with Square, so I may suggest how the Square POS API  can be made better. I will justify my suggestions as best I can using technical terminology, as I am a Web Development and Design student at Full Sail University on course to get my BS next year.

 

Starting the Sale

I enter a SK/UPC, and the item is added to the transaction. I modify the item price to $1 for testing purposes.

 

 

 

20170829_181752.png

Confirming Payment

I confirm payment in a separate tab. The on-screen button is an HTML anchor tag with the href attribute set to the Android intent URL needed to make the Square API call.

 

 

20170829_181842.png

 

Business as usual in the Square app. Slid my card and the sale is complete.

 

 

Screenshot_20170829-181432.png

 

 

Let me explain my problem(s) with this the best way I can.

 

1. Callback URL destroys whatever tab you initiated the API call from

Confirming payment and making the API call should not have to be done in a separate tab. I do it in a separate tab because once you complete or cancel a transaction after clicking the Square intent URL, the entire parent window gets redirected to the callback URL you specify in the developer dashboard. I suppose this is nice in certain instances, but hogging an entire tab to get the callback info is unnecessary. 

 

Let me give you a scenario where this would hurt a business instead of help it. I have a customer who is buying multiple items. I ring up their total, then I hit the "Total" button. If that button initiated the API call, I'd jump from my app to Square to accept payment. Cool, but I actually forgot to ring up an item. I go to cancel the payment in Square, and all of a sudden I lose the browser tab I just had with their transaction. "Sorry sir, but I forgot to ring up one of your items. I have to re-start the whole order from the beginning." Do you see how useless the API would be in a situation like this? I could lose more money than I'd be making. I could program my POS software to "save" the transaction once the "Total" button is hit, but I feel like that's a lot of extra work I shouldn't have to be doing, not to mention it would be nice to not have to open a new tab at all considering I would like to make this software full-screen. Opening a new tab kicks my software out of full screen.

 

Here's what I've tried to solve this issue, along with the results:

  • Opening intent URL in a new tab using target="_blank" - Still kills the tab I was working in
  • Opening intent URL in an iframe using target="iframeName" - Does nothing
  • Opening a new tab using window.open("aBlankPage.html") and using window.location.href = squareIntentURLDoes nothing
  • Opening a page I built called payment.php that uses PHP to get the total and Android intent URL from the address bar. From there I use the URL and create a hyperlinked button that initiates the API call in that tab, so my work in the other tab isn't lost. This is not optimal at all, as earlier I said I would like to have a full-screen experience.

Proposed solution: allow API calls and callback data to be done through an HTML iframe.

 

2. Square app doesn't automatically initiate callback once sale is complete

 

This irks me. Why do I specifically have to hit "New Sale" to initiate the callback for a successful transaction? If I went into the Square app settings and said to skip the receipt, that means I want to speed up my checkout process. So why in the heck are you required to hit "New Sale" to initiate the callback for a successful transaction? Or what if I ever hired an employee that acciddentally (or purposely) closed the Square POS app before hitting that "New Sale" button? If that happened, the record for the transaction through my software would be lost in limbo, as without the success callback, I wouldn't be able to link the Square transaction to my software's transaction in my SQL database. This could prove to be a huge issue in loss prevention. If I can't track it, I don't know what happened with it. The employee could have marked down all the items to a penny for their buddy and I wouldn't know.

 

Proposed solution: just allow automatic callback initiation for a successful sale.

 

Here's my personal thoughts on these issues, and why they should be fixed immediately.

 

As someone who understands web design and development on an intimate level, I understand how important it is to make Square APIs play nice with web apps. In regards to the 2 issues I listed above, I feel very disadvantaged as a developer to have to try to work around these issues. APIs and frameworks are used to make programming easier, not more difficult. Not to mention, the easier you guys make it for one to create their own POS software, the more potential users you will have. By making the APIs perform to the best of their ability, you open Square to a large audience of fellow developers such as myself. Don't let this untapped revenue slide by. Even if fixing the issues I've listed above doesn't assist in driving developers using the API(s), you could make it easier for people like me to license custom POS software to companies, thereby still gaining more business. It's a win-win to fix the issues I've listed above.

 

Now, if I'm doing anything wrong, please feel free to let me know what settings I need to adjust or what code I need to write. But if the 2 things I listed above really are issues, they should be fixed promptly.

 

I would greatly appreciate any responses from the Square developer team as well as other developers of custom software solutions using Square. Thank you.

1,034 Views
Message 1 of 2
Report
1 REPLY 1
Alumni

Hey there @RYoder97

 

Thanks for posting this feedback here on the 👥 community. Big thanks for being so detailed, I'll definitely pass this to our Product Team. 

I also encourage you (if you haven't yet) to check out our developer community on Stack Overflow

998 Views
Message 2 of 2
Report