Payment Aggregator (PayFac, PSP, Master Merchant)

What Is a Payment Aggregator?

A payment aggregator is a company that processes card payments on behalf of multiple merchants under a single master merchant account. Instead of each business applying for and maintaining its own merchant account with an acquiring bank, the aggregator pools them together under one umbrella agreement.

Familiar examples include Stripe, Square, and PayPal. When a small business signs up with one of these services, they don't go through the traditional merchant account application process. Instead, they're onboarded as a sub-merchant under the aggregator's master account, and they can start accepting payments almost immediately.

That speed is the whole point. The traditional merchant-account model evolved in a world where most new businesses were physical shops with predictable cash flow. The aggregator model was built for a world where someone might decide on Sunday afternoon to start selling pottery online and want to take their first card payment by Monday morning. The compromise is real, though, and we'll get into it: you trade the friction of underwriting for less control and a higher per-transaction cost.

How Payment Aggregators Work

The traditional payment processing model requires each merchant to have a direct relationship with an acquiring bank. This involves an application process, credit checks, underwriting, and often a waiting period of days or weeks. The merchant gets their own merchant ID (MID) and is individually responsible for PCI DSS compliance, chargeback management, and contractual obligations with the acquirer.

Payment aggregators simplify this by sitting between the merchant and the acquiring bank:

• Master merchant account — The aggregator holds one or more merchant accounts with acquiring banks. All transactions from sub-merchants flow through these master accounts.
• Sub-merchant onboarding — New merchants sign up through the aggregator's platform, which handles identity verification, risk assessment, and compliance checks internally.
• Transaction processing — When a customer pays a sub-merchant, the transaction is processed under the aggregator's master MID. The aggregator then distributes the funds to the appropriate sub-merchant.
• Settlement — The aggregator receives settlement funds from the acquiring bank and handles the disbursement to individual merchants, typically on a daily or weekly schedule.

The mechanics behind a single transaction

