Breaking Down Door’s Payments: How DH Pace does Field Payments

The Square Developer podcast explores the intersection of technology and innovation in the world of payments and beyond. Your host and Square Head of Developer Relations, Richard Moot, sits down with a series of guests this season, walking you through the latest news, updates, and innovations in the Square developer ecosystem.

On today’s episode, we are joined by DH Pace Mobile Development Manager, Miles Rush. In today’s fast-evolving world of technology, businesses like DH Pace are leveraging innovative solutions to streamline operations and enhance their customers’ experiences. 

Guests

• Richard Moot, Square Head of Developer Relations
• Miles Rush, DH Pace Mobile Development Manager

About DH Pace

Full transcript

Richard Moot: Hello and welcome to the Square Developer Podcast. I’m your host, Richard Moot, and today, I’m joined by Miles from DH Pace. Thank you so much for being here. Miles, can you give us a quick little intro and tell us about yourself and DH Pace?

Miles Rush: Thank you, Richard. My name is Miles. I’ve been a software developer for over 20 years now, and I’ve been working at DH Pace almost that entire time, developing lots of different projects and mostly focused on the mobile space. So, for our field team doing field service and sales, DH Pace is a door company, so if it has a door, we work on it pretty much. So, your garage doors, the doors to the front of your building, and dock doors, if you walk through them, we touch it type stuff. And so we have a nationwide service and sales team, and my job is to help them be more efficient and get their work done.

Richard Moot: Awesome. And for those who aren’t familiar with, say, the size of DH Pace, how large are we talking? And I’m assuming it’s predominantly in the United States.

Miles Rush: Correct.

Richard Moot: But how many locations, what is the total reach of DH Pace?

Miles Rush: I think, last time I saw, we were around 50 locations nationwide. We have probably 3,500 employees, and about half of those are field employees.

Richard Moot: And so you have worked on building the integration with Square for DH Pace. Before we talk about that actual integration, I’d love to paint a picture of what it looks like when somebody is interacting with DH Pace. You mentioned the field service technicians. What is the typical life cycle of somebody who’s either buying a door or repairing a door? Tell me a little bit about that.

Miles Rush: Absolutely. So, one of probably our primary use cases is residential service. You have a garage door, and a spring breaks, or it just doesn’t open or something like that. And so you call us up, Hey, I need this fixed. So our office staff will create the order, dispatch it to our field tech, and they come to your house and start using their mobile device to record what they’re doing and see, oh, I need to, this is what’s broken, here are the parts I need to fix it. They’ll record those parts, record the time. And then, as far as customer interaction goes, once they’ve completed the work, we’ll have the customer sign off on what they did and then take payment right there in the field where they can use their credit card and take the payment, and then we’re out of your hair and moving along.

Richard Moot: It sounds like you have a custom-built system for actually handling this sort of interaction. I’ve had work done at my house before and mostly the other times somebody comes in, they do a quote, then they have to schedule somebody else to actually come out and then go and do all of the work. And then most of the time I get an invoice or I have to go write a check to them. But this kind of solves that. We have a payment device right here. It’s logging everything. We know exactly what was changed, what work was done. You can display this is how much you’re being charged and then pay it right then and there.

Miles Rush: Absolutely, yeah, so we have all of our pricing and everything sent down to the field on their phones and tablets that they use and they can invoice the customer right then and there and using the Square device makes it real easy for the customer to pay and for us to collect from them.

Richard Moot: Tell me a little bit about the devices that you’re using for doing this kind of payment integration or really for that interaction. You said that mobile devices, tablets, what do those actually look like?

Miles Rush: Yeah, so our field team primarily uses Samsung devices. We’re using Samsung phones and tablets for our field. Depending on whether they need a larger screen or not, we’ll use a tablet. And as far as for Square, we’re using the Square readers that connect via Bluetooth and they make it real easy to get those synced up and they’ll just pull it out of their tool bag when they need to take a payment.

