Scaling Entertainment Centers and Transforming Guest Experiences

Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moody, head of developer relations here at Square. And today I'm joined by Eric and Alex from Headpinz. Eric, tell us a little bit about Headpinz and what it is that you do there.

Eric Osborn: Sure. Absolutely. We're a chain of entertainment centers in Southwest Florida. We have everything from bowling to laser tied, the game zones, multiple restaurants, bars, and, soon to be adding an indoor racetrack. The chief information officer for head beans. And then I'm also joined by Alex here, one of our lead developers.

Alex Trepasso: I'm Alex. Piggybacking off Eric there with all those different entertainment options and attractions we offer. I pretty much take over integrating them and making our whole ecosystem kind of work as one when we're dealing with all these different systems, you know, from scheduling all the way down to buying a burger, basically integrating those and overseeing the IT operations side of it.

Richard Moot: Awesome. And so I don't know if this is quite mentioned, but like how many locations are you guys in the Florida region?

Eric Osborn: Right now we're operating two. Well, actually three, two in which our Headpinz, we're actually making a transition from a traditional type bowling centers to more of, a hybrid type environment where we have those leagues on Monday through Friday that people are used to, you know, seeing for the traditional bowlers. But then on late night, Friday night, Saturday, Sunday, we're very much an open bowling venue, open up for families and all that good fun with laser tag and such.

Richard Moot: Very cool. And so part of the reason that we're, we're talking today is you have built an integration with Square and it's it's quite interesting, but I'd love to hear the story about, you know, where you using something before. What made you go into using Square. Like tell me a little bit about like, you know what drove you into, you know, using Square through your locations.

Eric Osborn: Yeah. So a little bit of a back story. We're actually use Square before our current POS provider decided to do a partnership with Square. We originally started using it for to-go orders during the Covid era when the bowling centers were shut down and we needed to find a way to get our that working.

So we were online, and they were doing to-go orders and meeting them right at the door and delivering that food that has since grown into where we've actually made Square our base, then our truth of everything. And that's been a multi-year project. But everything that we do now, including the front end point of sale, our kiosk, our web reservation, anything that is touching financials are now funneling through the Square ecosystem.

So a big change over the past three years. And, and that matter of fact, just over the past couple of weeks, as we've finally moved our final processes over to the Square ecosystem. So that's been great. Then where, Alex comes into play and, and, and where the development actually came from was there was some third parties that just simply did not work with Square, such as one of our kiosks, and a couple other small little things like our group function where they actually sign a contract and actually take a deposit.

Those things weren't working with Square Alex along and, and worked with, the Square ecosystem on a solution to that. He can speak a little bit about how our kiosks work and such, even though they're not a native, you know, Square partnership that we got to work in on our own.

Richard Moot: Yeah, I'd love to like the I mean, that's one of the things that really piqued my interest is you know, you have, well, I don't want to steal thunder here at like, the front of the venue. You have these, like, sort of kiosks where, like, it allows somebody to be able to purchase, you know, various other things, like, other than bowling.

And you built this all yourself, essentially. Like, tell me a little bit about, like, the integration that you built with these kiosks and how that all works.

Alex Trepasso: Yeah. So it started from a position of when we first got the kiosks, one of their native integrations was another payment provider. And kind of where we came in was, okay, we have these two different systems. You have Square on one side and this other provider on another, both doing, you know, different transaction fee rates, different handling, different view of transactions.

And it came up one day in our operations and kind of just our discussions of can we unify these systems. And that led kind of down the rabbit hole of the Square terminal API was kind of our first dive into everything Square developer. And it came along, okay, we know that Square offers this, that we can use this for payments even without sending, you know, a forward or, or doing a whole POS based Square install.

Let's try some things from there. We used the terminal API to start listening for those transaction requests that our kiosks were sending to host those on a cloud provider, and it listens for those requests when it sees one, creates a payment request to the terminal and treats it just like any other would for the kiosk. The transaction is completely seamless and paid and just Square it, seeing the payment come through, you know, just as any other transaction, which started kind of our path of Square being our source of truth and opening up the doors of this could be our full ecosystem, even if it's not natively provided by Square, natively provided by our other vendors.

