What Is a Payment Facilitator (PayFac)? A Complete Guide

A payment facilitator (PayFac) is a company that lets other businesses accept card payments under its own master merchant account, then manages onboarding, underwriting, funds flow, risk monitoring, and compliance for those businesses as sub-merchants.

The model is common in platform payments, marketplace payments, vertical SaaS, embedded finance, and merchant aggregation. It can help businesses onboard sellers faster, but it also moves more responsibility onto the PayFac.

For cross-border merchants, the most important question is often different: do you actually need to become a registered PayFac, or do you need a provider that already supports local payment methods, local acquiring, settlement, risk controls, and reconciliation across markets?

This guide explains the PayFac model, how it differs from ISOs, acquirers, processors, and sub-merchants, and how to decide which path fits your business.

What is a payment facilitator?

A payment facilitator is a company that helps other businesses accept payments by onboarding them under a master merchant account.

Instead of every small merchant applying directly for its own merchant account, the PayFac signs up those businesses as sub-merchants. The PayFac handles the front-line work: merchant onboarding, KYC/KYB checks, risk review, transaction monitoring, settlement coordination, dispute handling, and ongoing reporting.

This creates a faster onboarding experience for merchants, but it also means the PayFac carries more responsibility than a simple referral partner or software provider.

In practice, a PayFac model is usually built around four relationships:

• The customer pays.
• The sub-merchant sells the product or service.
• The PayFac aggregates and manages many sub-merchants.
• The acquirer and payment processor connect the PayFac to card networks and payment rails.

What is a sub-merchant?

A sub-merchant is a business that accepts payments under a PayFac’s master merchant account instead of holding its own direct merchant account.

The sub-merchant usually signs a contract with the PayFac, not directly with the card networks. The PayFac then manages onboarding, risk rules, monitoring, settlement logic, and reporting obligations.

This arrangement can be useful for smaller merchants, platform sellers, creators, service providers, and marketplace participants that need to start accepting payments quickly. It also means the sub-merchant has less direct control over underwriting rules, reserves, payout timing, dispute handling, and certain payment method decisions.

Full breakdown: What is a sub-merchant?

PayFac vs ISO vs merchant acquirer vs processor

The PayFac model is often confused with ISOs, merchant acquirers, and payment processors. They all sit near the payment chain, but they do different jobs.

The simplest way to separate them is to ask four questions:

• Who signs the merchant relationship?
• Who touches the funds?
• Who carries underwriting and chargeback risk?
• Who owns compliance and monitoring obligations?

A PayFac onboards sub-merchants under its own master merchant account and carries day-to-day risk responsibility.

An ISO, or Independent Sales Organization, mainly refers merchants to an acquirer. It may sell payment services, help with onboarding, or manage the commercial relationship, but it typically does not sit in the funds flow or carry the same underwriting responsibility as a PayFac.

A merchant acquirer is the financial institution or acquiring entity that enables merchants to accept card payments and connects into the card-network environment. In a PayFac stack, the acquirer usually sits beneath the PayFac and carries ultimate liability.

A payment processor handles the technical processing of payment messages, authorization requests, settlement files, and transaction routing. The processor is critical infrastructure, but it is not the same thing as the merchant-facing PayFac.

Full breakdowns: PayFac vs ISO · Payment facilitator vs merchant acquirer

Comparing a PayFac usually means untangling a few neighboring roles too. These break down where each one sits in the payment stack:

• Payment service provider (PSP)
• Merchant acquirer vs payment processor
• Payment gateway vs payment processor
• Merchant account vs payment gateway

Why companies choose the PayFac model

Companies usually consider the PayFac model when they want to embed payments into a platform experience.

For example, a vertical SaaS platform may serve thousands of small businesses. A marketplace may need to onboard sellers quickly. A creator platform may want to let users receive money without sending each user through a long merchant-account process.

The PayFac model can make sense when payments are part of the product experience, not just a checkout tool. It allows the platform to control more of the merchant lifecycle, including onboarding, pricing, risk rules, settlement logic, and support workflows.

The trade-off is responsibility. Once a company becomes a PayFac, it is no longer only providing software. It also takes on payment operations, risk ownership, compliance obligations, dispute processes, monitoring, and reporting.

What a PayFac is responsible for

A registered PayFac typically needs to manage several areas at once.This is formalized in Visa's own Payment Facilitator Model, which sets minimum equity and risk-rating standards for any company operating as a PayFac.

First, it must understand the card-network and acquirer requirements that apply to its model. The PayFac operates within a broader acquiring relationship and must follow the rules set by its sponsor bank, acquirer, processor, card networks, and applicable local regulations.

Second, it must perform merchant due diligence. This usually includes KYC, KYB, sanctions screening, business model review, prohibited-activity checks, ownership verification, and risk classification.

Third, it must monitor transaction behavior. A PayFac needs to watch fraud patterns, refunds, chargebacks, sudden volume changes, abnormal ticket sizes, and suspicious merchant behavior. Card-network risk tools sit alongside this monitoring — for example, address verification (AVS) checks the billing address a cardholder provides against issuer records to screen higher-risk transactions.