Richard Moot: That makes it so easy. And previously you were integrated with a different payment provider, like you were using something before you actually started using Square. Tell me a little bit about what sort of things you were dealing with prior to that in terms of the technical issues and then some of the more logistical business issues.

Miles Rush: Absolutely. Before this, we were integrated with a provider that did not have any hardware. They only had a web API interface, and so we had to send all of our payment information through a web API to them. They would process the card and send it back. And while it worked, it wasn’t ideal. It put us into the space where we were PCI and had to take care of the PCI compliance because we were handling card information and then also was a poor customer experience. We were typing in their card number into our device and customers, a lot of our customers would get nervous seeing you type in their card into your phone, are you trying to steal my information or whatever?

Richard Moot: I know you have a stranger coming to your place and you just like they’re immediately typing in the card numbers. You’re just like, what is going on here?

Miles Rush: And so we wanted to get where it was, we could maintain our PCI compliance much more easily and have a better customer experience so they can just tap their card or swipe their card and we don’t have to handle the card numbers.

Richard Moot: Yeah, I mean it’s one of those things where I’ve talked to many developers over the years and PSI compliance, I get this mixture of feedback from folks. Some people are like, oh, it’s not that big of a deal. And for some people, it might not be. But I think at certain scales when you have to reach certain different levels of PCI compliance depending on how much you’re processing and the danger of the business, and it can be really onerous, running all of those audits and then having to run all these various checks so I can understand the desire to absolve yourself of we don’t want to deal with PCI compliance, we just want to sell doors. That’s what we want to be doing.

Miles Rush: And don’t forget the 50-page survey you have to fill out.

Richard Moot: Oh my gosh, I know I’ve thankfully not been the person having to fill that out, but I have had to review it and it’s lengthy and onerous. It might be 50 questions, but some of those questions might require quite a bit of research to go validate are we actually storing these things in this way? Do we know that these places are where we’re storing these things, like who has access? Do we have audit logs? Countless things that you’re trying to run through. And so you had tried out several vendors before switching from your previous integrator. Tell me a little bit about that exploration process.

Miles Rush: So we wanted to get a solution where we’re not responsible for PSI compliance. Our partner can take care of that for us. So we wanted to get out of that space. And then we wanted a better customer experience. So we needed some hardware where we could scan the card through tap, swipe, whatever it may be. We looked at lots of vendors that could handle that for us. And we settled on a couple that had the hardware. One of the ones we tried out was the SDKs and getting in there was just extremely cumbersome, couldn’t get in. So we kind of put them aside. And then the next one we tried, they had a device that worked for us. We had a proof of concept going, but it was very difficult to get it connected. There was either a) we had to have this device have its own cell phone plan in order to transmit payment information. So not only were we paying for the phone plan for the phone, we got to pay for another phone plan and that just doubles the cost of that.

Te connection process was difficult, you had to go through a lot of steps and hoops and it was just very difficult. And the devices, we talk to them and say, this isn’t easy, we need something easier. And they’re like, well, that’s a year away and that’s two years away. We’re almost there. We’ll give you there soon. And the vendors we were talking to we’re all saying that. And so one day I’m just kind of like, why is this so hard? And I’m walking around a baseball stadium and seeing the devices they’re using. I’m like, why can’t we use these devices that are just so easy to use? Why are we having so much trouble, and places like this baseball team have no problem, they’re up and running, have no issues. And that got me looking towards Square and places like that. I went ahead and just bought a square device, signed up for my own account, and within a week I had a proof of concept going and it was exactly what we needed.

Richard Moot: And so you originally built this, was it on reader SDK or mobile payments SDK? Correct. Okay. So it was on reader SDK. And I always love hearing that somebody just provisioned their own account, started building out their integrations. And I say that because too often I’ve sort of heard that the experience can sort of be like, oh, I have to go fill out this form, talk to these folks, build up my case sometimes provide, this is what volume my business is doing. So it’s great to hear. And so you had that working, at least the proof of concept, I’m sure it’s not a fully robust solution, but you had this working in under a week, right?

