What Is a Payment Facilitator (PayFac)? A Guide for SaaS and Digital Businesses

Understanding the PayFac model and what it actually takes to run one across the US, India, and other global markets.

A SaaS company crosses a familiar threshold. It started by selling to customers at home, added a payment gateway, and grew. Then the first international deals arrive – a buyer in the US, a subscriber in Germany, a reseller in Singapore. Suddenly the finance team is fielding questions it can't answer: Who registers for VAT in the EU? Which US states does sales-tax nexus apply to? Why did the authorization rate on foreign cards just drop? Should we become a payment facilitator to control all of this ourselves?

That last question is where many software and digital businesses go wrong – either dismissing the PayFac model without understanding it, or chasing it without grasping the cost, the liability, and how differently it works in each market they want to enter.

This guide explains what a payment facilitator is, how the model works, how it compares to the alternatives, and how the rules change across the US, India, and the rest of the world. By the end, you'll have a clear framework for deciding whether becoming a PayFac is right for your business, or whether there's a faster, lighter path to compliant cross-border growth.

How to read the claims in this article. We separate three kinds of statement throughout: regulatory requirements (what a law or regulator mandates, cited to the primary source), industry estimates (typical market figures, which vary by provider and scope), and Transact Bridge's analysis (our own view). Where a number is an estimate, we say so.

What is a payment facilitator (PayFac)?

A payment facilitator (PayFac) is a company that holds a master merchant account and lets other businesses – its "sub-merchants" – accept card payments under that account, without each one opening its own merchant account. The PayFac handles onboarding, underwriting, compliance, and the flow of funds, so a sub-merchant can start accepting payments in minutes rather than weeks.

Consider the traditional route first. Historically, any business that wanted to accept cards applied for its own merchant account through an acquiring bank or an Independent Sales Organization (ISO) – a slow, paperwork-heavy process involving individual underwriting and a unique Merchant ID (MID). For a platform trying to onboard thousands of small merchants, that friction is fatal.

The PayFac model collapses it. Instead of every business getting its own MID, the payment facilitator obtains one master merchant account and creates sub-accounts beneath it. The PayFac model was formalized by Visa and Mastercard to let platforms onboard sellers for card acceptance at scale. Its sub-merchants simply "turn on" payments inside the software they already use – which is why vertical SaaS platforms, marketplaces, and ISVs adopt it: payments become a native feature of the product rather than a third-party bolt-on.

A PayFac isn't only a payments vendor; it takes on the legal and financial responsibility for every sub-merchant it onboards. That responsibility defines the model and explains why it is demanding to run.

Exact regulatory classification varies by legal entity and market, so treat these as illustrations of the model rather than fixed labels. What they share is the outcome: businesses accept payments quickly because the provider has absorbed the underwriting and compliance work a traditional merchant account would push onto the business itself.

How does a payment facilitator work?

A PayFac sits between its sub-merchants and the acquiring bank: it onboards and underwrites each sub-merchant, aggregates their transactions under its master account, moves settlement funds, and takes on the risk and compliance obligations the card networks require.

The transaction flow, simplified:

Throughout that flow, the PayFac owns: KYC/KYB checks → sub-merchant underwriting → risk & fraud monitoring → processing → settlement → chargebacks and disputes.

Step by step:

1. Onboarding & underwriting. The PayFac verifies each business – running KYC (Know Your Customer) and KYB (Know Your Business) checks, screening against sanctions and high-risk-merchant lists, and assessing risk. Because the PayFac carries the liability, this due diligence is non-negotiable.
2. Sub-merchant provisioning. Once approved, the merchant is added under the PayFac's master MID – no separate bank application, no multi-week wait.
3. Acceptance. The sub-merchant accepts cards (and often wallets, bank transfers, and local methods) through PayFac's integrated technology.
4. Authorization. Transactions route through the PayFac to a processor and the card networks for authorization.
5. Settlement & payout. Funds settle into the PayFac's account, and the PayFac pays out each sub-merchant, minus fees, on a defined schedule.
6. Monitoring. The PayFac watches transactions for fraud and chargebacks and manages disputes on an ongoing basis.

How does a payment facilitator make money?

A PayFac earns in two main ways: a markup on payment processing – a share of the fee on every transaction its sub-merchants run and, when it's also a software platform, subscription revenue from the software itself. For a SaaS business, embedding payments can turn a cost center into a high-margin revenue line, which is a large part of the model's appeal and why platforms often overestimate how easily they can capture it.

PayFac vs payment gateway vs PSP vs merchant of record

The terms overlap, and vendors use them loosely. In one line: a payment gateway transmits payment data; a payment processor moves the money; a payment facilitator onboards you and takes on card-network risk so you can accept payments fast; and a merchant of record becomes the legal seller and can take on the tax and compliance obligations that would otherwise stay with you.