Richard Moot: Yeah. And so for the, the kiosk itself, I'm wanting to sort of refresh and also highlight for those, those listening and you know, you primarily do these like a bullion venue and then you have like other things like arcade food and beverage, you're going to be having like the, the go carts. And what all does the kiosk cover in terms of like the guest experience.

Eric Osborn: So on your kiosks are we basically covers everything from bowling. We actually have two different types of kiosks, one that is covering bowling and then one that covers all of our other attractions. Those are the ones that you see when you first walk into the facility. From there, you'll actually be able to schedule laser tag ax throwing. You'll be able to buy a Game Zone card, which is, you know, a card like POS system on the game, as well as schedule racing at our other facility.

That'll be just across the parking lot that is currently being built. So it's really a one stop shop. Bowling is not handled there because a lot of that does come in through our web payment system. You're booking online ahead of time. These are kind of like those extra attractions when you walk in the door and you're still waiting for your lane or you know you want to find something to do in the interim while you wait for your food.

That's kind of what these kiosks address.

Richard Moot: I see. And so one of the things you sort of touched on is like, you know, using Square as a source of truth, what kind of like, drove the desire for having that? I mean, and I only ask because, like, you know, I've talked with other people, they might, you know, say they have an ERP system or like, you know, their own bespoke solution.

And you know, what kind of started like getting you into the mindset of, of driving towards using Square as your source of truth for, you know, customer data, order data, that kind of stuff.

Eric Osborn: Yeah. So we had a plan to, you know, keep moving in the direction of Square wherever possible. However, some things along the way kind of just started to kind of pick up and get aboard the, you know, the path and the ecosystem as we were seeing. It's just easier to funnel the data through Square. That gives us a centralized system to look up all those transactions.

It's a centralized system to get all of our financial data over to our online provider. For finances was important to us. And then along the way, we discovered that we were writing all these different tools to make this happen. And we didn't need it. As long as we got the transaction into Square, it was going to do the rest for us.

So it really has become that seamless experience. We've taken it a step further and Alex can, you know, mention a couple things about this, but we're even going as far as the Square Catalog is now, that centralized source of truth as well, because it didn't make sense to have to do, you know, before Square came along, I had to put in place keys into three different centers, three different POS centers, or three different POS systems.

At each of those centers. And then get it all thinking back together. Whereabouts now, even those third party providers such as, you know, things that do our group function reservations are looking at the Square catalog. Our front desk bowling operation is looking at the Square catalog. So now we have one set of price keys, one set of financials.

And you just have that seamless flow into our financial system. And if Alex you want to touch on the thinking because that is something that he custom built as well. For one of the providers to make that happen.

Richard Moot: Yeah, I'd love to hear about that because, you know, it's like how often I end up hearing about people trying to sync things between, you know, various different systems. I'd love to learn how you sort of approached it here.

Eric Osborn: It's so hard to do it by hand. Though, I'm glad this worked out.

Alex Trepasso: Yeah. So it started as kind of a part of our discussion of we're a very report heavy company, and we really like to know what people are doing in our centers. We like being able to have an idea of what's going on. So it started with, okay, our reports at this point were just showing, you know, here's a customer amount transaction coming from a kiosk or this kind of uncategorized revenue that we we knew was coming in certain ways, but we didn't know what people were actually buying.

So we started down that path and it came upon a point of, okay, we're managing three different centers of systems here. We're managing three different locations of different products. What can we do to centralize? This started with our group functions, especially because they were a really good example of, you know, you have hundreds of different price keys that each center might use, different pricing and all that.

And we began down the path of creating a system to actually synchronize the Square catalog to our group function booking system that my, my thinking there kind of started with. Okay, so Square organizes items by category and it can have these different prices, different availability locations. Whereas our group function system really only has like, you know, one category layer kind of it has the ability to do this price keys, but not as in-depth as Square allows.

So we started with the idea of every location that's available. We're actually going to treat it as an independent price key on the vendor side. Whereas the Square it's one we're actually going to create three prices. So if we create a group function price for, you know, an hour of bowling on the Square side, we're seeing, you know, that uniform price, the price over it, any overrides for the location where it's available.

And then I'm turning around and taking that information, including the category, and it's kind of the setup of it and creating three separate keys off of that and saying, hey, all three of these are related back to this one in Square. But that vendor system doesn't need to know that that synchronization handles all of that actual communication. So if we update the price for one location, it will only update that singular version on the vendor side.

