Jareau Wadé, Chief Growth Officer at Finix, on building payments infrastructure for SaaS companies

The reason someone would use Finix is, first and foremost, the payments operations that are necessary for a platform are an order of magnitude more complex than a single merchant. If you are a merchant who's selling something, you can go use platforms like Shopify or sign up directly with Worldpay, Fiserv or things like that. When you’re a merchant and you have a settlement, dispute, refund or anything like that, it happens once -- maybe multiple times, but it's all for you, under the same entity. If you’re a platform who intermediates transactions between the buyers and sellers, you have to do this N times. Imagine you have 10,000 sub-merchants -- the complexity in operations is considerable. Our clients use Finix because our software helps decrease that burden and increase the efficiency and the simplicity of interacting with the underlying providers to make that happen. So the first distinction is just, you’re a platform, and that's why you would use Finix. That’s one of the main areas we focus on.

The other use cases that we're seeing are folks who want to get started processing payments today -- it's efficient, it's fast, it's straightforward -- but have an eye on the future, where they eventually want to grow to be that Toast-size company, with the economics, the customer experience, and honestly the lifetime value that companies like Toast are seeing. They work with Finix to get on that path to future-proofing their payments. They get started with us now on a much lighter-weight product offering, where they use our API, and a lot of the payments operations are offloaded to Finix. Then, as they grow, they can take on more and more of the functionality and capabilities as they see fit, for both the economics and customer experience reasons.

Permalink

What kind of transaction volume would you say the typical customer is doing?

It really varies. Finix works with startups to publicly traded companies, and that's exactly the point. Like I mentioned before, we have customers who want to make this movement in the future. They work with us when they have tens of thousands of dollars of volume per month, and we have clients who are doing a billion plus. That's what is unique about our platform: that we can technically and operationally support that full life cycle.

The other thing I would say is, we can offer two business models to go along with that, to support you wherever you are. Under one scenario -- and it depends on the client and their situation -- we will offer a standard transaction take rate, so we might get a couple basis points on top of cost. Then in another model, we will just charge a SaaS fee, a monthly recurring charge that doesn't scale as a percentage of volume. So there are two models that we can go to market with depending on the needs of the customer.

I've mentioned this progression, where we have a customer who grows over time. We're also seeing a lot of movement in the other way, where there are large companies doing hundreds of millions to billions of dollars of volume a year, and there might be some reason -- maybe it's a new initiative or new venture -- that they want to go a more lightweight route. Or they're deciding that they want to optimize for speed and becoming a payment facilitator; we make it a lot easier, but they still have to go through the underwriting process with the underlying sponsor bank. They'll work with Finix on one of our other models to get to market faster and then, knowing that they have that continuity of the same system and that the tokens are all stored in the same place, they feel comfortable working between these two different models as they see fit, even if they're already at scale to potentially justify the investment in becoming a payment facilitator themselves.

Permalink

Can you talk a little bit about the difference between a company going with the standard payment take rate versus going with the SaaS fee? What might be behind that decision?

We used to say it was the processing volume. What we've learned by listening to our customers is that, like I mentioned, there are businesses who are doing enough volume that would, on paper, justify the investment in payment facilitation. They choose not to. You can look to web services as an example of why not. There are many cases where you are going to be interested in the convenience, scalability, and flexibility of working with someone else's infrastructure. They like the fact they can work across our business models to make that happen, and they don't feel like they're sacrificing one opportunity or the other. They might want to prioritize speed, for example, over the unit economics at that point and pay the markup, and that makes sense for them.

It really does depend on both the vertical and the company life cycle. We have gotten away from saying this is a hard and fast rule of total processing volume. We used to say it was between $50 to $100 million. What our customer base has taught us, and what we've learned scaling the business, is that flexibility is the key. That's why we can and do support two-person startups all the way to folks who have stock tickers and are in the public markets.

How do you think about the cost aspect of it? From what we understand, there's some upfront cost in having an engineer on it, as well as the cost of compliance. How does that factor into the thinking around what companies are good fits, and where is the break-even point that you've seen?

These are software companies that have engineers on staff. The point of using Finix is that you don't need a dedicated payments engineer, because we're building that for you, and you are licensing or paying for that in a metered way. So some of that is standard across the board. You're going to need software developers to build your application regardless, and if payments are part of that experience, then you can use our API to make that happen. 

Then there are some additional operational obligations you take on as a payment facilitator. Compliance is one thing. Our technology drastically reduces the main compliance burden, which is PCI, and working with our banking partners and using the banking setup of the underlying sponsor bank can relieve the other compliance burdens, which are around money movement. 

