Square DeveloperIn this video, we explain all of the core concepts of the Square subscriptions model. We break down two different examples to give you a full picture of how different Square APIs, such as Catalog, Subscriptions, and Orders, can flex to fit your business model. By the end of this video, you will understand all of the different pieces that are required for integrating subscription payments into your application.
Chapters: 0:00 - Introduction to Subscriptions 0:41 - Subscription Plans and Variations 1:11 - Understanding Subscription Phases 1:58 - Finalizing the Subscription Setup 2:18 - Connecting Subscriptions to Customers 2:38 - Billing and Charging Options 3:07 - Subscription Setup for Physical Goods 3:46 - Attaching an Order Template 4:17 - Conclusion and Additional Resources
Subscriptions API ExplainedSquare Developer2024-04-30 | In this video, we explain all of the core concepts of the Square subscriptions model. We break down two different examples to give you a full picture of how different Square APIs, such as Catalog, Subscriptions, and Orders, can flex to fit your business model. By the end of this video, you will understand all of the different pieces that are required for integrating subscription payments into your application.
Chapters: 0:00 - Introduction to Subscriptions 0:41 - Subscription Plans and Variations 1:11 - Understanding Subscription Phases 1:58 - Finalizing the Subscription Setup 2:18 - Connecting Subscriptions to Customers 2:38 - Billing and Charging Options 3:07 - Subscription Setup for Physical Goods 3:46 - Attaching an Order Template 4:17 - Conclusion and Additional Resources
📖 Read the full guide here: developer.squareup.com/docs/mcpBuilding Innovative Mobile Solutions for RestaurantsSquare Developer2025-05-12 | Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard. Head of Devrel here at Square. And today I'm joined by David and Arielle from Blue Rocket. Thank you so much for being here. Can you go ahead and just give us a quick little intro and tell us about Blue Rocket.
David Foote: Blue rocket is a boutique design and development firm, and we kind of cut our teeth on restaurant apps very early in the history of the iPhone. We were the ones that put together Chipotle's first mobile app. And, today, we're still loving restaurants, but we're also spreading out into a lot of AI applications, especially where AI meets the phone.
Richard Moot: Very cool. And, what is it that each of you do here at Blue Rocket? Just to set the context for any of our listeners here so we can like, be sure like who's who and who does what.
Arielle Watson: So my name is Ariel. I do a little bit of everything. My technical title is VP of Client development. But, in any given week, that might look like working with our development team, working with clients, coding, if I'm lucky, and some design work as well.
David Foote: And I'm the CEO at Blue Rocket and haven't always been, but my, my partner retired a couple years ago, and so I stepped up from CTO to CEO, but I'm still I still code on a weekly basis on a daily, daily basis because there's lots of admin and overhead to worry about as well.
Richard Moot: I feel like you're describing a little bit of my life. So the majority of like, you know, your expertise within Blue Rocket is like these mobile apps. How is that like your approach to mobile app development sort of evolved over time? Or is it like you came in with, like a certain level of expertise or like, I'd love to know, like a little bit more of like, you know, how you approach those things.
David Foote: Well, historically we were very iPhone centric. You know, we've done Android apps along the way, but we've always kind of been more likely to be involved in an iPhone first sort of situation where, where everything was sort of vetted and, and figured out on the iPhone. And then an Android app was created later recently. You know, we tried in like 2016, I think it was we we tried out React Native, and it was just changing so fast that we just couldn't it was just too unstable for us to to do production apps on. But, we tried again recently and we really enjoyed it. It's been a good experience. Retention. So we're actually developing for both Android and iOS at the same time with that.
Richard Moot: Excellent. I think you're describing, like, exactly what my feeling has been with React Native for a very long time. And like, there's this very strong love hate relationship where I love it because I'm, I'm mainly a web developer. I know how to build stuff and react. So I felt like, oh, I suddenly feel powerful. I can make web apps or I can make mobile apps.
But every time I would come back to an app after, like, I don't know, three, six months, I mean, I'm mostly going to be, like, shocked by my own code. You like who wrote this? But I would also get endlessly frustrated, like, oh, I'm going to go upgrade my dependencies. And oh my gosh, like, I can't get anything to build.
And you know, actually X code's on a different version. And it was always a nightmare. So I'm glad to see that there's a little bit more stability here. It feels a little bit more reliable. Have you found that like most of this like expansion with React Native? Do you still do like native Android development or is it still kind of like iOS is like the deeper expertise and then like React Native enables this, like cross-platform, like code reuse?
David Foote: We still do Android native development as well. For instance, we're doing some SDK work for a client right now. That's all. It's Java. It's not Kotlin, but it's all Java.
Richard Moot: Very cool. And so part of the reason that we wanted to, like, have you on here and chat a little bit is that you've recently for one of your clients, actually started exploring building within Square's ecosystem. I'd love for you to like, tell a little bit more about, like, what brought you into adopting Square and like, how's it going?
Arielle Watson: Yeah. So we were approached by a prospective client last year and given what they were out to accomplish, we evaluated a few different vendors. Square was one of them. And for the functionality that we were looking to build, Square had everything that we needed. When we looked at your guys' documentation and looked at the different APIs that you had.
And so that was I think that was part of why, from a technical perspective, we recommended going with Square and then, for our client, they had a previous relationship with Square for some other of their businesses. And so they were also leaning that direction. So it worked out really well.
Richard Moot: Also. And like, what was it that sort of like, stood out for you in li...Scaling Entertainment Centers and Transforming Guest ExperiencesSquare Developer2025-05-05 | 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 ...Integrating Phone Numbers into Brand Identity VerificationSquare Developer2025-04-28 | 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 Binh Ly who's a member of our developer community and is the owner and operator of the company operating. Ben, thank you so much for joining us here. I'm so excited to chat more with you about what it is that you've built on the Square Developer platform. You're also a hackathon winner. I'd love for you to just tell us all a little bit more about how you first got involved with Square and a little bit about your involvement on the Hackathon.
Binh Ly: First, thank you for having me. It's a pleasure to be here. So Square has been on my radar since around the time of the company's founding. I was working with a device that could handle credit card swipes, but I wasn't using that component of the device, but I was trying to think of a reason to use it. And then back then the thought was like it stinks is when you go to the restaurant and you're with your friends, so why can't you split that check? So we're like, let's try and build something to do that. But back then onboarding a merchant account was not that fun. So that lag time and making the sale and then getting the software activated for someone was too long, but we were fascinated that Square could do it in two minutes. So I was like, Square is pretty interesting. So I just followed the company's trajectory that whole time. And then I finally switched careers since I changed the thing that I was working on from shipping software to messaging software around 2017. So that was the first version of Operator that existed in a different company. And back then the idea was that you should be able to message any company, but how do you do that without selling software at every business in the country? So we had this really insane approach where if you text it into the system, we would call the business and ask them the information and then text it back, but,
Richard Moot: Oh wow.
Binh Ly: That was pretty neat that it worked that way, but ultimately wasn't scalable.
But then once we realized that you could send text messages to the landlines, that changed everything because a majority of businesses have landlines and SMS is the most installed software on earth. So to get the customer you didn't have the two sided problem, the software was already on the phone. We just need to collect the text messages sent to the landline and present it to the business owner.
Richard Moot: I mean, I always think that that part is fascinating to me because it's still, even after you submitted the hackathon thing and every time I come back to it, I think this is something that most people just don't think is possible of getting SMS on a landline. So for those who are not familiar with this, how is this able to work or to what degree could you sort explain how this works to us?
Binh Ly: Yes. So the way it was explained to me about how it works is that you can picture a gigantic phone book and there's every phone number, every landline number is in there, and there's imagine two fields next to every phone. Number one says data traffic and one says voice traffic. So when you get a cell phone, the voice traffic says whoever your carrier is, AT&T, Verizon or whatever. And then the same for the data field, but for a landline, the data field is empty. So when you send a text message from your cell phone to a landline, it just goes to nowhere because it doesn't know where to route it. So by taking over provisioning the landline for voice traffic or data traffic, we're saying route that to the operator system.
Richard Moot: I see. And so does this require any kind of physical component or is this actually something that's like they just, it's done within at the carrier level?
Binh Ly: It's all at the carrier level.
Richard Moot: I see, okay.
Binh Ly: Yeah, so to actually utilize this capability, you just need authorization from the business that owns the landline. And so they just signed their name on a letter of authorization and we submit that to the carriers and then a few hours later, traffic starts flowing through. So that's one of the moments of delight for the customer is that they didn't realize this was happening. They signed up and they started getting traffic coming in and they're like, I didn't tell anyone we can do this. So I'm like, it's already happening all day every day and now you're getting access to it.
Richard Moot: So what you're saying there is have some businesses signed up for this and suddenly without even prompting of people are getting text messages and didn't realize that people were texting them this whole time? Yes. Wow.
Binh Ly: Yes
Richard Moot: Wow
Binh Ly: So a lot of missed business happens this way. We just saw, we signed up a window tinting business without telling any of their customers. They're getting requests, can I get a quote on this tint? If they didn't ha...Beyond the Network: Unlocking the Power of Programmable Traffic with NgrokSquare Developer2025-04-21 | Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard, head of developer relations here at Square, and today I'm joined by Peter from Ngrok. Peter, thank you so much for being with us here today. I'd love for you to just give us a little bit about yourself, a little bit about Ngrok, and let's kick things off.
Peter Shafton: Sure, hey, thanks Richard. Thanks for having me. So my name's Peter Shafton. I'm the CTO of Ngrok. I've been with the company for a little over three years, and I actually learned about Ngrok way back from when I was at Twilio about 13 years ago because the founder of Ngrok, Alan Shreve, was an engineer on a team there that I was running at Twilio. So I first started the voice and messaging parts of Twilio, that was actually the beginnings of Ngrok. But I've been sort of bouncing around Silicon Valley for a lot longer than that. A bunch of companies you all have heard of, probably Cisco and Yahoo, those who are old enough, SGI, and then a bunch of little startups that people maybe didn't hear of as much. But yeah, that is my past. So I'm a developer at heart, an engineer at heart, and then somehow ended up doing architecture and running technology.
Richard Moot: I feel like they always trick us and lure us into this in some way. I mean, it's very alluring, but then eventually you're just like, wait, what happened? I'm now the CTO of a company.
Peter Shafton: That's right. As long as they don't take away the keyboard, I can still type code there. I'm happy.
Richard Moot: Do you still get to occasionally write some code for things or do you find the time for it?
Peter Shafton: I do. I do. I do it badly, and most of my engineers hopefully don't let me do that. I end up in the data space more than anything or through SQL or the data warehouse and data lake areas, but at times I'll write some low level code and networking code and things like that.
Richard Moot: I mean, you got to find the time for it. It is kind of invigorating, but at the same time, I would agree that outside of Dev Rel, I am less inclined to build stuff that's going to be relied on in production, and I'm more inclined on building, here's how to do this particular thing, or here's a little script for pulling some data together so that we can make sense of stuff.
Peter Shafton: Yeah, I think most of us got into this because we loved writing code. I think if you'd asked me, I was a young kid, an Apple++, and I didn't realize this was a career. I just thought it was a really cool hobby to have, and then the thought that somebody would pay me to do it, and so this is the piece that got us excited. If you left most of us alone, we would still be writing code. It's just nicer when you're doing it at scale and allowing other people to see what you built versus,
Richard Moot: Yeah, no, I mean I think that it's really well put. I mean, most of the time I'd build tiny little automations in my house for like, oh, now it's much easier that when I want to go to bed, it turns all my lights off at one time instead of just me having to go through all of them. But now it's like now I can solve problems for thousands of people, millions people.
Peter Shafton: Oh yeah.
Richard Moot: So you used Ngrok a long time ago before you actually even joined the company. I'm curious, what was it when you first used, well, two things I kind of want to answer. For anyone who's maybe not familiar, we can give a quick little explanation of what Ngrok is and then what was it like when you first used Ngrok that made you fall in love with it, or I don't know if you'd call it love, but I mean I felt like I fell in love with it when I first used it.
Peter Shafton: No, it's a good story. It's a good story. Yeah. So there was an engineer by the name of Jeff Program. He was one of the early engineers at Twilio at the time. He had come from NASA and he built a tool called Local Tunnel, and he built it for a very specific purpose. So Ngrok basically fit into the webhook infrastructure that was Twilio. So the early days of Twilio, it's still true today is all powered by webhooks, which effectively means you get an inbound phone call, you get inbound text messages, you want to respond to that and control the programmability. You had to respond with XML, with twiML at the time to an inbound web request because that looked very much like how the internet worked. They figured people were writing PHP scripts or Python code for a website. They were used to getting a form post and responding, they thought, you can just reuse that infrastructure. It just happens. It's a telephone that's calling you instead of a browser client making the request, which made a lot of sense because that was what the developers were doing and it was easy to build on.
The challenge was if you're inside Twilio and you're building the product and you need to be able to test it or even iterate on what you're doing, a very slow loop is I build a thing...Codename Goose - Your Next Open Source AI AgentSquare Developer2025-04-14 | Richard Moot: Hello and welcome to another episode of the Square Developer Podcast. I'm your host, Richard Moot, head of developer relations here at Square. And today I'm joined by my fellow developer relations engineer, Rizel, who's over working on Block Open Source. Hi Rizel, welcome to the podcast.
Rizel Scarlett: Hey, Richard. Thanks for having me. And I know it's so cool. We're like coworkers, but on different teams
Richard Moot: And you get to work on some of the, I'll admit I'm a little bit jealous. You get to work on some of the cool open source stuff, but I still get to poke around in there occasionally. But today we wanted to talk about one of our most recent releases is Goose, and I would like you to do the honors of, give us the quick pitch. What is Goose?
Rizel Scarlett: Goose is an on machine AI agent and it's open source. So when I say on machine, it's local. Unlike a lot of other AI tools that you use via the cloud, you have everything stored on your computer, private, you have control over the data, and you get to interact with different lms. You can choose whichever you want, whether it's GPT, sonnet, 3.5, whatever you prefer, you get to bring it.
Richard Moot: Awesome. And so I'm going to hopefully give a little bit more because I want to just kind of clarify for Square developers who might be coming in, they're like, they're just building other APIs, SDKs, trying to extend stuff for square sellers. So when we're talking about an agent, an agent, I always end up thinking the matrix, the agents and the matrix. And from what I understand, it's not too far off. You give it instructions and it will actually go and do things on your machine for you write two files, edit files, run commands. It's almost like doing things that a person could do on your computer for you.
Rizel Scarlett: Yes, exactly. That's a really good description. It doesn't just edit code for you. It can control your system. So I had it dimmed, the lights on my computer open different applications. You can really just automate anything even if you didn't know how to code.
Richard Moot: Yeah, I mean that's one of the things that I didn't even really think about when I first tried Goose. So one of the fun benefits of working here at Block is that I got to have fun with it before it actually went live. And one thing that I didn't really think about until I tried the desktop client and I forgot to allow the plug, there's two different ways you can interact with it. There's the CLI and the terminal, and then there's a desktop client, which I think right now works on Mac os.
Rizel Scarlett: Yes,
Richard Moot: I know there's big requests and to have it work in more than just Windows.
Rizel Scarlett: Yeah. Yeah. Right now, I mean we do have what I think is a working version of Windows, but the experience for the build time is not great. So we're still working through that.
Richard Moot: Yeah, well, having my own wrestling with working with the Windows sub Linux, I only really think of it as WSL. I've had so many headaches of trying to deal with networking and connecting and when do I need to switch to the power show versus a terminal, and it's all the reason I end up falling back to doing all of my development on my Mac.
Rizel Scarlett: Yeah. I haven't used the Windows computer since I was an IT support person. I don't even know what the new developments are now.
Richard Moot: Yeah, I mean I recently got burned by that where I didn't realize that in order to do certain virtualization stuff, you had to have a specific version of Windows, like some professional version, and then that enabled virtualization to run a VM of something interesting.
I think since then they've baked in the Windows sub Linux thing, which is basically just running Ubuntu in a virtualization for you. But that was an eyeopener, but thankfully Microsoft's working on fixing these things, but we digress. So coming back to Goose and what is it that most people have that you've sort of seen from the community as they've been starting to try it out and use Goose?
Rizel Scarlett: Yeah, I mean I just see people, well, a lot of it is mainly developers. That's the larger side of just using it to automate a lot of the tasks that they are doing. Maybe setting up, what am I trying to say, the boilerplate for their code or just sometimes other different things. I see people wanting to build local models and just in general or doing things with their kids, but I've also seen people doing silly experiments. This is where I find a lot of fun where people are having Goose talk to Goose or having a team of different, I guess geese, a team of agents and they're basically running a whole bunch of stuff. So they had one Goose be the PM and it was instructing all the engineer agents to perform different tasks. So it's a varied amount of things, but a lot of people are just trying to make their lives easier and have Goose do the mundane task in the backgro...Lessons in Leadership, Delegation, and Team GrowthSquare Developer2025-04-07 | Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard. I am the lead for Developer Relations here at Square. Today I'm joined by Dina Spitzer, who is an engineering manager at Square, has been with the company for coming up on 11 years now, has seen a lot of changes over time. Dina, I'd love for you to just give us a little bit about you. What did you do before you joined Square, and then let's talk a little bit about your journey as you've been here.
Dina Spitzer: We can start back in 2010. So 2010, I graduated with my degree in computer science. Was really interested in the startup world in the Bay Area, and so kind of always knew that I wanted to go from Champaign, Illinois, glamorous Champaign, Illinois to San Francisco. And so I found a startup willing to relocate me out to the Bay Area, joined them, was super excited. And then I saw firsthand how chaotic startups could be and how for a while, every single year I was shopping around for a new job. Either I was laid off or was about to get laid off or the company was kind of flatlining. And so when I joined Square back in 2013, they were my very large stable company and I think we were at about 600 people when I joined. So still pretty small. Pretty small. Different world.
And yeah, I've been on three teams at Square. First team was around building internal tooling for risk management. Second team was the team management team. And so I got the opportunity to work on the Labor API, which is one of our public APIs on that team. And then I kind of got pulled into this world of APIs and I'm like, oh, there's a lot of improvements I want to make with our Square developer platform. And so after building Labor API, I moved over to the developer platform to one of the infrastructure teams to help actually improve the platform for internal developers to be able to build APIs at Square.
Richard Moot: And that's basically why I joined. I mean I think it was like Carl Perry who almost seven years ago and sort of convinced me with joining this team because it was very much, at least the way that it was pitched was it's a little startup within a larger company. And so it was very exciting, lots of new things being built, trying to figure out a lot of things like taking an existing product and how do we create APIs for it. And the team that you were part of is very critical to making that possible, building out the framework that was going to allow people to be able to expose the different parts of the Square point of sale system to transform into APIs and allow people to build on top of it. In that time, so you joined as a software engineer and then you evolved over time to being a lead within your team, becoming an expert in what it is that you were working on. And then more recently in the past couple of years, you transitioned to an engineering manager. So I'd love to chat a little bit more what the evolution has been and how at what point it felt like this felt like more of the same and then the point where it goes, okay, this is totally different.
Dina Spitzer: Yeah, sure. Great question. So I joined the team that I'm currently managing, I think five or six years ago as an IC, individual contributor software engineer. Just joined wanting to make the world a better place. And then I had a vision, had a drive, really studied our platform from the ground up. And I guess I can't say specifics about our internal tooling or internal infrastructure, but let's see, I identified some improvements I wanted to make to our internal architecture, internal infrastructure, got the team on board and we really started building in that direction. And then a little over two years ago, my manager departed the company and literally overnight asked, Hey, do you want my job? You have 24 hours to decide.
Richard Moot: Oh my gosh
Dina Spitzer: And I'd always been like, it was kind of crazy and I had just had a baby too. I'd been back for two months after coming back from maternity leave and I'm still catching up and I'm like, okay, let's do this. Let's just try out this whole engineering manager thing. Never looked back and it's been an adventure. Every day is a different adventure. It's a fun job. Yeah.
Richard Moot: Yeah. I mean, one thing that is, I similarly had gone through that transition from being an IC to being a manager. Granted, I know that I have had a very different role. I don't do traditional software engineering. It's a blend of things. But one thing that really stuck with me in that transition of IC to EM or management is I remember something that Carl Perry said to me before he had left when I was really thinking about whether or not to go into management is the difference between leadership and management. And that it's very easy for us to start to believe that in order to be a leader, you need to be a manager. And I think it's a very common misconception that just because somebody's a manager doesn't necessarily mean that they...Building a Closed-Loop WalletSquare Developer2025-03-31 | Richard Moot: Welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of developer relations at Square, and today I'm joined by Sophia Goldberg, who is the co-founder and CEO of Ansa. Sophia, would you be so kind as to give us a little intro about yourself and Ansa to let all of our listeners learn a little bit more about what it is that Ansa is and about you?
Sophia Goldberg: Happy to, and thanks for having me, Richard. So I'm the, like Richard said, the co-founder CEO of Ansa. I've spent the better part of the last decade building in payments. So I was at a company called Adyen across commercial and product roles. I also wrote the book, the Field Guide to Global Payments to help anyone learn payments a bit better. And here at Ansa we're a stored value wallet as a service or closed loop payments infrastructure platform to let any brand or platform launch customer balances. So that can look like the Starbucks in app payment experience that can also look like the backend of transportation systems, microtransactions for gaming and everything and the like, but especially we've been building the last few years in the food and bev and retail space.
Richard Moot: Very cool. And so you've built a lot of your integrations on Square and built a lot of this stuff for square sellers, but one thing I want to dig into with that is maybe tell us more about what is a closed loop wallet?
Sophia Goldberg: Yeah, it's a niche part of payments infrastructure and the payments ecosystem, but a really important one. And so closed loop really just means where funds can be spent and so a wallet like the Starbucks wallet say, or for some of our brands that are on Square that we've built for closed loop means the customer adds prepaid funds. The brand can fund that wallet with incentives and those funds in that balance can only be spent with that brand. And so in turn, that helps drive retention frequency, really stickiness, but also on the brand side reduces cost of payments, drives cash flow, and can kind of become this really virtuous cycle of retention, loyalty and customer lifetime value.
Richard Moot: Yeah, that makes a lot of sense. I mean one of the things that I know for particularly say coffee shops is you have these low ticket receipts and so it's actually in terms of percentage of fees that you're incurring on each sale is a little bit higher when looking at it marginally. So I'm guessing this helps mitigate that in many ways because you can then preload with these things and you're not incurring this on every single sale that coffee shops making.
Sophia Goldberg: Exactly. And so for brands that have high frequency and lower average tickets, we call them Holt Merchants, HULT habitual use low transaction Value, which coffee shops or bakeries are a great example of if you have a $4 latte, which unfortunately in San Francisco I can't find a $4 latte anymore, that brand might effectively be paying up to 10% in fees because the fixed fees of every payment really add up. You're paying probably 20 to 50 cents no matter how large of a brand you are. And so by having a customer prepay into a balance and say, add $25 to spend over five coffees over the course of a month, that means you're only hitting those fees on that first time. You have the benefit of that float in the meantime. And you're also guaranteeing that I'm going to come back four more times, enjoy my coffee, and you're going to be saving about a dollar just on that one customer that month.
Richard Moot: And so I'm curious, you've been in the payments space for a while now. What kind of really sparked that motivation towards building onset and building the solution?
Sophia Goldberg: It started to come up earlier in the pandemic when I was seeing more and more different types of commerce trying to catch up and meet us where we were all stuck inside our homes and apartments and it kind of tapped into an observation I'd been having that commerce and payments have continued to diverge, especially in the US there's so many more different types of brands, merchants, customer experiences, we're using our phones even more, even in-store payments have an e-commerce experience or element whether you're maybe at say a kiosk or on your mobile phone. So all of the lines are blurring and I saw time and time again merchants not being able to actually support the customer experience they wanted because payments was often kind of the stick in the mud for them of what they could innovate and build and launch. And I'm a bit of a purist.
I really love payments and I really love that our role is commerce enablement and that just didn't seem to make a lot of sense. And so actually in the early days we thought this was going to be a creator economy payment platform use case to enable online micro transactions, so think busking in the subway, but how you do that digitally, which is growing and happening all over the place and we couldn't find an infrastru...Scaling a Pop-Up Business to 120 FranchisesSquare Developer2025-03-24 | Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, and today I'm joined by Rhea Lana. I want to thank you all for being here today. I really, really appreciate you taking the time. If you wouldn't mind going ahead and giving quick little intros to tell us who you all are.
Rhea Lana: Hi, Richard. I'm Rhea Lana and I'm the founder and also the current CEO.
Erin Franklin: I am Erin Franklin. I am the CFO for Rhea Lana's, and I am also a franchise owner.
Dave: And I'm Dave. I help Rhea Lana with technology.
Richard Moot: Well, thank you so much. Rhea Lana, would you be so kind, tell us the story about what is Rhea Lana, give us the story of how this all started and bring us if possible to where we are today.
Rhea Lana: Sure. Well, we host children's consignment events, and so families bring their gently used children's things and we sell them for them. And so it started when I was a stay-at-home mom actually in the early nineties. We had made a move from the corporate world and Dave was doing nonprofit work. And so I was a stay-at-home mom on a really tight budget. I loved cute kid’s clothes, but it was just hard to find good deals in a really high quality atmosphere. So the goal then, Richard, was not to build a business. I really was just doing this little thing for my friends. And so I invited moms to, and we did our first sale in my little living room. We moved the furniture out of the living room into our bedroom, and we had three racks of clothes and 11 consignors. A consignor is a mom who's selling her kids things. And so that was our very first sale in 1997. So that's how it started.
Richard Moot: After the starting of that, what made you want to turn this into a full blown business?
Rhea Lana: Well, after that very first sale, Dave actually is the one that said, Rhea Lana, we should computerize this. Well, back in the early nineties, stay-at-home moms didn't have computers in there. I didn't even know a mom who had a computer in their house, but we did. We computerized it and we said we had barcodes. And the interesting thing is that families just kept asking me to do it again and again and again. And so the model is just two times a year. And so for those first several years, we would have these little sales in my house and they would take over another room of the house and my daughter's room and the kitchen and the garage. And then finally we moved out of our house and we began to hold these events in locations around our little town in central Arkansas. And then we had families that were driving in from Little Rock, Arkansas, which is about an hour away. And I began to realize families love this, they appreciate it. It's helping them not only be able to buy high quality clothes, but sell things their families didn't need anymore. And it gradually was making a profit more and more. And so we began to realize, oh, this is something that could be a business.
Richard Moot: That's awesome. And so where are we today with the size of Rhea Lana?
Rhea Lana: Well, in, let's see, it was about 2008, I think. That's right. We decided we would franchise and we still were on a very limited budget. And so we knew that if we tried, it didn't have much to lose. We couldn't risk a lot is what I was going to say. We didn't have the money to hire some big fancy firm to help us, some consulting agency. We just thought, well, we'll just franchise it. I actually read the book Franchising for Dummies. That's not a joke. I did. And while my kids were swimming at the pool, I would check the things off and do the things. And thankfully I had a friend who was a really smart tax attorney, and so he helped me put our contracts together and then we just decided to see if anybody would buy a franchise. And so that's how we started our franchising company. And so today we have about 120 locations in about 26 states across the country, and we've served, now millions of families. And our heart is we love serving families and we love just adding value to lives to families across the country.
Richard Moot: Wow, that's awesome. And so to hopefully give also how this all works, so you have 120 franchisees or franchises all throughout the United States, and this is an event based thing, right? There's two annual events. Tell me a little bit about how these events get set up and how big are they?
Rhea Lana: Well, I'll start and then I'll let Erin share because she owns one of our early franchises, and I still own and operate our franchise in central Arkansas. But you're right, the model is that we hold semi-annual events. So we just do 'em twice a year. And when the franchisees start, they're like a baby, but they grow into these huge sales. And so we will fill up large like a Walmart or larger, and we will have several thousand families bring their things, but we just set it up, we take items in for about a week, and then we sell items for about a week. And so it's kind of...Creating Payment Solutions for Everyday NeedsSquare Developer2025-03-17 | 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?
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, and then as 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 make, it's really meeting them where they are and with something that they're familiar with.
Ryan May: Yeah, I agree. Micro 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 tools like the Google Suite, which has some handicap, 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 from this originally come from?
Ryan May: Yeah, I mean it as actually my co-founder real world situation, it was during COD, 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 and if you have any allergies, what your food preference is, and ask for your t-shirt size. And she was like, why can't a Google form also just ask for $20? Because it became a nightmare. She had to get, some people were paying her with e-transfer, 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 goes 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 the 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, and 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 Micro seller space that we used to see initially with Square was y...Understanding the current state and near future of GraphQLSquare Developer2025-03-10 | Richard Moot: Hello and welcome to the Square Developer Podcast. I'm your host, Richard Moot, head of Developer Relations at Square, and today I'm joined with Alex Hancock and Watson from Apollo. Feel free to just go ahead and give us a quick little intro. Tell us about yourselves, what is it that you work on? And let's start with Alex.
Alex Hancock: Sure. Thanks for having me. I'm really excited to join this chat and talk with you guys today about all things GraphQL. I'm a Software Engineer here at Block. I've worked at Block for eight and a half years, and I most recently spent four years working on the GraphQL platform at Block.
Michael Watson: So my name's Michael Watson, I'm head of Dev Rel at Apollo. I've been there for about seven years now, and I really just work on GraphQL projects and kind of everything GraphQL. So I'm really excited here to talk more about GraphQL because I have a big passion and I'm obsessed with GraphQL, so this is fun.
Richard Moot: Awesome. I'm so glad to have you both here because we started on GraphQL here at, well, it was called Square at the time, but at Block for quite a while. It's been over five years I think. I mean, I feel like Alex could maybe keep me a little bit honest here. I just remember sitting in a round table with folks from Apollo and Strava and a bunch of others where we're just trying to figure out how should we build this and move forward. And so yeah, it's used pretty extensively here in some ways that we can talk about some ways that we can't talk about. But yeah, I think one thing I'd just like to kick things off with is talking about public GraphQL APIs and growing the adoption of those. I think that both of you have interesting ways of assessing that and looking at that. So I mean, either one of you want to tell us a little bit about public GraphQL APIs.
Michael Watson: Yeah, GraphQL has been around for a long time and I think public GraphQL APIs is something that's been on the rise. There was a lot of early adopters, I think of Shopify, GitHub's V4 GraphQL API, and the thing that I really love about it, if you look at the world before GraphQL APIs in the public space, you had your REST APIs, let's say even Square’s documentation of their REST API. There's a lot of great information in there, but as a developer that's coming to maybe a developer portal starting up with that API, they really have to start understanding of what are the domain entities I need to get into? And then there's always the orchestration problem like, okay, I got this one thing, now I need to make a second API call to go get this other thing. And that's kind of some of the magic that GraphQL provides is as a developer, I'm no longer thinking of these different endpoints that I'm getting and how I'm orchestrating them together, although that provides a lot of flexibility, but really sometimes I just want to add a couple extra fields into the request I'm making and just get that information and I don't have to think about what are the details.
And the magic sauce that I've seen in public Graph APIs that's really successful is this magic button that you click into the docs and it just logs you into that thing and then you could just start exploring and running GraphQL operations and seeing that right away instead of downloading a Postman collection. So I'm a big fan of that experience for developers just to explore to get up and building faster.
Richard Moot: Yeah, I couldn't agree more. I mean, one of the things that I work a lot on our REST APIs and I've been doing that for quite a while. One thing that always feels like a huge unlock for GraphQL over REST, not like we have to pit them against each other, but REST is really great about understanding the semantics of what are resources, what a resource might be doing given certain things. But the biggest missing piece that GraphQL does really well on is giving you the relationship between these entities and these resources. And it's just completely evident as you start navigating it. Like, oh, an order works with a customer or works with a payment and works with items because I see this directly in here. Instead of having to go and like, okay, I see the resource, now I have to dig through all the docs to figure out what do I use this with? So yeah, it's very, very great to see in that way.
Alex Hancock: Yeah, I would add I agree with all of that. I would add I think the most useful parts of GraphQL to me when thinking about public APIs are some of the most basic features of GraphQL, like field selection, just basic solving the basic problems of either under or over fetching of data depending on the client's needs. I think in the era of public APIs before GraphQL, you saw a lot of times some of those janky kind of custom built or half-baked ideas of adding field lists or something like that to REST API. And I think that how prevalent those were in public APIs speaks to the need for customization at the public API...Breaking Down Doors Payments: How DH Pace does Field PaymentsSquare Developer2025-03-04 | 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 in 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, dock doors, if you walk through it, 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 that 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 case is residential service. You have a garage door and 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's 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, hey, 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 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 ...Engineering Enterprise-Grade Payments that Scale GloballySquare Developer2025-02-28 | Richard Moot: 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 Adam and Cesar from MonStar Lab. Can you both give us a quick intro and tell us a little bit about yourselves and MonStar Lab?
Adam Mack: Thanks so much for having us, Richard. Really appreciate it. My name's Adam Mack and I am the director of Technical Product Management here at MonStar Lab in North America.
Cesar Aguilar: My name is Cesar Aguilar and I'm an engineer director here at Monster Lab based on New York.
Adam Mack: MonStar Lab is a New York and Tokyo based technology partner, and we have a staff of over 800 engineers, designers, and product managers all around the globe helping our clients in all manner or different industries to solve complex technology and business challenges. And what we end up doing at the end of the day is building human-centered software that delivers results for our clients. That covers a huge range of activities. We build consumer apps and consumer app experiences. We help design process automation and new operational workflows for different businesses. We help educate brands and internal teams about responsible use of ai and we help technology teams select the right vendors and partners to work with. At the end of the day, all of it comes down to overcoming complex technical challenges, but without ever forgetting that there's a human end user at the other end of the experience. So we try to ensure that we're balancing technology choices and making cool stuff with always doing what's best for our users. And part of that is a huge focus on payments and payment integrations. We recognize payments as one of the foundational drivers of a good customer experience in a lot of cases, and it's obviously a core driver for platform businesses all around the world. So it's a little snapshot of what Monster Lab does.
Richard Moot: You've been building and integrating stuff on Square for quite a while. I'd love for you both to just talk a little bit about one of the first big integrations that you've built with Square.
Adam Mack: Yeah, so we have a long history with Square, going back to very, I guess you would call them simple payment integrations. Many, many years ago, going back to the beginning of Square's, APIs and SDKs, we had a long working relationship with Shake Shack and we helped to build out the majority of their online ordering infrastructure, including their consumer ordering apps for iOS and Android web ordering. And in 2017 they approached us with this interesting challenge of let's take the really great experience that we've been offering in our consumer mobile apps that really polished ordering brand first experience, and let's bring that to a new form factor with kiosks. And the destination was going to be a sort of, I guess you could call it an experimental digital first location, starting to experiment with different form factors for the brand. So we were charged with helping to bridge this user experience that we built for iOS and Android into a new form factor and a huge part of that, a huge challenge aspect of that was integrating Cart present payment, which was a new challenge for the brand. So we looked at so many different providers to handle our card, present payments for the Shake Shack kiosk and Square ended up being the partner that we worked with and Square helped us and helped our engineering team to really rapidly prototype design and prototype a solution that met all of the user needs, met all of the security needs, met all of the operational and business needs that Shake Shack was putting in front of us and doing it incredibly quickly.
Richard Moot: So one of the things I've always been curious about when trying to build for these in-person type experiences compared to say, online, mobile, web, what were some of the more interesting things that people might not think about when building that in-person type experience? Because I remember that app does a really great job of walking you through a checkout flow but also displaying certain things where it feels very different than if you're just sitting in front of a person and just saying, oh, I'm just going to start reading off of this menu. You have a little bit more of a guided experience on this. So I'm just curious, what are the things that you'd say were the most interesting problems to solve or things that you wouldn't really consider compared to doing an e-commerce type build?
Adam Mack: Sure. So what's really interesting about kiosks is in a lot of cases they are designed to alleviate the burden on operational labor or increased throughput in a lot of cases. For Shake Shack, that was absolutely an operational goal. I think everyone who has spent any time in New York and knows the brand, knows the long curling line around Madison Park for the OG location, so that was line busting is not quite the right term, but expediting the c...Episode Zero – The Square Developer PodcastSquare Developer2025-02-28 | Adam Stacoviak: Well friends, we're here episode zero of the Square Dev Podcast. My name is Adams Stacoviak and I run Change Log, and I'm here with Richard Moot, head of Dev Rel for Square. Richard, how are you?
Richard Moot: I'm good. I'm so glad that you decided to help us out here in getting this episode zero of the Square Developer Podcast, getting everybody introduced to what it is that we're trying to do here.
Adam Stacoviak: Yeah, I love the platform. I love working with you guys. Amazing team, big fan, many, many years, big fan. And I'm even excited about the podcast, believe it or not, and behind the scenes we're helping you produce it, helping you with some of the editorial processes and just making an amazing podcast, which is really, really hard. As you may know, Richard, it's not easy to deliver a world-class podcast, but here we are. We're doing it.
Richard Moot: Well. I mean, when we thought that we wanted to do a podcast, there's nobody else that we wanted to partner with. I mean, you convinced us in all the years that we've been chatting with you, listening to the podcasts, definitely inspired to be able to come here and work with you and then ultimately tell the stories that we want to be able to tell, to get developers excited about our platform, understand what's possible, and really just showcase all the different use cases that people can have when it comes to Square and everything that makes it great to build on this platform.
Adam Stacoviak: Yeah, I think even in Episode Zero should be more common for new podcasts because I feel like if you just start launching shows somewhere in there, you have to explain who you are, what you do, why you care, what they can expect. There's some sort of promise that a podcast delivers, and that's my hope today was just to sit down with you and talk through what is this podcast going to be about? Who will you feature? Where will it live on the internet? Do you even know these questions yet? I know as you begin something new, there's things that you iterate towards. You don't always have all the details figured out, so what can we answer about who you'll feature and what this podcast will be about?
Richard Moot: I really want people to understand why they want to listen to this podcast, what they're going to be tuning into. We're really going to showcase some of our largest developers, some of our smaller developers. We have one person who actually won one of our hackathons, Bihn Ly, who builds the Operator app. It's a very interesting use case, allows SMS texting from landlines. It's something that has become more common, but I don't think we all really think about all too much.
And the interesting way is that this can make a business run better, especially if you're a solo business owner and the phone's ringing, but you're working with a client. They have ways of solving how to get business retention and get in touch with folks. And then we also talk to a different hackathon, one of ours payable with Ryan May, and they have a really interesting use case of integrating with Google Cloud and Google Business Suite and allowing you to just take a payment from a Google form.
It's so simple, but so useful and powerful because a lot of people use Google Suite for small businesses for doing their email and all that management. Sometimes they're just like, Hey, I want to be able to collect some info at an event and then have them pay for it right then and there. And it all started from really small things where you just had a group event where everybody was supposed to pay 20 bucks for a T-shirt and they had to fill out a form, and just thought, why can't we just take the payment at the end of the form? Why do we have to gather all this info and then later go, Hey, did you get the 20 bucks from each person? So it's just really simple. Things sometimes can be really powerful and unlock entire businesses.
Adam Stacoviak: So developer stories of course is always fun. Will you be featuring some of the inside of the developer podcast at Square, like the API the GraphQL stuff you're doing a lot of the innovation you're doing to enable merchants to be faster, better, stronger, all the things.
Richard Moot: Yeah, you're totally right. So we ended up also having the folks from Apollo GraphQL join us for the podcast and talk to one of the engineers that actually built our internal GraphQL endpoints that ultimately enabled us to publish the public version of the Square GraphQL Endpoints. And just really trying to talk about all the different things that we've leveraged of federated schemas, and we even start talking about the future of GraphQL as they're trying to solidify new standards and really trying to build a whole new community around this to get GraphQL to the same level of rest in terms of design standards
Adam Stacoviak: When it comes to the developers that should listen to this podcast, I know that I kind of have an idea who that might...Scavenger Hunt: The Great Code ChaseSquare Developer2025-01-23 | We’re excited to announce our latest scavenger hunt, The Great Code Chase! A pesky thief made off with a crucial bit of code, and we’re calling on all developers to help chase them down. Follow clues across Square Developer channels, and if you catch The Code Runner in time, you may win a limited-edition Square Developer LEGO Minifigure.
Here’s how to participate:
1. Create a Square Developer account or sign in. https://squ.re/codechase
4. Win a limited-edition Square Developer LEGO Minifigure of The Code Runner if you’re one of the first 500 participants to complete The Great Code Chase.
The first clue can be found in this video. Look around to see where to go next.
Good luck!
#SquareDeveloper #GreatCodeChase
No purchase necessary. Contest open to residents of the U.S. and Canada who have reached the legal age of majority in the participant's jurisdiction of residence at the time of entry. Contest begins on January 23, 2025 at 10 a.m. PST and ends on April 15, 2025 at 5 p.m. PST or until all prizes have been claimed. Winners will be chosen based on specific criteria and contacted via email. Limit one entry per person. Contest T&Cs here squareup.com/us/en/l/great-code-chase-rules.Square OAuth: User Management with Supabase AuthSquare Developer2025-01-16 | In this video, you'll learn how to simplify user management in your Square app! See how we simplified our Order Hoarder sample app's custom user management with Supabase's Auth framework. Supabase makes features like signup, JWTs, and secure token storage a breeze. By the end of this video, you will know how to:
- Replace manual auth code with a streamlined solution. - Integrate Square's OAuth API with Supabase Auth. - Safely store Square Access Tokens.
Chapters: 0:00 – Introduction 0:35 – Order Hoarder Review 0:53 – Introducing Supabase 2:01 – Configuring Supabase Credentials 2:43 – Refactoring the Login/Signup page 3:35 – Viewing User data in Supabase 4:05 – How to list Square Seller Location data 4:40 – How to securely store the Square Access tokens 5:49 – ConclusionHandle Fulfillments for Pickup and Shipment Orders | Square Orders APISquare Developer2025-01-09 | In this video, we take a deeper dive into the Square Orders API to understand order fulfillments. Fulfillments can be used to track the state of an order, and in this video you'll learn how to create an order with a fulfillment and how to update the fulfillment state. We'll do this for two real world examples that involve a pickup order and a shipment order.
Chapters: 0:00 – Introduction 0:27 – Orders API Resources 0:48 – Creating a Pickup Order 2:31 – Updating Fulfillment State 3:32 – Creating a Shipment Order 4:29 – Shipment Fulfillment States 4:41 – ConclusionIntroducing the Square Mobile Payments SDKSquare Developer2024-12-19 | The Square Mobile Payments SDK allows you to take in person payments directly within your mobile app by connecting with Square hardware like the Square Reader or Square Stand. In this video, we highlight some of the main features of the new Mobile Payments SDK and explain how to get started.
Chapters: 0:00 – Introduction 0:34 – How the SDK Works 0:44 – Payments and Orders API Integrations 1:12 – Offline Payments Support 1:38 – Reader Manager 1:51 – How to Get Started 2:09 – Helpful ResourcesGetting Started with the Square Orders APISquare Developer2024-10-22 | If you're new to the Square Orders API and want a solid foundation to get started, you’ve come to the right place! In this video, we’ll walk through the core elements of the Orders API, helping you understand how orders are structured and how they move through their lifecycle.
We’ll cover everything from the key fields within an Order object, like line items, taxes, discounts, and fulfillments, to understanding how orders are created, updated, and completed. By the end, you'll have a strong grasp of the basics, making it easier to start integrating the Orders API into your application.
Chapters: 0:00 – Introduction 0:27 – Key Elements of the Order Object 1:33 – Creating an Order with the Create Order Endpoint 2:04 – Updating an Order with the Update Order Endpoint 2:22 – How to Process a Payment for an Order 3:04 – Handling Orders with a Fulfillment 4:48 – Wrapping UpBuild an Order Ahead Menu with the Square Catalog APISquare Developer2024-10-16 | In this video, we dive into using Square's Catalog API to build a dynamic and sleek order-ahead app for restaurants. Whether you're creating an app for a burger joint or any food and beverage business, understanding how to structure and query a seller’s catalog is crucial.
We walk through the key Catalog object types—ITEMs, IMAGEs, CATEGORYs, and MODIFIERs—and show you how to organize and retrieve the necessary data to display menu items, customizations, and prices.
Watch as we break down common API calls, from querying menu categories to fetching modifier details for item customization. Perfect for developers who are new to Square's APIs or those looking to fine-tune their app with better menu structuring.
Chapters: 0:00 - Intro: Why the Catalog API is key for food and beverage apps 0:47 - Understanding how a restaurant menu is structured 2:06 - Querying menu items using the Search Catalog Objects endpoint 3:17 - Retrieving price data from item variations 4:05 - Fetching modifier data for customizations 5:10 - Conclusion: Tips for working with Square's seller dashboard and API explorer
🔗 Links: Catalog API docs: developer.squareup.com/docs/catalog-api/what-it-doesImplement Square OAuth | Order Hoarder Sample AppSquare Developer2024-10-10 | In this video, we'll demystify OAuth and show you how to implement it for your Square applications. We'll take a deep dive into an example app called Order Hoarder, a third-party order management system for Square Sellers, to walk you through the entire OAuth flow using PKCE. From setting up permissions, to constructing the authorization URL, to handling tokens and webhooks, you'll learn how to securely link your app to Square without headaches or security risks.
Chapters: 0:00 - Introduction to Square OAuth 0:27 - Overview of Order Hoarder App 2:08 - Constructing the Authorization URL 4:28 - Handling the Callback and Validating the OAuth Flow 6:42 - Storing and Encrypting Access Tokens in the Database 8:01 - Decrypting Tokens for API Requests 9:56 - Handling Square Deauthorization with Webhooks 12:31 - Order Hoarder Github Repo & Other Resources
🔗 Links: Order Hoarder Github repo: github.com/Square-Developers/order-hoarder OAuth API docs: developer.squareup.com/docs/oauth-api/overview Square Developer Discord: discord.com/invite/squaredevAutomate Marketing with Squares Customer Custom Attributes APISquare Developer2024-08-08 | Unlock the power of marketing automation with Square's Customer Custom Attributes API! In this developer-focused tutorial, we'll show you how to leverage customer custom attributes and customer segments to create personalized and targeted marketing campaigns for Square Sellers' customers. Learn to automate customer segmentation, enhance customer engagement, and drive sales using Square's powerful APIs.
In this video, you'll learn: The workflow of customer attributes and customer segments. How to create custom attribute definitions. Upserting and retrieving customer custom attributes. Building dynamic customer segments for targeted marketing. Practical use cases for marketing automation with Square APIs.
Chapters: 00:00 - Introduction to Marketing Automation with Square APIs 00:31 - Use Case: Personalized Emails Based on Favorite Drinks 00:49 - Workflow Overview: Custom Attributes & Segments for Marketing 01:09 - Understanding Customer Segments in Square 01:32 - Creating Custom Attribute Definitions via Square's API 02:13 - Setting Up Favorite Drink Options in Custom Attributes 03:12 - Assigning Favorite Drinks to Customers (Upsert Custom Attribute) 03:39 - Retrieving Customer Custom Attributes Data 03:56 - Automating Targeted Marketing with Customer Segments 04:23 - Creating Customer Segments in Square Seller Dashboard 05:10 - Updating Customer Attributes & Automatic Segment Updates 05:33 - Dynamic Customer Segmentation Based on Attributes 05:51 - Advanced Marketing Automation: Discounts & QR Codes 06:14 - Conclusion & Next Steps with Square APIs
Chapters: 0:00 - What are Terminal API actions? 0:40 - Confirmation screen action 0:50 - Signature capture action 1:00 - Data collection action 1:11 - Menu selection action 1:20 - QR code action 1:30 - Receipt action 1:39 - Ping action 1:51 - Save card action 2:00 - Link Terminal actions together
Resources: Terminal API actions docs: developer.squareup.com/docs/terminal-api/advanced-features#types-of-terminal-actionsSquare APIs ExplainedSquare Developer2024-07-23 | In this video, we take a high level look at the Square developer platform. We discuss the relationship between your application and a Square seller, and we also highlight some of the most foundational Square APIs and their capabilities. If you're new to the Square developer platform, or looking to develop a better sense of how the Square APIs work, this is the video for you!
Chapters: 0:00 - Introduction 0:22 - Relationship between Square developer and Square seller 1:00 - Connecting your app to a Square seller 1:29 - Foundational Square APIs 3:29 - Learning resources
Resources: OAuth Best Practices: youtube.com/watch?v=3gLqCJC6kLI Square docs: developer.squareup.com/docs Sample apps: github.com/square-developersSquare Unboxed 2024 | Opening keynoteSquare Developer2024-06-18 | On June 5 we gathered partners and Squares in Oakland, California, for our annual Square Unboxed event. Watch the morning’s keynote to get the latest on the Square platform, check out new product demos, hear how partners and sellers use Square in the hospitality industry, and catch a Q&A with Square CEO Jack Dorsey. The TL;DR: We had plenty of reasons to celebrate our work together — and to get excited about all the good things ahead.
Here’s a rundown of what we covered:
The state of the Square platform Partnerships and International Lead Vijay Vachani shared which trends and investment areas Square is focused on, as well as the progress we’ve made on partner programs over the last year.
What Square is made of Chief Product Officer Saumil Mehta detailed the features and products that set us apart.
Product launches and demos Square Partner Offers directory New referral partner bounty program Mobile Payments SDK (U.S.) Square App Marketplace: self-serve publishing App subscriptions
Now serving: Partner and seller success Panelists from CAMO Eats, 7shifts, and Square talk shop about the hospitality industry and how Square and its partners can enable more modern and efficient service for both front- and back-of-house operations.
Q&A with Jack Dorsey Jack answered the room’s top questions about Square initiatives for small businesses, our commitment to reliability, international growth, AI, and more.
Chapters 00:00:00 | The state of the Square platform 00:05:43 | What Square is made of 00:24:23 | Product launches and demos 00:43:52 | Now serving: Partner and seller success 01:05:45 | Q&A with Jack Dorsey 01:16:14 | Closing remarksWeb Payments SDK with React & Next.jsSquare Developer2024-05-22 | In this how to guide, we walk through the process of adding online payments to a Next.js application using the Square Web Payments SDK. This implementation utilizes all of the modern Next features such as the app router and server actions to create a seamless developer experience.
Chapters: 0:00 - Introduction 0:23 - Install React Square Web Payments SDK 0:40 - Create Frontend Payment Form 1:52 - Next.js Server Actions 2:18 - Create Server Action File 2:33 - Initialize Square Node.JS Client 3:07 - Process Payment with Server Action 3:44 - Connect Frontend and Backend 3:58 - Conclusion
Resources: Github Repository: github.com/Square-Developers/corner-blog-examples/tree/main/squaredev-next-online-payments-example React Square Web Payments SDK: react-square-payments.weareseeed.com/docsSubscriptions API TutorialSquare Developer2024-05-14 | In this tutorial, we take a look at the specific API calls that you need to make in order to create and manage subscription payments. We walk through the example of a meal kit delivery service so you can see exactly how this would be implemented in a real world application. By the end of this video, you will be able to implement a subscription payment flow in your own application.
Chapters: 0:00 - Introduction 0:20 - Create Subscription 0:49 - Create Subscription Plan Variation 1:39 - Create an Order Template 2:08 - Subscribe User by Creating Subscription 2:28 - Pause Subscription 3:04 - Get Subscription Status 3:25 - Conclusion
Chapters: 0:00 - Introduction 0:36 - How did Reference Health get started? 2:28 - Early learnings 3:27 - Technology choices 7:07 - Feedback and development process 8:51 - Expanding Reference Health 10:45 - Customer onboarding 11:47 - How would you do things differently? 13:05 - Biggest challenges building the application 15:11 - Flexibility of building on Tauri 16:51 - Why Tauri? 18:19 - Conclusion
Resources: Reference Health: https://reference.health/ Reference Health Developer Spotlight: developer.squareup.com/blog/developer-spotlight-reference-health Square Online Payments: developer.squareup.com/docs/online-payment-options Tauri: https://tauri.app/Building Mobile Apps with Square and Flutter #shortsSquare Developer2023-10-10 | Our conversation with the co-founders of Morel Technologies spans everything from insights into the restaurant industry to the experience of integrating Square into a Flutter app. Check out the full interview here: youtube.com/watch?v=jw5GfrPFQZM #softwareengineerBuilding Mobile Apps for Square Sellers | Square Dev Chats | Morel TechnologiesSquare Developer2023-10-10 | In this Square Dev Chat, we sit down with Marcus Twichel and Matt Blank, co-founders of Morel Technologies. Morel provides Square sellers with the ability to quickly and easily create their very own mobile app for their business. Our conversation with Marcus and Matt spans everything from insights into the restaurant industry to the experience of integrating Square into a Flutter app. We hope you enjoy!
Chapters: 0:00 - Introduction 0:42 - Morel’s average user 1:35 - How Morel got started 4:50 - Initial funding and acquiring the first customer 8:41 - Early learnings 11:19 - Working with the Catalog API 12:55 - Why Square? 19:27 - Technology choices 22:21 - Feedback and feature development process 27:02 - What would you do differently? 30:04 - Conclusion
Resources: Morel Technologies: https://app.morel.technology/ Square Catalog API: developer.squareup.com/docs/catalog-api/what-it-does Flutter plugin for In-App Payments SDK: developer.squareup.com/docs/in-app-payments-sdk/flutter Flutter plugin for Reader SDK: developer.squareup.com/docs/reader-sdk/flutterBuilding a Custom Kiosk App with Square #shortsSquare Developer2023-10-03 | We sat down with the founders of Gamsa.io to learn all about their experience building a restaurant kiosk app with Square APIs. Check out the full interview here: youtube.com/watch?v=fncIGgPd1vY #softwareengineerIntegrating Square with Restaurant Kiosks | Square Dev Chats | Gamsa.ioSquare Developer2023-09-25 | In this Square Dev Chat, we sit down with James Youn and Jiwon Kim, co-founders of Gamsa.io. James and Jiwon have built a custom kiosk app that integrates directly with Square in order to empower Square sellers in the QSR (Quick Service Restaurant) industry. Gamsa integrates with the Square catalog, terminal, and more to create a seamless experience for sellers looking for an automated way to service their customers. Our conversation with Gamsa touches topics of development phases, Square integrations, technology stacks, and so much more. We hope you enjoy!
Chapters: 0:00 - Introduction 0:57 - What is Gamsa? 1:49 - Acquiring the first customers 3:01 - Early learnings 4:01 - Important features 6:15 - Learning from customers and improving UX 8:27 - Technology choices 11:55 - Feedback and feature development process 12:43 - Text message notifications and other features 15:28 - Exploring the quick service restaurant industry 17:39 - Working with Square 21:04 - Terminal API vs Reader SDK 22:54 - Conclusion
A complex checkout can lead to confusion which, in turn, leads to abandoned carts. So for your contact info section, this means you only want to ask for what is absolutely necessary.
You can also reduce confusion by providing automatic formatting. So if you ask for a user’s phone number, instead of just displaying it as a string of ten digits, you can insert these dashes as they type in their number, making it easier for them to input and verify.
One way you can do that is with a function like this that checks the length of the phone number, and then adds the appropriate number of dashes.
You can then use an `input` event listener to run this format function every time there’s a keystroke.
This may sound like a small feature, but even small improvements to your checkout experience can have a huge impact.
#shorts #softwareengineer #webdevelopmentAutofill Shipping Info Section on Checkout #softwareengineer #shortsSquare Developer2023-08-23 | The secret to a great shipping info section is an autofill address input.
This feature can drastically reduce the amount of time your users spend inputting their address, which will help them to complete their checkout much quicker.
Great as this may be, this can be a fairly complicated feature to implement.
Don’t worry though, you don’t have to build this from scratch.
Instead you can reach for tools like the Google Maps Places API which has a service called Place Autocomplete that can help you achieve this exact effect.
And if you’re looking for a more out of the box solution, the Square Checkout API has you covered.
All you have to do is set “askForShippingAddress” to “true” when you create a payment link, and the autofill address input will be automatically added to your checkout page.
If you’d like to play around with this, you can give it a try, right now, in the API explorer.
One of the best ways to streamline your user’s checkout experience is by adding the option to pay with a digital wallet.
Digital wallets are services like Apple Pay, or Google Pay that securely store a user’s payment information in order to speed up their checkout process.
So you’ll want to make sure that you include the digital wallets options at the top of your checkout.
This way your users won’t waste time inputting information that they already have stored in their wallet.
You can add support for digital wallets by using the Square Web Payments SDK.
You can initialize Apple Pay by first building a payment request.
From there, you can tokenize and process the payment just as you would a credit card.
And you can see the code for supporting Google Pay is very similar, with the one exception that the googlePay object must be attached to a button.
For a deeper dive, go on and check out the digital wallets section of our docs, linked below.
#shorts #development #webdevelopment #ecommerceSquare Unboxed 2023: A Partner and Developer EventSquare Developer2023-07-10 | In case you missed it, Square Unboxed took place on June 8, 2023. Watch the recording and hear from a curated lineup of Squares, partner and developer community members, and sellers sharing their platform experiences. Plus, we announced new releases and feature updates along the way.
00:00:00 - The State of the Square Developer Platform 00:17:24 - The Future of AI at Square 00:37:24 - Block Strategy and Industry Trends 00:49:04 - Connecting Ecosystems 01:01:14 - Better Your Business: Seller and Partner Panel 01:27:05 - Closing RemarksSquare Unboxed 2023: A Partner and Developer EventSquare Developer2023-06-09 | Watch the Square Unboxed livestream here on June 8, 2023, at 10 a.m. PST. Don’t miss our curated lineup of Squares, partner and developer community members, and sellers sharing their platform experiences. Plus, we’ll announce new releases and feature updates along the way.
Custom attributes store properties or metadata that can be used to simplify integration and synchronization or enable new personalization workflows. You can use the Customer Custom Attributes API to define custom attributes that can be associated with customer profiles, such as Favorite Drink, Occupation, Last Check-In Date, and Entity ID. You can also use the API to retrieve and manage seller-defined custom fields.
Follow along to learn how to get started with the Customer Custom Attributes API.
0:00 - Intro to Custom Attributes API 0:38 - Creating a Custom Attribute Definition 1:24 - API and Endpoint Setup 1:54 - Configuring Custom Attributes 2:20 - Assigning Attributes to Customers 2:42 - Setting & Retrieving Attribute Values 3:33 - Conclusion & API Exploration
When building an OAuth integration, it's very important that you encrypt the access tokens you obtain before storing them. It'll help protect you and your app's users.
OAuth access tokens, refresh tokens, and the application secret all have privileged access (or the potential to get privileged access) to seller resources. You should use them in a secure environment and protect access to them following best practices.
In this example we'll show how to encrypt using Node JS, but each language has their own libraries for encrypting and the process should be roughly the same.
00:00:00 - Introduction 00:00:11 - Importance of Encrypting Access Tokens 00:00:35 - Node Crypto Library Functions Overview 00:00:57 - Importance of Protecting the Encryption Key 00:01:15 - Encrypting Tokens: The Create Cipher IV Function 00:01:47 - Encryption Process Details 00:02:08 - Completing the Encryption Process 00:02:29 - Returning the IV and Encrypted Token 00:02:49 - Decrypting Tokens: Overview 00:03:12 - Decrypting Tokens: Step-by-Step Process 00:03:33 - Practical Example: Encrypting a Token 00:03:53 - Output Demonstration: Encrypted Token 00:04:15 - Decrypting the Encrypted Token 00:04:39 - Conclusion and Reminder to Protect Encryption Keys
With the Square Cards API and Web Payments SDK, you can store customer card details to a customer to allow charging those card details in the future. This can simplify your payment processing and customer experiences since customers don’t need to keep entering their card details multiple times. Additionally, you can also store card details using a previously processed payment using Payments API along with Cards API.
00:00 - Introduction 00:11 - Storing a Card on File Overview 00:31 - Configuring Web Payments SDK 00:52 - Using the Cards API 01:18 - Making a Payment with Stored Card 01:38 - Setting Customer ID and Processing Payment 02:02 - Importance of Buyer's Permission for Storing Card 02:21 - Creating a Payment with Payments API 02:42 - Storing a Card Using a Previous Payment 03:13 - Final Reminders and Conclusion
Gift cards help bring in new customers and drive incremental sales for a seller’s business, so it is important to make sure that a seller’s website is able to support Square Gift Cards for completing purchases. In this tutorial, we’ll cover how to add Square Gift Cards to an existing payment form integration. The integration requires additional payment form code in your web frontend client and Square API calling code in your backend application.
For more information, please see our documentation on Square Gift Cards or reach out to us in our forums.
In this tutorial, we'll show you how to get started with implementing Gift Cards API.
The Gift Cards API provides endpoints for creating a gift card, retrieve gift card info, linking a customer to a gift card, and unlinking a customer from a gift card.
Square Developer Forums – developer.squareup.com/forums Square Developer Community – https://squ.re/slack Square Developer Twitter – twitter.com/squaredev Square Developer Blog – developer.squareup.com/blogSandbox 101: Locations APISquare Developer2022-09-22 | Locations represent the sources of orders and fulfillments for businesses. When a seller signs up to become a Square merchant, they provide core business profile information that describes their business.
In the Square API, some customer-related interactions (such as taking payments, issuing refunds, and managing inventory) must be attributed to a specific location in the API call. Your software should honor the seller’s existing locations, and might optionally create new locations for its own use.
In this tutorial, we show you the basics around using our Locations API, like creating a location, updating a location, and retrieving a location.
Square Developer Forums – developer.squareup.com/forums Square Developer Community – https://squ.re/slack Square Developer Twitter – twitter.com/squaredev Square Developer Blog – developer.squareup.com/blogSandbox 101: Checkout APISquare Developer2022-08-19 | Using the Checkout API is the simplest and fastest way to integrate Square to accept payments. With just an API call, you can create a Square-hosted checkout payment page. A simple API call allows an application get a URL to a Square-hosted checkout payment page for a buyer to pay for goods and services.
We cover 3 different ways you can create payment links using Checkout API, which are Quick Pay checkout, Subscription checkout, and Square Order checkout.
Square Developer Forums – developer.squareup.com/forums Square Developer Community – https://squ.re/slack Square Developer Twitter – twitter.com/squaredev Square Developer Blog – developer.squareup.com/blogSandbox 101: Bookings API Example AppSquare Developer2022-07-28 | The Bookings API lets you create applications for Square sellers and their customers to create and manage bookings. This sample web application integrates the Square Bookings API and showcases some of its functionality, including:
- Creating bookings - Updating bookings - Canceling bookings - Searching availabilities - Listing team member booking profiles - Retrieving a team member booking profile
In addition to using the Bookings API, the application demonstrates how to integrate the Bookings API with the following Square APIs:
- Calling the Catalog API to create and retrieve catalog objects of the appointments service type. - Calling the Customers API to create and retrieve customer profiles in the seller's Customer Directory. - Calling the Locations API to get information about the seller's business location used throughout the application. - Calling the Team API to retrieve the profile of a team member providing booked services in an appointment.
0:00 - Intro and Bookings API Overview 0:41 - App Onboarding and Setup 1:53 - Services and Employees Setup 2:40 - Sample App Walkthrough 3:05 - Booking Management 3:31 - App Environment and Files 4:23 - Service and Staff Selection 7:04 - Booking Completion 7:54 - Rescheduling and Canceling 9:22 - Summary and Closing Remarks
Square Developer Docs – developer.squareup.com/docs Square Developer Forums – developer.squareup.com/forums Square Developer Community – https://squ.re/slack Square Developer Twitter – twitter.com/squaredevSandbox 101: Implementing Cash App PaySquare Developer2022-07-14 | Cash App Pay lets customers seamlessly pay with their Cash App account, enabling a fast and familiar checkout experience using a mobile payment app. You can add Cash App Pay to your online checkout flow using Square Web Payments SDK.
In this tutorial, we cover how you can get Web Payments SDK set up to accept Cash App Pay using Web payments SDK. We also show the different flows that you'll see when paying with Cash App Pay.
Implementing Cash App Pay – https://squ.re/cash-app-pay-docs End to End Payments with Web Payments SDK – youtu.be/SymdOPCGvq4
Square Developer Docs – https://squ.re/dev-docs Square Developer Forums – https://squ.re/sq-dev-forums Square Developer Community – https://squ.re/slack Square Developer Twitter – twitter.com/squaredevMain Stage | Pretty Bird + Flash Order + SquareSquare Developer2022-06-09 | Check out how Flash Order used Square APIs and SDKs to integrate kiosks that helped create a seamless ordering experience for Pretty Bird's customers, staff, and owners.