Payment gateway vs payment processor: Key differences explained
Payments 101
Updated 21 Sept 2026
9 min
Andrii Kononenko
Head of Merchant Operations, Solidgate
A payment gateway captures and encrypts card data at checkout; a payment processor routes that transaction between banks and card networks to complete the payment.
Every online payment runs through two distinct functions: one that handles card data at the point of entry, and one that moves money between banks. The terms – payment gateway and payment processor – describe those two functions.
Businesses mix them up because most providers bundle both, but they operate at different layers of the transaction and carry different responsibilities.
This article explains what payment gateway and payment processor are, , how they differ, how they interact, where acquirers and card networks fit in, and how to decide what your setup actually needs.
TL;DR
- A payment gateway is a technology layer that captures and encrypts payment data at checkout, moving it securely between the customer, the merchant, and the processor. A payment processor routes that data through the relevant network and settles funds between banks.
- Every online transaction runs through both – authorization, capture, clearing, and settlement all depend on the gateway and processor working in sequence. In-person POS setups need only a processor; the terminal handles capture.
- Behind the gateway and processor sit the acquiring bank, card network, and merchant account – their configuration directly affects approval rates, settlement speed, and cost.
- For most businesses, a single PSP bundling both functions is the right starting point. At higher volumes or across multiple markets, a payment orchestration platform gives you routing control across multiple providers.
What is a payment gateway?
A is a technology layer that collects card data at checkout and moves it securely between the parties involved in a transaction – the customer, the merchant, and the payment processor. Every time a customer enters a card number on a website or taps a phone at a terminal, a gateway is handling the data capture.
In physical retail, the same function is performed by a POS terminal – capturing card data via chip, swipe, or NFC and passing it to the processor.
The gateway's core job is security. It encrypts card data before it travels anywhere – so raw card numbers never pass through the merchant's own servers.
What a payment gateway does NOT do:
- Move funds
- Communicate with banks
- Determine whether a transaction is approved
The moment encrypted card data leaves the gateway, the processor takes over.
What is a payment processor?
A is a service – typically a company or a function provided by one – that routes payment transactions between the merchant and the customer's bank or payment account. It takes encrypted data from the gateway, moves it through the relevant network, and coordinates the movement of funds once a decision comes back.
Its job is to make sure the right authorization request reaches the right destination, and that the approval or decline comes back correctly.
Most modern payment service providers (PSPs) combine with gateway functionality in a single integration, which is why the terms are often conflated in practice.
What a payment processor does NOT do:
- Handle the checkout interface
- Collect card data from the customer
- Apply encryption at the point of entry
Those are the gateway's responsibilities.
What’s the main difference between payment gateway and payment processor?
The gateway is the data layer; the processor is the money layer. They operate at different points in the transaction and communicate with different parties.
Here’s a more detailed comparison.
Role in the transaction. The gateway's role ends once card data is encrypted and passed forward. The processor's role begins there – carrying the transaction through to authorization, capture, clearing, and settlement. One handles the entry point; the other handles everything that follows.
Who each talks to. The gateway communicates with the processor – that's its only counterparty. The processor communicates with the card network, the issuing bank, and the . The processor is the institutional participant; the gateway is the technical interface.
Fund handling. The gateway moves no money and holds no funds at any point. The processor coordinates the full financial flow – requesting authorization from the issuing bank, submitting transactions for clearing, and triggering settlement into the merchant's account.
Security responsibilities. The gateway owns the entry-point security layer: encryption in transit, tokenization at rest, scope reduction, and 3DS . The processor's security role operates at the network level – fraud signals from the issuing bank, scheme-level compliance, and decline code handling.
Standalone capability. A processor can operate without a hosted gateway in an in-person POS setup, where the terminal handles card capture directly. A gateway cannot operate without a processor – it has nowhere to send the data it captures. Online, both are always required.
Channel fit. The gateway is purpose-built for card-not-present environments – online checkout, in-app, payment links – where the customer enters card details remotely. The processor handles all transaction types: card-not-present, in-person, and recurring.
One source of confusion is the term "payment gateway processor" – treated as a single entity. The label fused in everyday usage because most modern PSPs bundle both into one API, so merchants rarely interact with them separately. The functions remain distinct even when the same company delivers both.
Payment gateway vs payment processor: A comparison table
| Payment gateway | Payment processor | |
| Role | Data capture and encryption at checkout | Transaction routing, authorization, settlement |
| Counterparty | The payment processor | Card networks, issuing bank, acquiring bank |
| Handles funds? | No | Yes |
| Security layer | Encryption, tokenization, 3DS, PCI DSS scope | Network-level fraud signals, decline handling |
| Standalone use? | Only with a processor | Yes – in-person POS setups |
| Channel | Card-not-present, online, in-app | All transaction types |
Core insight: The gateway and processor share a provider in most modern setups, but their responsibilities never overlap – one owns the data layer, the other owns the financial layer. Knowing which does what determines where to look when a transaction fails.
How payment gateways and processors work together
Every card transaction follows a fixed sequence. The gateway and processor each handle distinct stages within it.
Step 1 – Card data capture. The customer enters card details at checkout. The gateway encrypts the data and creates an authorization request.
Step 2 – Authorization request. The processor receives the encrypted request and routes it through the relevant card network – Visa, Mastercard, Amex, or another scheme – to the cardholder's issuing bank.
Step 3 – Issuer decision. The issuing bank checks available funds, fraud signals, and card status, then returns an approval or decline code through the card network to the processor.
Step 4 – Response. The processor passes the issuer's decision back through the gateway to the merchant's checkout. An approval lets the merchant proceed; a decline ends the transaction at this stage.
Step 5 – Capture and clearing. For authorized transactions, the merchant captures the payment (in most setups this happens automatically). The processor submits the captured transaction to the card network for clearing – the formal record that the transaction occurred.
Step 6 – Settlement. The acquiring bank receives funds from the issuing bank via the card network and deposits them into the merchant's account, minus interchange fees and processing fees.
The gateway is involved in steps 1 and 4 – data entry and response delivery. The processor handles steps 2, 3, 5, and 6. Neither function operates independently in an online transaction; both are required for a payment to complete.
Core insight: The gateway and processor divide the transaction at a clean boundary – card data in, authorization out. Every step from the issuing bank's decision onward is the processor's domain; every step before it belongs to the gateway.
Where acquirers, card networks and merchant accounts fit
The gateway and processor are the two components most merchants interact with directly. Three other entities operate in the background of every transaction – and understanding where they sit explains why some payments approve in one market and decline in another.
Acquiring bank
An acquiring bank is the financial institution that holds the merchant's account and receives funds on their behalf. The processor communicates with the acquirer; the merchant typically has a contract with both.
Approval rates are partly a function of which acquirer processes a given transaction – different acquirers carry different issuer relationships, BIN acceptance patterns, and network standing. arrangements vary significantly by region, which is why a merchant expanding into a new market often needs a local or regional acquirer to maintain authorization rates.
Card networks
Card networks – Visa, Mastercard, Amex, Discover – operates the messaging infrastructure between the processor and the issuing bank. It sets the rules both sides must follow: interchange rates, dispute timelines, authentication requirements, and scheme compliance thresholds. The card network does not hold funds; it facilitates communication and enforces the rules of the system.
Merchant account
A merchant account is a holding account at the acquiring bank where settled funds land before being paid out to the merchant's business bank account. A merchant account is a distinct entity from a payment gateway – a common point of confusion in search.
The gateway handles data; the merchant account holds money. Some providers offer aggregated merchant accounts (where multiple merchants share a single acquiring relationship), while others issue dedicated merchant IDs.
The distinction affects settlement timing, chargeback handling, and the ability to route transactions across multiple acquirers.
Core insight: The gateway and processor are the merchant-facing layer. The acquiring bank, card network, and merchant account are the financial infrastructure behind them – and their configuration directly affects approval rates, settlement speed, and cost.
Payment gateway vs payment processor: Which do you need?
For , the answer is both. A processor cannot receive card data that hasn't been captured and encrypted by a gateway; a gateway has nowhere to send data without a processor to route it. The two functions are interdependent in any card-not-present environment.
For in-person POS transactions, a payment processor is the core requirement. The POS terminal handles card capture directly, so a standalone hosted gateway is typically not part of the setup. Some in-person setups use a processor with integrated terminal software; others use a combined POS and payments provider.
In practice, the decision is rarely gateway vs processor as a binary choice. Most businesses are choosing a payment service provider that bundles both. The relevant questions are:
What card-not-present channels do you need to support? A provider with a robust hosted checkout handles both gateway and processing in one integration. If you need embedded payment forms, payment links, or in-app flows, verify the gateway layer supports your integration model.
Which markets are you operating in? Gateway support for local payment methods and 3DS configurations varies. A provider with strong regional coverage reduces the friction of market expansion.
What is your PCI DSS exposure? An iFrame or hosted gateway integration limits your compliance scope to SAQ-A – the lightest certification tier. A direct API integration that passes raw card data through your servers requires SAQ-D, which is substantially heavier. The gateway architecture you choose determines your compliance burden.
Do you plan to scale across markets or add providers? As transaction volume grows and you expand into new markets, a single provider's coverage and approval rates may not hold up consistently. An orchestration layer lets you connect multiple providers and route each transaction to the best-performing one – without managing separate integrations.
| Scenario | Payment gateway needed? | Payment processor needed? | Typical setup |
| Online checkout (e-commerce, SaaS, in-app) | Yes | Yes | Single PSP bundling both |
| In-person POS only | POS terminal handles capture | Yes | Processor + terminal hardware |
| Omnichannel (online + in-store) | Yes | Yes | Unified PSP or separate gateway + processor |
| High-volume, multi-market | Yes | Yes | Orchestration layer across multiple providers |
For early-stage businesses, a single provider that bundles gateway and processing is usually the right starting point. Scaling businesses that process across multiple markets or currencies often outgrow a single provider's coverage. A payment orchestration platform connects multiple providers through one integration – giving you routing control, fallback options, and consistent approval rates as you grow.
Core insight: The gateway vs processor question is rarely a binary choice in practice – it's a question of which provider to use and how their gateway layer is configured.
Scaling your payment stack beyond a single provider
A gateway and a processor give you the mechanics to accept payments. At higher volumes and across more markets, the question shifts from "can we accept payments" to "are we accepting them as well as we could."
A connects multiple providers and payment methods through a single integration and to the provider most likely to approve it, based on card type, issuer, market, and historical performance. When a transaction fails on one acquirer, retries it through an alternative before the customer sees a decline.
If your current setup is hitting approval rate ceilings or you're expanding into markets where your existing processor doesn't have strong acquiring coverage, to map where the gaps are.
Frequently asked questions
Yes. In a card-not-present environment, the gateway captures and encrypts card data at checkout; the processor routes that data to the card network and issuing bank.
Neither function works without the other – the processor has nothing to route until the gateway delivers the authorization request. Most providers package both in a single integration.
A payment processor vs a payment gateway are two different functions. The gateway handles the data layer – capturing card details at checkout and encrypting them before they travel anywhere.
The processor handles the financial layer – routing the transaction between banks and settling funds. The confusion comes from the fact that most PSPs bundle both, so merchants rarely interact with them as separate entities.
Stripe operates as both. It provides a hosted gateway layer through its APIs and handles payment processing under the same integration – functioning as a payment service provider that bundles both functions. Most modern PSPs follow the same model.
No. A payment gateway handles data – it captures, encrypts, and transmits card details to the processor. A merchant account is a financial account at the acquiring bank where settled transaction funds are held before being paid out to the merchant's business account. You can change your gateway without changing your merchant account, and vice versa.
Yes – and most do. The underlying technical distinction between the two layers still exists; it's just abstracted behind a single API and contract. Businesses working with these providers configure one integration and access gateway and processing capabilities from the same dashboard.
A payment processor routes the transaction and manages the relationship between the merchant's acquiring bank and the cardholder's issuing bank. A card network – Visa, Mastercard, Amex – is the messaging infrastructure between those two banks.
The card network sets the rules (interchange rates, dispute timelines, authentication requirements) and carries the authorization request; the processor executes within those rules on behalf of the merchant. Merchants contract with a processor; they do not contract directly with card networks.
