Warren Brown, VP of Product at Order, on 4 ways to monetize payments in vertical SaaS

We are a longtime Lithic partner.  They are a huge part of what makes the Order.co platform work as smoothly as it does.  We're annually issuing hundreds of thousands of single and multi use virtual cards via the Lithic API.  We love the easy webhooks to monitor transaction activity and the ability to create custom authorization rules.

They've also been great advisors for us, helping us to sort through strategic decisions like BIN type, and how to mitigate fraud and declines.

Could you run through your sources of revenue?

We have four sources of revenue. 

Our customers pay us a monthly subscription to help manage all of their spend. That's source one. 

Similar to a digital GPO, we negotiate bulk buying discounts from key vendors that many of our customers use and generate savings for our customers.  We keep a share of those savings, which is source two. 

As I mentioned earlier, we pay many of our vendors using Lithic’s generated virtual cards, which generates interchange revenue, that’s source three. 

We also offer pay later and extended terms options to buyers for a fee.  This financing revenue is our fourth revenue source.

Could you talk about the payment rails underlying catalog spend? For non-catalog, it's cards, credit but how do the payments work for catalog spends?

Today we pay Catalog vendors either via virtual card or via ACH.  Off-Catalog we currently only support virtual card.  In 2024, we are looking to expand our ACH capabilities across both channels.  We think Lithic’s new ACH APIs can be helpful there.

Let’s talk about ACH vs. credit card. Obviously, the credit card has higher fees. If a vendor says, "I only want to get paid via ACH," is their consideration mostly around fees and associated aspects?

It’s pretty common that vendors with high ticket items will only accept ACH.  As we are upgrading our ACH capabilities, we are focused on ensuring we do more than just move the money, that we add value for both buyer and vendor.  For example, we know that reconciliation is often time consuming and painful for both buyers and vendors - searching a bank statement with cryptic transaction details to match a payment to a PO/invoice isn’t a good use of anyone’s time.  Because we’re originating the payment AND have the PO/Invoice data in the platform, we’re confident we can save enough time and money for both buyer and vendor to make the economics work for all parties.

Imagine a world as a vendor, where you spend zero time chasing customers for payment and all the orders you receive from Order.co are automatically written to your QuickBooks, Sage or Netsuite accounting software and automatically reconciled against deposits in your bank account - how much more time could you spend on acquiring customers and fulfilling orders?

Is one way to think about it—and you see this in products like Ramp, like this—you used to have your corporate card and those things that you bought with credit card. Separately, it’s those things that you get invoiced for larger amounts that you run through e.g. Bill.com. Now are those things basically coming together? Does the software abstract away some of the actual method of payment?

Yeah. I don't think customers ultimately care about how payment is made, and vendors don't ultimately care about how they receive payment. 

As a concept, vendors care about four things: cost of accepting payment; how quickly they get paid; how certain they are to get paid; and how easy it is to reconcile payment in their books. 

To the extent that software can make the underlying rails invisible and solve for those front-end needs, I think, the vendor doesn't really care how the payment is made.

On the buyer side, CFOs push all spending to platforms like Order.co because it saves them time, saves them money and simplifies the bookkeeping three-way match.  It’s not about preferring cards or ACH, it’s about what platform saves me time and money.

How important are maybe some of the card-specific features like chargebacks and some of the guarantees around like, "Hey! If things go sideways, I can do a chargeback," vs. "If I send money via ACH, it's gone?"

With regard to chargebacks, I think, it is much more valuable in the consumer space, at least in my experience. I don't see a lot of businesses really thinking about it as I'm putting this on the card, because that gives me chargeback protections. For vendors, I think accepting cards is largely about convenience for their customers and certainly of next day payment.

Is there any nuance with respect to recurring payments and direct debit ACH, for example?

No, that's a good point. I think, where we do see customers choosing card over ACH is; what's annoying about how most banks process ACH is the description fields that are available on your bank statement are cryptic at best. The description fields associated with your card statement are slightly less cryptic. At least if you work with one of the major card companies, vendor identification is clearer. 

So the “Who is it to?” is generally easier to decipher if you're looking at a card transaction information than it is if you're looking at a traditional, typical bank ACH transaction. The “What is it for?” is almost impossible in both cases, unless you have a matching invoice that you can tie back or it's the same thing every month and it's just, "Oh! Yeah, that $50 charge, I know what it's for."  That’s where both buyers and vendors benefit from managing their spend on Order.co.

Do you think virtual bank accounts and some of this other ACH-related kind of infrastructure, have made a dent in any of this?

No. I do think that B2B banking as delivered by the banks is, as a general rule, terrible and so, the opportunity to deliver a better banking experience to most businesses of any size is significant. 

To me, the virtual accounts are underlying infrastructure that allow software companies like us to think about, “Do we offer customers a value prop of more than just payments of, "Let us be your core bank as well?"” In doing that, it would simplify a lot of things. 

When I think about Lithic and competitors, they started out focused—which we all need to do as startups—saying, "We're just about card issuing," and the way we want to see them is, "You are our embedded payments channel." So the fact that they've added ACH is very helpful. 

Over time, I see players like Lithic continuing to add payment rails to be a one-stop shop for embedded payments APIs.  As a customer, maintaining multiple partners for different rails adds complexity and cost. 

It takes time and work to add the rails, but I think the winners in embedded payments will be multi-channel embedded payment processors.

Do you have a rough split of payment volume that happens on cards vs. ACH today?

Yes, for us, payments to vendors, it's probably like 80% cards to 20% ACH.

With regard to this notion of distributed spend, how does card infrastructure enable a product like Order.co to empower its customers and employees all with spend vs. a system like ACH?

You make a good point. One of the things that I think comes with the embedded card issuing infrastructure is fraud prevention. By spinning up transaction or vendor-specific cards, with amount limits tied to the expected transaction, it’s much harder for a fraudster to abuse the virtual card vs if they get a hold of a customer’s routing and bank account number.

In that sense, Order.co fundamentally could not just purely have been built on ACH, one, because of the unique benefits of card-based payments that we're talking about.

Yes. Virtual card issuing and embedded card issuing have been a crucial part of enabling our growth. Lithic's been a super partner. We've worked with multiple other partners, and there's a reason that we're still with Lithic.

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.