Miles Rush: Correct. 

Richard Moot: You built this in Android. I’m going to take a guess here. Using Samsung tablets and phones, that’d probably be what you wanted it in.

Miles Rush: Yeah, so the original proof of concept, I used Android Studio and Java to get up and running. That’s how we got the original one going and since when we moved to the mobile payment SDK which just came out not too long ago, we switched over to using, still using Android Studio, but now we’re using Kotlin —tried to modernize our efforts there.

Richard Moot: Yeah, I’ve heard, I mean I’m not familiar. I am not really a Java Kotlin developer, but from what I’ve understood from my peers is that Kotlin is a breath of fresh air and helps abstract a lot of the onerous parts of Java away to make it less painful to develop in.

Miles Rush: Yes.

Richard Moot: And so what is the main things that you have been building stuff with for DH Pace previously? It sounds like the Android studio and Java wasn’t really what you’re predominantly building with. I’d just love to know what it is that you’ve sort of done most of your mobile development and backend development with.

Miles Rush: Yeah, so we purchased a rapid development platform that kind of drag and drop and you’ve got your workflows in there and they have a component that lets you integrate with native Android libraries and SDKs and stuff like that.

And so we were able to take our rapid development platform and just link it up with the native Android stuff and we just pass the parameters we need, it passes back, payment was successful, and then we’re good to go there. The development switching to the mobile payment SDK was really nice because Square added these quick start forms essentially. So you don’t even have to develop your own forms. You just say, ‘Hey, I’m taking a payment now,’ and it already knows, pops up a standard form that lets you get going really fast. We didn’t even have to create our own forms to do the payments.

Richard Moot: That’s awesome. I mean I recall, and this is just to sort of give a little bit more illustration to those that might not be familiar previously with reader SDK, it was like you had this connection process, authorization process and then it would kind of kick off a one continuous checkup flow where you’d sort of say, this is how much I want to charge for. It would kick it off and then it kind of like you’d just have to wait for that to complete and then you would sort of get back like, okay, transaction’s done, we have this all process, but with mobile payments, SDK, it was kind of decomposed a little bit. So you had little flows for different components of what you wanted to do through the process.

Miles Rush: Yeah, and what I’m going to call ’em quick start forms, I’m not sure what you guys call them, they were great accelerators to getting us done. The branding on them is really limited so you don’t have to worry about it saying all this stuff everywhere that detracts from our company and if we did need to customize it though and make a real custom checkout, all that stuff’s there. But this just got us to market a lot faster being able to use these standard payment flows.

Richard Moot: And so I don’t know if this was something that was difficult to deal with previously, but I’m curious for your field service technicians, I’d imagine a common problem, and I don’t want to say common, all of them deal with this, but common enough that you have to figure out a process for this of troubleshooting the devices when it’s not connected, and a payment won’t go through. Tell me about how things have sort of evolved from the previous things that you’ve been using from reader SDK to mobile payments, SDK. How has that sort of changed over time?

Miles Rush: We actually never went fully live with the reader SDK. It was always in the proof of concept stage and then we only went live with the mobile payment.

With Square APIs and SDKs, it’s Square — customized.

Learn more -/^

Richard Moot: And then how has it been for the field service techs in terms of troubleshooting issues or dealing with connectivity?

Miles Rush: Yeah, it’s been pretty good for them. What we did is we just recorded a video like hey, here’s how to set up a device and sent it out to them. And then when we showed it to them, there was this big apprehension when we first rolled this out, they’re like, oh, what do we do? What do we do with this? What do we do with that? And we recorded a video, we sent it out, they saw the video and they go, oh, that’s really easy. I don’t even know why we were so concerned about this. And they just were able to connect the devices really easily, get up and running, and when there’s a problem it’s usually just restart the device and you’re good to go.

