Skip to main content
Commerce Security Authority
Category: Payment Ecosystem

Payment Facilitator

Also known as: PayFac, payfac, payment facilitation provider
Simply put

A payment facilitator (PayFac) is a merchant services business that lets platforms and software providers accept card and other non-cash payments on behalf of the businesses that use them. Instead of each individual business setting up its own merchant account, the PayFac aggregates them as sub-merchants under its own arrangement, simplifying onboarding and payment processing. The PayFac typically handles integration and paying out funds to those sub-merchants.

Formal definition

A Payment Facilitator (PayFac) is a merchant services entity that aggregates payment processing for multiple sub-merchants under its own master merchant relationship with an acquiring bank, rather than each sub-merchant holding a direct merchant account. In this model the PayFac takes on payment integration and acts in a processing capacity on behalf of its onboarded users, and it directly handles disbursement of funds to sub-merchants. Most operational requirements applicable to PayFacs are defined and enforced by the card networks and acquiring banks, and vary by network and region; readers should confirm current obligations against the applicable card brand and acquirer rules. Note that a PayFac's role in aggregating and processing cardholder data may bring it within the scope of applicable PCI DSS obligations, which should be assessed against the current published standard.

Why it matters

The payment facilitator model has reshaped how software platforms and marketplaces bring businesses online, because it removes the need for each individual business to establish its own direct merchant account. By aggregating many sub-merchants under a single master merchant relationship with an acquiring bank, a PayFac can dramatically simplify and speed up onboarding. For security and compliance teams, this consolidation matters because it concentrates responsibility: the PayFac sits in the flow of cardholder data and funds for potentially large numbers of sub-merchants, which shifts where risk, controls, and oversight need to be applied.

Because a PayFac aggregates and processes cardholder data on behalf of its sub-merchants, its role may bring it within the scope of applicable PCI DSS obligations. The nature and extent of those obligations depend on how the PayFac handles, stores, or transmits cardholder data and must be assessed against the current published standard rather than assumed. PCI DSS is distinct from other standards in the PCI portfolio, and the specific validation path for a PayFac should be confirmed with its acquirer and the relevant card networks.

Operationally, most of the requirements that govern PayFacs are defined and enforced by the card networks and acquiring banks, and these rules vary by network and region and change over time. This means a PayFac's obligations around sub-merchant onboarding, monitoring, and fund disbursement are not fixed by a single universal rulebook; teams should confirm current obligations against the applicable card brand and acquirer rules rather than relying on generalized descriptions.

Who it's relevant to

Software platforms and marketplaces
Platforms and software providers that want to let the businesses using them accept card and other non-cash payments are the primary users of the PayFac model. It lets them offer embedded payments and simplified onboarding by aggregating those businesses as sub-merchants, rather than requiring each one to obtain its own merchant account.
Acquiring banks
Acquirers hold the master merchant relationship with the PayFac and are among the entities that define and enforce the requirements that govern it. They have a direct interest in how the PayFac onboards and monitors sub-merchants and disburses funds, and these obligations vary by network and region.
Compliance and PCI teams
Because a PayFac aggregates and processes cardholder data, its role may bring it within scope of applicable PCI DSS obligations. Compliance officers and PCI assessors need to determine the applicable validation path against the current published standard and the acquirer's requirements, rather than assuming a fixed obligation.
Sub-merchants
Businesses onboarded under a PayFac accept payments through the facilitator's arrangement rather than through their own direct merchant account, and receive fund disbursements from the PayFac. They benefit from simplified setup but should understand that the PayFac sits in the flow of their payments and funds.
Fraud and risk teams
Because a PayFac aggregates many sub-merchants under one relationship, risk and fraud monitoring teams at the PayFac and its acquirer must consider risk across the aggregated portfolio, including sub-merchant onboarding and monitoring, within the rules set by the card networks and acquiring banks.

Inside PayFac

Master Merchant Account
A PayFac operates under its own master merchant account with an acquiring bank, aggregating many smaller businesses (sub-merchants) beneath it rather than requiring each to establish a direct acquiring relationship.
Sub-Merchant Onboarding
The process by which a PayFac underwrites, registers, and provisions sub-merchants, including identity verification, risk assessment, and application of Know Your Customer and anti-money-laundering checks as required by network and regulatory rules.
Sub-Merchant Underwriting and Risk Monitoring
The PayFac assumes responsibility for evaluating and continuously monitoring sub-merchant risk, including transaction monitoring intended to help detect potential fraud, prohibited activity, or unusual chargeback patterns.
Settlement and Funds Flow
The PayFac typically receives settlement funds and disburses them to sub-merchants, which places the PayFac within the funds flow and may create associated liability and reserve considerations.
PCI DSS Responsibility
A PayFac is generally responsible for its own PCI DSS compliance for the systems it operates and may bear responsibility for how sub-merchant card data is handled, depending on the integration model. Applicable validation requirements depend on transaction volume and card brand program rules, which readers should confirm against current published requirements.
Card Brand Registration
Payment facilitators are subject to registration and program rules defined by the card networks, which vary by brand and region and are subject to change.
Sub-Merchant Agreement
A contractual arrangement between the PayFac and each sub-merchant defining responsibilities, prohibited activities, liability, and compliance obligations flowing down from network and acquirer requirements.

Common questions

Answers to the questions practitioners most commonly ask about PayFac.

