 Hey, how's everyone doing today? Excellent, excellent. So my name is Jacques Vu. I'm the CTO and co-founder of Fat Merchant. I just wanted to thank Spree Lee for inviting us here. We're very passionate about the topic of partnerships. We consider them a great partner of ours, and ideal in many ways. And we want to talk about what makes a great partner, what are those things that you should expect from them. Hopefully you can take some lessons away from that. Great, and I'm Steve Carr from the Vice President of Strategy at Fat Merchant. Standing up here in front of this audience reminded me of a post that a friend, a business colleague of mine back in Atlanta made on LinkedIn last week, couple weeks ago, ranting about executives who get up at technical events that have never coded in their life. I'm happy to say that I have an illustrious coding career of basic on an Atari 800 in the early 80s. It kind of flamed out pretty quickly. But I've been in the payments industry almost my entire career, 20-plus years, mostly on the business, various business sides, operation sales, consulting, et cetera. But I'm not a tech guy. But if somebody has to play the role of executive and their coding experience at this event, I guess it's going to be me. We have a couple of quick slides about Fat Merchant. We really are conscious of not being the folks that come up and spend 20 minutes talking about themselves and their experience in the company. Plain and simply, and Justin alluded to it, we are a SaaS-based provider of payment processing services for SMBs. So you'll hear us use SMB. It's just an acronym for Smaller Medium Business. That is what we live and breathe. We have it from day one. So four years of experience, thousands of customers. And the long and short of what we sell for are the three main pain points that our industry as a whole has been pretty terrible at for 25 years, which is technology. Many of our competitors have been around for a lot longer than us. They're large, they have legacy systems. They don't really effectively help small businesses into the world they're in today of bridging card not present, card present, mobile, all those kind of things. So pretty clunky technology. We think we have a really good answer and solution for small businesses. Service, not a hallmark of our industry. Go down, walk down Main Street here and talk to 10 small businesses about their credit card processor. You will hear 53 different curse words and you'll get thrown out nine times. The 10th guy might talk to you. Our industry is terrible for service. So you'll hear us talk about things like net promoter score. Not many merchant service providers or payment processors ever talk about net promoter score, which is a fairly generally acceptable way of defining customer satisfaction. We're really proud of ours in an industry that runs negative, which means that you have far more people that detest you than like you or would ever refer you to somebody else. We run over 70, which puts us in kind of Apple, Tesla, Pearl Schwab type territory. And then lastly is pricing. So it's kind of ironic, Justin. You said you guys got away from subscription model and I don't know much about the early days of the history. We are one of the few payment processors that go to market with a subscription based pricing model and what that sells for is the pain that SMBs for years have felt around the way that our industry prices to them, which is intentionally confusing, complicated, kind of buried in arcane language as such. So we bring a very simple trade forward way to price. So technology, service, and price, not rocket science, but our industry has not been very good at those things. And those are all things that we really focus on. We're pretty proud of the recognition and awards we've received. I'm not going to talk about all this. Some of it I think maybe starts with our name. Fat Merchant is pretty interesting. When I started at the company six months ago, I told my 76-year-old mother I was working for a company called Fat Merchant. She very quickly said that the dumbest name I've ever heard. I said, we have nailed it then. No offense, mom. She won't ever see this video because she's not going to get online or wherever it's posted anyway. So we've done pretty well for ourselves. Like I said, we've been around for four years and pretty well received in the industry. So I thought it would just be worthy of taking a few minutes before we get into the heart of the topic to talk about the way we think of the market. And the market really, for this audience, we wanted to break into three pieces. This all comes from data that I've been a part of over the years with Bain and Accenture in various ways, not the end-all, be-all, but fairly credible sources on the market. So we'll talk a bit about the market, talk a bit about what does small business owners tell you they want when it comes to payments. They're actually very specific about what it is they want and what really matters to them. And then what is some of the research that we've seen say about why do developers and software men and women who are building an app or building a website or coding to this or coding to that, why do they care about payments? Why do they want to get into payments? A little bit on the market, just some data points. There are about 30 million small businesses in the United States. There are, by any estimation, between 10 and 30,000 providers of software that payments in some way, shape, or form is relevant to that software provider. I've never seen a great number. But let's just call it 10,000-plus. There are literally hundreds of payment processors, call them merchant service providers, payment processors, credit card processors, whatever you want to call it. There are literally hundreds of companies that do it in one way, shape, or form. And when you think about that whole ecosystem of hundreds of guys like us, thousands of software developers, tens of millions of potential customers, all of that folds into an industry where every year 25% of small businesses that accept cards make a choice to switch to somebody else. So something is not happening well in an industry where 25% make a choice to leave. For a point of comparison, think of another industry that we probably all touch as individual consumers, which is retail banking. So whether you're with a big bank or a credit union or somewhere in between, and that's not an industry really well known for amazing service, amazing technology, or a lot of different things, they run between 10% and 15% annual customer attrition. So our industry, pretty bad. When you actually talk to a small business owner and ask them what really matters to them, they're going to get a series of answers. But at the end of the day, when you ask them what is the most important thing to you in your world as it relates to payments, 40% say price, 25% say reliability, 20% say feature, 15% say service. So another way to kind of wrap all this up is 80% of small businesses just want the basics. They don't want to feel like they're getting screwed. They want to feel like they're getting decent customer service, and it has to work. The other 20% actually has more sophisticated needs in terms of use cases or channels or the way in which they accept payments. But it's just kind of, for me, it's always a good anchoring point that when I talk to customers or have gone on sales calls with salespeople over the years, you can just never forget when you're in front of a merchant, whether it's somebody that just has a website or a store or a combination, you can never forget that they're looking for the basics, eight out of 10 of them, the other two out of 10. Now this is small business, so we're not talking about Fortune 500 or Fortune 1,000 type users, but for the 30 million small businesses in America, this is what matters to them. And then kind of similarly on the developer side, when you look at research that asks developers what matters most to them, why are they even messing with payments? Again, you're going to get multiple answers, but if you force a developer or software provider to give you the number one reason they're in payments, 50% say it's to enable the product. They're building whatever they're building. They're building an app to help a yoga studio run its yoga studio. They're building an app to help a winery manage their wine club, as well as the tasting room, as well as their relationship with their party distributors. 50% of the software people that I've seen in the research are doing what they're doing with payments, not because they're amazingly interested in becoming experts in payments, but it's part of how they enable their product. 20% are doing it because they want to generate leads. 20% are doing it because they want to increase stickiness in 10%. Only 10% say that making money off payments is the number one reason. Now, this data is a couple of years old, three or four years old, so my guess is that 10% is a little bit higher. But again, just like small businesses, what they want out of payments is the basics. All the research I've seen, developers and software providers get involved with payments to enable their products. They're not trying to get rich off payments. They're not trying to use it as a way to take their business model in a different direction. It's to enable the product. So hopefully, useful context for the rest of this discussion with Jacques and I are going to tag team on. And we'll be a bit more to the heart of the topic, which was, I think the title was, payments partners more than just the API. I'm going to pass this back to Jacques. I got it right here. OK, there you go. Yeah, so here's some high level qualities that you would want to have in a partner, especially the one that you're integrating with that's offering some sort of API solution to you. But this isn't just for payments. You have all kinds of partnerships. And if you've been through the pain of investing in a partner, finding them, doing integrations, and then having to rip them out because they weren't performing for you or strategically aligned with you, then you kind of know the pain that I'm talking about. Choosing the right partner can really make or break your business in the long run. And so this was a topic that I was very passionate about. And it reminded me of an early memory that I had. This is a little bit of inspiration for me to talk about this. But it was on an integration call with a partner. We were very excited about joining forces with. We kind of had complimentary situation. So they had an API, which was awesome. I said, great. I'm on your website. We're on the call. Let's talk about this API. So they asked me for my email address. I said, no, no, no. Don't worry about it. I'm on your website. I don't tell me where to go for your API docs. And he said, well, I have to send it to you. It's an attachment. It's like attachment. OK. Well, F-U. Sorry. That's my name. I was spelling out my email address. Jacques Fu. So I got the documentation. And immediately, I'm reading it. It's a PDF, of course. I can't copy and paste anything. It's not formatted properly. It's soap gross. Some of you guys probably know what I'm talking about. And they dig a little deeper. And they're just doing some weird things with it. They've got XML, escaped inside XML, threw up in my mouth a little bit. That's bad, by the way. Got to brush your teeth. So if I had known, if that was something that, in retrospect, after everything I've learned about enabling partnerships and doing integrations, if I had known all the things I known at that time, I would have probably steered our owners in a different direction of how they wanted to achieve that partnership. So again, I just think it's very important. Some of these things are table stakes. But choosing what your partner does and how they align with you is absolutely critical. I can't say it enough. Testing is something that often falls by the way. So it's one of the first things I look at. So I know it was a joke, you test in production, right? But I have literally had a lot of partners that give me an API and don't give me any way to test it. I literally have to test it in production. So one of the first things I asked for, right? You have a sandbox. And then another thing is just how detailed is it, right? So do your docs allow you to connect to your sandbox, or is it just simulated response, right? And then how many of you have gotten weird error messages after you've gone live that you didn't see in tests, right? So being able to know what those error messages are, having a dictionary, those are things that you would expect from someone who really understands how to develop a solution, how to be a good partner. This one I think is really funny. You can actually find this. This is on GitHub, if you guys know Open Source Project. It says some guy comments, were you able to resolve the issue? Because the guy closed the ticket, and the guy says, no, I decided I don't care, right? I don't know if some of you had to work through ticketing systems to talk to your partners. But it's really interesting how the different paths that those conversations go down. Multiple lines of communication is key here, right? Not just having one system not hiding behind that ticketing system as a way of being able to resolve issues. Raise your hand if you were impacted by last year's March meltdown of Amazon that took down the internet. Yeah, it was like all of us, right? And then when you go onto the Amazon website, if you even knew that Amazon was the culprit, you look on their status page, because that was really, I guess, the main way that they communicated outages. And it said everything was up. Well, it turns out that S3 was down, but they were communicating the S3 status through a cached image. And so it was always green, even if it was down. So just an example of failure, right? You probably could have gone on Twitter, and you would have found out sooner than trying to contact Amazon to figure out what was going on. Another thing is just how those conversations happen once you do start them. So I'm married to a DBA. I can have a whole separate talk about that, but she was telling me how she called Microsoft the other day, and she was expiring this person's password. And it's like, but he's still able to log in using his old password. And they're like, well, if they log in on their mobile, then the expiration is ignored. And I was like, is that, no, that's the feature. That's how it was designed. It's not a bug. We're done, right? So yeah, just having some common sense, right? And it's one thing to say, we hear your feedback, we're gonna have our engineers take a look at it. It's another thing to just deny, deny, deny, right? So moving on. I won't talk too much about this, but actually, this is a positive for me. So once in a while, rarely, there are issues with all partnerships, all APIs. If you don't plan on downtime, you're not doing it right. And what I really love is, there was a little bit of downtime here, it was no big deal for us, but I really love was like, I knew a day later, I was gonna get this awesome report, right? And so kudos to Spreely for this one. I actually really enjoy opening up those postmortems. Not only do they just say, the service was, I mean, how many, you see the service is disrupted and they don't say anything, right? That's a common thing that you see. But not here, I mean, I open it up and I learn something every single time. I think of, what are the chain of events that cause that thing to happen? When did it start? When did it stop? How can I communicate that back to my customers? And honestly, I share those back to the team when I say, we don't even do this internally. Like I get more information when Spreely has an issue than internally when we have an issue. So this is awesome, right? So I really love those reports. I learn a lot. Transparency and communication is awesome. And so when you can get that from your partner, you've got gold. The other thing that is kind of a hard thing to gauge, but it's very important is when you, if you're a startup or if you're rapidly growing or maybe you've just been in business for a while and at some point you start to amass a larger infrastructure, a larger customer base, and you need different things than you needed when you were smaller. It's very important that to know that your partner is constantly evolving and that they're a little bit ahead of you, right? So if you're on your way to let's say moving up mid-market and serving more enterprise customers, then you're gonna wanna know that your partner has single sign-on and logging and some of those enterprise capabilities that you might not get right out of the box. And then you just basically wanna make sure your partner's gonna evolve with you. When new technologies come out, like the account updater as an example, you wanna know that your partner is gonna make it easy for you and now you can go back and say you have a value add for your customers just because your partner was able to develop that capability. And then the other thing is, I know some of you probably have economic terms that have an annual or semi-annual cycle to them and so you get that phone call and they wanna talk about, oh I see you guys, our contract is expiring. I like not having a conversation about that kind of thing. I'd rather talk about what new things that I can leverage with that partner and how we can grow together. So to the extent that this sort of baked in growth and knowing that you and the partner are gonna grow together and you're both gonna economically benefit from that and those are just baked into the contract are really awesome things to have. Yeah, I had to add a comment to that. So we're, the trajectory of our business looks fairly similar Justin to the up and to the right chart you showed for your business. Maybe shame on us for being a little bit slow and late on this but we're kind of going through that first pass of going back to many of the partners that we've been with for two, three, four years, maybe even since day one of the business and we've never collectively revisited either the economics or the solutions that were entailed in the original agreement and it's just a really telling conversation when you go back to a partner and say look, we're a lot different than we were when we signed this agreement. It isn't just to go back and beat him up on Pricel, that's usually that often is part of the discussion too but we're a much different company and I'm sure you are too so why is it that, let's figure out what the next three, four years should look like together and so we're kind of on the other side of the table on this exact same point. So many of the companies that Justin had up on his slide as I believe customers of yours, the stripes and world pays and some of the big providers, we compete against guys like that every day. Again, they're part of the universe of the hundreds of payment processors, there's five or six that control about 60% of US market and then there's a long tail of dozens and dozens of other players, many of whom have been around for a long time, many of whom are relative upstarts like ourselves who bring a different approach and flavor the marketplace but the ways in which we try and drive discussion to how we win business against some of those players and we're talking to a software developer and ISV going back to a lot of the things Jacques referred to as table stakes around SDKs and documentations and APIs and all that sort of stuff. There's a whole other layer that we think is really important and some software developers are kind of a little bit more mature and experienced themselves so they're in a position of having probably maybe felt a little bit of the pain of working with someone who hasn't thought this way but we do look at things of customer satisfaction. If we're gonna partner, if we're gonna provide our service to a shared customer who are with software developer X and they wanna integrate into us to use our payment processing platform, the end of the day there is a business of some type that we both have to support and so if we're not caring about that customer as much as you care about that customer, I can guarantee you if something gets screwed up on the payment side, yeah they're gonna call and scream at us but they're probably gonna call and scream at you louder because you're the one that they look at as the people that brought them, they may not even know who we are and that's okay, we're not, that merchant oftentimes does sit in the background and we're the engine, we're the intel inside and if we're not caring as much about our shared customers as you do, there's gonna be a problem. Understanding the business you're in or the verticals you serve to use the kind of a little bit crazy examples I referenced a minute ago, what a yoga studio needs to run its business, let's put them broadly in the category of kind of health and wellness vertical versus what a winery needs to run its business from a payments perspective are wildly different and yeah, there are absolutely commonalities and shared traits of what they both need to be successful but the nuances of those industries are, they're nuances to all industries so I think understanding, having experience in the verticals in which you're trying to play as a software provider is really important. Frictionless merchant boarding, all right, this, you know, the risk of oversimplifying their value prop, especially because I gather some of you might be in the room here, right? This is the calling card of people like Stripe, right? That's the reason Stripe has done an amazing job of transforming the expectation of software developers around that initial experience, right, moving into the background, all the things around risk and underwriting, all that stuff that we have to care about and Stripe has to care about but that's not what a software developer cares about. They care about having a seamless experience so that when their customer needs to integrate payments in, it can just happen, not, oh, well, the underwriting of a merchant account takes 48 hours so you're gonna have to wait to do the payments part of the software platform for 48 hours, like that's a big challenge. Pricing, right, I think pricing is something that, that's a pain point for everybody in every industry and being simple and transparent is such a core fundamental tenet of what small businesses have said over and over they need and want, right? That's part of what Square has innovated on, that's part of what Stripe has innovated on, as part of the world in which we live in where companies are punished severely in the marketplace over the long run for pricing and go-to-market strategies that are not understandable that are either intentionally or somewhat unintentionally confusing. This whole thing around card present and card not present so I actually came from one of the large players in the industry. They are now the largest global payment process from the world, world pay which merged with Vanov so the largest in the world. There's a reason companies that large, for all the intelligence of the IT leadership to have those companies still tend to run on multiple if not literally dozens of platforms around the globe and so when they're trying to present to a small business a logical easy joined up solution for I need to take card payments in my store, I need to take them online and maybe I need to take them out in the field somewhere. How do I do that? And so what the challenge that legacy companies tend to have is what they're doing is cobbling together a whole series of kind of siloed platforms slapping some layer on top which may look pretty good, may actually be an okay experience in some regards for the customer but things like billing and how it operationalizes and flow of data usually ends up being less than ideal so the ability to marry card present card not present is just really critical. It's one of the calling cards of our platform and our technology. And then I talked about way back in the beginning that 10% of software developers said that driving revenue is the number one reason they're in payments. So that's only 10% but if you take the other 20% that said generating leads for their business and then the other 20% that said stickiness that's 50% of the software developers say they want to get into payments for what I consider to be customer lifetime value or economic reasons and so understanding how a payment partner can help you drive leads, help you have a stickier product, et cetera, is really important. So I think this is the hard stuff because these aren't, you know, these aren't, you can't, there's no sandbox for this, right? There's no documentation, there's no, these aren't programming languages, this is business and so you gotta have all the other stuff that we've talked about earlier but in our view this is what differentiates a good partner from a great partner on the payment side. So how to start, right? So you kind of heard some of our stories, got some best practices on what we think in our experience a great partner should have but I think the challenge is you all have business to do and so you need to know that you're choosing the right partner before it's too late and so here are a few kind of tips. My dad gave me some dating advice where he said, don't wait till you get married to move in and I think that's relevant here in this scenario. I think when you have partners that you're able to kind of dip the toe in the water, so to speak, there are some things that you can do to see if long term it's gonna work out. So some of the things that I would recommend is so first of all, build a sample project, just do something really fast, authenticate into the API, see how hard that was. It's a really quick little smoke test before you start doing any sort of serious integration work in your code base so definitely do that. I'd also recommend just opening up a bullshit ticket, like just look for some obscure thing, open up the ticket and see how they respond, see how quickly they respond, see how thorough their answer is, see how condescending they are. A little condescending is okay but not too much. Call your account manager. If you don't have an account manager or if you don't have a phone number for their support, something to think about, right? And then look for alternatives. So troll the forums, see what other people, there's complaints about everyone, right? So figure out what are sort of the gaps and what people are saying about the other alternatives and you may find that those aren't gonna create heartburn for you or you may find that those are deal breakers but now you have a list of other places to go. So that's pretty much it. I hope that was informative and you have some ideas now on how to really choose the right partner.