Richard Moot: That’s awesome. And so to give everyone an understanding of maybe the scale, so you originally said about 3,500 ish company-wide, almost half-ish being field service technicians. What is the scale of your device management and how is that, how do you make sense of all that? I imagine that’s a lot of devices to be managing.

Miles Rush: Because for our phones and our tablets and everything, we have a device management system we use to push out software updates. That’s how we pushed out the square package — through our MDM software. And as far as the hardware itself, because these Square readers are at such a low price point, we’re treating them just about any other tool that if it breaks, we’ll buy you a new one. And so we ordered the initial batch from Square, pretty much just drop ship them out to all the locations, and then they were able to pick ’em up, give ’em to a technician, they put ’em in their tool bag and away they go.

Richard Moot: Couldn’t be easier. So in terms of the simplifying of things, so in one of the proof of concepts, it was having to use individual payment devices with their own cell plans. I’m assuming that the company-issued phone is the same phone that they use for handling service calls, but it’s also the same one that pairs with the reader for actually doing the payment stuff?

Miles Rush: Yeah, absolutely. They’re able to use the same device for their work, for their phone and then to pair to the reader. The only extra equipment we had to buy was the actual reader itself to scan the card.

Richard Moot: So Reader SDK and then mobile payments SDK isn’t the only thing that you’re integrated with. You also have made use of our web payments SDK. Can you tell us a little bit about how you’re using that?

Miles Rush: Yeah, that’s correct, so we have our field force that goes out there and interacts with the customer and taps/swipes the card. We also will have people call over the phone and need to pay their invoice over the phone. A lot of our larger commercial customers will do that for payments on account and that sort of thing. And so we needed a way to handle that securely as well. We don’t want our users typing in card numbers over the phone and storing that in plain text and any of that stuff. That’s just not a good way to do that. So basically we just created a webpage using the web payment SDK. And so anytime they need to collect the payment over the phone, they go to the webpage, type in the card numbers, Square handles, all of that as far as taking the card number and the expiration and any of that information that’s needed to process the card, you hit the process button, it goes to Square returns back approved or denied and away you go. And then we take that result back to our system to record the payment and it made it real easy to securely take payments without storing those card numbers.

Richard Moot: When it comes to the payment processing volume, to what extent can you sort of touch on, I think it’s also just so people can sort of understand what is the average invoice that might come through for a repair installation and nationwide, what kind of payment volume? These can be ballpark numbers to whatever extent you can give us an understanding of it.

Miles Rush: I haven’t looked at our volume stats in a while. I was surprised with how quickly it hit a million dollars when we went live, it was within a few weeks.

Richard Moot: Wow, that’s great.

Miles Rush: And processing that all through Square.

Richard Moot: Has there been any sort of noticeable difference in terms of improvements to either completion, deny authorization, anything like that in terms of the transition from your previous one over to using Square?

Miles Rush: We get a lot more approved cards upfront. So Square does a pre-validation step when you type in the card number. And so we know we have a valid card number before we even process it as far as we’ve got all the right digits and all the right pieces of information before we actually charge the card, which has been really nice. Before we had to actually send it off and they’d be like, well, that zip code isn’t right or something like that, or you transposed a digit and well, we got to do the whole thing again where Square stops us before we even get that far when you’re typing in the card numbers or things like that. And now that we’re also doing the taps and swipes and stuff, those just go through seamlessly. We don’t even have to worry about those anymore.

Richard Moot: And wanting to also touch on something new that you have been exploring with Square is our terminal devices because you have this all-in-one payment solution with the receipt printer and we have an API for it. Tell us about your new integration with that and what you’re hoping to achieve with it.