But if we want to update all three at once in Square, that would just be one little change. And then the system would synchronize those changes over to the outside system. The biggest hurdle that we kind of ran into, is Square keeps everything very clean. And its catalog, it is very kind of intuitive. A lot of these outside systems have these layers of complexity that we didn't feel for.

At least our setup needs to exist. And Eric could explain more on that of just, you know, we don't need to go through five pages to find one price key where Square has it right ready to go. And we can set up kind of how intuitively a customer or a staff member would actually want to look at that.

Eric Osborn: And that now reminds me, Richard, the thumb before let us into a whole nother web of what we could do marketing wise as we were. You know, we originally only just using Square for food and beverage, but then as it grew into our other systems that grew into bowling and laser tag and the game zone, all of a sudden our marketing capabilities, the doors opened wide open.

We can now see that, you know, when a guest walks in the door, are they simply coming in for bowling or they coming in for bowling and and buying a couple drinks and buying food by and laser tag. We can see what portions of the building that they're actually utilizing and do more direct in particular marketing to them, like, hey, why didn't you come, you know, participate in Act growing, you know, with us who did laser tag but not actually showing.

Maybe here's a coupon for you to come back and give that an experience the next time. And it was really a, it wasn't something I was expecting at first, but once it all started flowing together, those transactions started coming from multiple different areas. That's when we really started seeing the power and what we could do with those different types of marketing campaigns.

Richard Moot: Yeah. I'm so glad that you mention that, because that's one of the things that, I mean, there's a period where it felt weird to like, sort of promote this to folks because, you know, it's like it sounds like, oh, man, this is like, you know, high level, amount of tracking, but it is like, really like, you know, I'm I'm gonna throw out some assumptions here.

Please feel free to correct me if I'm off-base on how this is working. But, you know, you can see a particular credit card come in and say you have no idea who this person is when they first set foot in the door. They may or may not have a reservation for bowling, but they go up, they go to the kiosks and they're like, oh, I'm going to go get some game zone cards for my kids.

And, you know, like send them on their way to go, like play in the arcade. And then I'm going to go buy some food. And you're seeing this credit card making each one of these purchases. So you're already creating a profile of this particular customer. And then when they go to say maybe they paid for the bowling online and you might already have like, you know, have this profile.

As soon as they do that first transaction, you're like, okay, we know we now know this person's here. You actually know how far ahead of their appointment they're there because they're immediately starting to do these purchases and like leading up to maybe their reservation time. And it's just like one of those things where like when you have this integrated throughout your entire system, you realize, like, you can see so much more about customer behavior.

And it just sounds like so much more interesting in a place where, like, there's like all of these different opportunities for like, you know, the go carts, the arcade, the food, the, the actual bowling itself that you can like really sort of see core to like the main things that certain cohorts tend to gravitate towards and like, I know that we, we, you know, like a pre call, we talked a little bit about like how you can like build different marketing campaigns of like, hey, how do we encourage a little bit more of like go cart usage.

Maybe we could send you something a few hours or a day or two before somebody like reservation to be like, hey, here's a promo for doing this while you're already at the venue. So it's just really powerful.

Eric Osborn: Yeah. Especially with the we do a lot of that through the smart groupings now leveraging that data. And when they were, they're left in particularly what category of stuff did they actually purchase. So you know, just to give an example, the stuff that we launched yesterday was just a basic survey to guess that were bowling and VIP because we want to know, hey, did you get your complimentary chips and salsa, did a manager check on you?

And we're already seeing within a 24 hour period, that we just launched it last night, dozens of these surveys coming back of people wanting to give us the feedback, and we're just simply sending them a Square gift card in return. So we're gathering data. That's a very powerful to the business and how it operates, and where we can fill in gaps of where we could potentially make more revenue producing opportunities.

And we're starting to feel it taking some time to leverage all that data. But it's working for us. And one of the things that actually encouraging them to give us more of that data is like our rewards program and thoughts. So you mentioned you're following the credit card, but most of our customers there's a good 20% or something now, which is really good for rewards program.

