Gateway vs Processor vs Merchant Account

Most merchants who accept cards can name their payment provider. Very few can explain what that provider actually does, which layer of the payment stack they occupy, and what a different provider in the same stack would look like. The confusion is understandable because the three layers are often delivered by a single company and described interchangeably in marketing materials.

Gateway, processor, and merchant account are three separate functions. They sometimes live inside the same product, but they solve different problems, sit at different points in the transaction flow, and carry different implications for pricing, risk, and account stability. Understanding the difference is practical, not academic, because the distinction becomes visible the moment something goes wrong.

The Payment Gateway: The Front Door

A payment gateway is the technology layer that sits between the customer and the rest of the payment infrastructure. When a customer enters their card details at checkout, the gateway captures that information, encrypts it, and transmits it securely to the payment processor. The gateway is the customer-facing layer: it handles the data collection, encryption, fraud screening at the point of entry, and the communication of the approval or decline back to the checkout page. Stripe’s published resource on how these three components work together, available at stripe.com, confirms that the gateway encrypts and transmits data to the processor, the processor routes authorization through the card network, and the merchant account holds settlement funds before they are released to the business bank account.

A gateway does not move money. It moves information. When a transaction is approved, the gateway tells the merchant’s checkout system that the transaction succeeded. The actual movement of funds happens downstream, in the processor and merchant account layers.

The gateway also handles stored credentials for recurring billing, 3D Secure authentication challenges when the issuer requires them, and in some configurations the routing logic that determines which processor or acquiring bank receives the transaction. A gateway with multiple processor connections can route transactions based on card type, geography, or processing load, which is the foundation of the cascading and load balancing strategies covered in the merchant accounts section of this site.

Common standalone gateway providers include NMI, Authorize.net, and Braintree. In many merchant configurations the gateway is a separate monthly fee and a separate integration from the processor relationship underneath it.

The Payment Processor: The Router

A payment processor is the entity that routes the transaction between the acquiring bank and the issuing bank through the card network. After the gateway transmits the encrypted card data, the processor takes it, formats it for the card network, sends the authorization request to the issuing bank through Visa or Mastercard, receives the approval or decline, and returns that result to the gateway.

The processor is the technical and operational backbone of the transaction. It handles the interchange and assessment fee calculation, the clearing and settlement of approved transactions, the batch processing that moves funds from the card networks to the acquiring bank, and the reporting that populates the merchant’s processing statement.

The processor is not the same entity as the acquiring bank, though they are often described that way. The acquiring bank holds the merchant account. The processor manages the technical infrastructure that connects the merchant to the acquiring bank and to the card networks. Some processors operate their own acquiring licenses and function as both. Others are independent processors that route through multiple acquiring banks.

The distinction matters for high-risk merchants because the processor’s relationship with the card networks determines what transaction types are supported, what MCC codes are available, and what monitoring thresholds apply. A processor that routes through an acquiring bank with a low tolerance for chargebacks will pass that tolerance down to the merchants on its platform.

The Merchant Account: The Holding Tank

A merchant account is a specialized bank account held at an acquiring bank that is specifically authorized to receive card settlement funds. When a batch of transactions settles through the processor and the acquiring bank, the net proceeds after fees are deposited into the merchant account. From there, the merchant account releases funds to the merchant’s operating bank account on the settlement schedule defined in the contract.

The merchant account is not the same as the merchant’s operating bank account. Settlement does not go directly from the card network to the merchant’s checking account. It goes to the merchant account first, which is held at the acquiring bank under the terms of the merchant processing agreement. This is the account that carries the rolling reserve, where funds are withheld as collateral. This is the account that is frozen when an acquirer takes action on a merchant’s processing relationship.

The merchant account is where the commercial and credit relationship with the acquiring bank lives. The underwriting that determines whether a merchant can process cards, the reserve requirements, the processing limits, and the chargeback thresholds are all conditions of the merchant account. When a merchant is terminated for excessive chargebacks and a MATCH listing is submitted, it is the acquiring bank that manages the merchant account that submits it.

Stripe, Square, and PayPal do not give merchants their own merchant accounts. They give merchants access to their master merchant account, which is what makes them payment aggregators. Every merchant on Stripe is a sub-merchant under Stripe’s account, not a holder of their own account. The difference in account stability, termination risk, and chargeback ratio isolation between the aggregator model and a dedicated merchant account is covered in the merchant accounts section of this site.