Then what you're left with is operations around really what look like customer support: how you’re handling chargebacks and things like that. When you're a vertically focused software company, which is what we focus on, you're often doing other things to vet and support the customer already that allow you to feel higher confidence in the fact that they're a good actor. It’s not a 100% all the time; chargebacks do happen. But what we've seen is that vertically focused software companies specifically have a relatively low chargeback rate compared to industry averages. Because of their narrow focus on the specific vertical, they're able to know, vet and support their customers in a way that a horizontal company can’t always do.

Would you be able to name a few of your customers on the earlier start-up side? I’m curious what they might look like.

There are two that are on our website. We have Zendoor, which focuses on the real estate space and is based out of Arizona, and .NGO, which is a nonprofit funding platform. There are several others that we haven't made public yet and many more to come, but those are two that we've talked publicly about.

Permalink

Are there benefits for the end user, the merchants themselves who are on the platform? Is it beneficial to them to be on a platform that pays through Finix versus something else?

There are four models roughly for how payments are delivered.

We'll go over the pizza first and then we can talk about the payments. Basically, the legend at the bottom is: what do you do versus what does the vendor at the pizza shop do? 

First is, you're hungry, you want to eat pizza, you decide you're going to dine out. You're essentially asking the restaurant -- the vendor in this case -- to do everything for you. You're showing up, but they're baking it, it's their ingredients, and they provide the table and the drinks. You outsourced it. 

Then there's the delivery model, which is a hybrid in a way. You're still not baking, and it's not your electricity or gas that you're paying for the oven and not your ingredients. But you're eating at your own house. 

Then the take-and-bake model -- the DiGiorno model. This is where you meet in the middle: another hybrid model where you are using your oven this time. You're a bit more invested in the infrastructure, but you're still not preparing the pizza from scratch. It's prebuilt for you and you bake it. 

The last one is full from-scratch: you're tossing dough, making pasta sauce. Yes, you bought some things from the store, but really you're creating the entire product yourself.

If you go to the payments model, this maps very cleanly to the four popular models right now for delivery of payments, at least in the US. They are: the ISO model, outsourcing to a PayFac, becoming a PayFac yourself and using a infrastructure provider and, again, full custom in-house build. The most dramatic product experience that you're going to see as an end user is going from model one to model two or model three.

Model one is the referral or ISO model. ISO stands for “independent sales organization,” where the software company has a gateway integration with the payments provider, but it ends there. If the merchant wants to go sign up for the payments, they have to do that elsewhere. If they want to inquire about settlement, funds delivery or a dispute or chargeback, they have to go to the payments processor. Not the software vendor, who might be the primary relationship and the reason that they have that payments provider. 

I’ll use one of our customers, Clubessential, as an example of what you get when you go from, let's say, model one to model three. They're a Cincinnati-based fitness and wellness club management platform. They're narrowly focused and this is vertical. The experience before is that a club would have to sign up for their software and then also sign up for a payments provider. When that club had a question about why a transaction was declined or why there was a dispute, they would go to Clubessential first. Then there was an operational burden on Clubessential to go and seek that information from the payments processor themselves. Often they couldn't get that information, because the direct relationship was between the merchant and the payments provider underneath the surface. By going to model three -- where Clubessential has become a payment facilitator using Finix’s software -- they can answer those questions themselves because they essentially are a mini processor. The software and the payments are delivered from one entity and in one experience, which increases the happy path scenario, where the merchant can get their questions answered and there's less operational burden on Clubessential in this case.

But it doesn't stop there. We've seen other clients that I won't name, but they were able to build custom funds flows because they were able to receive an approval from an underlying bank sponsor that wasn't something offered off the shelf under model number two. The specific example I'm thinking about is: we have a client who wanted to pay back loans from credit card proceeds. You can imagine the benefit if you were the small business who's receiving a loan. You don't have to have this funds flow issue, where you're waiting to get a line of credit opened and you get your funds delivered into your bank account, only to turn around and pay them back to the same entity that's delivering the funds from your credit card processing. You can just automatically have it go back to pay back your loan and keep your credit line open or higher than it was otherwise.

That type of invisibility and effortless experience is exactly what you enable by merging software and payments. On the left side of this distribution, there are a lot more disjointed and separate experiences. It's a bit of a spectrum, but that's really what you unlock by combining these things. It's not just transactional, it's not just the economics. There are great benefits, like we saw when Lightspeed used Finix with Worldpay to launch Lightspeed Payments in 2019. You can see in their public filings that they expected to double their take rate per transaction, and that turned out to be true and then even a bit more.