They're electing to give us more information. So we're getting their name, their email, their phone number and their birthdate, and they're staying in a part of our text programs. But because they want to get the rewards to come back and do laser tag, or if they've never done act throwing, come and do that. So we're leveraging multiple different things that are starting to come full circle.

And I don't think we realized that as a company a couple of years ago, I think you can even ask, you know, any one of our management teams, you know, what was the goal here and what did what did you envision this coming about? And I don't think they understood the full scope or the full circle, but we're there and we're now seeing the result of it, which is awesome to see.

Richard Moot: Yeah. I'm curious like to, trying to like, think of how exactly to phrase this, but like, you know, it started out with something fairly simple, like, you know, the curbside pickup, you know, during during a time where, like, you know, this is the this is the way to keep the doors open, keep some people employed is doing this like curbside pickup thing.

And then it kind of grew from there. I'm sort of curious about that evolution as you started to sort of plug Square into various other places, like how is that sort of mixture between stuff that you just sort of like had off the shelf stuff that you've extended on Square? Like, I guess I'm trying to like sort of understand, like, you know, how much like stitching together of things has gone off over time or is it like, really just like, oh, we just found like something within Square that we can actually replace something else that we were using and then just do like smaller extensions, like, I mean,

Yeah. How does that sort of grow over time in terms of trying to get Square working with any of these other tools?

Eric Osborn: It is I think it was, you know, we started with the simple stuff. Obviously, off the shelf, the food and beverage was the easiest to to get up and running because that replaced our, our, existing cards. Any kitchen printers, any more printers we had. That was a very off the shelf move for us. So right off the bat, we were able to move, you know, about 15 to 20 terminals per location over to the new system.

And our staff caught on to it quickly. It was just an easy flow. And then as that evolution started coming back around, we just realized that any time that we got that data into Square, it was making all the back end stuff so much more easier. So we talked about marketing. We talked about the web financials and all that whereabouts we were piece mailing it all together.

So if we needed up and from our front desk or we needed something from our our kiosks, we were writing custom dev to in order to do that, we threw out almost all of that and went to basically writing Square orders, and it simplified the whole process of not having to have our own categories, not having to have our own financial mappings.

So everything we're doing as of, you know, and we might have probably just made the decision at 2025, but we're going back and looking at why isn't that in Square. So if it is currently outside of Square like can we get it in there? And if so, how can we do that? And that's where Alex comes along. And utilizing all those APIs and and the resources that are available to us, to see how we can accomplish that.

Honestly, the main stumbling blocks or something, most of the time that third party partners are POS is that you have to work with because you got to make sure that they at least have the open mechanisms to be able to grab the data that you need and push it to Square. If that's not there, you know, it's totally out of the question. But, thankfully we've had really good partnerships with, with all of our plus companies and we're able to accomplish that.

Richard Moot: Yeah. That's great. I mean, like, it's one of those things where like, it feels weird to, like, start having the suggestion as a software engineer to other folks when you when you're basically sort of looking at the entire landscape of your business and saying like, okay, like in order for us to answer, say this particular question, it requires me to pull data from like 3 or 4 different places and like they're all in different types of formats.

And then I'm having to sort of do some data munging to like, kind of like, well, these are done in like the wrong time period. So I have to adjust it in order to work in the same time period as this other data set. And like once you actually homogenize everything into like a singular system, you're, you're writing less like throwaway code is like kind of like what I think of it because like, these one time reports are like maybe quarterly or biannual that you're just like, oh, well, we really need to answer this particular question because it's going to let us know, like, can we run this marketing campaign and expect it to be successful?

Eric Osborn: Yeah, I mean, there's dozens of one off code that we've been throwing out over the past couple of weeks just by pushing the data into Square. You know, I keep, you know, running into more and more of things that we're moving over. I said, we just moved to surveys and stuff over. We just moved to another POV.

But not even a week ago, while I was IPO, Alex moved to a game zone system over to Square as well. So yeah, we mentioned those games on cards that you're buying at the front on the kiosks. We're actually now grabbing the data from the video games, and every 15 minutes uploading those transactions to Square as well.

So we know how much video game play versus virtual reality versus laser tag. All that's now being funneled in. And that was a, I think for Alec that was, maybe a two day project. And we have another POS system that was linked in the Square. It's just it's been that easy for us.

