Q&A: Discover what’s new in the Mobile Payments SDK beta
Learn about how KIOS, a kiosk software, conducted early stage testing of the SDK and their integration experience.
Six years ago, we launched the Square Reader SDK. Since then, we’ve had hundreds of developers and partners integrate the SDK into their apps and we’ve enabled thousands of sellers across diverse business types to seamlessly process in-person payments with Square via these integrations.
Today, we’re thrilled to introduce the Square Mobile Payments SDK in beta, the successor to the Reader SDK. Similar to the Reader SDK, the Mobile Payments SDK will continue to enable processing in-person payments directly within your app using Square hardware, while also introducing new and exciting features built upon your feedback. New capabilities include orders integration, delayed capture, app fees, a Reader management API, accepting Square Gift Cards, and much more. The SDK is currently available only to developers serving sellers in the US, with future plans for international expansion.
KIOS, a Square partner building robust kiosk software for restaurants, was among the first to integrate and test the Mobile Payments SDK. We sat down with JJ Cheng, a co-founder of KIOS, to learn more about his team’s experience building with the SDK during its alpha phase, their favorite features, and what it was like working with the Square team to shape the product. Keep on reading to learn more about their integration journey.
Photo taken at South Block Georgetown
To start, tell us more about what you’re building at KIOS, your team, and how it all started.
We started this company on a mission to re-imagine what digital ordering looks like, and we saw an opportunity to innovate and simplify the complexity that restaurants face. We pulled together our backgrounds from building kiosks for giants like McDonald’s, and in mobile gaming, to develop a turnkey self-order kiosk, which acted as an agent of change for restaurants. This was especially prevalent because we launched it during COVID, a time when restaurants were seeking solutions to adapt to the sudden shift to digital.
Our team is still under 10 people, with most of them focused on product. We have close to 300 or more customers, but prefer to keep our teams small because we find that with larger teams, it’s easy to overlook a lot of small details that are essential. A smaller team helps us stay focused and provide the level of services our customers need.
Today, we work with some of the largest businesses out there, such as grocery and restaurant chains with over a hundred locations. Our kiosk solution helps them scale by remote controlling a lot of their services. Also, since our entire system is on the cloud and 100% serverless, it’s very elastic and allows us to handle businesses of this size who have massive catalogs.
How did you discover the Mobile Payments SDK? What motivated you to integrate with the product?
A member on our team actually had a lot of prior experience with the Reader SDK, the predecessor to the Mobile Payments SDK, many years back. We also saw that more of the Square Developer Platform was opening up and felt that this new SDK opened up a lot of features, accessibility, and ways that we could construct our own experiences. We felt that it was superior compared to other vendors out there, or other POS systems who do have an SDK, but usually offer a very limited subset of things you can do. With the Mobile Payments SDK, there was a concerted effort to bring it to market and make it an open-ended tool for innovation, and that’s what drew us towards it.
“We felt that it was superior compared to other vendors out there, or other POS systems who do have an SDK, but usually offer a very limited subset of things you can do. With the Mobile Payments SDK, there was a concerted effort to bring it to market and make it an open-ended tool for innovation.”
Are there any features of the Mobile Payments SDK that stood out the most to you?
Yes! The Orders integration and itemization, offline payments, Reader Management API, and app fees are all capabilities of the SDK that we’re currently using.
Orders Integration: We love how the SDK allows us to just plug into Square Order Manager and touch on every aspect throughout the ordering flow. We are now able to enable itemized receipts, which has been huge, as sellers need to see detailed items printed. What’s most interesting is that when we sell to a new restaurant, they don’t always understand the magic of how everything just plugs into their Square system. They’re always asking us if they need to get another KDS, printer, or other things, and we just say “no, you turn it on, make a payment, and the order will pop up on your system”. It’s that type of magic that gets people going “oh wow, this really just plugs in”.
Offline payments*: We’ve been working on integrating this feature as our seller base requested it. Offline payments will greatly enhance the durability and uptime of a restaurant by reducing the dependency on a long chain of system infrastructure. For example, a loss of WiFi or internet is no longer the “snake in the grass.” It becomes a “we can get to that later.”
Reader Management API: This capability has helped us tremendously because it raises visibility for both our team and sellers of what’s going on behind the Reader, allowing us to troubleshoot faster. The Reader services its current status every time something happens, so you know whether it’s connected or disconnected, when the last transaction was run, the battery life, and software version. We can now be really precise about what’s wrong and how to remedy the issue. Imagine you’re in San Francisco and something happens in New York. The first thing you want to do is fix the issue, not get on the phone or Google to figure out what it is. Now that you have visibility into what’s happening with the Reader, you can immediately see on your system that the device is unauthorized. You can then remote authorize the Reader or send someone to fix it. Without that visibility, you’re sort of running around blind.
App Fees: This capability provides us with monetization opportunities, but one of the most underrated things about it that most people don’t realize is how Square also gives you the funds at the end of the day. For some businesses, this can actually be very important because it allows them to operate as a cash business as opposed to an accrual business, providing tax benefits.
“Offline payments will greatly enhance the durability and uptime of a restaurant by reducing the dependency on a long chain of system infrastructure.”
What was your experience integrating with the Mobile Payments SDK? How did you find the documentation, resources, and working with the Square team?
It’s very well documented and the integration wasn’t that difficult. It was an alpha product when we first adopted it, so we saw the documentation grow from when it was just two pages long. It’s improved a lot and it was great getting to work behind the scenes with Mathew, the product manager. The migration to Discord also helped a lot. The ability for us to quickly send a message to ask for help is better than filing a ticket and not really knowing where it goes.
We started developing with the SDK on native but are moving increasingly to cross-platform, specifically React Native. Overall, there’s been a ton of enhancements, a lot of stability, and we believe it will continue to get better as the SDK becomes public and more resources get put behind it.
As the Mobile Payments SDK transitions to a beta release, do you have any advice to share for developers and businesses interested in integrating with the product?
My golden advice is that you should read the documentation, but also reach out to the channels provided by Square and ask questions at the same time. It may be daunting at first to figure out what’s going on because there’s a lot of different moving parts, but from what I see, a lot of people are willing to help each other out. At the end of the day, no matter whether it’s another developer answering that question, or the Developer Support team on Discord, you’re going to get an answer. It’s going to be like any other integration where you’re going to have to learn how it works. But when it works, it works really well. You just gotta put your foot in there.
“It’s very well documented and the integration wasn’t that difficult … Overall, there’s been a ton of enhancements, a lot of stability, and we believe it will continue to get better.”
KIOS has been a Square Partner for a while now, and to close off this Q&A, we’d love it if you could share some insights into how you were able to attract sellers to your app. Did you leverage any Square resources?
We acquire through a lot of different channels and it depends on who they are. We rely a lot on word-of-mouth, the Square App Marketplace where we get a lot of traffic coming from small to medium businesses, and also work a lot with the relationship managers on the Square Sales and Success teams. The latter helps us connect with the businesses who are a bit more sophisticated and have more stringent and technical needs.
We’d like to extend a big thank you to JJ Cheng from KIOS for taking the time to speak with us about his experience building with the Mobile Payments SDK and working with the Square team!
Get Started
Mobile Payments SDK is currently available in beta to all developers serving sellers in the US, and can be accessed publicly in sandbox and production. To start building and learn about all the new capabilities, check out our developer documentation, iOS technical reference, Android technical reference, and payments pricing.
Already integrated with the Reader SDK?
We recommend migrating to the Mobile Payments SDK as soon as possible. Check out this migration guide for instructions.
As we move towards general availability, you can expect more exciting features for the SDK to be released soon and we encourage developers to share their feedback on our community Discord channel or Square Developer Forums. If you want to keep up to date with the rest of our content, be sure to follow this blog and our X account.
*Offline payments are processed automatically when you reconnect your device to the internet and will be declined if you do not reconnect to the internet within 24 hours of taking your first offline payment. By enabling offline payments, you are responsible for any expired, declined, or disputed payments accepted while offline. Square is unable to provide customer contact information for payments declined while offline. Offline payments are not supported on older versions of Square Reader for contactless and chip (1st generation - v1 and v2). Click here for help identifying your contactless reader. Learn more about how to enable and use offline payments here.
Authored By
