Skip to main content
Commerce Security Authority
Category: Payment Ecosystem

Payment Gateway

Also known as: gateway
Simply put

A payment gateway is a technology service that lets a business accept card and electronic payments from websites, point-of-sale terminals, or mobile devices. It acts as an intermediary that connects the merchant's checkout to the merchant's bank and payment processor so a transaction can be initiated and completed. It typically transmits payment data in an encrypted form between the customer, the merchant, and the parties that authorize the payment.

Formal definition

A payment gateway is an intermediary service that captures payment credentials at the point of interaction (e-commerce checkout, POS terminal, or mobile device) and transmits them, generally in encrypted form, to a payment processor and acquiring bank to initiate authorization and subsequent settlement. Because it handles or transmits cardholder data and potentially sensitive authentication data during a transaction, a gateway is typically in scope for PCI DSS; the extent of that scope, and any scope reduction achieved through mechanisms such as tokenization, encryption, or hosted payment fields, depends on the specific implementation and its validation rather than on the label 'gateway' alone. Note that a payment gateway is distinct from a payment processor and acquirer even when a single provider performs several of these roles, and that gateway functionality does not by itself constitute authentication of the cardholder (for example EMV chip authentication, 3-D Secure, or strong customer authentication are separate controls). Readers should confirm applicable PCI DSS requirements against the current published version of the standard.

Why it matters

The payment gateway sits at the point where payment credentials enter a transaction flow, connecting a merchant's checkout to its processor and acquiring bank. Because it captures or transmits cardholder data, and potentially sensitive authentication data during authorization, it is typically in scope for PCI DSS. That makes the gateway a focal point for both security controls and compliance validation: how it handles, protects, and passes payment data directly affects the merchant's own scope and obligations.

The way a gateway is implemented can meaningfully change a merchant's compliance burden. Mechanisms such as tokenization, encryption, or hosted payment fields may reduce the extent of cardholder data a merchant environment handles directly, but any resulting scope reduction depends on the specific implementation and its validation, not on the fact that a service is labeled a 'gateway.' Merchants who assume the label alone limits their responsibility can misjudge what remains in scope.

It is also important not to overstate what a gateway does. Transmitting encrypted payment data helps protect that data in transit, but gateway functionality does not by itself authenticate the cardholder. Controls such as EMV chip authentication, 3-D Secure, and strong customer authentication address that risk separately and at different points in a transaction. Treating a gateway as a complete fraud or authentication solution can leave gaps that other controls are designed to cover.

Who it's relevant to

Merchants and e-commerce teams
Merchants rely on a gateway to accept card and electronic payments across websites, POS terminals, and mobile devices. How the gateway is integrated — for example whether it uses hosted payment fields or passes cardholder data through the merchant environment — affects the merchant's PCI DSS scope and validation obligations, so integration choices should be assessed rather than assumed.
Compliance officers and QSAs
Because a gateway handles or transmits cardholder data, and potentially sensitive authentication data during a transaction, it is typically in scope for PCI DSS. Compliance teams must determine the actual extent of scope based on the specific implementation and any scope-reducing mechanisms in use, confirming applicable requirements against the current published version of the standard rather than relying on the 'gateway' label.
Payment processors and acquirers
Processors and acquirers receive the transaction data the gateway transmits in order to authorize and settle payments. Understanding the boundary between gateway, processor, and acquirer roles matters even when one provider performs several of these functions, so responsibilities for handling and protecting payment data are clearly allocated.
Security engineers and fraud teams
Engineers designing payment flows should recognize that a gateway's transmission of encrypted data does not by itself authenticate the cardholder. Fraud and authentication controls such as EMV chip authentication, 3-D Secure, and strong customer authentication address different risks at different points and should be considered alongside, not replaced by, gateway functionality.

Inside Payment Gateway

Authorization request routing
The core function of a payment gateway: transmitting a transaction's authorization request from a merchant environment toward the acquirer and card network for approval or decline. The gateway acts as an intermediary that formats and relays messages rather than as the entity that ultimately authorizes the transaction.
Cardholder data handling
Payment gateways may receive, transmit, or process cardholder data (such as PAN, cardholder name, expiration date, and service code). Depending on implementation, a gateway may also come into contact with sensitive authentication data (for example CVV2/CVC2/CAV2/CID or, in card-present flows, track data), which must not be stored after authorization even when encrypted.
Encryption in transit
Gateways typically protect data as it moves between the merchant, the gateway, and downstream parties using cryptographic protection. Encryption transforms data so it is unreadable without a key; its effect on PCI DSS scope depends on how keys are managed and how the implementation is validated, not on the label alone.
Tokenization services
Some gateways offer tokenization, replacing a PAN with a surrogate value. This differs from encryption (reversible with a key), truncation and masking (which reduce or hide displayed digits), and hashing (a one-way transformation). Whether tokenization reduces a merchant's PCI DSS scope depends on the specific implementation and how it is validated.
Integration methods
Gateways expose different integration models (for example hosted payment pages, direct API posts, or redirect flows) that determine how much cardholder data touches the merchant's own systems. The chosen integration model affects the merchant's PCI DSS scope and applicable validation requirements.
Relationship to other payment roles
A payment gateway is distinct from an acquirer, a payment processor, and a card network, though a single provider may perform several roles. The gateway is the messaging and connectivity layer; it does not by itself constitute the acquiring relationship or the settlement function.