Richard Moot: One thing I do want to kind of circle back to just, because I'm, I'm interested on a, on a technical level with the kiosk that you're using. If I recall, this is, like a kiosk system that you got through a vendor, but, the device itself, it's running on, like a windows OS as its base, which is kind of like part of the motivation for using terminal API versus like, say, our mobile payments SDK.

Yeah, yeah. Tell us a little bit about building the integration with terminal API and this device. Because from what I've understood, like, you know, thankfully the device that you have is like, you know, fairly open in terms of being able to plug and play certain things with it. But I'd love to just, you know, tell us a little bit about, like, the app that you built and how that sort of works and communicate with this kiosk.

Alex Trepasso: Yeah. So I'll, I'll kind of start from where when we first started designing it, where I jumped off from was, I know we had provided by the kiosk different payment methods that I could do. There's, you know, ones that are hosted on site. There were cloud providers. They had, none of which were Square at that time.

So we found a provider that they had set up that actually was using a Soap protocol to send out its transactions to what it assumed was a local server. And that transaction information was just a little here's the bill ID, here's the amount to charge, you know, charge it and move on. What we ventured from there was kind of, almost pentesting that of, okay, can I intercept this and act as that receiving server?

From there, it jumped to, okay, so now I got the request. I can take it in, I can serialize that. I know what my amount is. I know my bill information. I know what response it's wanting or expecting. That little piece in the middle that we've named, Mercury. Just because I used record naming for a lot of our software just for the fun of it, basically acts as just a messenger in between.

So it takes that so request translates what the charge should be, what any of the bill information sends that to the terminal API to create a transaction. And then basically sits and waits for the terminal to reply or that transaction update and say, hey, I'm complete or I'm canceled. From there, I translate that back into what the kiosk is expecting as a payment response that just says, hey, was it a denied?

Was it rejected? Approved? What's the status? I tell the kiosk, yep, we're good. We took the payment and it moves on just like it would request a normal vendor or the normal system that it thinks it's talking to. Basically just that messenger in between. So there's no creating of orders or trying to mess with the bill in any way.

It's just going, hey, here's my amount. Translate this into something that terminal API can understand, and then translate the terminal API response back to something that the kiosk can understand, and that that became the philosophy for a lot of the software was instead of trying to reinvent the wheel or make these throwaway reports or that throwaway code you were mentioning, we go, okay, what if we turn these into basically data pipelines and let Square continue to do what it's really good at with the reporting and the transaction handling and just get the data to Square, let Square do the actual work.

We just act as kind of this in-between data integrator of saying, see, here's the data Square can do whatever it needs or whatever it wants to do with those numbers for marketing, loyalty rewards, business tracking, anything like.

Eric Osborn: That, unless you're currently working on it. Good to mention that this integration was done well over a year ago, before we thought that, you know, Square was going to be that total ecosystem and where we were going to funnel all of our data. So it basically started as a custom amount integration on those kiosks. And Alex can speak a little bit about what we're doing now.

He's working on the full itemized integration for that kiosk as well. Now that we see the benefits of what we need to do there.

Alex Trepasso: Yeah. With the, I'd almost compare it to a snowball if we started very small in control and we started with this one off kiosk integration. And then as we integrated more systems and more features of the different systems, I realized and through discussion with Erik, realized we're doing a lot of the same actions over and over again.

So instead of designing, you know, five apps that communicate between the five different pieces, what if we do one that understands data and knows how to get it to Square? And instead of building everything from the ground up, every time we just build these essential sort of intakes of data. So we take the data from the POS, let this centralized system convert it to what Square wants and what Square's looking for, and open that door to when we have a new POS.

We're not trying to rebuild everything, we're just doing something that integrates. We got the data in this format. We already know Square wants this. Let's just take it and format it how we need, which is really spelled out development times. It's allowed us to, like Eric said, turn around an entire new POS onto the system in two days, rather than, you know, having to go all the way from floor zero or ground zero of where am I going to go with this?

Now we kind of have a set template of every time when we're moving forward. Yeah.

Richard Moot: Now that's very cool. I mean, like, you know, I had this, like, silly. I thought I might have this, like, this, like this Borg, like a simulator. That's just as you bring it in, like this new thing. It's just like going to go, I'm going to assimilate you to, like, funnel the data into Square and make this unified.

