Creating Payment Solutions for Everyday Needs

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 Ryan May, co-founder of Payable Apps. Payable Apps helps small business owners integrate payments with forms making the transition from sign-ups and orders to payments seamless. Learn how Payable Apps has evolved, its long-time partnership with Square, and how everyday tools can become powerful business assets.

Guests

• Richard Moot, Square Head of Developer Relations
• Ryan May, Payable Apps Technical Co-Founder

About Payable Apps

Full transcript

Richard Moot: Hello and welcome to the Square Developer Podcast. I’m your host, Richard Moot, Head of Developer Relations here at Square, and today I’m joined by Ryan from Payable. Thank you so much for being here. Ryan, could you go ahead and just give us an intro of yourself and tell us a little bit about Payable Apps?

Ryan May: Yeah, for sure. Thanks for having us. So Payable Apps has been a Square partner for probably about three or four years now. We got started by making connections with Google applications. So everybody knows Google Forms and Google Sheets and how easy they are to use. And what we did is we made a payment connection for Google Forms and Google Sheets so you could connect them to a payment provider like Square. Then while you’re creating a Google Form for somebody to fill out, whether it’s a t-shirt signup or a membership or an order form, it can also take payment right inside that Google Form for you and keep small businesses organized inside the software.

Richard Moot:  I’ve always really loved the idea of what you guys have built because it’s taking something that is really simple and ubiquitous with a lot of small businesses and then allowing them to make sales using that ; it’s really meeting them where they are and with something that they’re familiar with.

Ryan May: Yeah, I agree. Sellers are huge. There are so many of them out there. Almost everybody has a side hustle, or they’re doing something to try to turn their passion into a business, and they’re all using free tools. They want to use free tools as much as they can, and so our goal was to take some of those free tool,s like the Google Suite, which has some handicaps, some lack of advanced features, and try to just build it out just enough so that it is good enough for somebody who’s doing five orders a day, 25 orders a day, until they grow that business into something more serious. It actually is a really good solution for them.

Richard Moot:  Yeah. So I’m curious, where did the inspiration for this originally come from?

Ryan May: Yeah, I mean, it was actually my co-founder’s real-world situation. It was during COVID; her boss tasked her with this task of saying, Hey, I need you to go around the office and get everybody’s t-shirt size for this event, and you have to collect $20 from every one of them for this team outing event. So she was like, okay, well, no worries. I’ll use a Google Form, and I’ll get your name and whether you’re going to attend, if you have any allergies, what your food preference is, and ask for your t-shirt size. She was like, why can’t a Google Form also just ask for $20? Because it became a nightmare. She had to get it — some people were paying her with e-transfer, and some people were bringing cash to her desk. It was all over the place, and it was up to her to manage this collection of funds.

And she turns to me. My background is in payments. She’s like, well, Ryan, why can’t we do this? Why can’t a Google Form also just have a pay with credit card button attached to the end of it? And I was like, there’s all these PCI compliance and all these rules, and it’s not extendable in that way. And I was like, yeah, it’s just not possible. But I sat there thinking about it a little bit one night, and I was like, you know what? I think I looked at Google’s developer docs and how you could extend it. And I thought if you were a little bit creative, you might be able to tack on an extra page and collect payment and do this in line to make it look very native and secure with payment providers like Square or Stripe or PayPal. So we started with PayPal, and we launched it and I said, well, if I’m going to build it for you, I might as well build it for everyone. Why build code once? So if I’m going to build this little solution for you, we might as well build it together. 

So that was the idea. And yeah, that was our first app called Payable Google Forms. And since then it’s been downloaded over, we now have a hundred thousand different active small businesses who use it on a given month. It’s one of the more popular Google Form payment and accounting add-ons that exist in the marketplace today, so it really has grown. It hits that one simple problem where people really know how to set up a Google Form. Almost everybody has done it, and they just add payable options inside of it. And it’s live and easy for them, especially for things that are one-offs. Like we think about life, and there are people who are creating a business, and they want to have, I’m opening a t-shirt shop, and I’m going to sell t-shirts all day, every day. But for people who are tasked with these rare, or seasonal, or occasional projects, something like a payable Google Form is a really good way to set something up and go live quickly.

