How to Become a PayFac in 2026: Embedded Payments for Vertical SaaS
AI Summary: Becoming a Payment Facilitator (PayFac) allows vertical SaaS companies to offer embedded payment services directly within their platforms. The process involves partnering with an acquiring bank, completing card network registration, integrating payment infrastructure, and building merchant onboarding, underwriting, and risk management capabilities. This guide explains the PayFac model, key requirements, revenue opportunities, and the differences between PayFac-as-a-Service and operating as a full PayFac. |
Vertical SaaS companies (software for salons, clinics, gyms, property managers, schools, field services, restaurants) sit right where their customers get paid. Adding payments to that software can turn a subscription business into a payments business, with revenue that grows with each customer's sales. The question is how deep to go: refer customers to a processor, embed a partner's PayFac-as-a-service, or become a payment facilitator (PayFac) yourself.
This guide explains what a PayFac is under the card network rules, the ladder of embedded payment models, what full PayFac status involves, the regulatory edges to check in the US, a reference architecture, the APIs you will integrate, and the factors that drive cost and timeline. For a wider view of licences across the US and India, start with our Fintech Licensing Requirements 2026 guide.
What a payment facilitator is
Visa's Payment Facilitator Model describes a PayFac as a third-party agent that:
Signs a merchant acceptance contract with a sponsored merchant on behalf of an acquirer, so the PayFac can own the merchant relationship without the acquirer being party to the contract (at the acquirer's option), and
Receives and distributes settlement of transaction proceeds from the acquirer on behalf of its sponsored merchants.
The important point is liability. Visa says acquirers are responsible for the acts of both PayFacs and their sponsored merchants. That is why every PayFac needs a sponsor: an acquiring bank (often working through a processor) that contracts with you, monitors you and registers you with the networks.
Party | Role |
Card networks (Visa, Mastercard and others) | Set the rules, including the PayFac framework and registration |
Acquirer / sponsor bank | Contracts with the PayFac, does due diligence, registers it with the networks, stays responsible for its activity |
Processor | Provides authorisation, clearing and settlement technology; often packages the sponsor relationship |
PayFac | Onboards and contracts sponsored merchants, monitors them, receives and distributes settlement |
Sponsored merchant | Your SaaS customer who accepts card payments through you |
Visa also lists eligibility points. A PayFac cannot be listed on the Visa Merchant Screening Service (VMSS) or similar files. It cannot sponsor another PayFac, a staged digital wallet or P2P/money transfer activity. Sponsored merchants must be in the acquirer's jurisdiction. Above a Visa-set annual sales volume, a sponsored merchant may need to sign a direct agreement with the acquirer while keeping the PayFac for acceptance and settlement. Mastercard has its own framework: acquirers register payment facilitators with Mastercard, and the Mastercard Rules set PayFac obligations.
The embedded payments ladder
Most vertical SaaS companies should not start as a full PayFac. Here is how the options compare.
Model | What you own | Who carries network liability and holds funds | Your build effort | Revenue control |
Referral / ISV partnership | A link or integration to a processor; the processor owns the merchant | Processor and its acquirer | Low | Low (revenue share) |
PayFac-as-a-service (PFaaS) | The merchant experience, pricing and branding on top of a provider's PayFac licence and stack | The provider (it is the registered PayFac) | Medium | Medium to high |
Managed or hybrid PayFac | You are registered as a PayFac, but a provider runs underwriting, risk or settlement operations for you | You, with contractual support | Medium to high | High |
Full PayFac | Registration, underwriting, risk, settlement, disputes, compliance and operations | You, under your sponsor acquirer | High | Highest |
PFaaS is where most platforms land. Providers in this space include Stripe Connect, Adyen for Platforms, Finix, Payrix and others. Our overviews of payment gateway APIs for US fintech apps and embedded finance and BaaS providers compare options. Check each provider's current product terms, because these change.
What full PayFac status involves
If you decide to become a registered PayFac, expect these workstreams:
Sponsor acquirer and processor selection. The sponsor reviews your financials, ownership, policies and risk controls before it registers you with the networks.
Network registration. Your acquirer registers you with Visa and Mastercard after its due diligence. Visa says the acquirer must confirm it has done a comprehensive risk and financial review of the PayFac.
Policies and controls. Merchant onboarding and underwriting policy, prohibited and high-risk merchant lists, transaction monitoring, chargeback management, reserves and funding holds, sanctions screening, and information security.
PCI DSS compliance. As a service provider that stores, processes or transmits cardholder data, or that can affect its security, you must meet PCI DSS at the level your acquirer and the networks require. Using tokenisation and hosted fields can shrink your scope considerably.
Financial exposure. Your sponsor may require collateral or reserves, because you carry first-loss exposure for merchant losses and chargebacks you cannot recover.
Operations. Underwriting staff, risk analysts, dispute handling, merchant support and finance operations.
The operational load is the real cost. The technology is the easier part.
Regulatory edges to check
PayFacs are not licensed by a single US regulator, but several laws touch them. Treat this section as a checklist for your counsel, not legal advice.
Money transmission
Handling sub-merchants' funds raises the question of whether you are a money transmitter. At the federal level, FinCEN's definition of money transmitter in 31 CFR 1010.100(ff)(5) excludes a person that only acts as a payment processor to facilitate the purchase of goods or services, or the payment of bills, through a clearance and settlement system, under an agreement with the seller or creditor. FinCEN's administrative rulings explain how it applies the exemption, including that funds should move through systems that admit only BSA-regulated financial institutions. How you pay out matters.
State law is separate. Many states have exemptions, such as agent-of-payee provisions, but the scope varies by state. Get a state-by-state view before you design fund flows that touch your own accounts. If your product also lets end users send money to each other, you are into money transmission. Our money transmitter app guide covers that route.
Tax reporting (Form 1099-K)
A PayFac that settles card payments to its merchants is generally treated as a payment settlement entity for IRS purposes. The IRS Form 1099-K FAQs say merchant acquiring entities report payment card transactions with no minimum threshold, while third-party settlement organisations report above $20,000 and 200 transactions. Your platform needs TIN collection and validation, gross payment aggregation per merchant, and year-end filing, or a provider that does it for you. See the Form 1099-K instructions for details.
KYC, KYB and sanctions
Card network rules require due diligence on sponsored merchants, and US sanctions law applies to everyone. Build KYB with beneficial owner checks, OFAC screening, and website and business-model review into onboarding. Our compliance guide for US fintech apps covers the building blocks.
Reference architecture
Module | Responsibilities |
Sub-merchant onboarding | Embedded application inside your SaaS, KYB/KYC, beneficial owners, bank account verification, terms acceptance |
Underwriting and risk scoring | Rules and manual review queues, MCC assignment, processing limits, reserve and payout-delay settings |
Payments gateway layer | Tokenised card capture (hosted fields, SDKs, terminals), ACH and wallets, authorisation, capture, refunds |
Split settlement and payouts | Fee calculation, platform revenue split, payout schedules, holds and reserves, ACH payouts |
Ledger | Double-entry balances per sub-merchant: pending, available, reserved, paid out, disputed |
Reconciliation | Daily match of processor settlement files, bank deposits, payouts and ledger |
Disputes and chargebacks | Network dispute intake, evidence submission, merchant notifications, loss recovery |
Transaction monitoring | Velocity, refund-rate and chargeback-rate monitoring, MCC drift, prohibited activity detection |
Tax and reporting | TIN matching, 1099-K data, merchant statements |
Admin and compliance | Audit logs, policy configs, network reporting, sponsor bank reporting |
Sub-merchant onboarding and underwriting
Onboarding is where vertical SaaS has an edge. You already know the customer's business type and history. Pre-fill applications from your SaaS data, verify bank accounts instantly, and route only edge cases to manual review. Keep every decision and data source logged for your sponsor's audits.
Payments, split settlement and payouts
Design fee logic as configuration: per-transaction pricing, interchange-plus, monthly fees and platform revenue share. Payouts should support daily or custom schedules, instant payouts where your provider supports them, and holds for risk.
Ledger and reconciliation
The ledger is the heart of a PayFac. Every authorisation, capture, refund, dispute, fee and payout must post balanced entries, so you can answer "how much do we owe each merchant?" at any moment. Reconcile daily against processor and bank files. Our guide to payment orchestration for US fintechs covers multi-rail ledger patterns.
Risk, disputes and reserves
Monitor chargeback and refund ratios per merchant against network thresholds, hold reserves for high-risk merchants, and automate dispute evidence from your SaaS data (appointments, invoices, delivery records). That evidence is a real advantage vertical platforms have over generic processors.
Key APIs and integrations
Processor / PayFac provider APIs: merchant onboarding, payments, refunds, disputes, payouts, settlement reports and webhooks
KYB/KYC and sanctions: business verification, beneficial owner checks, OFAC screening
Bank account verification: instant account verification for payouts
ACH: for payouts and bank payments (see our ACH payment integration options)
Terminals and tap-to-pay: for in-person verticals
Tax: TIN matching and 1099-K filing
Accounting: sync of payouts and fees into merchants' books
If you are still choosing between processors and merchant service models, our explainer on merchant services providers sets out the trade-offs.
Cost and timeline drivers
We do not publish fixed prices because scope varies widely. These are the factors that matter:
Driver | Why it matters |
Model | PFaaS is an integration and product build; full PayFac adds registration, PCI, underwriting and operations |
Sponsor due diligence | Often sets the timeline for full PayFac more than engineering does |
Payment methods | Cards online, in-person terminals, ACH and wallets each add flows and reconciliation |
Payout options | Instant payouts, custom schedules and multi-party splits add ledger complexity |
Risk tooling | Automated underwriting and monitoring reduce headcount later but cost more up front |
PCI scope | Tokenisation and hosted fields keep scope small; handling raw card data expands it a lot |
Migration | Moving existing merchants from a referral partner to your own stack takes planning and re-papering |
A staged path for vertical SaaS
Start with PFaaS to prove attach rate and processing volume, with your own ledger view of merchant balances.
Own the data model. Keep merchant, payment and payout data in your systems so a later move is a migration, not a rebuild.
Build underwriting and risk tooling on top of the provider's controls.
Evaluate managed or full PayFac when your volume, margins and risk team justify the sponsor relationship and operations. Get counsel on money transmission and tax reporting before you change fund flows.
Migrate in cohorts, new merchants first, then existing ones.
Build embedded payments with Fintegration
Fintegration builds payment, lending and banking platforms for fintechs and SaaS companies in the US and India. We can help you compare PFaaS providers, design the sub-merchant onboarding, ledger, split settlement and reconciliation layers, and plan a path to PayFac status without a rebuild. Talk to our team to scope your embedded payments build.
FAQ
1. What is a PayFac and how does the payment facilitator model work?
A Payment Facilitator (PayFac) enables businesses to accept payments through a shared merchant account structure. It onboards and manages sub-merchants while working with an acquiring bank and payment processor.
2. How can a vertical SaaS company become a PayFac?
A vertical SaaS company can partner with a sponsor bank, complete card network registration, integrate payment processing infrastructure, and establish merchant onboarding, underwriting, and risk management processes.
3. Do I need a license or sponsor bank to become a PayFac in the US?
You generally need a sponsoring acquirer to operate as a registered PayFac under the card network model. Additional state or federal licensing requirements depend on your funds flow, services, and business activities.
Stripe+1
4. What is the difference between PayFac-as-a-Service and becoming a full PayFac?
PayFac-as-a-Service lets you embed payments through an established provider, while a full PayFac manages its own registration, merchant underwriting, risk, compliance, and payment operations.
5. How does a PayFac make money from embedded payments?
A PayFac can generate revenue through payment processing margins, transaction fees, and other merchant services. The actual revenue depends on processing volume, pricing agreements, provider costs, and risk exposure.