*Footnote on "legal seller": card-network merchant-of-record terminology and legal/tax seller status are not necessarily the same thing. A provider can be the "merchant of record" to the card networks while your business remains the legal seller for tax purposes. See the distinction below.

PayFac vs PSP vs MoR: the comparison that matters most

Use this matrix to compare the models against the questions a CEO or finance lead actually asks.

The "merchant of record" trap. The phrase merchant of record means two different things, and conflating them costs companies money.

• At the card-network level, a PayFac is often described as the "merchant of record" for its sub-merchants – the master merchant on the acquiring side.
• At the tax and legal level, a Merchant of Record (such as Paddle, or the Apple App Store) becomes the legal reseller of your product. The customer buys from them, so they calculate, collect, and remit VAT, GST, and sales tax where they operate.

A PayFac solves acceptance. It does not, on its own, file your EU VAT return or your Texas sales-tax return – that obligation typically stays with you, which is why businesses on a PayFac often still buy separate tax software and register where they have nexus. 

A Merchant of Record can take on the seller-side tax and transaction obligations that would otherwise remain with the business. Different problems, different models.

PayFac vs embedded payments: not the same thing

"Embedded payments" describes the experience and business model – payments built natively into software so users never leave the product. "PayFac" describes one regulatory and operational structure that can sit behind that experience. 

Many SaaS teams meet the phrase "embedded payments" first and assume they must become a PayFac to offer it. They usually don't.

You can deliver embedded payments by becoming a registered PayFac, by using PayFac-as-a-service infrastructure, or by working with a PSP or Merchant of Record – each a different trade-off of control, revenue share, speed, and liability. 

The embedded experience is the goal; the PayFac licence is one route to it, and rarely the fastest for a company whose core product isn't payments.

The PayFac model across the US, India, and other global markets

"Payment facilitator" is largely a US card-network construct. The moment you cross a border, the model – and even the terminology – changes. For any business planning international expansion, this is the section that matters most.

United States: a card-network and state-by-state regime

In the US, operating as a PayFac means being registered with the card networks and building a compliance operation around it. The core elements:

• Card-network registration with Visa and Mastercard (and, for full coverage, American Express and Discover), including Mastercard's Business Risk Assessment and Mitigation (BRAM) program. Industry sources commonly cite annual registration of around $5,000 per network.
• Money Transmitter Licenses (MTLs) in states where you control the flow of funds – a regulatory requirement set state by state, with fees and surety-bond amounts that vary widely. Businesses that never touch settlement funds can sometimes avoid MTLs by structuring flows so money doesn't pass through them.
• Federal registration as a Money Services Business (MSB) with FinCEN, plus a Bank Secrecy Act / anti-money-laundering (BSA/AML) program, OFAC sanctions screening, and Suspicious Activity Report (SAR) filing.
• PCI DSS compliance at the level your volume requires, governed by the PCI Security Standards Council.
• Reserve funds to cover chargebacks and sub-merchant defaults.

The enforcement risk is real and long-standing. In 2013, Florida's Office of Financial Regulation fined Square $507,000 for operating without a state money-transmitter licence (covering 2010–2012 activity). The specifics are dated, but the lesson isn't: in the US, "move fast and sort out licensing later" is a liability.

India: the RBI Payment Aggregator framework, not "PayFac"

India does not use the PayFac framework in the same way as the US card-network model. Businesses performing payment-aggregation activities fall under the Reserve Bank of India's Payment Aggregator (PA) framework – and cross-border flows sit under a distinct licence. For any business operating between India and the West, this terminology bridge is essential.

On 15 September 2025, the RBI issued the consolidated Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 (available at rbi.org.in), replacing the earlier 2020–21 PA/PG guidelines and the 2023 cross-border rules. Issued under the Payment and Settlement Systems Act, 2007 and FEMA, 1999, it defines three categories:

• PA-O – online payment aggregation
• PA-P – physical / proximity (point-of-sale) aggregation
• PA-CB – cross-border aggregation, split into inward (receiving from overseas customers) and outward (Indians paying overseas merchants)

The following are regulatory requirements under those Directions:

The scale behind this regulation explains its rigor. Per Press Information Bureau (Government of India) data drawing on NPCI figures, UPI processed roughly 24,162 crore transactions worth about ₹314 lakh crore (~US$3.58 trillion) in FY 2025-26 and now accounts for around 85% of India's digital payment volume, with India holding close to 49% of global real-time payment transaction volume. 

Any business accepting Indian payments has to reckon with this rails-first, UPI-dominant, escrow-governed environment – not just cards.

The EU and UK: two separate regimes