Richard Moot: Yeah, no, I mean, it makes perfect sense. I mean, there’s an interesting kind of parallel between, in that same seller space that we used to see initially with Square was, you go to a farmer’s market or some sort of collective where they meet up and sell goods there. And there are a lot of folks who might sell at those very infrequently, but it’s very easy to just have a phone, have a Reader, or even just take payments directly on the phone. And so having something like a Google Form where it’s like, well, I just want to be able to get this thing started. It’s as simple as you use a Google Form and you connect Payable, and now all of a sudden you’re taking payments and collecting and starting your business.

Ryan May: And the cool thing is all the data goes into a connected Google spreadsheet. So every time that somebody submits the form, a row goes into your spreadsheet, and then we update a payment column with whether the person is paid and what their Square transaction number is. And so it’s all really organized, and a lot of people then add extra logic or complexity into that Google sheet. So if they want to have a view where it’s sorted by just people who have paid or sorted by people who have bought this product, people really know how spreadsheets work these days. And so they’re able to build even more automations kind of off of that spreadsheet. So the core of it too is instead of having to go to a dashboard or a different portal is, you’re really just, we’re piggybacking on a lot of the goodness of what is a Google sheet. So if you need to share that sheet with other fundraisers or other people who need to look at it, they can look at it and say, this person’s arrived, they’ve received their t-shirt. And it takes a lot off of our back for having to build up all these different obscure workflows because people can just use their normal spreadsheet knowledge to take over the rest of the business process.

Richard Moot:  So I’m curious about the evolution of Payable, and maybe I’m going to be very self-serving here, a little bit more specific of initially integrating with Square and how has that changed over time?

Ryan May: Yeah, for sure. So we started with PayPal because we looked at it, and it was one in the most countries, and it was one of, I had the most experience working with, PayPal. So with myself, I started with them, but what we really liked about Square was how fast you could onboard casual sellers quickly. The most important thing for our business was you have all these small casual sellers who are just many times individuals or sole proprietors, and they want to get up and running quickly. And Square was the best at that, and also giving you really professional-looking credit card processing out of the gate. So you have Apple Pay, you have Google Pay, you have your checkout page that looks pro when you’ve signed up with Square. So it became very quickly after we integrated the number one payment provider that we would recommend. If somebody reached out to us, said, Hey, I don’t have any one of your payment providers yet.

Should I use Stripe? Should I use PayPal? Should I use Square for the average sole proprietor or small business? We always went with Square. And also if their business extended to the physical world, where in time they may need to take a credit card payment in person, we could help them in that place too. So how it’s evolved over the last four years is we’ve got more and more users using our simple add-ons, and we’ve been working on a new product called Payable Pro, which has a bit more robust features, and it also handles some of the in-person stuff. So it has Kiosk built into it, and it has in-person workflows, so when somebody arrives, you can scan their ticket.

And check them in and check them out. It has more of that full, robust dashboard, whereas our traditional Payable Apps run inside of the spreadsheet. And so spreadsheet is great for simple workflows, or custom workflows are really unique things. But for some of our bigger users who are using us for things like ticketing or kiosks, we have the new Print Payable Pro platform. And with Pro, Square is our only partner just because of how great and easy it was to extend the eCommerce capabilities to the online, the physical world capabilities using the card readers and the card reader APIs were quite nice.

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

Learn more -/^

Richard Moot: So in the very first iteration of the app, and it’s been a while since I remember how this worked, but was the very first version built using Square Checkout, or was it using the web, I don’t know at the time, might’ve been Square Payment form or Web Payments SDK, what it was initially built with. 

Ryan May: Yeah, so we’re entirely a web dev shop, so we do no native apps, so no iOS, no Android, everything is a web app. And so we used Square Web Payments SDK, so it’s all just the extra JavaScript that you include, and it has a little iframe that appears on the page, and you can include your Apple Pay button and your Google Pay button and that’s right on the page. So generally what we do is we transition users from the Google Form to our hosted checkout page, almost kind of like an invoicing platform might do. Like you were used to paying an invoice with QuickBooks, you would go over to the QuickBooks page. So you come over to our Payable-hosted checkout pages, where we kind of take the data that was submitted in the Google Form, automatically turn it into a checkout page, almost like your cart or your payment page. You would enter your data right on that payment page. And because Square does all the latest client-side encryption, the users are typing their credit card data, and they do end up typing it into a tiny little iframe that encrypts the data and sends it to Square. So we never touch, or the customer never Googles, or anybody never touches the user’s credit card data or their customer’s credit card data. It’s all encrypted by you, and it goes off and comes back. 

