What a payment gateway does, and how it differs from a processor

Payment gateway vs payment processor: the short answer

What is a payment gateway? It is the software that captures payment data and sends it on. When a cardholder enters card details at a checkout, the gateway transmits the payment instruction toward the processor and the card network, and passes the answer back. Visa’s guidance describes gateway software as something that initiates, submits, transmits or controls payment instructions for a merchant.

A gateway, a processor and a merchant account are three different roles. The processor connects to the card networks for authorization, clearing and settlement. The merchant account is the underwritten relationship with an acquirer, or with a payment facilitator as a sub-merchant, through which funds settle. One company can play several of these roles, which is why the terms blur so easily.

‘Card processing’ is also used for the whole service a merchant buys; in network terms, the processor is the party connected directly to the network.

This is the path a card authorization request takes, from the person paying to the bank that issued the card.

1. Cardholder
2. Your platform
3. Gateway
4. Processor and card network
5. Issuing bank

What a processor does

Visa defines a processor as a company directly connected to VisaNet that provides authorization, clearing, settlement or other payment-related processing services for merchants or members. Members are the financial institutions that take part in the network.

That direct connection is the core difference between a payment gateway and a payment processor: the gateway collects the payment details and transmits them, and the processor is wired into the network and does the processing for the merchants and banks it serves.

The acquirer and the merchant account

Visa defines an acquirer as a member that signs a merchant and directly or indirectly enters the merchant’s transactions into interchange. In plain terms, the acquirer is the merchant’s bank in the card system, and it is responsible for the merchants it signs.

In short, acquirer vs processor comes down to who holds the merchant: the acquirer holds the merchant relationship and the risk that comes with it, while the processor provides the network connection and the processing. An acquirer can do its own processing or use a separate processor.

The merchant account is what an acquirer, or a payment facilitator, sets up for a business once it is approved: it lets the business accept cards and receive the funds.

So merchant account vs payment gateway is not a choice between two products: the merchant account is a business relationship that someone has approved and is responsible for, and the gateway is the software that carries the payment data. A business taking card payments online usually needs both.

Issuers, networks and interchange

The issuer is the cardholder’s bank. It approves or declines each transaction and bills the cardholder. The card network connects issuers and acquirers, writes the network rules and sets interchange.

Interchange is a fee paid between banks: the acquirer pays it to the card issuer. Visa’s US interchange schedule, effective April 18, 2026, says merchants do not pay interchange. Instead, they pay a merchant discount to their own financial institution, and that rate bundles interchange with other fees.

Interchange varies with the card product, the channel (card-present or card-not-present), the merchant segment and whether a transaction meets the qualification criteria. For how these pieces add up to what a business pays, read credit card processing fees explained.

The life of a card payment

This is how credit card processing works from checkout to funding, in four stages.

Authorization. The issuer, or VisaNet standing in for the issuer, approves or declines the request. This is the answer the cardholder sees at checkout.

Capture and clearing. The merchant confirms the sale, usually by capturing authorized transactions in a batch. The transaction details are then validated and financially assessed.

Settlement. Net positions are calculated and funds move between issuers and acquirers.

Funding. The acquirer or payment facilitator pays the merchant, net of fees, on its contract schedule. Funding timing and any reserve come from that contract, not from the network rules, so ask your provider how funding works for your customers.

ISOs, payment facilitators and Merchant Servicers

Three more roles show up wherever software and payments meet. Under Visa’s framework, an independent sales organization (ISO) is an agent of the acquirer. It solicits and supports merchants, but it does not process transactions, receive settlement funds or access account data. A business that signs with an ISO is signing with the acquirer. An ISO may resell a gateway that another registered provider runs.

Payment facilitators and sponsored merchants

A payment facilitator (PF, often called a PayFac) signs sponsored merchants on the acquirer’s behalf, receives settlement for them, or both. Doing either one makes an entity a PF. The acquirer is responsible for the PF and its sponsored merchants, and a PF cannot sponsor another PF. Both Visa and Mastercard call the businesses under a PF sponsored merchants; they are also known as sub-merchants or submerchants.

Large sponsored merchants can outgrow the model, and as of October 2026 the two networks draw the line in different places.