Does becoming a payment facilitator remove my sub-merchants' PCI DSS responsibilities?
No. A payment facilitator does not eliminate PCI DSS obligations for its sub-merchants; it changes how those obligations are structured and validated. The PayFac typically takes on responsibility for certain controls and may simplify validation for sub-merchants, but PCI DSS applicability depends on how each party stores, processes, or transmits cardholder data. Sub-merchants generally still have responsibilities, and the specific validation path varies by the sub-merchant's environment, transaction channels, and the card brands' current programs. Confirm the applicable requirements against the current published PCI DSS and the relevant card brand rules rather than assuming all responsibility shifts to the PayFac.
Is a payment facilitator the same thing as a payment gateway or an acquirer?
No. These are distinct roles that are often confused. An acquirer (acquiring bank) is the entity licensed by the card brands to hold the merchant acquiring relationship and settle funds. A payment gateway is a technical service that routes transaction data between parties. A payment facilitator is a registered entity that enters into a relationship with an acquirer to onboard and manage sub-merchants under its own master merchant account, aggregating them rather than requiring each to obtain a direct acquiring relationship. A single organization may perform more than one of these functions, but the roles, contractual relationships, and governing rules differ, and card brand registration and rules define who may act as a PayFac.
What must a payment facilitator address when onboarding sub-merchants?
Onboarding practices are typically defined by the acquirer agreement and card brand rules, and commonly include due diligence and underwriting on the prospective sub-merchant, verification of business legitimacy, screening against applicable prohibited or restricted business categories, and ongoing monitoring for changes in risk. The goal is intended to help reduce onboarding of fraudulent or high-risk sub-merchants, though no screening process eliminates that risk. Specific required steps, thresholds, and documentation vary by acquirer, card brand program, and region, so confirm them against current contractual and network requirements.
How does a payment facilitator model affect PCI DSS scope for the PayFac itself?
A PayFac's PCI DSS scope depends on how its systems store, process, or transmit cardholder data and how they connect to sub-merchant and payment environments. Because PayFacs commonly handle transaction data across many sub-merchants and operate onboarding, aggregation, and settlement systems, they often have substantial in-scope environments. The use of tokenization, encryption, truncation, or masking may reduce scope, but only where the implementation and validation actually limit exposure of cardholder data; the label alone does not determine the effect. Determine and validate scope against the current PCI DSS and, where applicable, related standards such as PCI P2PE for point-to-point encryption solutions.
What monitoring is expected of a payment facilitator after a sub-merchant is live?
Ongoing monitoring is generally expected and typically includes transaction and volume monitoring, watching for indicators of fraud, excessive chargebacks, or activity inconsistent with the sub-merchant's underwritten profile. These controls are intended to help detect problematic behavior earlier, but they involve false-positive and false-negative trade-offs and do not guarantee detection of all fraud or misuse. The specific monitoring obligations, chargeback thresholds, and reporting expectations are defined by acquirer agreements and card brand rules, which vary by region and change over time; confirm them against current requirements.
How are settlement and fund flows typically structured under a payment facilitator?
Under the PayFac model, transactions are generally processed under the payment facilitator's master merchant account, and the PayFac is often responsible for distributing settled funds to its sub-merchants according to its agreements. This introduces responsibilities around fund handling, reconciliation, and controls over disbursement. The precise permitted fund-flow structures, any limits, and related obligations are governed by the acquirer relationship and card brand rules, which vary by region and may change, so validate the specific arrangement against current contractual and network requirements.

Common misconceptions

Sub-merchants under a PayFac have no PCI DSS obligations because the PayFac handles compliance.
The PayFac is responsible for its own PCI DSS compliance and often for the aggregation infrastructure, but sub-merchants may still carry responsibilities depending on how they handle or transmit cardholder data. The applicable validation scope depends on the integration model and current card brand program rules, which should be confirmed rather than assumed.
A PayFac and a traditional payment processor or ISO are the same thing.
These roles differ. A PayFac operates under its own master merchant account and aggregates sub-merchants within its funds flow and liability, whereas an ISO or processor arrangement may not place the entity in the funds flow or assume the same underwriting and risk responsibilities. Roles and obligations are defined by acquirer and card brand rules.
Onboarding sub-merchants faster means the PayFac can skip underwriting and monitoring controls.
Streamlined onboarding does not remove the obligation to underwrite and monitor sub-merchants. Transaction monitoring is intended to help detect potential fraud and prohibited activity but does not eliminate risk, and controls involve false-positive and false-negative trade-offs.

Best practices

Confirm current PCI DSS validation obligations and applicable card brand payment facilitator program rules against the published standards and network requirements, rather than assuming fixed requirement numbers or thresholds.
Clearly define and document the division of PCI DSS responsibilities between the PayFac and each sub-merchant based on the specific integration model and how cardholder data flows.
Apply sub-merchant underwriting and continuous transaction monitoring intended to help detect potential fraud, prohibited activity, and chargeback anomalies, while accounting for false-positive and false-negative trade-offs.
Ensure sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs) is not stored after authorization, even when encrypted, and limit storage of any cardholder data to what is necessary under defined controls.
Use appropriate data-reduction techniques such as tokenization, truncation, or masking where suitable, recognizing their effect on scope depends on implementation and validation rather than the label alone.
Maintain sub-merchant agreements that flow down network, acquirer, and compliance obligations, and address liability, reserves, and funds-flow responsibilities.
Reassess registration status and program obligations periodically, since card brand and network rules governing payment facilitators vary by region and change over time.