Payment Aggregator vs Payment Gateway vs Payment Processor: Who Does What

A single card payment can pass through three different companies before the merchant is paid: a gateway that carries the message, a processor that talks to the networks and the banks, and an aggregator that holds the merchant relationship and the settlement risk. Sometimes one company does all three. Sometimes the merchant only ever sees one of them. The confusion in the industry comes from the fact that the names describe functions, and companies bundle functions differently.

Simpaisa, where I run product, is a gateway and an aggregator for over 150 merchants across five markets. This essay is the explanation I give to a new product manager in their first week.

The four functions in one transaction

Follow one payment from a customer's card to a merchant's bank account.

The gateway captures the payment details at checkout, tokenises or encrypts them, and forwards the authorisation request. It is the technical front door: the API, the hosted page, the SDK. A gateway does not decide whether the payment is approved and does not hold money.

The processor takes the authorisation request from the gateway and routes it to the card network, which routes it to the issuing bank. The processor is connected to the networks and to the acquiring bank, handles the response, and later handles clearing and settlement files. Processors are licensed or sponsored by banks and are usually invisible to the merchant.

The merchant account is the acquiring relationship: a bank or licensed acquirer agrees to accept card payments on the merchant's behalf, underwrites the merchant, and receives the settled funds before paying them out. A merchant with its own merchant account is the "merchant of record" with the acquirer.

The aggregator (also called a payment facilitator in the card world) holds one master merchant account with an acquirer and onboards many sub-merchants under it. The sub-merchants never sign with the bank. The aggregator underwrites them, collects their funds, settles to them, and carries the risk if they default or commit fraud. Stripe, Square and Adyen are aggregators in most markets; so are local players in every emerging market.

Gateway vs aggregator

This is the comparison most people are actually asking about.

A pure gateway gives the merchant technology and expects the merchant to bring their own merchant account. The merchant signs with an acquirer, passes underwriting, and the gateway connects the two. Larger merchants prefer this because they control the acquiring relationship, the rates and the settlement.

An aggregator gives the merchant technology and the merchant account together. Onboarding is fast because the aggregator has already been underwritten by the bank and applies its own, lighter, underwriting to sub-merchants. Smaller merchants prefer this because they could not get a merchant account alone, or not quickly.

The trade-off is control against speed. The aggregator model works because the aggregator takes on risk it can manage at scale: it sees thousands of merchants, can price risk into the fee, and can hold reserves. The failure mode is an aggregator that onboards faster than it can underwrite. In our own onboarding we cut the time from weeks to hours by reducing touchpoints and applying predefined rules by merchant tier, and the reason that worked is that the rules were written by the risk team before the product team automated them.

Gateway vs processor

A gateway carries the message to the processor; the processor carries it to the network. Many companies do both, which is why the terms blur. The distinction matters in two situations.

When choosing a provider: a gateway-only provider gives you the integration and lets you choose the processor or acquirer behind it, which matters if you want to route between acquirers or negotiate rates directly. A processor-integrated provider is simpler and usually cheaper to start with.

When something fails: a declined payment can be declined by the gateway (validation, fraud rules), by the processor (routing, format), by the network or by the issuer. Knowing which layer said no is the first step in fixing authorisation rates, and providers that bundle the layers do not always expose it.

Gateway vs merchant account

A gateway is technology. A merchant account is a banking relationship. You cannot accept card payments with only a gateway, and a merchant account without a gateway cannot receive payments from a website. The question "gateway or merchant account" is usually a founder asking whether they need to sign with a bank; the answer is that they either sign with a bank (merchant account plus a gateway) or sign with an aggregator (who has done it for them).

How the answer changes in a frontier market

In Pakistan, Bangladesh, Nepal, Iraq and Egypt, the markets Simpaisa operates in, the card model above is only part of the picture. Most consumer payments run through mobile wallets, bank transfers and telecom billing, each with its own equivalent of the four functions. A "gateway" in these markets has to connect to a dozen local rails, not one network; an "aggregator" holds accounts with several wallets and banks, not one acquirer; and settlement happens per rail, on different cycles, in local currency.

That is why global merchants such as marketplaces and app stores use a local aggregator rather than integrating each rail: the aggregator absorbs the rails, the regulatory approvals and the settlement complexity, and gives the merchant one contract and one settlement. Our aggregator clients include dLocal, Thunes, Boku and Coda Payments, who in turn serve merchants like TikTok, Temu and InDrive.

Choosing between them

For a merchant: if you process small volumes or need to be live this month, use an aggregator. If you process large volumes, operate in several markets and want to control acquiring costs, take your own merchant accounts and use a gateway that can route between them. Most companies start with the first and move to the second.

For a product manager building any of these: the function that carries the risk (the aggregator) is the one where the product decisions are hardest, because every onboarding rule, reserve policy and settlement cycle is a trade-off between merchant growth and losses.

FAQ

What is a payment aggregator? A provider that holds a master merchant account with a bank or acquirer and onboards many sub-merchants under it, handling their underwriting, collection, settlement and risk. Card networks call the same model a payment facilitator.

Is a payment gateway the same as a payment processor? No. The gateway captures and forwards the payment from the checkout; the processor routes it to the card network and the banks and handles settlement. Many providers do both, which is why the terms are often used interchangeably.

Do I need a merchant account if I use a payment gateway? Yes, unless the gateway is also an aggregator. A gateway alone is technology; a merchant account is the banking relationship that lets you accept and receive card payments.

Which is better, an aggregator or a gateway with your own merchant account? An aggregator is faster and simpler; your own merchant account gives more control over rates, routing and settlement. Small and new merchants usually start with an aggregator and move as volume grows.

What is an example of a payment aggregator? Stripe and Adyen act as aggregators for most of their merchants. In frontier markets, local providers such as Simpaisa aggregate wallets, banks and telecom billing under one contract for international merchants.