Introduction
Payment gateway and payment processor are two distinct components of the electronic payment infrastructure that are frequently described interchangeably in commercial contexts, creating persistent confusion among merchants, platform developers, and financial technology buyers. The distinction is not semantic. Each component performs a separate function in the transaction lifecycle, operates under different technical and compliance obligations, and presents different failure modes when payment flows break down in production environments.
A payment gateway is the software layer responsible for capturing, encrypting, and transmitting payment credentials from the customer’s checkout interface to the processing path. A payment processor is the entity that executes the financial mechanics of the transaction — routing authorisation requests through card networks to issuing banks, managing clearing, and coordinating settlement of funds into the merchant’s account. The gateway handles data; the processor handles money movement.
Understanding the operational boundary between these two components has direct relevance for businesses designing payment infrastructure, for platform operators evaluating provider contracts, and for financial technology teams assessing where liability, PCI DSS scope, and integration responsibility reside. The global payment processing market was estimated at $71.5 billion in 2026 and is projected to reach $122 billion by 2031, according to industry forecasts — a scale that reflects the foundational role these systems play in digital commerce.
What a Payment Gateway Does
A payment gateway is the technology interface through which customer payment data enters the transaction chain. Its primary functions are data capture, encryption, and transmission — not fund movement.
When a customer completes a checkout form on a merchant website, initiates a contactless tap at a point-of-sale terminal, or authenticates a payment through a digital wallet, the gateway captures the payment credentials and immediately encrypts them. Tokenisation replaces the raw card data with a unique identifier that carries no exploitable value outside the specific transaction context, limiting the exposure of cardholder data across the subsequent stages of the payment chain.
The gateway then transmits the encrypted transaction data to the payment processor via a defined API or network connection. For online payment environments, this transmission occurs through application programming interfaces that connect the merchant’s website or application to the processing network. For in-store environments, a point-of-sale terminal connected to the payment network via internet serves an equivalent function.
Beyond data capture and transmission, payment gateways perform several ancillary functions. Fraud detection tools apply risk scoring, velocity checks, and 3D Secure authentication protocols at the checkout stage. Integration surfaces — including hosted payment pages, drop-in user interface components, and direct API connections — determine the degree to which the merchant’s systems are isolated from direct exposure to cardholder data, with implications for the scope of the merchant’s PCI DSS compliance obligations.
The gateway does not move funds. Its function ends when encrypted transaction data is successfully delivered to the processor.
What a Payment Processor Does
A payment processor manages the authorisation, clearing, and settlement stages of the transaction — the phases in which the financial mechanics of the payment are executed.
Upon receiving encrypted transaction data from the gateway, the processor routes an authorisation request through the relevant card network — Visa, Mastercard, American Express, or an equivalent scheme — to the issuing bank. The issuing bank assesses the request against the cardholder’s available balance or credit limit, applies fraud and identity checks, and returns either an authorisation approval or a decline response through the same chain. This exchange typically completes within milliseconds.
Following authorisation, the processor manages the capture and settlement phases. Capture is the instruction to collect the authorised funds; settlement is the interbank transfer process through which funds are moved from the issuing bank to the acquiring bank and credited to the merchant’s account. Settlement typically completes within one to three business days of the transaction date, depending on the processor, acquiring bank, and applicable card network rules.
The processor also manages exception handling — including chargebacks, disputes, and declined transaction workflows — and maintains compliance with card network operating rules and PCI DSS requirements across the segments of the data path it controls.
How Payment Gateways and Payment Processors Work Together
In a standard online card transaction, the gateway and processor operate sequentially, each handling a defined phase of the payment lifecycle.
The customer initiates a transaction by entering payment credentials into the merchant’s checkout interface. The gateway captures and encrypts the data, applies any configured fraud controls, and transmits the encrypted transaction to the processor. The processor routes the authorisation request through the card network to the issuing bank, receives the response, and communicates the outcome — approval or decline — back through the chain to the merchant’s system via the gateway.
If authorised, the merchant confirms the transaction and proceeds with order fulfilment. At end of day, or in real time depending on the configuration, the processor submits captured transactions for settlement, initiating the interbank transfer that credits the merchant’s account net of applicable fees.
For in-store or card-present transactions, a point-of-sale terminal performs the data capture function that a web gateway would perform in an online environment, though the processor’s role in authorisation and settlement remains identical across both transaction types.
Market Structure: Bundled Versus Separated Gateway and Processor Functions
In practice, the gateway and processor functions are frequently bundled under a single provider contract, particularly in the payment facilitator model adopted by companies including Stripe, PayPal, Square, and Adyen. These providers offer unified products that combine checkout integration, gateway data capture, processing, and in some cases acquiring services under a single API and commercial agreement.
This bundling simplifies onboarding and reduces the number of counterparty relationships a merchant must manage, but it also means that the functional boundary between gateway and processor is abstracted away from the merchant’s view. When payment flows fail in production — whether due to authorisation decline rates, settlement timing issues, or gateway connectivity problems — understanding which component in the stack is responsible for the failure becomes relevant for diagnosis and remediation.
Merchants operating at higher transaction volumes, or those with specific requirements around multi-currency processing, cross-border acceptance, or alternative payment methods, may pair a specialist gateway with a separate acquiring or processing relationship. In this architecture, the technical integration between gateway and processor is managed through APIs and certificates, and PCI DSS scope is distributed across the two providers according to which component handles cardholder data at each stage.
Payment orchestration platforms, sometimes referred to as payment hubs, represent an additional architectural layer that sits above multiple gateway and processor connections, routing transactions across providers based on optimisation criteria such as acceptance rate, cost, and geographic availability. This model is increasingly relevant for larger e-commerce operations and marketplace platforms where a single processor connection is insufficient to meet performance or coverage requirements.
The Role of the Merchant Account and Acquiring Bank
The merchant account is the settlement destination — the account held at an acquiring bank into which processed transaction funds are deposited. It is distinct from both the gateway and the processor, though frequently conflated with them in commercial descriptions of payment products.
In traditional acquiring arrangements, a merchant maintains a dedicated merchant account directly with an acquiring bank. The payment processor connects authorised transactions to this account through the settlement process. In the payment facilitator model, merchants are placed on a shared merchant account maintained by the facilitator, which then distributes funds to individual merchants from its aggregate settlement receipts. This arrangement enables faster onboarding but gives the facilitator greater discretion over fund holding and account termination decisions.
The acquiring bank underwrites the merchant’s payment acceptance activity, assuming financial liability for chargebacks and fraud losses up to the limits of its risk assessment of the merchant. The processor executes the technical message flow and settlement mechanics; the acquirer holds the financial risk position. In some market structures these functions are combined within a single institution; in others they are performed by separate entities under distinct contractual arrangements.
Security, Compliance, and PCI DSS Scope
Both payment gateways and payment processors operate within the Payment Card Industry Data Security Standard framework, which establishes mandatory security requirements for any entity that stores, transmits, or processes cardholder data.
The distribution of PCI DSS compliance scope between gateway and processor depends on the integration architecture. Hosted payment page configurations, in which the customer enters card credentials directly into a gateway-controlled interface rather than the merchant’s own system, significantly reduce the merchant’s PCI DSS scope by ensuring that raw cardholder data never passes through merchant-controlled infrastructure. Direct API integrations provide a more seamless checkout experience but extend the merchant’s PCI DSS compliance obligations to the systems through which card data flows.
Tokenisation at the gateway layer limits cardholder data exposure downstream by replacing card credentials with tokens before they are transmitted to the processor or stored for recurring payment purposes. Strong Customer Authentication requirements, mandated under the EU’s Payment Services Directive 2 for transactions within the European Economic Area, impose additional verification requirements at the gateway level for electronic payments above specified thresholds, requiring integration of 3D Secure or equivalent authentication protocols into the checkout flow.
Costs and Fee Structures
Gateway fees are typically structured as a combination of monthly subscription charges and per-transaction fees, which may include a fixed amount per transaction and a percentage of transaction value. Processor fees — incorporating interchange fees paid to the issuing bank, scheme fees paid to the card network, and the processor’s own margin — are commonly bundled into a single merchant service charge, or disaggregated under interchange-plus pricing models that present each component separately.
Stripe’s standard pricing of 2.9% plus $0.30 per transaction represents a bundled flat-rate model that incorporates both gateway and processing functions. Square charges 2.6% plus $0.10 per card transaction under a comparable structure. High-volume merchants may negotiate interchange-plus arrangements that reduce the effective cost of acceptance by isolating the processor margin from the fixed interchange and scheme fee components.
Merchants evaluating the total cost of their payment stack should assess fees across the anticipated transaction mix — accounting for card type, average order value, international transaction proportion, and chargeback exposure — rather than comparing headline rates in isolation.
Conclusion
Payment gateway and payment processor are sequential components of the electronic payment chain, each performing a distinct and non-interchangeable function. The gateway manages secure data capture and transmission at the checkout layer; the processor manages authorisation, clearing, and settlement through card networks and banking institutions. In commercial practice, these functions are frequently bundled under unified provider products, but the operational boundary between them remains relevant for integration architecture, PCI DSS scope allocation, and production incident diagnosis.
For businesses accepting card payments online, both components are required. The selection of gateway and processor solutions — whether bundled or separated — involves evaluation of fee structures, integration requirements, geographic coverage, fraud management capabilities, and the settlement and chargeback operational model appropriate to the business’s transaction profile. As alternative payment rails including account-to-account payments and real-time settlement networks continue to develop, the gateway and processor architecture through which these methods are accepted is evolving in parallel, adding additional dimensions to infrastructure decisions that were previously limited to card network connectivity.