And then over time, we got into subscriptions. So we expanded from doing just single one-time payments into subscriptions using the Square subscription engine as well, and taking cards, putting them on file, and then attaching them to subscriptions for the user as well. So we also have a really easy way, if you were, say, a gym membership or you wanted to make six payments for a more expensive coaching or basketball class, you could divide that up or offer those types of solutions to your customers right through the Google Form as well.

Richard Moot:  And what have you used? It’s a web dev shop. What is your tech stack of choice, and has that changed over time?

Ryan May: For me, it’s pretty old school, so I mean, it kind of dates me a little bit. It goes back to my history of being an engineer. So when I went to school and I learned PHP. It was the first web, pretty much the first programming language I actually learned. And so because of that, for the rest of my career up to this point, I’ve stuck hard. I’ve been a hard PHP advocate, so the core backend is just PHP MySQL, so it’s a LAMP stack and we use Google Cloud to kind of run our Google Cloud SQL and our infrastructure, which is good because a Google partner, so it sometimes makes sense. I always say the servers are close to each other, they’re in the same area, which helps speed things up and keep it in a closed ecosystem. But yeah, a good old-fashioned LAMP stack that has been around for decades.

Richard Moot:  Nice. And so with that, are you using a particular PHP framework, or are you just going plain old standard PHP?

Ryan May: No, a lot of it is vanilla PHP starting from a starting point, and we’ve customized quite a few of the libraries. So what we’ve done is we’ve abstracted our main bread and butter; it’s almost like we’re a gateway of a gateway, so we’ve abstracted a lot of the concept of what is going on behind the scenes with Square, and we have that same logic for PayPal, Stripe, RazorPay, Rapyd, and so generally the background of those frameworks is that. We don’t have a lot of, there’s not a spot on our site where people actually even log in and look at their data, so we are essentially a connector, a connector. There’s not a lot of UI, there’s not a lot of tables, there’s not a lot of things going on that we are using. Our framework would add a ton to it. Nowadays you probably start with some sort of API framework or go a different way, but because of the way it was born, it’s generally a vanilla PHP connector.

Richard Moot:  Well, I mean, from what I’ve understood in the tech industry, it seems like PHP and LAMP stack is actually making a little bit of a resurgence in the indie hacker community because it seems like it’s tried and true, it’s reliable. You can let it just sit there and run, and it’s not difficult to maintain.

Ryan May: Yeah, it’s tough. I think a lot of the times your young junior engineers want to work on whatever is the sexiest or latest thing, and so sometimes it might be a little boring to them, but I feel like I’ve converted our team into slowly starting to love it a little bit. But at the end of the day, what’s interesting about code is I’ve seen some startups, crazy fuss about the latest technology, the latest load balancing, the latest optimization building these really complex things, like you could log into Google Cloud and create an extremely expensive platform for a product that people aren’t using. And we talked about it a little bit before, but one of the most important things is, how many lines of code can you write for seconds of time you’re actually saving a customer? And that is what is really nice about a lot of the Payable Apps is they’re very invisible. There’s not a lot of code there. It is generally what we wanted to do, is go, how much time can we save the average small business for a small amount of codes, like a small amount of lines? And that’s the most rewarding thing as a developer: when you’re able to have 250 lines of code that take data from here and put them over there, but it saves people hours and hours of putting things manually into a spreadsheet or doing something by hand, and so that’s kind of where we’ve tapped into solutions like that.

Richard Moot:  Yeah, well, I mean, I think the way that you put that about lines of code for minutes saved or hours saved for end customers really kind of positions that in a really customer-centric way of, I mean, code is supposed to serve a purpose, it’s supposed to be understood by people, but it’s also supposed to be solving a problem, and if you’re adding in code just to add an abstraction because it’ll be easier to understand later. I mean, there’s a value to that, but I mean, it’s harder to see that in the near term.

Ryan May: Yeah, I mean, I’ve worked as an engineer at both tech startups and at bigger payment companies, and sometimes the hardest thing as an engineer is not knowing who your customer is while you’re doing all of this engineering work and not really knowing how you’re going to save them time and why they’re going to love it. And I think that’s the hardest part. What we did at Payable was, so when I started the first product, Payable Google Forms, I already had the customer. My co-founder was the customer of the product, so if I could save her time, that was my whole goal with it. And I think that’s how every engineering product should be made. Find your target person that is going to use this and work closely with them to build them what they need. That way you’re at least building something that one person is going to need, and then you hope you’ll be able to find five or six or 10 or 500,000 people just like that person. But it always is great to start with one person in mind and work with that customer while you’re building it.

