PayFac vs ISO: When Does One Make Sense over The Other?

Throughout the history of payments processing distribution was a critical part of the game. When a merchant opened up shop, how would they find a payments provider to ream them? You have to remember this was pre-internet and services weren’t exactly at your fingertips.

The ISO, or independent sales organization, became the workhorse of payments distribution. ISOs were “entrepreneurs” insomuch as you could define selling commoditized goods with no necessary iteration for product-market fit as entrepreneurial. ISOs would sign up with an affiliated payments acquirer and resell the acquirer’s payments processing capabilities. In exchange for onboarding merchants the ISOs would command about 90% of the acquiring economics.

ISOs almost always started as “retail” ISOs. A retail ISO is one that uses the acquirer’s default technology (what we’ll term payments stack) out of the gate. The benefits of doing so are lower upfront costs and faster speed to market. The downside is a lack of flexibility over customer experience, and depending whom you ask, a limit on the economic upside.

As retail ISOs grew larger they’d often become wholesale ISOs. Wholesale ISOs were more costly to stand up but they had the benefit of customizing the merchant experience and could dictate better economics from their partner-acquirer in exchange for shouldering more of the merchant risk.

Yet there were groups of people who thought the ISO model was still too limiting. According to Todd Ablowitz, co-founder and co-CEO of Infinicept, a PayFac-as-a-Service (PaaS) provider, there are two major constraints that drove the evolution of the ISO model.

First, ISOs aren’t allowed to have a two-party agreement between the ISO and the merchant. Instead, the processing agreement must have the sponsoring bank on the paperwork. There are even some esoteric rules on this front, like Visa requiring ISOs to have the bank’s logo of equal size to that of the ISO on the application and agreement. This slows down merchant onboarding dramatically – a traditional ISO might take days to onboard a merchant, which is particularly painful for online merchants who demand speed.

Second, ISOs can’t touch the money in the processing stream. The funding goes from the acquiring bank to the merchant, not through the ISO. The downside here is that the ISO is limited in what it can do.

Todd Ablowitz, Infinicept

These peculiarities weren’t sufficient for a new breed of payment innovators, and the PayFac model was born. But it wasn’t exactly overnight. At a high level the PayFac exists to simplify the onboarding of merchants and the movement of funds. In the early days this was an issue as the nuance of card network rules and state finance laws made the simplicity of a PayFac quite difficult to execute in practicality.

The card networks, namely Mastercard and Visa, created specific rules for PayFacs in 2011, adding a great deal of clarity to the model. However, because PayFacs weren’t exactly a well understood entity, states took issue with PayFacs moving settlement funds on behalf of their submerchants. As a result, they began determining that many PayFacs were money transmitters, which requires a unique license in 47 states. A work around, especially by acquirers looking to grow their PayFac business lines, was the creation of an FBO, or “for benefit of” bank account. Acquirers like Vantiv would create bank accounts for their PayFac partners and keep the funds on their balance sheets. This often provided PayFacs the legal coverage they needed to get around limiting regulations. It didn’t always go so smoothly though, as Square’s history demonstrates.

Today’s PayFac model is much more understood, and so are its benefits. While we’ll discuss costs below, PayFacs can onboard merchants much more quickly than a traditional ISO model. The downside of this speed is the risk exposure in a breach; if a retail ISO is breached the acquirer steps in and shoulders most of the load. That’s because retail ISOs are using the acquirer’s default technologies and are giving up processing economics in exchange for higher assurances. PayFacs and some types of wholesale ISOs, meanwhile, choose onboarding speed and flexibility, and higher processing economics. In doing so these entities are responsible for building and supporting their own technologies. Thus any breach invites a too-bad, so-sad situation.

This graphic explains the correlation in broad strokes.

When do the economics for a PayFac make sense? The rule of thumb seems to be around $50M of processing volume. PayFacs earn an average processing margin of 100 basis points, excluding restaurant and retail PayFacs. The cost to become a PayFac starts around $250,000. From there a PayFac would need to either build or buy the underwriting and reporting tools, which run around $100,000 annually in a subscription model. The PayFac would also need to hire a FTE to take exceptions and review these exceptions for risk. One FTE is sufficient until $250M in processing volume, then you’d need to add more bodies.

Then the PayFac needs to build a number of other tools or go through compliance processes, like becoming PCI Level 2 certified, but as soon as they reach 300,000 transactions they’d need PCI Level 1 certification. PayFacs can get 93% out of scope, however, by working with third parties. Confused yet?

As with most things it’s not all or nothing, and PayFacs can buy many parts of the payments stack from PaaS providers. What exactly is in the payments stack? Well, it’s all the technology and compliance needed to serve up payments. Stripe has done a great job making a graphic on their PayFacs explainer which we’ve copied below – think of the pink and green items as requiring technology, while the blue items require compliance for working within the confines designed by the existing payments ecosystem.

Here’s another list of the payments stack:

• Merchant Application and Agreement (Just the interface / sales aspect)
• Payment Processing
• Funding/Settlement
• Pricing/Billing
• Flow-of-funds/Reconciliation
• Chargeback Management/Administration
• Risk Management
• Compliance Management
• Terminal Management
• Merchant Support
• Merchant portal/reporting

Rich Aberman, co-founder of WePay, wants to be clear that there are some really fuzzy lines between ISO and Payfac.

I’ve seen PayFacs that look and act like ISOs, and ISOs that look and act like PayFacs. When you reach the extremes of the wholesale ISO model you have ISOs who have the same risks as a PayFac. You’re also now seeing PayFacs who use tools from the PaaS providers to offload risk and these PayFacs look much more like a retail ISO for all intents and purposes.

Rich Aberman, WePay

As an example, a large POS ISV (independent software vendor) that thought about becoming a PayFac decided the ISO model worked better for them – they wouldn’t need to build the payments stack and could use the WePay infrastructure on top of JP Morgan Chase to get the benefits of a PayFac without the associated costs and risks.

“WePay built a fintech layer on top of JP Morgan Chase to make it easier for ISVs to operate as PayFacs without all the overhead. Think of us like using AWS instead of building your in-house server architecture,” explains Rich.

We’ve taken in all of these data points to come to the following conclusions.

If you just want to make money referring payments then the retail ISO model is the fastest and easiest way to get started. But you’re reliant on the default merchant experience built by the acquirers, and the acquirers wouldn’t know how to build a decent software product if it saved their moms from getting run over by a bus. So it will take a long time to onboard merchants, and the merchant will feel like they’re suffering through medieval torture, especially if they’ve experienced a seamless online commerce experience for comparison.

But ISOs without any proprietary technology eventually die as the days of integrated payments come to a close – i.e. every software vendor is going to become some version of a wholesale ISO or PayFac because it’s trivial in relation to building actual software. The distinction between wholesale ISO and PayFac is thusly less critical than the distinction between being a technology company and being a troglodyte.

Smaller ISOs might rush to become PayFac because it sounds sexy, but we’re talking drastic cultural changes necessary to transform into an actual technology or software company. These are much harder than labeling yourself as an entrepreneur and reselling payments.