Miles Rush: Yeah, so not only do we have our field service that is taking payments, we also have showrooms around the country where customers can come in off the street and purchase stuff and we wanted to make that experience better as well. So the person behind the counter is still typing your order information into our existing computer system to record what you are purchasing, but we just needed to give them a better way to pay. And so we didn’t need a full point of sale system for that. We just needed a way for them to tap a card. So we’re integrating with Windows computers at this point and it just made sense to use the terminal, Square Terminal product, so it was very easy to get set up. What we did is added integration to our computer system that sends the web call to Square.

Square then contacts the terminal, says, ‘Hey, you need to collect a hundred dollars payment,’ and boom, it’s right there in front of the customer and they can tap their card, swipe their card, and it automatically prints out a receipt right there as well. We are piloting that here very shortly with our first location and once we work out all the kinks, then we’ll be rolling that out nationwide as well.

Richard Moot: That’s awesome. I mean that’s one of the more common use cases that I’ve started to come across with Terminal API i, companies like already say we have a web point of sale that kind of does inventory management, order management or it’s like an ERP system or health medical record system and they’re just like, but we need to connect to actual hardware for taking payments and we want it to be connected directly to our main source of truth. And so we’ve found that that’s actually a very common way to adopt a terminal for larger businesses. The other one I would say that we’ve commonly seen is self-order kiosks. It’s like you want to have this really nice tablet that displays everything and can walk somebody through a checkout and then just have a payment device that does receipt printing. I mean, I know that mobile payments SDK also works great for this, but if somebody needs a physical receipt, you now have to be like, okay, now we need to connect a receipt printer. And it gets, I don’t know if you’ve ever dealt with printing drivers, but printing drivers can drive most of us a little bit batty.

Miles Rush: Yeah, and the terminal made perfect sense integrated with Windows because the reader is primarily a mobile product, so iPhones and Android stuff where the terminal can connect to just about anything. And so it made perfect sense to use with Windows integration.

Richard Moot: Yeah, no, definitely. I mean, that’s what I’ve seen as well is that it makes it easy that anything that has a web connection, you can just make a call to your backend server, and trigger a payment flow. And do you know if with your terminal integration, is it primarily just for payment capture or are you using any of the actions that we’ve introduced that allow certain sort of data capture or signature capture in that flow?

Miles Rush: Yeah, we didn’t have a big need for the action part. Primarily, we’re just using it right now for payment capture and printing the receipt. I do see that as an area we might investigate further if the need were to arise, but for now we’re just using the payment and the receipt printing.

Richard Moot: Was there anything that surprised you or you wish could be a little bit better as you were working with our APIs and SDKs?

Miles Rush: That’s a great question.

Richard Moot: I just go straight for a tougher one towards the end here.

Miles Rush: Yeah. One thing that has surprised me in a good way is all of the APIs are you can explore every single API through the web webpage. Once you sign up for an account, you don’t have to jump through any hoops to just see what this API does. You have the API Explorer and we actually, we’ll use that for troubleshooting in production sometimes. Why does this data look kind of funny? Let me go to the API. I’ll just run a quick command from there. I don’t have to create a whole program or application. I can just run a quick call through the API explorer. That’s been a great time saver for us.

Richard Moot: That’s great. I mean, I am obviously very biased, but I still use that to this day. I used to use Postman way back before we had API Explorer, and that worked most of the time, but for anyone who’s used Postman, it’s really great until you realize you’re constantly going in there and modifying your queries and updating things. Did I save it and is somebody sharing it? And API Explorer has sort of really simplified a lot of things for the development process. One thing that I’ve seen that still actually surprises me to this day is how many people come in to use API Explorer. They do the testing part, and then once they build the requests that they want, they’ll switch the language to the language that they’re actually building in and literally just copy-paste some of that into their own code and then modify from there, which I hadn’t been doing that, but I was just like, I didn’t even really think about this. It does actually simplify, oh, this is all the data that I want. It already looks sort of generated it for me, and now I can just copy-paste it somewhere else. I mean, as a developer, who doesn’t love copy-pasting someone else’s code?

