What Is a PayFac
Definition
A PayFac (payment facilitator) is a master merchant that enables sub-merchants to accept card payments under its own merchant ID, handling underwriting, onboarding, compliance, and settlement on behalf of its sub-merchants without each needing their own merchant account.
How It Works
The PayFac registers as a master merchant with an acquiring bank under a single merchant identification number (MID). When a sub-merchant (typically a customer of the ISV's software) needs to accept payments, the PayFac performs KYC/KYB checks and onboards them under the master MID. Transactions are processed through the PayFac's infrastructure, and the PayFac is responsible for splitting settlement funds to individual sub-merchants.
Why ISVs Care
Becoming a PayFac — or using a PayFac-as-a-Service provider — lets ISVs own the entire payment experience, earn revenue share on every transaction (typically 20-80 basis points), and control merchant onboarding speed (minutes instead of days). The tradeoff is significant: full PayFac registration requires $1M+ in setup costs, a dedicated compliance team, and ongoing liability for sub-merchant fraud and chargebacks.
PayFac is short for payment facilitator — and it’s the business model that turned embedded payments from a feature into a revenue line for ISVs.
PayFac in Plain English
Traditionally, every business that wanted to accept card payments needed its own merchant account — a process that took days to weeks, required extensive paperwork, and involved credit checks. A PayFac eliminates this by acting as a master merchant that onboards businesses under its umbrella.
Square is the most visible example. When a small coffee shop starts using Square, it doesn’t apply for its own merchant account. Square (as a registered PayFac) onboards the shop as a sub-merchant under Square’s master merchant ID. The coffee shop can accept payments within minutes.
For ISVs, the PayFac model means your software can onboard merchants to accept payments as a native part of your product — no third-party merchant applications, no multi-day waiting periods.
How the PayFac Model Works
The Registration Path
Becoming a registered PayFac requires:
- Sponsoring bank relationship — An acquiring bank agrees to sponsor the PayFac’s master merchant account
- Card network registration — Registration with Visa (as a Payment Facilitator) and Mastercard (as a Payment Facilitator Model participant)
- Compliance infrastructure — KYC/KYB processes, transaction monitoring, chargeback management, and PCI DSS Level 1 certification
- Risk management — Underwriting policies, fraud detection systems, and reserve fund management
- Technology build — Merchant onboarding APIs, settlement splitting, reporting, and reconciliation systems
This process typically takes 6-12 months and costs $500K-$2M+ in initial investment, with ongoing compliance costs of $200K-$500K annually.
The Transaction Flow
- Merchant onboards via the ISV’s software (KYC/KYB automated through the PayFac’s system)
- Customer pays through the ISV’s embedded checkout
- Transaction routes through the PayFac’s master MID to the acquiring bank
- Funds settle to the PayFac’s trust account
- PayFac splits funds — merchant receives their portion minus the PayFac’s markup and processing fees
- PayFac earns the spread — the difference between interchange + network fees and what the merchant pays
PayFac vs. PayFac-as-a-Service
This is the critical decision for ISVs today:
| Factor | Full PayFac Registration | PayFac-as-a-Service (PFaaS) |
|---|---|---|
| Setup cost | $500K-$2M+ | $0-50K |
| Time to market | 6-12 months | 2-8 weeks |
| Revenue per transaction | 60-100+ bps | 20-50 bps |
| Liability | Full — fraud, chargebacks, compliance | Shared — PFaaS handles most |
| Control | Complete | Limited by PFaaS provider |
| Best for | ISVs with $100M+ TPV, dedicated payments team | Most ISVs starting embedded payments |
PayFac-as-a-Service providers (Finix, Payrix, WePay, Stripe Connect) let ISVs act like a PayFac without the registration. They handle the acquiring bank relationship, compliance infrastructure, and risk management — the ISV integrates their APIs and gets PayFac-like economics at a lower margin.
The Economics That Make PayFac Compelling
Here’s why ISVs pursue the PayFac model:
A SaaS company charging $200/month per customer with 1,000 customers earns $2.4M in annual recurring revenue.
Add embedded payments at 30 basis points on $500K average annual processing per merchant:
- 1,000 merchants × $500K × 0.30% = $1.5M in payment revenue
- That’s a 62% revenue increase from the same customer base
- Payment revenue scales with merchant growth — no additional sales effort
The math gets more compelling at higher transaction volumes. ISVs processing $1B+ in aggregate TPV through a full PayFac model can earn 60-100+ basis points, generating payment revenue that exceeds their SaaS revenue.
Who Should Become a PayFac
Full PayFac registration makes sense when:
- You process $100M+ annually through your platform
- Payment revenue is or will be a primary business line (not a feature)
- You have or can hire a dedicated payments/compliance team
- Your vertical requires deep control over underwriting (e.g., regulated industries)
PayFac-as-a-Service makes sense when:
- You’re adding payments for the first time
- Your aggregate TPV is under $100M
- You want embedded payments without a dedicated payments team
- Speed to market matters more than maximizing per-transaction margin
Common PayFac Misconceptions
“Any ISV can become a PayFac.” Technically yes, practically no. Card networks and sponsoring banks require minimum processing volumes, financial reserves, and compliance capabilities that exclude most early-stage ISVs.
“PayFac-as-a-Service gives you the same economics.” It doesn’t. PFaaS providers take their cut — typically 10-30 bps — leaving the ISV with less margin than a registered PayFac. The tradeoff is speed, simplicity, and shared liability.
“PayFacs only matter for card payments.” The model is expanding to ACH, real-time payments, and even crypto. The principle — master entity onboards sub-entities — applies beyond cards.