Then the last thing that this does is it reduces churn. If you're getting your payments and your software from one provider and it's a great experience, because of all these things we just talked about -- or maybe even the software company can subsidize and offer cheaper rates because they're making money from payments, not just software, or vice versa -- that relationship will exist longer into the future, which pushes up your lifetime value.

Permalink

I’m curious about the idea of a network effect with, say, Stripe, in the second category. Have you seen a tendency for companies to want to bring along Stripe as their payments provider, where they might not actually mind having to outsource because it's something they're familiar with? Maybe that depends on the market. For example, a health club in Cincinnati probably doesn't necessarily have a preference for Stripe. Is that fair to say?

I would actually put what you're talking about into model one here -- the ISO model -- not the number two model. Stripe can support both, but the model I think you're talking about is much more in the situation of, let's say, you're BigCommerce and you have integrations with multiple payments providers. They can bring their Fiserv, their Worldpay, their Stripe account and then plug it into your software. I don't know if I would call that network effects, because it is the ISO model, with the only difference being that a company like Stripe or even CardConnect is often providing that relationship through an API. You can click a button, authorize your account, do an OAuth handshake between the application and Stripe, and now the application has the ability to make transactions and pull data on behalf of that Stripe account owner. That is essentially an ISO relationship.

There's both a push and a pull. There might be merchants who show up with that account and they want to use it, but then a common model is also that you show up to use the software first and then on the back end, you are asked to use a menu of providers. Stripe might be one of them, or CardConnect or Worldpay.

So you're not seeing companies who already have Stripe accounts and are wanting to use them.

No. I would say what's happening more -- and you can see this, not just on payments acceptance, but on neobanks, card issuing, etc. -- is the selection choice for the merchant or the consumer, depending on what the product is for fintech, is that you choose the application first, and then financial services are provided either under the hood or behind the scenes by another party that is usually brought in through a set of options, like one of many, or as the sole and dedicated provider by that software application.

This is what's happening with embedded fintech, neobanks and banking-as-a-service. And very much we're seeing neobanks, remittance apps, etc. succeed when they find attachment in a community. The vertical SaaS companies succeed when they get dominance in a specific cohort of merchants or group of merchants. In a lot of ways, there are similarities between those two and that's what we're supporting.

Finix has some partnerships with both neobanks and banking-as-a-service. I’m curious how you think about partnerships and supporting each other's growth. Is it an alternative to the Stripe vision of an all-in-one ecosystem or the PayPal vision with Braintree, where you can offer many different things under one hood?

We work with folks like Synctera, Dwolla, Metabank, but also several other banking partners. This is very much like the partner model. I think companies like Plaid are really popular with this, Modern Treasury -- a lot of their value prop is that they offer this ledgering software, but you can select from a menu of different partner banks. We're more into that vein. There are other companies that choose to build almost everything. But I think there are successful models under both categories of “we do everything” and “you can have whatever you want as long as it's blue.” We're just using the partner approach right now.

Is one of the motivations for switching to Finix the idea of -- Starbucks gift card-style -- using abandoned revenue as float, in the sense that this might be an advantage of running payments internally versus via Stripe or another platform?

Not really. There's not really breakage in the sense of the Starbucks model you mentioned, where it’s prepaid, so you top up or load funds and those funds might not be used. In the model that we're talking about, where a software company becomes a payment facilitator, they are receiving or processing transactions on behalf of a sub-merchant, and those funds are then paid out to that sub-merchant. So there's no real opportunity for breakage where those funds are not used.

There's another technology that’s like push-to-card and you can build P2P applications, which has much more of the dynamics you're talking about. But even then, Visa and MasterCard have certain rules around how and when those funds need to be paid out, so I wouldn't say that's a big motivator.

Is there anything else that we didn't get a chance to cover that you think is important to understanding the space or Finix?

One of the things I always like to underline and highlight is the difference in supporting platforms versus merchants. I think a lot of people bring a merchant-focused understanding to our space. I am very confident that if you look forward and at payments specifically -- looking across neobanks and all these other fintech apps -- the way that new users, both merchants and consumers, are going to come into the digital economy and the fintech space is through platforms: Square, Cash App, Chime, Toast, Lightspeed.

Personally, I've spent most of my career on this idea of payments for platforms. It’s because platforms are the engine that's going to drive not only financial inclusion, but also the bedrock of the economy. This goes back to Finix’s mission: we want to create the operating system for fintech to create the most accessible financial service ecosystem in history. We're starting with payments to do that, because that's the primary way to move money in and out, and then you can layer on financial services on top of that.

Platforms are our focus area. Not because they’re just personally important and interesting to me, but because I think the way that we're going to get more small businesses, solo entrepreneurs, creators, etc. onto the map is through these platforms.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.