Common questions

Answers to the questions practitioners most commonly ask about Payment Gateway.

Is a payment gateway the same thing as a payment processor?
No. Although the terms are often used interchangeably, they describe different roles. A payment gateway is the component that captures and securely transmits transaction data from the merchant environment toward the acquiring side, while the processor handles the routing, clearing, and settlement of the transaction through the card networks and the acquirer. A single provider may offer both functions, but they are distinct roles and should not be conflated when defining scope or responsibilities.
Does using a payment gateway automatically take my systems out of PCI DSS scope?
No. Using a gateway does not by itself remove your environment from PCI DSS scope. The effect on scope depends on how the integration is implemented and validated—for example, whether cardholder data traverses, is processed by, or is stored in your systems, and which integration method is used. A gateway may help reduce scope, but the actual reduction must be determined through your own scoping analysis and validation, not assumed from the presence of a gateway alone.
What integration methods are commonly used to connect to a payment gateway, and how do they differ in scope impact?
Common approaches include hosted payment pages, embedded fields or iframes served by the gateway, and direct server-to-server API calls. These methods differ in how much cardholder data touches the merchant environment, which in turn influences PCI DSS scope and the applicable validation approach. Methods that keep cardholder data entry within the gateway's controlled environment may reduce the merchant's handling of that data, but each option should be assessed against the current PCI DSS requirements and confirmed through appropriate validation.
How does a payment gateway handle sensitive authentication data during a transaction?
Sensitive authentication data—such as full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks—may be used during authorization but must not be stored after authorization is complete, even if encrypted. When a gateway processes a transaction, any handling of sensitive authentication data must respect this prohibition on post-authorization storage, which differs from the treatment of certain cardholder data that may be stored under defined controls.
Can a payment gateway support tokenization, and how does that differ from encryption?
Many gateways offer tokenization, where a token replaces a primary account number and can be used for subsequent operations without exposing the underlying data. Tokenization is distinct from encryption, which transforms data into a reversible ciphertext, and from truncation, masking, and hashing, which reduce or obscure data differently. The effect any of these has on PCI DSS scope depends on the specific implementation and validation rather than the label, so the tokenization design should be assessed accordingly.
What authentication controls might a payment gateway interact with, and which risks do they address?
A gateway may facilitate controls such as 3-D Secure for card-not-present transactions, and its use can relate to strong customer authentication and multi-factor authentication requirements. These controls address different risks at different points in a transaction and are governed by different frameworks and network rules; no single control eliminates fraud. Which controls apply, and how, depends on the transaction type, region, and applicable card brand and network rules, which vary and change over time.

Common misconceptions

Using a payment gateway automatically takes a merchant out of PCI DSS scope.
A gateway can reduce the cardholder data a merchant handles, but scope reduction depends on the integration model and how it is implemented and validated. Merchants generally retain some PCI DSS responsibilities even with a hosted or tokenized gateway, and the applicable requirements should be confirmed against the current published standard.
A payment gateway and a payment processor are the same thing.
These roles are distinct. The gateway focuses on securely routing and formatting transaction messages between the merchant and downstream parties, while processing and acquiring functions handle authorization decisions, clearing, and settlement. One provider may offer multiple roles, but the terms are not interchangeable.
Because a gateway encrypts data, it is safe for it to store CVV2/CVC2 or other sensitive authentication data.
Sensitive authentication data must not be stored after authorization, even when encrypted. Encryption protects data in transit or at rest but does not create an exception to the prohibition on retaining sensitive authentication data.

Best practices

Choose an integration model (such as a hosted payment page or redirect) that minimizes the cardholder data touching your own systems, and confirm the resulting PCI DSS scope and validation obligations against the current published standard rather than assuming a fixed requirement number.
Verify how the gateway distinguishes cardholder data from sensitive authentication data, and confirm that no sensitive authentication data is retained after authorization anywhere in the flow, including in logs.
Understand whether the gateway offers encryption, tokenization, truncation, or masking, and treat each differently; validate the specific implementation instead of relying on the label to determine its effect on scope.
Obtain and review the provider's applicable compliance documentation, and clarify which PCI DSS responsibilities remain with the merchant versus the gateway, since responsibilities are shared and vary by integration.
Confirm that data in transit between your environment, the gateway, and downstream parties is cryptographically protected, and assess how encryption keys are managed as part of your validation.
Do not assume the gateway alone addresses fraud; layer it with appropriate authentication and fraud-detection controls suited to your card-present or card-not-present flows, recognizing that such controls involve false-positive and false-negative trade-offs.