How Aggregator Merchant Works
An aggregator merchant sits between an acquiring bank and a portfolio of smaller businesses called sub-merchants. Instead of each business applying for its own merchant account, the aggregator holds a single master merchant account and routes all sub-merchant transactions through it. The acquiring bank deals with one vetted entity; the aggregator manages the complexity of onboarding, monitoring, and settling funds to dozens or thousands of merchants below.
Aggregator registers as a master merchant
The aggregator applies directly to an acquiring bank and, if seeking formal status, registers with Visa and Mastercard as a payment facilitator. This process involves deep underwriting of the aggregator's business model, financials, and risk controls.
Sub-merchants apply through the aggregator
Businesses wanting to accept card payments sign up on the aggregator's platform. The aggregator runs KYC and KYB checks, often using automated decisioning, and approves merchants in minutes to hours. Each approved business becomes a sub-merchant under the master account.
Transactions are processed under the master MID
When a customer pays at a sub-merchant's checkout, the transaction is submitted to the card networks under the aggregator's master merchant ID (MID). The card networks and issuing bank see the aggregator — not the individual business — as the merchant of record.
Aggregator settles funds to sub-merchants
After the acquirer settles funds to the aggregator's account, the aggregator distributes net proceeds to each sub-merchant, deducting its processing fees and any reserves. Settlement timing varies by platform — typically T+1 to T+2, with instant payout options often available for an additional fee.
Aggregator manages risk and chargebacks
The aggregator monitors all sub-merchant transactions for fraud and excessive chargebacks. Because it is liable for the entire portfolio's losses, it may hold rolling reserves, impose transaction limits, or terminate sub-merchants who breach risk thresholds set by the acquiring bank.
Why Aggregator Merchant Matters
The aggregator model fundamentally changed who can accept card payments and how fast they can get started. Before aggregation, obtaining a merchant account required weeks of underwriting, minimum revenue thresholds, and often a personal credit check — barriers that excluded millions of small businesses.
The impact is measurable. According to the Federal Reserve's 2023 Payments Study, card payments account for over 50% of all non-cash transactions in the United States by value, and the widespread adoption of aggregators is a primary driver of that shift for small businesses. Stripe alone has reported onboarding millions of businesses across 46 countries under its aggregator model. Meanwhile, a 2022 McKinsey Global Payments Report estimated that payment facilitators collectively process over $1 trillion in annual payment volume globally, a figure growing at roughly 20% per year as more platforms embed payments into their core product offerings.
Why aggregation accelerates commerce
Traditional merchant account approval rates for businesses under two years old are below 40% at many acquiring banks. Aggregators approve the same cohort at rates exceeding 85% by using alternative underwriting signals and assuming the risk themselves.
Aggregator Merchant vs. Payment Facilitator
These terms are often used interchangeably in the industry, but there are meaningful distinctions worth understanding — particularly for platforms evaluating which structure to build on.
| Dimension | Aggregator Merchant | Registered Payment Facilitator |
|---|---|---|
| Definition | Any entity pooling merchants under one account | Formally registered with Visa/Mastercard as a PayFac |
| Card network registration | Not required | Required (Visa PFAC, MC PayFac programs) |
| Liability for sub-merchants | Yes | Yes |
| Underwriting responsibility | Varies | Explicitly mandated by card networks |
| Time to implement | Days to weeks (via sponsor bank) | 6–18 months for full registration |
| Sub-merchant volume limits | Set by sponsor bank | Set by card network rules |
| Typical use case | Startups, SaaS platforms using PayFac-as-a-service | Large platforms processing $100M+ annually |
| Regulatory scrutiny | Lower | Higher |
Both structures place the merchant of record responsibilities on the aggregating entity, but registered PayFacs operate under more explicit card-network oversight and compliance obligations.
Types of Aggregator Merchant
The aggregator category encompasses several distinct operational models, each with different risk profiles and use cases.
Full PayFac (Registered): The aggregator has completed formal registration with Visa and Mastercard. This unlocks the highest sub-merchant volume limits and the greatest control over pricing, branding, and data. Examples include Stripe, Square, and Adyen for Platforms.
PayFac-as-a-Service (Managed PayFac): A platform uses a third-party infrastructure provider to act as the master merchant on its behalf. The platform gets the sub-merchant experience without the regulatory burden of full registration. Examples include Stripe Connect (Custom), Finix, and Payrix.
Marketplace Aggregator: An e-commerce or gig marketplace aggregates sellers or service providers under its account to handle split payments and seller payouts. The marketplace itself is the merchant of record for the buyer, managing complexity behind the scenes.
Vertical SaaS Aggregator: A software platform serving a specific industry — restaurants, gyms, salons — embeds payments and becomes the aggregator for its customer base, monetizing the payment flow as a core revenue stream rather than a feature.
Best Practices
Understanding the aggregator model is one thing — operating effectively within it requires different discipline depending on whether you are a merchant or a developer building payment infrastructure.
For Merchants
Understand your fee structure before committing. Aggregator pricing is simple but often more expensive than interchange-plus for merchants processing over $50,000/month. Request a cost comparison and model your actual interchange categories before assuming the flat rate is cheapest.
Know your settlement timeline. Different aggregators settle on different schedules. If cash flow is critical, confirm T+1 settlement is available or factor the delay into your working capital planning.
Keep chargeback rates below 1%. Aggregators are monitored by acquiring banks for portfolio-level chargeback ratios. Merchants with rates above 1% are often suspended without warning. Implement fraud screening and clear refund policies from day one.
Read the reserve policy. Most aggregators hold a rolling reserve (typically 5–10% of volume) for new merchants. Understand when reserves are released and factor this into your liquidity model.
For Developers
Design for sub-merchant data isolation. When building on top of an aggregator API, ensure sub-merchant transaction data is strictly scoped. Commingling data across sub-merchants creates compliance and support nightmares.
Implement webhook reliability from the start. Aggregator platforms communicate settlement, dispute, and payout events via webhooks. Build idempotent handlers with retry logic — dropped webhooks cause reconciliation failures that are painful to debug retroactively.
Automate KYC/KYB collection. Sub-merchant onboarding friction directly impacts your conversion rate. Use the aggregator's hosted onboarding flows or build progressive information collection that requests only what is needed at each stage.
Monitor sub-merchant health metrics. Track chargeback rate, refund rate, and decline rate per sub-merchant. Proactive intervention before thresholds are breached protects your portfolio and your relationship with the acquiring bank.
Common Mistakes
Assuming aggregation is always faster than a direct merchant account. For high-volume merchants, a direct acquiring relationship often delivers better economics and higher authorization rates within a similar timeframe. Aggregation is optimized for speed-to-market, not necessarily long-term cost efficiency.
Ignoring the liability chain. Platforms that integrate aggregator payment APIs sometimes treat themselves as purely a technology layer, not realizing that facilitating payments for others may expose them to liability as an unlicensed money transmitter depending on the jurisdiction. Legal review is essential before launch.
Underestimating the risk of sub-merchant fraud. Aggregators that scale quickly without robust underwriting can suffer rapid portfolio deterioration. A single sub-merchant running a fraud scheme can generate thousands of chargebacks before detection. Continuous transaction monitoring — not just onboarding KYC — is non-negotiable.
Conflating "merchant of record" with "aggregator." The merchant of record is specifically the entity legally responsible to the customer for the sale. An aggregator is the entity responsible to the card networks for the transaction. These roles often overlap but are not the same, especially in marketplace contexts where the platform handles returns but a seller fulfills the order.
Neglecting reserve impacts on sub-merchant cash flow. Platforms that fail to communicate reserve policies clearly to their sub-merchants create churn and support overhead. Transparent, predictable reserve schedules should be documented at onboarding, not discovered at first settlement.
Aggregator Merchant and Tagada
Tagada's payment orchestration layer is designed to work seamlessly alongside aggregator and PayFac infrastructure. Platforms that have built or are building aggregator models often route transactions through multiple acquirers depending on card type, geography, or cost — and Tagada's routing intelligence handles exactly this complexity.
Using Tagada with aggregator infrastructure
If your platform operates as a PayFac or uses PayFac-as-a-service, Tagada can sit upstream of your acquiring connections to optimize authorization rates and reduce processing costs across your entire sub-merchant portfolio — without requiring changes to your existing onboarding or settlement flows.