Keeping this deliberately at decision level rather than licensing detail: in the EU, a PayFac's activity requires authorisation as a Payment Institution or Electronic Money Institution under PSD2. 

The practical advantage for expansion is EEA passporting – an authorisation in one member state can extend across the EEA via notification (authorisations are listed in the European Banking Authority register).

The UK is a separate regime. After Brexit, firms are authorised by the Financial Conduct Authority, and UK authorisations do not carry EEA passporting rights (nor do EEA authorisations cover the UK). 

A business selling into both must plan for two licensing tracks, not one. Separately from payment licensing, consumption tax – EU VAT (including OIDAR rules for digital services), UK VAT, and the B2B reverse charge – applies with its own thresholds and filings.

The cross-border takeaway: "Becoming a PayFac" is not one project. The US means card-network registration plus state money-transmitter licensing; India means RBI Payment Aggregator authorisation with net-worth floors and escrow; the EU means a PSD2 licence; the UK means a separate FCA authorisation. Each market is its own regulatory build.

What are the risks of becoming a PayFac?

Becoming a PayFac means absorbing risks a software company doesn't otherwise carry. They're manageable with the right capital and operations – which is why the model suits well-resourced, payments-centric platforms and strains everyone else. The main exposures:

• Merchant fraud : a fraudulent sub-merchant becomes your liability.
• Chargebacks and disputes : you're on the hook across the whole portfolio.
• Negative balances : when a sub-merchant can't cover refunds or chargebacks, the shortfall lands on you.
• Underwriting failures : approve the wrong merchant and you inherit their risk.
• AML/KYC/KYB failures : sanctions, SAR, and due-diligence lapses carry regulatory penalties.
• Reserve requirements : acquirers may require cash reserves, tying up capital.
• Data and security obligations : PCI DSS duties are continuous, not one-time.
• Settlement and liquidity risk : you manage the timing of money in and money out.
• Multi-market licensing complexity : every new country is a fresh authorisation.

This list isn't an argument against the model – it's the job description. Equipped teams can make the economics excellent; unequipped ones should weigh a managed alternative.

Payment facilitator for SaaS: when does it make sense?

For SaaS companies specifically, the PayFac question comes down to whether payments are central to the business or a supporting feature. Becoming a PayFac is a legitimate, sometimes highly profitable strategy – it lets a platform own payments and their economics at scale. 

It tends to fit vertical SaaS platforms and marketplaces that onboard large numbers of sub-merchants, where payment volume is high enough that the revenue share justifies running a payments operation.

Becoming a PayFac tends to make sense when:

• Payments are core to your product, not a supporting feature.
• You onboard a high volume of sub-merchants – the economics reward scale.
• You want direct control over payment economics and the revenue share.
• You can staff and fund underwriting, risk, and compliance as an ongoing operation.
• You have the capital and time to pursue licensing market by market.

Managed infrastructure tends to fit better when:

• Payments are secondary to your core product.
• Your priority is speed and international expansion.
• You'd rather not carry regulatory and fraud liability.
• You need to launch quickly, not over many months.
• You want tax and compliance handled externally.

The cost and time, realistically

Precise figures vary widely by scope, so treat the following as illustrative industry estimates, not fixed prices. A US PayFac build can require anywhere from hundreds of thousands to several million dollars before launch, depending on licensing scope (especially state money-transmitter coverage), compliance architecture, staffing, PCI level, and whether you handle settlement funds directly. 

Timelines commonly run to about a year or more before onboarding a first sub-merchant. None of that US spend transfers to India (where you'd need RBI PA/PA-CB authorisation and ₹25 crore of net worth) or the EU/UK (where you'd need PSD2 or FCA authorisation). The multi-market PayFac path is a company-defining commitment.

A quick decision framework

• Are payments core to your product, or a feature? If they enable your real product, owning the full PayFac stack is usually over-building.
• How many merchants are you onboarding? The model pays off at high sub-merchant volume.
• Where are your customers? If you're generating meaningful revenue outside your home market, cross-border tax, payment, and compliance requirements should be assessed before expansion – not after the first international sale. A PayFac addresses acceptance, not tax.
• Do you want to own liability, or offload it? A PayFac means you absorb risk; many software teams want the opposite.
• What's your time-to-market? Months and significant capital per market – versus days to integrate a managed alternative.

The alternative: managed payment infrastructure and the Merchant of Record model

For businesses whose goal is to sell across borders – not to become a payments company – managed cross-border infrastructure can deliver the outcome a PayFac promises, without each market's licences, capital, and liability landing on your balance sheet.

What that infrastructure does: it provides compliant payment acceptance in each target market; supports the local payment methods customers expect (cards, wallets, UPI and bank rails in India, local alternatives elsewhere), not just international cards; structures settlement to local rules. 

