Referral vs. PayFac vs. Merchant of Record for Vertical SaaS
What each model gives you, what it asks of you, and how to choose
A founder I know sent me an unusual request. He was close to making his platform the merchant of record for all of his clients, and he asked me to find reasons not to.
I sent one short email, and for his platform at that stage it settled the question.
He was not being naive. He was doing what most platforms do, which is choosing a payments model by reading about what each one gives you. Few guides cover what each one asks of you, and much of what is written comes from companies that sell one of the options. So here is a balanced look, from someone who has seen referral models up close and has talked several platforms through the alternatives. None of these models is wrong. The right one depends on your platform.
First, the words
These terms get used loosely, so here is how I use them.
In a referral model, you send your clients to a processor and earn a share of what the processor makes from them. The processor onboards them, underwrites them and carries the risk.
A payment facilitator, or PayFac, holds a master merchant account and signs your clients up underneath it as sponsored merchants. You can register as one yourself, or use a partner that carries the underwriting and compliance for you.
Merchant of record is the slippery one. In the strict card network sense, it is the legal seller: it appears on the cardholder’s statement under its own name and answers for refunds and disputes. In vertical software, people use the phrase for something different. The platform opens one merchant account in its own name, runs every client’s payments through it, and pays the clients out. That second meaning is the one I mean in this post. It is closer to payment facilitation than to being the seller, and that mismatch is part of why the term causes so much confusion.
Referral: the fastest way to start, with the processor carrying the risk
In a referral model, the processor sets each merchant’s cost and the platform earns a revenue share. There is a real upside: you take on none of the risk.
It is also the quickest model to launch. The processor onboards your clients, underwrites them and handles the compliance, so a small team can take payments without building any of that. For many platforms, especially early on, that is exactly the right trade.
What to plan for is visibility and leverage. In the setups I have seen, the platform picks from a short menu of buy rates, and anything beyond that, such as interchange plus for a larger merchant, is negotiated with the processor. With a very good partner, that works well. Your revenue also depends on costs you do not control, so as volume grows it pays to understand the underlying economics: where your share comes from and what it would look like under different terms. At the very beginning it may well be the easiest model to run. I have watched a platform sit in exactly that spot, earning a thin share on part of its volume while other volume earned nothing. That is not a reason to avoid referral. It is a reason to look at the numbers as volume grows.
Wherever you land, the gap between what you signed and what you are actually paid can open up over time. That is processor contract drift, and it is a large part of what we call payment margin leakage. It is easier to spot when you can see the full picture than when you only see your slice.
PayFac: more control over pricing and experience, with more to run
With a PayFac model you own the client relationship. You set pricing, you control onboarding, and you see the data. You also take on what the processor used to carry: underwriting, disputes, payouts, and the compliance that goes with them. Depending on the contract, a partner can hold much of that for you, so read exactly who carries what.
Networks also set an annual volume line above which a sponsored merchant may need its own agreement with the acquirer. Those lines have moved up over the years and now come with exceptions, so figures that circulate in blog posts can be out of date. I will not quote one here. Ask your acquirer for the current rule before you plan around it.
Merchant of record, the way platforms actually use the term
It is easy to see the appeal. One merchant account. One system to reconcile. Predictable payouts and easier forecasting. For a young platform, that simplicity is real.
It is not a margin play: in the case I mentioned at the start, there was no economic upside, only simplicity. Simplicity can be a good reason to choose a model, as long as you know what comes with it. These are the four things I put in that short email.
Risk is pooled. Card network monitoring programs track dispute and fraud ratios at the merchant level. When every client runs through one account, there is one ratio for all of them, so one client with a bad month can put every other client’s processing at risk.
You inherit the payout machinery. Payouts, failed payouts, the cash flow of moving other people’s money and the reporting duties that come with it all land on you. In a processor-run platform program, much of that work sits with the processor.
It may not scale into bigger clients. If the networks view your setup as payment facilitation, volume lines apply, and your best clients are the ones most likely to cross them. Plan for the day your largest client outgrows your account.
Special rates can depend on each client’s own category. Reduced interchange for registered charities, for example, depends on the merchant’s own category code. Put those clients under your platform’s code and they can lose access to it.
None of these is exotic, and all of them can be weighed before you sign. For his platform, at that stage, they pointed to a processor-run platform program. For another platform with different priorities, the weighing could come out differently.
Changing models later
Whichever model you start with, you may change it later. I have watched platforms unwind a merchant-of-record structure, and it is rarely one project. It is technical, because you rebuild payout and reporting work a processor used to handle. It is contractual, because the terms you signed no longer match the business. And it is merchant-facing, because you have to tell your own clients their payments experience is changing. It is all of it, at once. That is why the first post in this series argues that your payments strategy starts the day you embed payments, not the day volume forces the question.
One light flag
Holding and moving other people’s money can raise licensing questions. In the US, that is a money transmission analysis. In Canada, the Retail Payment Activities Act can reach platforms with Canadian operations or Canadian customers, including some based elsewhere. I am not the person to answer that for your structure, so talk to counsel before you pick one.
How to choose
I would not start with a volume number. I would start with what you want to own and what you would rather hand to a partner. As well as a good understanding of your customers.
Referral tends to suit platforms that want to launch payments quickly, keep risk off their books and lean on a processor for the heavy work. A PayFac model tends to suit platforms that want control over pricing, onboarding and the client experience, and are ready to run the operations behind it or buy them from a partner. A single merchant account in the platform’s name tends to suit a platform that values simplicity above all and has weighed the risk, the payout work and has the right type of customers.
Then ask three questions of whichever one you lean toward. Who is on the hook when one client’s disputes spike? Who fixes a payout that fails, and who pays for it? And if you wanted to change models in two years, what exactly would it touch? If you can answer those, you are choosing with open eyes.
Questions platforms ask
Is a platform that pays out its clients a merchant of record? By the strict card network definition, usually not. A merchant of record is the legal seller, and funds settle to it rather than being distributed to others. In industry shorthand, platforms use the term for one account in the platform’s name with payouts to clients, which is closer to payment facilitation.
Is referral the safest model? It carries the least risk for the platform, and it is the quickest to launch. As volume grows, platforms often want more visibility into the underlying economics and more say in pricing, so it helps to plan for that early.
When do I need to become a PayFac? There is no single volume line I would trust. Start from who you want carrying underwriting, disputes and payouts, then check current network rules with your acquirer.
What does it take to leave a merchant of record model? Technical, contractual and merchant-facing work, all at once, which is worth planning for when you choose.
Talk it through
If you are weighing one of these models, or already live inside one and want to see what it earns and what it costs you, book a demo. We will walk through your setup and model the options against your own data.