What is a payment facilitator (PayFac), and how is it different from an aggregator?
You can onboard a merchant in ten minutes instead of ten days. The price is that their losses are now yours.
What actually changes
Traditionally, every business that wants to take cards gets underwritten individually by an acquirer. Documents, checks, a decision, an account. It is thorough and it takes days to weeks, which is fatal if your product is a marketplace with sellers who signed up this morning.
A payment facilitator collapses that. It is underwritten once, at depth, and then onboards sub-merchants under its own umbrella using its own risk rules. Sign-up becomes minutes. The acquirer sees one counterparty.
In exchange, the facilitator becomes responsible for the things the acquirer used to do: know-your-business checks on every sub-merchant, transaction monitoring, chargeback handling, and the losses when a sub-merchant takes money for goods it never ships and then disappears.
Facilitator, aggregator, marketplace, merchant of record
These four terms are used interchangeably and should not be.
A payment facilitator is the card scheme's term for the model above. It is a defined role with registration requirements and volume thresholds per sub-merchant.
An aggregator is the same shape of idea, and in India it is a regulated category with its own licence and its own rules on how customer funds are held. The word is not a synonym for PayFac, it is a local licensing term.
A marketplace is a commercial arrangement about who the buyer is contracting with. It may or may not involve facilitating payments.
A merchant of record is the entity legally selling the goods, which means it owns the tax obligation and the customer relationship. A facilitator is usually not the merchant of record. This distinction is where teams get hurt.
You can be a facilitator without being merchant of record, and merchant of record without facilitating anything. Decide both deliberately.
The economics, honestly
The appeal is margin. You buy processing at wholesale and price it to sub-merchants at retail, and the spread is yours. On top of that, payments becomes a retention mechanism rather than a line item, because a business that settles through you does not leave casually.
The cost is that you have become a small financial institution. You need underwriting, reserves against loss, a chargeback operation, compliance staff, and capital that is not doing anything productive. Scheme registration and the associated obligations are ongoing, not one-off.
The blunt test is volume. Below a certain level of processing, the spread does not cover the operation, and you are better off with a provider that offers facilitator-like onboarding while holding the risk itself. Plenty of teams built the whole apparatus for volumes that never justified it.
A landlord takes one lease on a building and sublets forty desks. Tenants move in the same afternoon rather than negotiating with the freeholder. The landlord keeps the difference between one rent and forty. The landlord also pays when a desk sits empty, when a tenant leaves without notice, and when one of them turns out to be running something the freeholder would never have allowed.
What to check before you commit
Three questions, in order. What is your annual processing volume, and does the spread on it fund a risk function. Who eats a fraudulent sub-merchant's losses in your model, written down, before it happens. And which regulated category you actually fall into in each market you operate in, because the scheme's definition and your regulator's definition are different documents.
Where you meet it
Every marketplace where a seller starts taking payments the day they sign up. Every software product that added payments and got much more valuable. Every platform that had to freeze a seller's payouts and could not explain why.
Building this? A second pair of eyes on the architecture is what the advisory is for. →