How the Three Layers Work Together

In a standard card transaction, all three layers operate in sequence. The cardholder enters their card details at checkout. The gateway captures and encrypts the data and sends it to the processor. The processor formats the authorization request and routes it through the appropriate card network to the issuing bank. The issuing bank approves or declines and returns the result through the network to the processor. The processor returns the result to the gateway. The gateway tells the checkout whether the transaction succeeded or failed. If approved, the transaction enters the settlement batch. At settlement, the processor clears the transactions and the acquiring bank deposits net funds into the merchant account. The merchant account releases funds to the operating account on the contracted schedule.

Each step in this flow is where a different cost layer is assessed. Interchange goes to the issuing bank. Assessment fees go to the card network. Processor markup goes to the processor. Gateway fees go to the gateway provider. Reserve withholding goes to the acquiring bank’s merchant account. Monthly statement fees and account maintenance fees go to the processor or ISO. Understanding which entity is taking which fee at which step is what makes reading a processing statement a useful exercise rather than a confusing one.

When They Are Combined and When They Are Separate

Many merchants use a single provider that bundles all three functions. Stripe, for example, is simultaneously a gateway, a processor, and a PayFac that provides merchant account functionality under its master account. A merchant using Stripe has no separate gateway relationship, no separate processor relationship, and no dedicated merchant account. All three functions are delivered by one company through one contract.

High-risk merchants on dedicated accounts frequently have these relationships separated. The gateway is a standalone provider, often NMI, connected to the merchant’s integration. The processor is a separate entity that routes transactions through one or more acquiring banks. The merchant account is at the acquiring bank, governed by the underwriting terms the ISO negotiated. Three separate monthly invoices. Three separate points of contact when something goes wrong.

Understanding which entity holds which relationship matters when a problem arises. A gateway failure is a technical issue with the gateway provider. A processing decline pattern is a question for the processor. A reserve increase or account termination is an action by the acquiring bank. Routing these conversations correctly saves time and produces solutions faster.

The full picture of how payment gateways work and what gateway-specific decisions affect a merchant’s processing setup is in the gateways hub of this site. The full picture of how merchant accounts work, from underwriting through contract terms, is in the high-risk merchant accounts hub. The foundational payment infrastructure concepts are covered in the payments 101 section.

For merchants who want a processing structure where the gateway, settlement, and risk functions are handled without the three-way separation of a traditional high-risk setup, RiskPay operates on non-custodial rails that combine gateway access with direct wallet settlement. There is no separate merchant account holding funds in transit, no reserve at an acquiring bank, and no three-layer fee structure to reconcile. Settlement goes directly to a merchant-controlled wallet in USDC on Polygon.

Frequently Asked Question

What is the difference between a payment gateway and a payment processor?

A payment gateway captures and encrypts card data at the point of checkout and transmits it to the payment processor. A payment processor routes the transaction through the card network to the issuing bank, handles the authorization response, and manages clearing and settlement. The gateway moves information. The processor moves money. Both are required for a card transaction to complete.

Do I need a separate merchant account if I use Stripe?

No. Stripe provides merchant account functionality through its master PayFac account. Merchants using Stripe are sub-merchants under Stripe’s account rather than holders of their own dedicated merchant accounts. This means Stripe handles settlement, but the account stability and chargeback ratio isolation that come with a dedicated merchant account at an acquiring bank are not present. The implications of the aggregator model versus a dedicated account are covered in the merchant accounts section of this site.

Why do high-risk merchants often have separate gateway, processor, and merchant account relationships?

High-risk merchants on dedicated accounts typically have separate gateway and processor relationships because the acquiring banks that underwrite high-risk categories often work with independent processors and ISOs rather than bundled solutions. A standalone gateway gives the merchant more routing flexibility, the ability to connect to multiple acquiring banks, and independence from a single provider. This separation also means the merchant can replace the gateway without changing the acquiring relationship, or change the acquiring bank without changing the gateway integration.

What happens to settlement funds between the card network and the merchant’s bank account?

Settlement funds move from the card network to the acquiring bank, where they are deposited into the merchant account. From the merchant account, the acquiring bank releases net funds to the merchant’s operating bank account on the settlement schedule defined in the processing agreement, typically T+1 to T+3. The merchant account is the holding point where rolling reserves are withheld and where the acquiring bank can freeze or offset funds if a risk trigger fires.

---