Merchant Servicers

Visa’s October 2026 third-party agent guidance lists both payment gateways and embedded-payment or vertical SaaS platforms as Merchant Servicer functions. These are third-party agent roles that must be registered with Visa through an acquirer.

A Merchant Servicer is contracted directly by the merchant, not by the acquirer. It may not sign merchant agreements on the acquirer’s behalf or receive settlement for the merchant, and merchants must tell their acquirer which Merchant Servicers they use. A provider can be a Merchant Servicer without ever handling card data, and one provider can hold several of these roles at once.

Visa says registration is required for all third-party agents, and Mastercard requires its customers, the financial institutions that take part in its network, to register every service provider. Ask any gateway provider which network registrations and PCI DSS validation it holds. For a side-by-side look at the two acquiring models, read PayFac vs ISO: how the models differ.

To recap the card roles in this guide, this is who does what.

Encryption, tokenization and 3-D Secure

Encryption and tokenization both protect card data, but they are not the same tool. Encryption scrambles card data so it can be read again with a key. Because it can be reversed, encrypted card data stays in PCI DSS scope wherever the key is reachable.

Tokenization swaps the card number for a substitute value, the token. It can shrink the number of systems in scope, but it does not remove PCI DSS obligations, and the token vault that maps tokens back to card numbers stays in scope.

EMV 3-D Secure (3DS) adds a check to online and in-app card-not-present payments: the merchant and the issuer exchange data to authenticate the cardholder. It runs either as a frictionless flow, which is risk-based and asks nothing extra of the customer, or as a challenge flow, such as a one-time passcode or a biometric check. As of October 2026, EMVCo’s current specification is version 2.3.1.1. Visa brands its program Visa Secure, and Mastercard’s equivalent is Identity Check.

Our guide to PCI compliance for SaaS platforms explains what encryption and tokenization mean for your platform’s PCI scope.

The ACH equivalents

ACH bank payments have their own cast, and the names differ from cards. Nacha describes five core participants, shown here in the order an entry travels.

1. Originator
2. ODFI
3. ACH Operator
4. RDFI
5. Receiver

The Originator, a business or person, starts the payment through its bank, the ODFI (Originating Depository Financial Institution). The RDFI (Receiving Depository Financial Institution) posts the entry to the Receiver’s account, and the Receiver must have authorized the Originator to credit or debit it.

The US has two ACH Operators: the Federal Reserve Banks (FedACH) and The Clearing House, through its Electronic Payments Network (EPN). Nacha writes the Operating Rules and administers the network, but does not clear or settle payments.

For a debit, where a business collects from a payer’s bank account, the ODFI loosely plays the acquirer’s part, the ACH Operators the network’s and the RDFI the issuer’s. How ACH payments work walks through the full flow.

Why the difference matters to a platform

For a software platform, these roles decide three practical things.

• Contracts. Your customers’ merchant accounts sit with an acquirer, directly or through an ISO, or with a payment facilitator that holds them as sub-merchants. Under Visa’s framework, a gateway the merchant contracts with directly is a Merchant Servicer. Know who signs what, and who is responsible for whom.
• PCI scope. How card data reaches the gateway, and whether your systems ever hold card numbers, encrypted data or tokens, shapes how much of your stack is in scope.
• Who touches funds. Visa’s guidance says moving funds to merchants requires classification as a PF or another acquiring third-party agent category, and a Merchant Servicer may not receive settlement for the merchant. Decide early whether your platform will ever hold or move your customers’ money.

Before you add payments to your software, map each role to a company. One company may fill several of them, as long as you know which ones and what each means for your platform.

Sources

1. Visa Developer, Glossary
2. Visa, Third Party Agent Registration Program: TPA types and functional descriptions
3. Visa, Visa acceptance entities
4. Visa, The Visa payment facilitator model
5. Visa, Visa Core Rules (public edition)
6. Visa, Security and compliance
7. Mastercard, Mastercard Rules
8. Visa, U.S. interchange reimbursement fees
9. EMVCo, EMV 3-D Secure
10. PCI SSC, Tokenization guidelines information supplement
11. Nacha, How ACH payments work