Building a Closed-Loop Wallet

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 infrastructure platform to really easily build that on. And so started pulling its strings and realized there's a big there there and for many types of brands, but especially in the restaurant area, cost of payments is often their second highest cost as a business. And so any way that we can help realign unit economics but have technology that really works inside their ecosystem was kind of the gap we found and where we started to build and grow.

Richard Moot: So I'm curious even digging more granularly to day one, week one, month one, whatever it is, when you have this idea and you were first trying to test this out, give us a sense for how you got that zero to one moment and how did you start to grow from there?

Sophia Goldberg: Yeah, so we knew from early on our technology was going to be very API focused. And we also knew that we starting out, my co-founder JT and I were two people at a WeWork in San Francisco. And so the companies that implement APIs don't typically buy from companies that are two people. And so we started thinking about the very famous adage do things that don't scale. How can we help brands that our product can be useful for but maybe don't have the resources or infrastructure today to otherwise work with us? And so actually our first customer that went live is a square customer out of the East Bay who I mean phenomenal coffee, really awesome team, really great brand and really forward thinkers on experimenting. They care a lot about brand and their customers and their customer experience. And so we did the thing that didn't scale and we thought, okay, well if they would like to use our product and we would love to work with this team locally, what if we just do something crazy and build them and order a head app, which was not and isn't really our core business, but thanks to actually the Square Docs, we were able to build and order a head app that existed fully on top of their square stack.

And I don't even think we had to talk to your team until quite a ways into the project and the build and we were able to build it in a way that they didn't have additional lift or process because it lived alongside their entire ecosystem, which for them obviously is Square. And for us it meant we had this piece of software and this really great early design partner to be able to test and iterate with.

Richard Moot: That's great. And so I'm curious on the part, what part of that felt the most not scalable? Was it just that you're building this sort of bespoke app for one customer and then trying to figure out what you learned along the way?

Sophia Goldberg: It definitely was. The initial impetus was, or the concern was we don't want to be this turn into a dev shop, which I think every or at stage software company, there's a fine line between building custom for your design partners because you need them to have a reason to take a risk and the fine line of what are we building that's scalable and can be used by a dozen, a hundred other brands like them. And so that was kind of a constant push me, pull you, but what we ended up learning I think was so valuable because if we had had a first customer who owned their entire app and use our APIs and docs and just ask some questions, we wouldn't have the same understanding of what that stack looks like for a brand.

Those considerations are sometimes we call it, we can say it's really easy to integrate us, but we only know the iceberg above the water. We got such a great insight into what's below the water for a brand or a coffee brand of, I didn't know the acronym KDS kitchen display system and how all of those data elements flow and all of those learnings have compounded to help us grow with both other square brands or brands on Square, but also throughout the ecosystem and larger brands with more patchworked stacks.

Richard Moot: Yeah, no, I mean it makes so much sense. I can definitely vouch for, I mean granted, I know that I probably have a different perspective doing developer relations here. I spent the first year not knowing what QS R meant and I thought this was just some sort of FinTech term that I'm familiar with. It's in digging into a real business and sort of getting your hands dirty with them, you really start to see the things that they're actually concerned with. I know here at Square we're very much about trying to get out of a business's way. They don't want the payments to be slowing them down or being front and center for the customer interactions. They should fade into the background and allow them to just run their business and save them time. But one of the things that I think because you say order ahead and the most eyeopening thing that I've even found with people who are having an Order ahead farm when they're trying to manage Uber Eats, DoorDash, Postmates, and seeing the tablet farms that they used to have in the back where somebody's just sitting there press