Richard Moot:  Yeah, I mean, it’s so important. I mean, I can entirely agree with you at times of working at a larger company that the engineer working on the feature is so far removed or disconnected from the end user. For us, it would be, say, sellers, and so getting to work closely with that use case is crucial to providing value. I’m curious, as you’ve gone from working in the payments industry, you’re still kind of in the payments industry, but more, I guess, hands-on with working for your end customers. How has that evolved over time in terms of writing software versus managing a business? Has that evolved or changed your perspective on engineering or business in general?

Ryan May: Yeah, I mean, I loved engineering. When I first got into it. I remember I took my first PHP class we talked about, and I was still, I think, second-year university. And I was like, wow, okay, so you could just, this concept of, okay, I could make a form and data could go into a database, I could do something, and then I could build software. This concept was really exciting, and I loved it. I also found it to me to be soothing, almost like painting. So, some people love to paint, and they’ll sit down, and they get to be a little bit creative. As an engineer, I also found solving these problems and building little tools to be kind of like a soothing process.

After school, I went to California, and I worked for a startup there, and I loved it. It was so fun to work for a company and build something bigger than I could do on my own. And we were building a product that was bigger than what I could do. I loved that so much, especially in the early stages where you’re taking that first customer and you’re building something; you have that build stage. It’s a really fun and exciting part of any startup. And I always loved working on the payment stuff. When you’re the engineer that gets to make money move, it just is a little bit more exciting. You’re like, I’m putting in credit cards, and I’m moving money from here to there. And it was always an exciting part of being an engineer. So, when I changed roles, I always wanted to be somebody who got to move the money. I loved being the engineer who specialized in either working with different payment providers or building those flows out. Eventually later in my career, I was able to be hired by one of the bigger payment providers, and that’s where it gets a little bit more abstract. So as an engineer, you start to lose connection with who your end customer is.

Sometimes you might be managing a product or a suite or an engineering team, and the roles and the tasks, the stories that come in, you’re often pretty removed from. And it was even surprising at times to go like, we’re working for this big company. We’re working on something; maybe it was related to point of sale for quick service restaurants, but none of my engineers have ever worked in a quick service restaurant. They don’t know what it’s like to have a KDS display pop up three things in a line versus two things in a line or how a bump screen works and all of these different things. And so it’s really tough. You become abstracted quite quickly from who your end customer is, and it can be quite difficult as you get into that position. A lot of really good engineers just specialize in, okay, well, how do I do this one piece of the pie really, really well?

How do I write database queries that are super fast, or how do I do infrastructure or architecture? But you lose that connection with the customer, and I think that’s the hardest part. And so for me as an engineer, I always wanted to go like, well, what’s going on? Who’s making these decisions in this big room that they’re giving to us as engineers? So you’d sit there and you’d get your user stories and say, Hey, this week you’re coding this, this, and this. And I was like, where are these coming from? Who is giving us these instructions? 

So later in my career I said, well, if I can learn how to code, I can learn business. So I decided to kind of go back to school and do an MBA, and so I could kind of go into that room with all the businesspeople who were like, oh, Ryan, you’re just an engineer. Stay in the engineering room. And so I think that was helpful in a couple ways. One way I thought it was going to help me in the corporate world was, like, speak corporate speak instead of geeky engineering speak when I would sit down with executives, which it did a little bit, and it helped me understand a little bit of accounting and revenue recognition and some marketing and some things like that. 

But the other thing it did is it made me a bit more confident that I could do those other aspects and start my own company. And so I think it was after that a little while, that I realized, okay, I think I have the skills to not just make code, but then make a product and market that product and do all of it. And so after a little bit of time, we created our first product, and then I’ve broken out onto my own. So that’s kind of my journey from a developer at startups to a developer at a bigger company and then through product manager into starting my own company.

Richard Moot:  Yeah, I mean, it sounds like, and I don’t want to be putting words in, but it sounds like going through the MBA program also helped give that reliability or that confidence to be able to go run your own company or start your own company because now it’s like while you can understand the larger picture of how to connect things between understanding product, I mean, you could probably understand from an engineering perspective, product market fit loosely, but I feel like it probably gives a more concrete understanding of what to be considering in terms of how do we market this thing, how do we talk about this thing?