Eric Osborn: Yeah. And we would say no at this point if it couldn't funnel in the Square that but the amazing part about it, and the only reason those systems exist are because they're specialized systems, like a game zone or running a go kart or running bowling. So those are always going to exist in the entertainment world.

Richard Moot: I mean, like that part I still is, just like I feel is like very fascinating because, like, you know, I probably one of the few people in this world that, like, will ask random people who own a business, like, you know, what is it that you use to, like, operate various different components and like in an entertainment center like this?

I'm just surprised, like how many different types of systems that you need for managing different entertainment parts. Like, you know, I mean, most of the time we might just, like, take it for granted, like, oh, yeah, you know, they got cards for the arcade, you know? But there's got to be a whole system for, like, you get the card, you got to load the card, you got to track how much is on the card.

It has to communicate with each one of the game machines, which is then also going to communicate back to a server to say like, hey, does this person have credits or multi-location? Yeah, yeah. One thing I do want to touch on is even in like, you're, you're handling payments for the game. So cards you originally were had this approach where you were sort of like sending the revenue directly to your accounting software.

But then part of this, like migration you had like this, you know, win of going by having this go directly into Square and Square, then now sinks into your accounting integration. Yeah. And so that's kind of like sort of saving you even from having to deal with sending your stuff directly into the accounting software.

Eric Osborn: Yeah. We actually had some of those one off development things that were going on because a lot of them didn't have that native integration to the accounting platform that we were using. So Alex had these, these one off tools that would run in the middle of the night, basically exporting, you know, text or CSV files that could be ingested into the accounting software.

So we've eliminated all those little one off things. And as Alex was saying, it's kind of all using the same mechanism now for ingesting the data, throwing it into a Square transaction. No matter where it's going. So just overnight we, we eliminated all the actually within the past couple weeks, 3 to 6 different little one off, import export tools that are now just being ingested into, Square.

Richard Moot: And I mean, it's, it's like, I feel like you're just, like, telling my, my dream story to be telling about the ecosystem because, you know, we we love to talk about the, the ecosystem that we provide here. I think sometimes it's even hard to, like, really understand, like what the ecosystem of products really is. And I think you have like, just like the right mindset to, to be able to see like, oh, like, you know, it's working in this particular area and like, you know, it kind of could work for this other thing.

Let's try it over there. And like you know, you solve the small problem first and then you kind of realize like, okay, well, now that we solve the small problem, we realize we can kind of have it solve more than just that. And you keep growing it and all these different areas and eventually it's just like you're now at this point where, like, if it doesn't work with Square, we're not really that interested.

Eric Osborn: We're not going to use that. Yeah. Yeah, it's kind of amazing now that, y'all, I find myself scrolling through the dashboard or transactions. What funneling through there is pretty incredible. Now that we can link all these transactions together. And our staff and our managers, our team, they all know that, you know, anything that they need to manage now, as far as refunding or voiding or crediting a customer, they go right to a Square tablet.

It doesn't matter where they bought it in the building, whether it's a kiosk, a game or online or bowling, it doesn't matter. They pick up a Square tablet and you now have every single one of those transactions. Right there would be for us to go into three, 4 or 5 different pieces of software just to figure out where to refund it.

And at one point we were going into multiple credit card processors to figure out, you know, what went wrong or what needed to be refunded. So I find myself scrolling through the dashboard every once a while ago, and while this was actually really starting to come together for us.

Richard Moot: So I think the final thing I do want to touch on because, just to geek out on, is you built, the integration for the kiosk system. So you're running that, I'm assuming somewhere locally, or is that actually like a cloud solution? It's like connects with the kiosk software that you're sort of having, like, I guess I'm more curious.

Like, what did you build it with? You have like a little server that's probably like sitting there listening, waiting for, you know, something to come through. Tell me a little about your tech stack is really what I'm getting.

Alex Trepasso: Yeah. So the first point I kind of went with was knowing that it is a payment provider. It needs to be incredibly reliable because you don't want a customer having a failed transaction, as typically, at least with me, within FCX, a failed transaction or a pain point will push a customer to no longer use it. It's kind of an all or nothing of if it's difficult, they just simply won't go through that flow anymore, regardless of what the end result would be for them.

