Company details, ownership and bank data arrive through your branded form, in your wording rather than a vendor's.
White Label Payment Facilitator Solution
Onboard businesses under your own brand.
A payment facilitator signs businesses itself instead of sending each one to an acquirer. This page sets out the PayFac model, what the payment platform underneath has to do, and which parts stay a regulated responsibility rather than a software one.
What Is a White Label PayFac Model?
A PayFac holds one master account with an acquirer and onboards sub-merchants underneath it. Each merchant trades under that umbrella, so it can accept card money in days rather than after a full underwriting cycle of its own. Doing this at scale needs software you manage yourself: onboarding, account records, payment processing, split funding and fee logic.
A payment facilitator solution supplies that software under your brand. Your clients see your portal, your API and your statements. What no vendor supplies is the licence: the registration, the acquirer agreement and the liability for every business you sign remain yours.
PayFac vs ISO vs Payment Gateway vs Orchestration
An ISO solution refers merchants and earns a share; a gateway moves the transaction; an orchestration layer picks which provider receives it. A PayFac does what none of them do: it takes on the merchant relationship and the risk attached to it. That difference turns a payment product into a regulated business, and it is the first thing to be honest with yourself on.
Merchant and Sub-Merchant Onboarding
Four stages your own team manages itself rather than through the acquirer.
KYB and KYC checks run against the transaction record, because sanctions screening and document capture are managed inside the payment system.
Your risk policy sets limits, pricing and reserve. Automatic approval for clean profiles, a managed queue for the rest.
Credentials are issued, the status flips to live, and the first payment can be processed the same day.
Merchant Management and Configuration
What you manage per account, with no release and no support ticket.
Setting
Payment limits
Pricing
Descriptor
Settlement schedule
Status
Why it sits per account
Daily and monthly caps follow the risk profile you underwrote.
Each business has its own rate card and its own margin.
A clear billing descriptor prevents disputes before they start.
Daily, weekly or on demand, with a reserve held where needed.
Pause, suspend or close one account and leave the rest running.
Payment limits
Why per account
Daily and monthly caps follow the risk profile you underwrote.
Pricing
Why per account
Each business has its own rate card and its own margin.
Descriptor
Why per account
A clear billing descriptor prevents disputes before they start.
Settlement schedule
Why per account
Daily, weekly or on demand, with a reserve held where needed.
Status
Why per account
Pause, suspend or close one account and leave the rest running.
Transaction Processing and Payment Routing
Every transaction carries a merchant identity through the whole path. Five things the payment stack has to get right.
- Attribute each transaction to the right merchant before anything else happens.
- Apply that account's limits, risk rules and accept-or-decline policy.
- Route the transaction to the acquirer with the best live approval for that card and market.
- Retry an eligible transaction failure on the next provider and never duplicate the charge.
- Return one normalised result to the client and to your own ledger.
The decision engine behind step three is described on smart payment routing.
Fees, Pricing and Revenue Configuration
Your margin lives here, so the fee engine has to be as configurable as the risk engine.
Per-account rate cards, so a large account and a new one are not priced from one template.
Blended or interchange-plus, whichever your acquirer agreement and your market expect.
A fixed fee per transaction alongside the percentage, calculated at authorisation not at settlement.
Chargeback, refund and retrieval fees priced explicitly rather than absorbed into your margin.
Currency conversion as a separate line, so nobody has to reverse-engineer the rate.
Revenue share for referral partners, calculated by the platform and paid from one ledger.
Payouts, Split Funding and Settlement Operations
Money in is one problem. Getting it to the right party on the right day is the one that generates support tickets.
One card payment can be divided between the seller, a marketplace fee and your own margin at the moment it is approved, so the ledger never has to reconstruct that split afterwards from a settlement file that arrived days later.
Settlement timing is a commercial lever, not a technical constant. Daily settlement for a trusted business, weekly with a rolling reserve for a newer one, and an on-demand option where the funding model and the risk profile both allow it.
Every acquirer settlement line is matched against captured payments, fees and reserves, and only exceptions reach a human. Your clients get a statement that agrees with your ledger, which is what keeps arguments about money rare.
Risk, Chargebacks and Fraud Operations
As a PayFac you carry the loss when a business under you fails. That changes the shape of the risk function: it watches accounts as well as payments, and it acts on the account rather than only on the payment.
The platform side is ordinary. Scoring before authorisation, velocity rules per account, chargeback alerts sent to the right account, and ratio monitoring against scheme thresholds per account rather than in aggregate.
The conclusion worth writing down
A payment model that only monitors transaction data will find its losses in account behaviour instead. Watch the account curve: sudden volume, a shift in ticket size, refunds that outpace sales, or a complaint cluster. Those signals arrive before the chargebacks do, and they are what your reserve policy exists to answer.
Working out whether this model fits your business?
Branded Merchant Portal and Back Office
1
Your brand, your domain
The portal and the API documentation carry your name, so every API key a client sees is yours. Nothing a client reads points anywhere else.
2
What the client sees
Payments, disputes, settlements, statements and credentials for the account they hold with you.
3
What your team sees
The whole portfolio: onboarding queues, limits, pricing, reserves and today's exceptions to work through.
4
Who can do what
Role-based access with a versioned audit trail, so any change has an author and a timestamp behind it.
API and Provider Integrations
Your clients integrate once, against your own payment API, under your brand. Behind it the payment layer holds the connectors to acquirers, alternative payment methods and the risk vendors you already use, so adding a provider is configuration rather than a release your clients have to absorb.
The payment API surface needed here is small but strict: create a merchant, read its status, accept a payment, refund it, list settlements, and receive a signed webhook for each state change. Everything else can wait; those six cannot.
Sub-merchant — a business that can accept card payments under a master agreement instead of holding its own acquiring contract. It is onboarded, priced and monitored by you, and you are also the party the acquirer holds responsible for its behaviour. The connector layer beneath is described on payment connector.
Compliance Responsibilities in a PayFac Model
What software does: run KYB and KYC workflows, manage the records, screen payments, enforce the limits you set, hold card data inside a PCI DSS Level 1 ready environment and produce the audit trail an examiner asks for.
What software cannot do: hold the registration with the card schemes, sign the acquirer agreement, own the AML programme, or accept liability for a merchant you signed. Those stay yours. PayAdmit is a technology vendor and does not act as a payment facilitator, an acquirer or a PSP.
Build a PayFac Stack vs Use White Label Infrastructure
Building the stack yourself is right when onboarding logic is your actual product. For everyone else the maths is unkind: the onboarding engine, the fee engine, the ledger, the portal and the certification work all have to exist before the first payment is processed, and none of them are what your customers are buying. A licensed solution moves the launch from a multi-year programme to a configuration exercise, and leaves the registration — which nobody can shortcut — as the critical path it always was.
Launch Process
What a deployment looks like once the scheme registration is under way.
Markets, business types, acquirer agreements, the pricing model and the risk policy you intend to apply.
Branding, onboarding forms, fee tables, limits, settlement schedules and the portal your clients will manage.
Acquirer testing, PCI scope confirmation and end-to-end runs covering declines, refunds, disputes and settlements.
A first cohort onboards, volume ramps against your limits, and the rest follow once the numbers hold.
Frequently Asked Questions
Do we need our own registration?
Yes, if you want to be the payment facilitator. The scheme registration and the acquirer sponsorship are yours to obtain; the platform supplies the software you operate once you have them.
How fast can a merchant start accepting payments?
Same day for a clean profile that clears automated checks, and a few days where the file goes to a manual queue. Speed is a function of your own risk policy rather than of the software.
Can pricing differ per account?
Yes. Rate cards, fixed fees, dispute charges and revenue share are configured per account, and a house default can be inherited then overridden where a deal requires it.
Does PayAdmit hold any of the money?
No. Funds move between the acquirer, your settlement account and the businesses you signed. We supply the software layer and never take custody of funds.
What happens if an account goes bad?
You carry the exposure, which is why reserves and limits are set at onboarding rather than after a problem. The platform lets you suspend the account, hold a settlement and freeze processing immediately, but the loss is yours.
Can we keep our existing acquirer?
Yes. Existing acquirer relationships connect as routes, and more can be added later with no change to how your clients integrate.
Is this model right for a small portfolio?
Often not. Below a certain volume the registration and compliance overhead outweighs the margin, and a referral or gateway arrangement earns more per hour of effort. The break-even depends on your ticket size and your cost base.
How long does a deployment take?
One to two months of platform work in a typical case. The registration and the acquirer agreement usually take longer, so most operators run both tracks in parallel from the start.