Ryan May: Yeah, I mean, definitely, I would recommend it. It’s hard to recommend formal education these days anymore, especially now that AI is out. And I could talk to ChatGPT about almost anything, and he’s faster than our lawyers and better, so sometimes it’s hard, but what it does give you is a forced sampling of a whole bunch of stuff. And a solo engineer can be really, really fast when you are a good solo engineer. You can build things in a day or in a week that would take a big corporation years, and it would still fail to actually hit the right thing. And so you’re really giving yourself all of those other ingredients, all those other tools, just a little bit of graphic design, a little bit of marketing, a little bit of exposure to your accounting, to your books. And then the other thing is, as an engineer, you can start to automate all the other pieces that the average business wouldn’t automate. So if I was just an ice cream shop or I was a restaurateur, I might not look at where all these other inefficiencies are in the rest of the business cycle. Whereas as an engineer, you can fix those other inefficiencies with code or with software. And so having a background in tech and building for tech also helps you automate the rest of your business as opposed to making the rest of your business also just inefficient or outside of the scope of what you’re doing.

Richard Moot:  Yeah. Do you feel like maybe some of that is, it can sort of spawn out of necessity? I know that we try to automate things in larger companies, and we do, but it does require a lot more coordination and planning and consideration of maintenance, whereas on the smaller side, I don’t want to say it’s like you can choose to automate things but then not be married to them. But I feel like some of it you just have to automate out of necessity. We don’t have the bandwidth to keep doing this process over here, so it’s got to be automated. I’m just curious, how do you evaluate that?

Ryan May: Yeah, I think when you have a super small startup, we are only four or five people, you start to realize which tasks get tedious quickly. So you go, okay, what are tasks that we are obviously a computer could do? And then we try to pick up those. And we have an engineering team. So the other thing I always go is I have an engineering team. There’s no reason that that engineering team is limited to just building customer-facing products. They can also build internal tools, dashboards, reporting pieces, something that automates receipt syncing for our QuickBooks or for our accountant. So we have a lot of things that the team works on that maybe are not are always customer-facing. So whereas when you’re at a big company, you don’t really have, you’re not taking your engineers who are working on the Venmo app and assigning them to help you with payroll automation or something like that.

So I do it because I find it’s also good for the team to look at other APIs that are out there. The good thing about SaaS, we were talking about the pros and cons to software as a service. The pros are these days, many of them have an API that’s open and out there. And if you have a company that has engineers like us, well, we can interface with those and use them for the average small business; having APIs for QuickBooks might not be the easiest thing for you to do. How is that supposed to make your life easier? So they end up using plugins or add-ons. And so, yeah, that’s where our business is really quite invisible. We don’t want you to have a separate login. We are a plugin or an add-on. So for people who don’t know how to code or can’t make these connections, we have really tried with every part of our business to automate as much as we can.

Richard Moot: Well, I love to hear it because, I mean, it feels very aligned with Square. I mean, obviously I’m very biased here, but folding into and sort of fading into the background was something that was very essential to the initial designs with Square. We designed our payment hardware to sort of blend into, I’m talking about in the in-person experience, but it was intended to be blended into many different types of business. It wasn’t intended to be sticking out in your face when you needed to make the payment. It was there when it needed to sort of fade away and allow you to be focused on your business and the customer interaction.

Ryan May: I agree a hundred percent. If you’re building software for small- and medium-sized businesses, you want their brand to be front and center. They are so proud of their brand. They’ve spent time getting customers. If they’re a yoga company and they’ve chosen to paint their whole building pink, you want that; their form can be pink, and it can have the logo at the top. And sometimes payment companies, you might look at, oh, a QuickBooks invoice came or something like that, and it just looks like QuickBooks, and it doesn’t represent your brand. And that was one of the things I did like a lot about working with Square. Even when your card reader came out at the beginning, one of the first things you guys built for your card reader was that you could put different splash screens on it. So when it’s just in its passive mode when nobody’s looking at it, you could upload different screens, and you have no idea how much the small businesses love that so that when the card reader is off, they could have a picture if they’re a mountain bike shop of a mountain bike coming around a corner, or if they’re a yoga studio, they could have their pink yoga studio brand and just use their card readers as promotion for their own businesses or a sale that’s coming up — that’s super important.