We then, using our cloud provider, found out we can integrate it directly into our network essentially. So while it's a cloud hosted server and they handle, you know, the uptime and making sure it's online, making sure it's reachable, making sure it's, you know, healthy as an app, it's integrated directly into our network. So that kiosk is sending out a request to what it thinks is a local server running in the building, that goes through our networking system and then gets to our cloud provider.

It processes that request and sends it back, without really any points in the middle that neither system thinks it's in the cloud. Essentially, they both think they're working locally and they both have direct access to these resources without any kind of pain points there.

Eric Osborn: It's funny that Richard mentions the, you know, the computer sitting in the office or the computer, the server sitting in the server room, because that is where a lot of this stuff started. When I first started and where Alec first started, there were a lot of these one off little servers, you know, sitting around. But, like he's saying, it's going through an SD-Wan solution at this point to the cloud provider.

So it's just there and there's multiple redundancies in place for that, to make sure that continues to happen in any way, shape or form, you know, for losing a number, we might switch over to broadband and then broadband. Unfortunately, we don't have great 5G connections, but we could switch to a 5G connection if we absolutely need it to.

Alex Trepasso: And I think, on the tech stack, a little bit of that app that provides some of that is we knew going in, we didn't have, you know, time to reinvent the wheel. We needed something that we could kind of develop quickly on, iterate quickly on, you know, if something needs change, change it, you know, on those one off scenarios.

So, that was kind of our first dive into Node.js and using TypeScript, Node.js and essentially an express server that's processing those requests and allowing us to kind of quickly get things working. And I got to give some of that credit to you guys over at Square for that your API is very developer friendly. Probably one of the most developer friendly we've worked with in our different vendors and with its multiple different kinds of integrations, both with its direct SDK for Node.js and its direct different integrations with these different platforms and tech stacks.

We're able to, you know, take something that normally would take a week because we're designing everything for it and quickly iterate and go, you know, overnight turnaround and have a solution to integrate these different technologies. And that's been carried forward into pretty much every software of the Square API has been very developer friendly and very open to working with different data formats that we've been able to quickly spit out these integrations and get things up and running without, you know, huge turnaround times.

Eric Osborn: I mean, that chaos integration. And looking back at almost all the integrations, it was a 1 or 2 days of dev, and we're writing the testing and, the chaos integration was one of the most flawless ones. The testing from day one, there wasn't one failed transaction. And then going into a weekend that has, you know, a thousand transactions in a week and then not having one failed was pretty amazing.

And that gave me the confidence and the entire team, the confidence to continue moving forward with this.

Richard Moot: I love to hear it. I mean, like, it's it's one of the things that I, I've heard time and time again. I feel silly because it feels like I'm just singing our own praises here. But, the ability to just, like, sign up for a developer account, get credentials, and immediately start building and testing. I can't tell you how many times, like, somebody, you know, started out with an idea where, like, they were at, like a baseball game or like the coffee shop and they see the payment system there and there's like, wait, what is this?

Can I and then they go look up the docs and within a week they have a proof of concept up and running and they're like, hey, I already like having a terminal device taking a payment. And, you know, they're shopping around within their company to be like, hey, we can use this. Like, this can actually solve the problem.

And of course, like, you know, eventually have to build out to scale. So, you know, you go through the process of getting Docker-ized apps in your cloud provider and getting, like everything strung up. But like, you know, you have that moment initially where you're just like, no, like, this can work. Like I've, I've always believed in that.

Like for developers, like you can convince them, like in that moment, this can work. It's working for you right now. Like, yeah, you got to build out the scale and the reliability. But it's going to solve the problem that you want.

Eric Osborn: Yeah, it's even more exciting when it's, when there's a known pain point in our operation that we can bridge. And a lot of times, you know, the staff, customers or management won't even realize the bridge is there. Making that a simple process. Where about if you go to, you know, a lot of the, the one off folks that are single train operators and that they might not have, you know, had somebody to be able to take that leap for them.

So they are still doing it all that multi transaction and the multi POS, it's really a seamless process at this point.