Fourth, it must manage funds flow. This includes settlement timing, reserves, payout rules, refunds, disputes, and reconciliation between customer transactions and sub-merchant payouts.

Fifth, it must maintain documentation. Underwriting policies, monitoring procedures, risk decisions, merchant agreements, compliance records, and operational controls all need to be clear enough for review.

Simplified checklist below; full version: Payment facilitator compliance checklist .

PayFac compliance checklist

A PayFac compliance program is not one document. It is a set of controls across onboarding, transaction monitoring, risk operations, data security, funds movement, and reporting.For the full picture, see Visa's Payment Facilitator and Marketplace Risk Guide, which covers underwriting, monitoring, and risk obligations in detail.

At a minimum, companies evaluating the PayFac path should review:

• Card-network registration and sponsor/acquirer requirements
• PCI DSS scope and service-provider obligations
• KYC, KYB, AML, and sanctions screening
• Local licensing and money movement rules
• Sub-merchant underwriting policies
• Funds flow, payout logic, reserves, and reconciliation
• Chargeback, refund, and dispute operations
• Ongoing monitoring and merchant reporting
• Documentation, audit trail, and policy ownership
• Whether PayFac-as-a-Service is enough before becoming a registered PayFac

The point is not only whether a company can technically process payments. The real question is whether it is ready to own the operational and compliance layer that comes with aggregating merchants.

When PayFac-as-a-Service may be enough

Not every company that wants embedded payments needs to become a registered PayFac immediately.

PayFac-as-a-Service can be a middle path. In this model, a provider gives platforms some of the merchant onboarding, payment acceptance, risk, and settlement capabilities of a PayFac structure, while reducing the amount of compliance infrastructure the platform needs to build from zero.

This can work well for platforms that want embedded payments but are still testing volume, markets, merchant categories, or risk exposure.

It may not be enough for companies that want full control over underwriting, pricing, reserves, funds flow, payment operations, and merchant lifecycle management. At that stage, the business may need to evaluate a deeper PayFac setup or direct acquiring relationships.

How to decide which path fits

The right model depends on business volume, geography, risk appetite, compliance readiness, and how much of the payment experience the company needs to control.

A company should consider staying a sub-merchant when it mainly needs to accept payments quickly and does not want to own payment compliance.

It should consider PayFac-as-a-Service when embedded payments are important to the product, but the company is not ready to build the full registration, risk, and compliance stack.

It should consider becoming a registered PayFac when payment onboarding, merchant control, pricing, risk policy, and settlement operations are central to the business model.

It should consider cross-border local acquiring when the main challenge is not merchant aggregation, but accepting local payment methods, improving authorization routes, settling across currencies, and managing payment operations in multiple markets.

Cross-border reality: PayFac is not always the answer

Many international merchants use the word “PayFac” when they are really describing a different need.

They do not necessarily want to aggregate many sub-merchants. They want to sell into more markets, accept the payment methods local users trust, reduce payment friction, manage settlement, and keep finance operations clear across currencies and entities.

That is a cross-border acquiring and local payment infrastructure problem.

For example, a gaming company expanding into Latin America may need Pix, local cards, bank transfer options, fraud controls, and local payout or settlement support. An AI SaaS company may need subscription payments, failed-payment recovery, multi-currency settlement, and cleaner reconciliation. A content platform may need a checkout experience that supports local wallets, card payments, and payment-status synchronization.

In those cases, becoming a PayFac may be unnecessary. The stronger question is whether the provider can support local methods, local acquiring paths, settlement, reporting, risk controls, and API integration across target markets.

Where HaiPay fits

For most cross-border merchants, the practical need is more direct: they need to accept payments from overseas users through local methods and reliable acquiring paths, then manage settlement, reconciliation, and risk across markets.

HaiPay is a licensed payment provider, regulated in the markets where it operates, including the Philippines, Indonesia, the United States, and Canada. Operating under its own licenses, it supports cross-border local acquiring, local payment methods, multi-currency settlement, payment API integration, order status synchronization, and localized risk-control capabilities — so businesses can build a more manageable payment stack. HaiPay does this under its own payment licenses, rather than by registering with the Visa or Mastercard card networks.

This is especially relevant when a company is expanding from one market into several markets. At that stage, payment work often shifts from “can we collect money?” to “can we collect through the right local methods, settle clearly, manage risk, and avoid rebuilding the payment stack in every market?”

• Built for developers. A REST/JSON API with signed requests covers pay-in (collect) and pay-out (pay); for example, the Brazil integration supports Pix for collection (QR) and payouts to CPF, phone, or email. See the HaiPay developer docs.
• Built for operators and finance teams. Payment status, settlement records, refund handling, and reconciliation data need to be understandable outside the engineering team.
• Built for cross-border growth. Local acquiring and local payment methods matter most when users are paying from markets where international cards are not always the preferred path.

See how cross-border local acquiring works →
Start integrating →