It's worth slowing down on what actually happens when a customer pays a sub-merchant, because the path is different from a traditional merchant flow. The customer enters card details on the sub-merchant's checkout (or the aggregator's hosted checkout embedded into it). The card data goes directly to the aggregator's PCI DSS-validated environment, not to the sub-merchant's server. The aggregator authorises the transaction against the card networks using its own master MID and category code, applies its risk rules, and returns an approval to the sub-merchant.

From the card networks' perspective, the transaction belongs to the aggregator. Visa and Mastercard see a single large merchant. The sub-merchant data is included in the transaction message (Visa's Card Acceptor Name and Mastercard's equivalent fields) so the customer's statement shows a meaningful descriptor, but the regulatory and contractual responsibility sits with the aggregator.

How settlement actually flows

Funds land in the aggregator's bank account first — not the sub-merchant's. The aggregator deducts its fees, reserves any amount required for chargebacks or rolling reserves, and then pays the rest to the sub-merchant on a schedule (next-day, T+2, weekly, or held until a payout is triggered). This is a critical distinction from a traditional merchant account, where funds settle directly into the merchant's bank account from the acquirer. With an aggregator, the merchant is paid by the aggregator, not by the bank. That changes the legal nature of the relationship and the risk profile in ways that matter when things go wrong.

Advantages of Payment Aggregators

• Fast onboarding — Merchants can start accepting payments within minutes or hours, rather than the days or weeks required for a traditional merchant account.
• Simplified compliance — The aggregator takes on much of the PCI DSS compliance burden. Sub-merchants still have obligations, but they're significantly reduced compared to having a direct merchant account.
• No upfront costs — There are typically no setup fees, monthly minimums, or equipment purchases required.
• Integrated tools — Aggregators usually provide a complete payment stack including APIs, dashboards, reporting, and developer tools.

Why fast onboarding matters more than it sounds

Underwriting a merchant account properly takes time because the acquiring bank is extending credit. Every card payment is conditional on the merchant being good for the money if the customer charges back six months later. Aggregators get round this by holding the credit risk themselves, then using algorithmic underwriting to make a decision in seconds. The trade-off is that the aggregator's risk model is conservative by design — it has to assume the worst about any new sub-merchant because it can't afford to check each one carefully. That's why a brand-new business can be live in ten minutes but might have its first £10,000 day flagged for review.

Disadvantages and Limitations

• Higher per-transaction fees — Aggregators typically charge a flat percentage per transaction (often 1.4% to 2.9% plus a fixed fee) which can be more expensive than negotiated rates with a direct merchant account, especially for high-volume businesses.
• Account stability — Because sub-merchants share a master account, the aggregator must actively manage risk. This can lead to sudden account holds or freezes if the aggregator's fraud detection flags unusual activity — even if the merchant has done nothing wrong.
• Less control — Merchants have limited ability to negotiate rates, customise settlement schedules, or manage their own chargeback processes.
• Shared reputation — If the master merchant account experiences problems due to other sub-merchants, it can indirectly affect all merchants on the platform.

The freeze problem in real life

The single biggest complaint we hear about aggregators isn't the price — it's the freeze. A business is running fine, processes a slightly larger transaction than usual or sees a small spike in chargebacks, and the aggregator's algorithm holds the funds. The merchant gets an email saying their account is under review. Sometimes the review takes 48 hours. Sometimes it takes 180 days while a rolling reserve clears.

This isn't the aggregator behaving badly. It's the model working as designed. The aggregator carries the chargeback risk for every sub-merchant on its master account, so it has to be able to claw back funds quickly if a sub-merchant turns out to be a problem. That power has to be in the contract from day one. A business that depends on next-day settlement to pay wages or suppliers needs to understand that the aggregator can interrupt that cash flow at any time, for reasons that may or may not be explained.

When per-transaction cost actually bites

The fee maths is the part most people get wrong. A 2.9% + 20p rate on a £20 transaction is fine. The same rate on a £2,000 transaction is £58.20. If you're processing £100,000 a month in larger ticket sizes, you're paying around £2,900 a month to an aggregator. A negotiated interchange-plus deal on a traditional merchant account might cost you £1,200 for the same volume. The break-even point depends on the business but tends to land somewhere around £15,000-£30,000 a month in processed volume.

Payment Aggregator vs Payment Facilitator

These terms are closely related and sometimes used interchangeably, but there is a technical distinction. A payment facilitator (PayFac) is a specific designation granted by the card networks that allows a company to onboard and underwrite sub-merchants. A payment aggregator is a broader term for any company that processes transactions under a master merchant account.

In practice, most modern payment aggregators are also registered payment facilitators. The PayFac designation comes with specific regulatory obligations around sub-merchant due diligence, transaction monitoring, and compliance reporting.

The card network rules in plain English

Visa calls a PayFac a "Payment Facilitator". Mastercard calls it a "Payment Facilitator" as well (the older "Payment Service Provider" term has largely been retired). To be one, the company has to register with each card network it operates on, submit to ongoing risk monitoring, and apply the network's sub-merchant onboarding rules — including a £100,000 (or local equivalent) annual transaction cap per sub-merchant above which the sub-merchant has to be moved to its own merchant account. That cap is the reason why high-volume merchants on Stripe or Square eventually get nudged into a different commercial arrangement.

Marketplaces are a slightly different animal

It's worth flagging the marketplace model because the lines blur. A marketplace (Etsy, Uber, Airbnb) takes payment from the buyer and splits it between the platform and the underlying seller or service provider. Some marketplaces operate as PayFacs in their own right. Others use a third-party PayFac (Stripe Connect, Adyen for Platforms) and let that PayFac do the regulated work. The distinction matters because it changes who is responsible for KYC on the sellers, who handles chargebacks, and who is on the hook if a seller disappears with prepaid funds.

Payment Aggregators and Telephone Payments

Many businesses that use payment aggregators also need to take payments over the phone. However, most aggregator platforms are primarily designed for online and in-person payments. Telephone payment functionality — particularly secure, PCI-compliant phone payments — is often an afterthought or not available at all.

This creates a gap. A business might use Stripe for their online payments but still need a separate solution for secure telephone payments. The challenge is ensuring that both channels are PCI-compliant and that payment data flows securely regardless of how the customer chooses to pay.

What "MOTO support" really means

Aggregators will often advertise MOTO (mail order/telephone order) support. In practice that usually means the merchant or agent can type the customer's card details into a virtual terminal in the aggregator's dashboard while the customer reads them out over the phone. That works as a payment mechanism, but it puts the card details directly into the contact centre — spoken aloud, heard by the agent, sometimes captured in call recordings, sometimes typed into systems that weren't designed to hold cardholder data. The aggregator's PCI compliance covers the virtual terminal, not the phone call.

The fix is to keep the card details out of the contact centre entirely. Secure payment IVR hands the call off to an automated voice prompt, the customer keys their card number on the phone keypad, the digits are masked from the agent and never enter the contact centre's systems. The aggregator still processes the underlying transaction — the IVR layer just protects the bit the aggregator can't see.

PCI DSS Considerations for Aggregator Users

When you use a payment aggregator, the aggregator handles a significant portion of PCI DSS compliance on your behalf — but you are not entirely off the hook. As a sub-merchant, you still have responsibilities. At minimum, you must complete the appropriate Self-Assessment Questionnaire (SAQ) and ensure that any part of your business that touches card data meets the relevant PCI DSS requirements.

The aggregator's compliance covers the payment processing infrastructure, but it doesn't extend to your own systems. If you take card details over the phone, for example, and those details pass through your telephony equipment or are heard by agents, your contact centre environment is in PCI DSS scope — regardless of which aggregator processes the transaction.

This is a common blind spot. Businesses assume that because their aggregator is PCI-compliant, they are too. In reality, PCI compliance applies to every system and person that handles card data, not just the processor. Any business taking telephone payments needs to address the telephony channel separately.

Which SAQ applies to you

PCI DSS v4.0.1 is the current standard as of 2026. The SAQ you complete depends on how the cardholder data reaches the aggregator:

• SAQ A — The simplest. You qualify if all card data entry is handled by the aggregator's hosted page or iframe, and your systems never touch the card number. This is the goal for most online merchants using Stripe Checkout or similar.
• SAQ A-EP — You qualify if your website controls the form fields that collect card data, even though the data is submitted directly to the aggregator. This is what you get if you use Stripe Elements or similar in-page integrations. More controls apply because an attacker who compromises your site could intercept the card data before it leaves.
• SAQ D — The full questionnaire. You end up here if your systems handle card data at any point — including agents reading card numbers off a screen during phone payments.

An SAQ A environment has about 25 controls to evidence. SAQ D has over 300. That difference is the practical reason businesses care about scope.

What PCI v4.0.1 changed

PCI DSS v4.0 went live in March 2024 and v4.0.1 is the current revision. The deadline for previously future-dated requirements passed in March 2025, so by 2026 every assessment is on the new standard. The headline changes that matter for aggregator sub-merchants are stronger requirements around third-party service provider management (you have to evidence that you've checked the aggregator is doing what it claims), more granular requirements around scripts loaded on payment pages (Requirements 6.4.3 and 11.6.1 about script integrity), and a tightening of the phishing-resistant authentication rules. The script-integrity rules in particular caught a lot of merchants who thought they were SAQ A but had analytics tags loaded on their checkout page.

Edge cases and failure modes

What happens when the aggregator freezes funds

The aggregator's terms give them broad discretion to hold funds. Triggers include a chargeback rate above their threshold (often 1% of transaction count or 0.65% by value), a sudden change in transaction patterns, a single very large transaction, suspected fraud, or a complaint from a card scheme. The hold can range from a few days to 180 days. The merchant's options are limited: respond to the review, provide documentation, and wait. There's no acquiring bank to escalate to because the merchant's relationship is with the aggregator, not the bank.

Chargebacks under the aggregator model

Chargebacks work differently when you're a sub-merchant. The aggregator receives the chargeback notification from the card network first, then forwards it to you. You respond through the aggregator's dispute interface. The aggregator's fees apply (often £15-25 per chargeback win or lose). Your win rate depends partly on how well the aggregator's dispute system surfaces the evidence to the issuing bank — some are notably better than others. Critically, the aggregator can recover the disputed amount from your account immediately, before the dispute is resolved.

When the aggregator goes down

If the aggregator has an outage, every sub-merchant on the platform stops taking payments at the same time. This is a real operational risk for any business that depends on a single aggregator. The mitigation is to have a fallback — either a second processor configured in parallel, or a manual process for taking payments offline.

International transactions and currency conversion

Most aggregators support cross-border transactions but add a currency conversion fee (typically 1-2%) on top of the standard processing fee. They also apply a different fee tier for cards issued outside the merchant's home country (often an extra 0.5-1%). For a business with a significant international customer base, these add up fast.

Regulatory context: UK, EU, US

The aggregator model exists everywhere but the regulation around it varies. In the UK, payment aggregators have to be authorised by the FCA either as a payment institution or under permission from another authorised firm. The FCA's Payment Services Regulations 2017 set out the rules around safeguarding customer funds, which is why aggregators hold sub-merchant funds in segregated accounts.

In the EU, PSD2 is the framework. The interesting wrinkle is Strong Customer Authentication (SCA), which adds an extra layer at the cardholder side rather than at the aggregator. Aggregators handle the SCA flow for sub-merchants, but the sub-merchant still has to make sure their checkout integrates it correctly. PSD3 is in progress and will tighten the rules further, particularly around how PayFacs handle data and disclose fees.

In the US, the regulatory picture is fragmented. Aggregators have to register as Money Services Businesses with FinCEN at the federal level, then potentially get money transmitter licences in some or all 50 states depending on how they handle funds. This is why most US-focused aggregators avoid actually holding sub-merchant funds for long — the regulatory cost of doing so is significant.

Comparisons: aggregator, traditional merchant account, ISO

An aggregator gives you fast onboarding, shared compliance, and flat-rate fees. A traditional merchant account gives you a direct relationship with an acquirer, negotiated rates, and full control over chargeback management — at the cost of an underwriting process and ongoing administrative work. An Independent Sales Organisation (ISO) sits between these: an ISO resells acquiring services from a bank, so you get a dedicated merchant account with the negotiation and support handled by the ISO rather than the bank itself.

The right answer depends on transaction volume, risk profile, and how much control matters. Subscription businesses with high recurring volume usually want a traditional merchant account because the interchange-plus pricing is dramatically cheaper at scale. New e-commerce businesses, gig-economy platforms, and marketplaces usually want an aggregator (or a Connect-style PayFac) because the onboarding speed and shared compliance are worth the higher per-transaction cost.

Choosing Between an Aggregator and a Merchant Account

The decision depends on your business profile. Payment aggregators make sense for businesses that are just starting out, process low to moderate transaction volumes, want to start accepting payments quickly, or prefer a simple all-in-one solution. A traditional merchant account becomes more attractive when transaction volumes are high enough to negotiate better rates, you need more control over the payment experience, or you want dedicated support and customised settlement schedules.

Many businesses start with an aggregator and migrate to a merchant account as they grow. Some use both — an aggregator for online payments and a separate arrangement for other channels like telephone payments.

A short checklist

If you're trying to decide, the questions that actually matter:

• What's your monthly card-processed volume, and what's the average transaction size?
• How predictable is your transaction pattern? (Aggregators don't like volatility.)
• What does a multi-day funds hold cost you operationally?
• Do you take payments over channels (phone, mail, in-person) where the aggregator's compliance won't cover you?
• How important is the integration cost? Aggregators win hands-down on time-to-live.

Best practice if you're using an aggregator

A few things worth doing whatever aggregator you use:

• Run the SAQ honestly — If you've got any scope at all on the cardholder data flow, you're not SAQ A. The aggregator's word for it isn't evidence; the actual data flow is.
• Separate the channels — Use the aggregator for what it's good at (online checkout) and pair it with a channel-specific solution for phone payments, mail order or in-person. Trying to bend the aggregator's tools to fit every channel usually breaks PCI scope.
• Watch the chargeback ratio — Card schemes class you as high-risk above 1% by count or 0.65% by value, and that triggers monitoring programmes that the aggregator will pass on to you. Catch the trend early.
• Have a fallback processor — Even if it's only configured and not active, a second processor protects you from an aggregator outage or freeze.
• Read the freeze clause — Know what triggers a hold, how long it can last, and what your options are if it happens.
• Reconcile daily — The aggregator's payout statement is your accounting source of truth. Anomalies caught quickly are anomalies you can dispute.