Richard Moot: Yeah I mean you know going going back to like what you touched on earlier of that still surprises me to this day of like you know a lot of businesses in or like other software providers or hardware providers for that matter, you know, have this expectation that you might have this like literal server setting in like a back office somewhere that's going to be connected to your network.

That's like, no, it's I'm going to try and find this thing. I mean, like, that's the whole reason that you're able to build this, this integration with the kiosk solution because, yeah, a lot of businesses have that. I've talked to that. Clinics, law firms, some of them have to for regulatory reasons like, you know, their system data has to be in this very controlled format.

But it makes these integrations like a lot more difficult when, you know, you have to then go talk to a vendor, get special documentation and like try to figure out like, how does this system actually work and how can we make it like work versus like, hey, here's like an open system where you can just immediately go in and build and test.

Eric Osborn: And that way a lot of our decisions at this point is looking for that open API. And what can we leverage and what can we do with it, rather than focusing on the front end, you know, the gooey and what that's actually happening is if we do need to do the one offs, or we do need to bring it over to Square, is that available for us to do so? And that's important at this point.

Richard Moot: I mean, it makes a lot of sense, you know, for something like, you know, an FCC like, you know, it's a very you want to have it how you build your business. Because what you build is very unique. You know, it's you know, it's your particular mixture of like having the go carts, having the arcade, having the bowling.

Like, you know, you're going to be able to, you know, find a solution and build something that works for you guys instead of just trying to like, you know, take stuff that's off the shelf and, you know, hobble it together.

Eric Osborn: Yeah. And our team hasn't seen it yet. But, you know, we're trying to focus a lot on selling packages and bringing the different attractions together so that when you're just coming in for laser tag, you're just coming in for bowling. It might be a little bit more enticing if you're, you know, getting 50% off on your next attraction by bundling it together or, you know, as I mentioned before, we'll fast Tracks will be our go kart place across the street or across the parking lot, essentially.

So you're going to walk in the Headpinz, you're going to be buying bowling, but you're going to be able to add racing to that all through one ecosystem. So you're going to be in one location while booking at location B, and that's all made possible by pulling these pieces together.

Richard Moot: Yeah. I mean it's like software. Is it like literally enabling the cross-sell?

Eric Osborn: Yep. Exactly.

Alex Trepasso: To jump in on that. I think a big part of that, at least for us, was a lot of these other vendors, you know, there's vendors like that do our games that have been in this business for 25 plus years. They know what they're doing. They've mastered their little niche. And while it may not be something that Square provides or would go down the path of writing, we can make that work because Square is very open to understanding.

Yeah, there are going to be things that, you know, especially in an FCC type environment or these large business environments. You have these multi different essential ways that a product gets old. You know, you have bowling. That's my lane. You have go carts. That would be by the time slot. The arcade is just money on a card that are all very different.

And how the user experience is in the business view is that just wouldn't exist together, that we can make work together. So for a customer, you know, they're checking out in one place and having that singular transaction rather than having to go through five different transactions to achieve the same result.

Eric Osborn: And it makes me think on the In the Square catalog side, like, one of our providers for bowling, they simply just added a custom attribute that decides is that price key for bowling shoes, price fun, whatever that may be. League bowling with just a simple dropdown that decides where it goes into that front desk. For bowling wise.

So it is really that simple when it comes down to adding those keys and utilizing them.

Richard Moot: Yeah, I really want to reiterate like what you said there that is very important to like sort of highlight for other folks or just like the different ways that you sell things. I have come through this time and time again, like just dealing with a catalog is, you know, different types of businesses have different products that they're selling.

But like, you know, bowling is by the hour, but like the shoes are like Purge Day and then like, you know, you're going to have all of these various, like, different things that like a very bespoke way of selling this particular product. And so having a flexible system that allows you to like, unify that and can meet your needs as you have different things you want to add or offer, and there's a programmatic way to do it.

I do want to thank you both, Eric and Alex for joining me here in the podcast. It's been very enlightening hearing how you have such a tech forward family entertainment center business. I would recommend anybody if you're in the Florida, Southwest Florida region. Definitely go check out Headpinz. You can find us at Square Dev on X. Or you can reach out to us on our discord. And if you have a project that you're working on, make sure to let us know about it. And don't forget to subscribe and check out developer Dot Square up.com for more. Keep building and catch you next time.