Miles Rush: The only thing I would love to see, I’m going to throw out one thing here is more places we can integrate with as far as more languages and things like that. For the mobile side, it was if you’re using iOS, you go to Swift and you do the development there. If you’re using Android, you pulled up Android Studio. I’d love to see that ecosystem expand it out even further. All these new tools out there with Fluent, and I think you guys have React, I think that just came out recently, so that’s great.

Richard Moot: Yeah, we just have the React native plugin come out.

Miles Rush: Maui and different things, more native integration to all these different platforms, I think would be a great boon to expand your reach.

Richard Moot: Yeah, I know that two, I’ve heard Maui from you, but I’ve also, the one I’ve heard previously, even for reader SDK when we first published, that was Zamarin. It is used quite commonly. I think that when trying to sort of triage at the time, what are the most popular multi-platform frameworks? It was React native was kind of dominating everything. Flutter was very new on the scene, and we partnered with Google in that initial Flutter 1.0 launch, but I can definitely share this feedback with the team and say that we have more requests for Maui and Zamarin. I do hope to have the flutter plugin for mobile payments SDK coming soon, and in fact, by the time that this actually publishes to air, who knows, maybe it’s already out there and you can already build and test with it. I’m definitely excited to go just try out the React native plugin and start trying to get a few examples working.

Miles Rush: I did remember one more area we’re going to be expanding into using the APIs, and that is the checkout links, so that’s something we’re looking at integrating into when we email invoices to customers, if we’re not doing it on-site and we want to email it, we’re going to put a link in the email and on the invoices they can just click and go straight to Square and pay from their browser and the customer handles all that interaction.

Richard Moot: Oh, that’d be great.

Miles Rush: Yeah. That’s another area we’re expanding into in the near future.

Richard Moot: As a consumer who’s worked with many different proprietors, I can’t say how much I enjoy when you have that ability. In fact, I have, I’m not going to name them, but I work with a pest control company that comes and does a monthly service, and the weirdest part about it is that they send me an email with an invoice saying, this is what I owe, and they give me a link to go pay them, but it’s not linked to the invoice, so I’m just hitting pay going and filling out a form and just assuming that because they see it’s my name and address that it’s like, oh, we know that this is for this invoice, but every single time I have thought, why on earth can’t I just save my info with you? Why can’t I just actually have this paying this specific invoice? 

So I’ve actually found that the checkout links product, it’s near and dear to my heart because it simplifies so much about the payment process. I’ve previously sort of been in the eCommerce space and having built out enough example payment flows at this point, you could probably build this integration using web payments SDK, but it suddenly creates all of these other things of where are you’re going to host this, how are you going to link it? You have to create user sessions and all of these various components and a checkout link simplifies all of that where it’s just like. Here’s a fully built-out streamlined checkout flow that’s going to give you an itemized list. Put in customer data. In many instances, if Square recognizes you like, Hey, we’ve seen this email before. We’ve seen this phone number before. We can actually say, store that for them and then just pre-fill it. So definitely excited to see you roll this out and what your customers think about it.

Miles Rush: It’ll be a big benefit for us.

Richard Moot: Excellent. Well, it looks like we are coming up on our time here. Miles, I want to thank you so much for coming in and telling us a little bit about DH Pace and what you’ve built, and what you’ve integrated with it. For anyone out there who’s listening and you need some doors or some repaired installed garage doors that you walk in and out of, make sure to go check out DH Pace.

Miles Rush: Yeah, thank you, Richard.

Richard Moot: That’s it for today. A big thanks to Miles from DH Pace. If you’ve got a project with Square, we’d love to hear about it. Reach out to us on our Discord, or you can reach out to us on X at Square Dev. Don’t forget to subscribe and check out developer.squareup.com for more. Keep building and catch you next time.