Too many SaaS companies want their brand to be everywhere. Thanks for clicking this Calendly link. It’s Calenday, this is a calendar. And you’re like, okay, I get it. I get it. There is a time to show your brand, but when you are supporting small businesses, the most important thing you can do is let their business and their brand shine as the front and center thing. And so yeah, with Payable Pro, the first thing we do is we let you pick your colors, we let you upload your logos we let you have, she kind of likes to wear a Square logo, a long logo. What is it about your brand that you want to have? And then we kind of take a step back. We want to be invisible. We want your brand to look professional. And that’s one of the biggest complaints people get sometimes about a Google Form as people want it to look professional. I don’t want it to say Google or Powered by Google. I want people to think my brand is big. And so that’s the other spot we’re coming in with Payable Pro is to help kind of disguise that it is a Google Form going on behind the scenes there and that it looks just a little bit more high-end and professional, like your brand.

Richard Moot:  Yeah, no, I mean, it makes perfect sense because as sellers grow into small businesses that then go into mid-market, and we’ve seen this within Square, there’s this natural propensity towards feeling like, oh, I might be outgrowing this thing, and I need something that looks like I have more identity with. And what you said about brand is, I couldn’t agree with it more because as the business owner, of course, you’re obsessed with your brand. You don’t want to be tacking on everyone else’s brand. And of course, there are places where you might want to have some other brand when you need to build trust. I know it’s very common on, say, checkout forms, particularly when they do a redirect. When I say this checkout is powered by, a trustworthy brand, because they’re like, otherwise, that experience can be really jarring to buyers when they suddenly go, wait, where am I? I don’t feel like I should be putting my credit card information in here.

Ryan May: No, 100% we found on the bottom of our checkout page as we always have powered by Square. Where are you putting your credit card in those locations? It does build trust. You’re like, I understand there’s no skimming. This isn’t a phishing scheme. This is going straight into Square. And Square does have that brand, brand trust. So when it comes to payments, having it in the right places, you’re right, is 100% crucial.

Richard Moot: So this is a little bit of changing gears, but I wanted to touch back on a previous topic. As we were talking about automation and using AI as part of your business, I’m curious, how much have you, for Payable or in general, been leveraging this for software engineering or business automation? How has this been something that you’ve been using?

Ryan May: Yeah, I mean, everybody’s typed into ChatGPT and seen how cool the responses can be and how amazing they are. And so as engineers, there are multiple ways that our team has been touching on it. So one is our IDs, so the code editors that we use to code these days, it’s pretty amazing how the ones that have AI built into them as you are typing a new function or a new piece, how good they are at anticipating what you actually want. And so that’s the first thing that’s been pretty amazing is the team. You still need to be a good engineer and kind of understand and read and understand the code. They’re not coding for you just yet, but the code editors are really amazing at doing predictive algorithms and tests as to what you want to do. Look at all the rest of the code on the page correctly; name your variables. It is really quite unbelievable there with the IDEs. So we’ve been doing that for a little while now. And then the other major change we made is customer support, so we have a ton of knowledge base. So we had this really long knowledge base. People get confused at times about how you set all this stuff up. And so we’ve written help articles, and we’ve made help videos, and a lot of it is helpful, but at the end of the day, we always had chat support on our site. And if anybody is a startup or at an early stage of their business, whether it’s a software business or a service business or any type of business, I definitely recommend putting a chat, like a little chat icon, on your site. You don’t have to code it. You go to Crisp or Intercom or some of the major supporters of chat, and you can set it up. So even if you’re a sole entrepreneur, when somebody chats you, it comes to your cell phone as a text message, and you can reply back wherever you are.

But chat is this low barrier to entry where people are willing to engage with your business as they’re trying to figure something out. So when we were getting started, it was me on the chat box, and people would ask questions in there, and as a sole engineer, it was invaluable to be like, okay, they’re getting confused about this step. This is the third person that’s got confused about step three. I’m going to have to change the way the UI looks or change something to make step three happen automatically with step two because it is weird that I make you click two buttons. And so when you have a new product that is invaluable. But as we grew, we got so many chat support requests that it was unbelievable, and a lot of the time it was the same thing. And back in the day, our chatbot was so it was hard, you had to say, if you see text that says fees or cost, send them to this article and try to have them figure it out. And it was painful for our customers to have those types of interactions. 