In a Merchant-of-Record arrangement, becomes the legal seller so that VAT, GST, and sales-tax calculation and remittance move off your plate in the markets where the provider operates. It collapses the compliance surface that would otherwise push a growing company toward becoming a PayFac in every country at once.

The strategic distinction is simple: a PayFac is a way to own payments; managed infrastructure and the MoR model are a way to use payments to scale globally.

Matching the payment model to your stage and geography

Checklist before expanding payments into a new market:

• Do we know the local regulatory construct (US PayFac/MTL vs. India RBI PA/PA-CB vs. EU PSD2 vs. UK FCA)?
• Who is the legal seller of record, and therefore who owes VAT/GST/sales tax?
• Do we support the local payment methods (e.g., UPI in India), not just international cards?
• What's our authorization rate on domestic cards in each market?
• Is settlement and escrow structured to local rules (e.g., India's InCA/OCA segregation)?
• Are chargebacks, refunds, and disputes handled locally?

Key takeaways

• A payment facilitator (PayFac) holds a master merchant account and onboards sub-merchants under it, trading fast payment acceptance for significant risk and compliance liability.
• A PayFac solves acceptance, not tax: you generally remain the legal seller and keep your VAT/GST/sales-tax obligations. A Merchant of Record can take those seller-side obligations on.
• The PayFac model is not portable across borders: the US runs on card-network registration plus state money-transmitter licensing; India uses the RBI Payment Aggregator (PA/PA-CB) framework, not "PayFac"; the EU runs on PSD2, and the UK on a separate FCA regime.
• Becoming a PayFac is a legitimate strategy for payments-centric, well-capitalized platforms – and typically a poor fit for companies whose main goal is fast international expansion.
• For many SaaS and digital businesses growing across the US, India, and other markets, managed MoR/PSP infrastructure delivers compliant, localized payment acceptance without becoming a regulated payments company.

FAQS

What is a payment facilitator in simple terms?

A payment facilitator lets other businesses accept card payments under its own master merchant account, handling onboarding, compliance, and payouts so each business doesn't set up its own merchant account. Stripe and Square are commonly cited examples.

What is the difference between a PayFac and a payment gateway?

A gateway only transmits payment data between checkout and processor. A PayFac goes further, onboarding businesses as sub-merchants under its master account and taking on the underwriting, risk, and compliance obligations the card networks require.

What is the difference between a PayFac and a Merchant of Record?

A PayFac helps you accept payments but generally leaves you as the legal seller, so you keep your tax obligations. A Merchant of Record becomes the legal seller and can take on VAT, GST, and sales-tax remittance plus chargeback and compliance responsibility. The core difference is who owns the liability.

Is Stripe a payment facilitator? 

Stripe operates a payment-facilitator model and offers PayFac-style infrastructure to platforms. Using a PayFac like Stripe does not by itself make you tax-compliant across jurisdictions – you generally remain responsible for your own VAT, GST, and sales tax unless you use a Merchant of Record.

How does a payment facilitator make money?

Mainly through a markup on payment processing – a share of the fee on each sub-merchant transaction – and, when the PayFac is also a software platform, through subscription revenue on the software.

Is there a PayFac model in India?

Not in the US card-network sense. India governs payment-aggregation activity through the RBI's Payment Aggregator (PA) framework under the 2025 Master Directions, with a dedicated PA-CB licence for cross-border flows. Non-bank PAs must reach ₹25 crore net worth by their third year and hold merchant funds in escrow.

How much does it cost to become a payment facilitator?

Figures vary widely; treat them as illustrative estimates. A US build can run from hundreds of thousands to several million dollars before launch – driven by state money-transmitter licensing, PCI DSS compliance, card-network registration, and staffing – typically over about a year or more. Those costs don't transfer to India or the EU/UK.

What are the risks of becoming a PayFac?

Merchant fraud, chargebacks, negative balances, underwriting and AML/KYC failures, reserve requirements, continuous data-security duties, settlement and liquidity risk, and licensing complexity in each new market. They're manageable with the right capital and operations, which is why the model suits payments-centric, well-resourced platforms.

How does a PayFac handle chargebacks and fraud?

It underwrites and monitors sub-merchants, screens transactions for fraud, manages disputes with the card networks, and often holds reserves to cover losses. Because it carries portfolio-level liability, the quality of its underwriting directly determines its exposure.

Can a SaaS company accept global payments without becoming a PayFac?

Yes. Managed cross-border infrastructure combining merchant-of-record and PSP capabilities provides localized acceptance (including methods like UPI in India), tax and compliance handling, and locally structured settlement – the outcome most companies want when they first consider becoming a PayFac. This is the approach platforms like Transact Bridge are built to deliver.