For platforms with meaningful payment volume, becoming a Payment Facilitator can turn payment acceptance into a strategic business line. It also introduces new merchant, risk, finance, and operational responsibilities that must work as one system.
What this business model means
This page explains PayFac in plain English: how sub-merchants fit into the model, what the platform takes responsibility for, a practical SaaS example, how PayFac differs from PSP-first, and why ledger and reconciliation become critical.
What is a Payment Facilitator?
A Payment Facilitator (PayFac) is a platform that enables other businesses — its sub-merchants — to accept payments through a sponsored acquiring arrangement. Instead of each merchant building a separate acquiring relationship, the PayFac manages a shared payment operating model that can include onboarding, pricing, transaction controls, reconciliation, and payouts.
PayFac can increase control over pricing, merchant experience, transaction operations, and payment margin.
Merchant onboarding, risk, ledger, reconciliation, and payouts must scale together rather than as disconnected systems.
A payment orchestration layer can reduce processor dependency and support multiple providers as the PayFac grows.
Why platforms become PayFacs
The PayFac model lets a platform manage sub-merchants as part of its own product and commercial model instead of treating payments as an external utility.
That control can improve onboarding experience, create new revenue, and enable provider optimization — but it also raises the importance of operational accuracy and financial visibility.
Payment Facilitator (PayFac)
A Payment Facilitator is a sponsored payments model in which a platform onboards and manages sub-merchants under an acquiring relationship and assumes defined responsibilities for their payment operations and merchant lifecycle.
Think of a PayFac as a platform that turns payments into part of its own product.
Instead of sending every customer business to an external PSP to create a separate payment setup, the platform can onboard those businesses as sub-merchants. The platform gains more control over the payment experience and economics, but also takes on more operational responsibility.
A vertical SaaS platform serves 5,000 fitness studios
The software already manages memberships, bookings, and billing for thousands of gyms. As a PayFac, it can onboard each gym as a sub-merchant and let the gym accept payments directly inside the software. The platform can then control merchant pricing and payment workflows while coordinating processor, risk, ledger, reconciliation, and payout operations.
What changes when you become a PayFac?
- Sub-merchant onboarding and lifecycle
- Merchant pricing and payment experience
- Transaction and operational controls
- Reconciliation, balances, and payout coordination
- Sponsor / acquiring relationships
- Card network and banking rails
- Certain processing and risk services
- Infrastructure required by the acquiring arrangement
Exact responsibilities depend on contracts, geography, acquiring arrangements, and the services included in the operating model.
PayFac vs PSP-first
The provider owns most of the payment infrastructure and the platform mainly consumes it.
Lower operational burden, but less control over payment economics.The platform manages sub-merchants and owns a larger part of the payment operating model.
More control and revenue opportunity, but significantly more operational complexity.Why this matters for Amaryllis: Once a platform controls thousands of sub-merchants, every fee, refund, reserve, dispute, settlement, and payout has to tie back to the correct merchant and original transaction. That is why ledger and reconciliation become core PayFac infrastructure.
Build one PayFac control layer
PayFac operations become difficult when onboarding, pricing, routing, transaction records, reconciliation, and payouts live in different systems. Amaryllis centralizes these functions above processors and acquiring rails.
One control layer across payment models.
Centralize merchant operations, routing, transaction records, reconciliation, and payouts while keeping underlying providers flexible.
A practical operating path
Create a centralized merchant lifecycle with status, pricing, risk, and operational controls.
Manage routing, fees, transaction events, adjustments, reconciliation, and reporting in one layer.
Calculate merchant balances and payouts from a unified ledger with clear financial traceability.
When this model fits
A PayFac model is a strategic choice about both economics and responsibility. Before adopting it, leadership should define expected payment margin, merchant ownership, risk operations, acquiring strategy, geographic scope, reconciliation requirements, and the resources needed to operate the model reliably.
Questions decision-makers ask
What is the difference between a PSP and a PayFac?
A PSP primarily provides payment acceptance and processing services. A PayFac goes further by managing sub-merchants under a sponsored acquiring relationship and taking responsibility for defined onboarding, pricing, transaction, reconciliation, and payout operations.
Can a platform become a PayFac gradually?
Yes. Many platforms begin PSP-first, then centralize merchant and transaction operations, introduce multiple providers and pricing control, and move toward a sponsored PayFac structure as volume and operational maturity grow.
Why does a PayFac need a unified ledger?
A PayFac must explain how each transaction becomes fees, adjustments, settlements, balances, and payouts. A unified ledger connects those events to one financial record and makes reconciliation and reporting scalable.
Capabilities that support this model
Reviewed for payment architecture clarity
Payments strategy, architecture, and operations.
Reviewed for technical and operational consistency.
Update when product, market, or regulatory context changes.