And the new chat interactions are absolutely unbelievable. So I am blown away by how our chat support works right now. Our AI chat support solves probably about 60% of our chat interactions. The person says, yes, this helped me, and the AI person solved it, and the other 40% now go on to our team, and a human will look at it or a human will step in, but it is able to take those complex help articles that we’ve written and point you at the exact right spot. So somebody is going to say, hey, I’m getting payment method not found, or I’m getting a free order. It’s like, okay, that is this article, it’s here, here is your exact answer. And it unblocks people. It gets them moving forward with your product quickly. And the most important thing you can have as a product developer or somebody who’s selling software is you unblock people and get them moving forward. 

So with support, AI has been unbelievable for us. So we spent a big chunk of time working with that, and it’s crazy how far it can go. So we are working on better integrating it so that when you talk to it, it knows which Google Forms you have set up; it knows which payment provider you have set up. So it can give you more tailored information when you’re trying to say, hey, how do I issue a refund? We could tell you the specific Square steps because we know who’s talking to us is with Square. And we would tell that to the AI, and the AI knows the Square refund steps, and it will walk the person through how to issue a refund with Square. So yeah, it is really for customer support. It’s pretty amazing.

Richard Moot: Yeah, it’s awesome to see it being leveraged that way. And I think it’s probably really, really helpful that you had such detailed documentation for it to more or less be trained on because we did a similar thing. I can’t remember if it was this last year or before that, but for our developer forums, we had released a Square Dev AI, which was trained on all of our — initially it was trained on our payments documentation and basically was extremely, I think even to this day, it works in sort of a semi-automated kind of way where somebody posts a question into our forums, it’ll generate a proposed response, our developer success folks will review it and make sure, like, hey, is it on base or off base? And then I don’t want to be totally quoted here. I think that they also can use that for retraining, so when it is correct or isn’t correct, it can sort of be like doing some sort of reinforcement. We’ve seen a very similar success, and it was in large part because we had such great, robust documentation, and now it’s very well versed in almost our entire API suite. 

So most of the time it can just immediately give an answer to someone. It saves developer success time because it’s answering the types of questions that they don’t need to go and point somebody to articles for. And in those instances where somebody’s asking something that’s so bespoke, the AI couldn’t ever really answer it, our dev success is already going to be able to say, like, nope, I’m just going to go ahead and step in here and answer this for folks. And it’s just been a huge boon for us and for our developer community; now they’re getting answers that they need that they might not be able to figure out on their own.

Ryan May: And for me, 60% getting self-service quickly is amazing because as much as we try, we’re a small team, and I always go, Google doesn’t have a human that you can talk to, and Microsoft doesn’t have a Google human that you can talk to. And so we do, as a small team; we are trying to get and service as many small businesses who have questions. Sometimes those questions err on the side of, like, I just need help figuring out how to set up a Google Form, or I’m confused at how spreadsheets work. And it can be tough. And what’s been nice is we’ve been able to take our AI and let him learn a little bit more about, okay, this is how you set up a Google Form. This is how you manage spreadsheet basics. And so sometimes you look at these in-depth conversations that people have been having with our AI, and it’s unblocking them, and it’s moving them forward, and it’s the most important thing we can have for our business. 

And then, yeah, every time he doesn’t get it right, or she or the AI god, they learn from the human answer that’s put in, and that’s really quite good, too. And then the last thing where we’re going with AI, it’s weird, but we’re on a couple of new projects, and the thing I like about our company is always just trying to come up with different things. And so we do a lot of hackathons — something we do with the team to try new ideas. And so hackathons are great; you can go to different places to find them, but Devpost often has them; they’re kind of an aggregate of all the different big companies that are putting on things. 

And if you’re thinking about trying to come up with a product idea or start something as an engineer, I always recommend going to Devpost, look at hackathons that are going on, and see what cool companies have new APIs that they want people to build new ideas with. And you might have something in your life that you have a solution for, or you might see another solve, but build and test with these hackathons because it’s a really good way that, number one, you can win money, and it’s a perfect little business case for you as a startup because usually you submit a little two minute-video and a demo of your code, and you have to solve one of these tasks.

And that’s exactly what it’s like to launch a business. You have a solution, you have a problem, you build a solution using technology for it, and you build a two-minute video that can market that technology. And so if you’re thinking about being an entrepreneur, trying hackathons, two or three of them, is a really good way to get your name out there. And if you’re looking for a job or work, many of the companies that put them on are hiring the developers or the people who have submitted ideas. They use them for headhunting or sourcing. So if you’re thinking about doing something like that, go do it as an aside. So how that transitions back into AI, one of the things we were working on is we have this other app that we are working on that is looking at ways to automate other things that are coming through your inbox.

