Payment Facilitator (PayFac)

A payment facilitator, usually shortened to PayFac, lets other businesses take card payments under its own merchant account. Rather than each seller applying to an acquirer and waiting through the checks, they sign up with the PayFac and can often trade the same day. The PayFac holds the deal with the acquirer and the card networks. The sellers sit beneath it as sub-merchants, so from the network's point of view one account covers many businesses.

The model exists because the old way in does not suit small sellers. A market site signing up a thousand traders cannot wait weeks per account. So the PayFac takes on the checks, the paperwork and much of the risk, and takes a share of the margin in return. UK rules list acquiring of payment transactions as a licensed payment service. What duties a given PayFac carries depends on how its deal is built and where it trades.

How The Structure Holds Together

The PayFac signs one deal with an acquirer to cover the whole book. Each seller becomes a listed sub-merchant under it. Payments from every seller flow through the PayFac's account and are split out afterwards, and that split is where most of the daily work sits: tracking what each seller earned, taking off fees, holding back reserves, and paying the balance on a set day. None of it is hard in principle. All of it has to be right every day.

Two Names For The Same Shape

The two terms overlap heavily in daily use. A merchant aggregator covers the same broad idea: many sellers under one account. PayFac tends to be used where the firm has signed up formally with the card networks and taken on set duties. Scheme rules on sign-up, volume limits and how sellers are named differ by network and by market. The label on its own settles little about what a given deal involves.

Fast Sign-Up Without Skipping The Checks

Speed is the selling point, and the checks do not go away to achieve it. As a rule the PayFac still has to know who it trades with, which means know your business checks, proof of who owns the firm, and sanctions screening under aml rules. What changes is that most of it runs against data sources in seconds, not through a manual file review. Volume limits apply too. Above them a seller needs a full account of its own, and the limits vary by network.

The Risk Lands On The Master Account

Say a seller takes money and fails to send the goods. The refunds and disputes arrive at the master account, not at that seller, which is the trade for holding the keys to sign-up. That is why PayFacs run reserves, staged payouts and spot checks. It is also why a high-risk merchant may be turned down or priced apart. Weak controls seldom announce themselves through one bad account. They show up as a dispute ratio creeping across the whole book over a quarter or two.

Card Data In One Place Means More Audit

Handling card data for many sellers puts a lot of sensitive traffic in one place. The PCI Security Standards Council document library sets out the rules that apply. A PayFac carries a heavier audit load than any one of its sellers would carry alone. Many cut that load by keeping card numbers out of their own systems. Hosted fields and tokens keep card data with a firm built to hold it.

Naming Each Seller On The Statement

Every seller needs to be named in the payment message, and needs its own descriptor. The name on a cardholder's statement is what tells them who took the money. A charge nobody knows is one of the more common reasons a buyer calls their bank and not the shop, which turns a cheap refund into a costly dispute. Each seller also needs its own merchant identification number in reports, or a problem cannot be traced back to the one seller causing it.

Whether The Model Earns Its Keep

Running as a PayFac buys control over sign-up, the buying journey and the margin. It also brings checks to run, rules to meet, reserves to fund and a support load that grows with every seller. Many platforms start with a managed setup. A partner holds the licence, and the PayFac style journey sits on top. They move further only once volume covers the overhead. That order is usually right, because the running cost arrives long before the margin does. This look at aggregator against orchestrator models sets out the trade-offs.

Before You Commit To The Model

Model the reserve and the dispute exposure before the revenue. Those are the numbers that surprise people. Work out what a bad month would cost and who funds it. Automate the sign-up checks, and keep a manual route for the odd case. Give every seller a clear descriptor and its own reference from day one. Watch dispute ratios per seller, not across the whole book. And keep settlement reports detailed enough that a seller can match its own money without asking you. A payment orchestration layer helps where several providers are involved, and this piece on managing several payment providers at once covers the connection work.

‍