So you have information coming into our inboxes all the time, and sometimes people QuickBooks does its best to try to figure out a receipt and match receipts and do other things like that. So we’ve been using AI to try to help build us self-healing regular expressions. So how this works is I get an email, and I’m expecting it to say total and transaction ID in these two different spots. And so we have a tool that parses an email that comes, maybe it’s, say, a receipt, and it parses it, and it puts it into the database, and updates an order for it. However, what happens all the time is people are changing the templates and the skins of the emails that are coming out, and they keep breaking. You would go, ah, we’re no longer able to scrape the right data out of this. It’s gone.

And so what we’ve done is, we built into the flow the ability, when our regular script doesn’t deliver the expected info, to then use the ChatGPT API to send it the email template and we ask it to help us locate these things and write a new regular expression. And we can take that new expression and add it to our database of attempted expressions for that email provider. And we can sell code that is self-healing itself, so the code is smart enough to now fix it itself on that first try. So we take situations where the code is breaking a lot. So as an engineer, you look at your code and you go, why is this code breaking? We’re dependent on a third party. That third party is changing stuff. Could we, instead of hard-coding it, use AI to look at it, give us the new code that we need and, save that new code in our database, and then automatically try a collection of our code?

So we are attempting to, in situations where we run up with infrequent errors or things that are changing a lot to start, and we don’t want to use AI every single time because, as we know, AI is a little bit slow, and it’s a little bit expensive to call. So what we want to do is use it to get a new algorithm or a new regular expression or a new way we can parse the data, save that, and then we move on. And it self fixes itself after it’s done it. So if somebody changes their template, if an email provider changes its template, our initial scrape will fail. We’ll end up without the right data. AI will figure out the right scrape, we’ll run the right scrape, it’ll be solved in about 15 seconds. It just fixes itself. So we’re trying places like that to do things like that.

Richard Moot: That sounds awesome. I mean, you’re inspiring me for an idea around an auto API migrator, but only because I want to envision a similar type of thing of switching the API version, testing out a feature set, seeing what fails, and then trying to do adjustments in the code to be like, well, this is what a proposed change to migrate to this API version would be granted very self-serving. One of the other things I do is I lead API design here. And so I very much want to get people moving along on our API migration story. 

But yeah, self-healing code for something like this just sounds so useful. I can’t tell you the amount of times that I’ve had to build my own parser for scraping data from blog posts or something to assemble things. And every month or so I’m having to go and retool it and readjust it because the stylings, the tags, the IDs got tweaked a little bit, and I needed to go fix it. And yeah, now it didn’t even occur to me that I could use something like open AI’s APIs to basically adjust it and figure out how I throw this into my database to fix my parsers.

Ryan May: And it’s going to get faster and better and better. And there are times where sometimes I go, well, do we even need to write an app? Just give it the HTML; let the AI figure it out. It knows the layout, it knows logos. It’s really good at doing the parsing right now. It’s just a little slow for something that’s coming so quickly. So for us, we’re using it; we’re phasing it in that way where when what we had regularly doesn’t work, then we’ll pop it in. But I can see a future where, as engineers, you’re no longer having to do manual parsing. You’re just kind of telling it, Hey, can you grab me the transaction ID and the total amount off this? What currency was this invoice in? You can just ask these types of questions, and it’s unbelievable. It’s really amazing.

Richard Moot:  So exciting. Well, I see that we’re here. We’re just at about time. So I want to give a huge thanks to you, Ryan, for joining us here and telling us about Payable and your journey along here. I recommend to anyone, if you are a Square seller and you’re interested in learning more about Payable, you can find their app in the Square App Marketplace. Ryan, is there any other way you want to plug for anybody who’d want to learn more about Payable and what you guys offer?

Ryan May: Yeah, you can always go to payableapps.com and check out our apps and go to the Payable Google Forms. If you’ve created a Google Form, they have an add-on section, and just type Payable Forms, and you can add our add-on right inside a Google Form there, and it’s compatible with Square, and it’ll get you up and running in no time.

Richard Moot:  Awesome. And if you’ve got a project with Square, we’d love to hear about it. Reach out to us on our Discord or 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.