What Is the Difference between a Payment Gateway and a Payment Processor?

A payment gateway is the software that encrypts card data at checkout and routes it to the payment processor. A payment processor is the financial intermediary that authorizes and settles the transaction between banks. Both are required for online card payments, both must comply with PCI DSS 4.0, and both depend on TLS encryption and key management to protect cardholder data in transit.

Quick Answer: Gateway vs Processor

A payment gateway handles the customer-facing, data-security side: it encrypts card details entered at checkout and transmits them to the payment network. A payment processor handles the financial-execution side: it routes the transaction between the acquiring bank and the issuing bank, authorizes the charge, and coordinates settlement. Gateway means secure data pipe. Processor means financial executor. Most online businesses need both, and many providers bundle them, but the distinction matters when evaluating compliance scope, data custody, and encryption responsibility.

The Four Parties in Every Card Transaction

Every card transaction involves four principals:

• The customer: the person presenting a credit or debit card for payment.
• The issuing bank: the bank that issued the customer’s card. It authorizes or declines transactions.
• The merchant: the business accepting payment.
• The acquiring bank: the bank that holds the merchant’s account and receives settlement funds.

The payment gateway and payment processor are the infrastructure connecting these four parties.

What Is a Payment Gateway?

A payment gateway is a software service that acts as the secure data channel between the customer’s browser and the payment network. From the customer’s perspective, it is the checkout page. From a security perspective, it applies TLS (Transport Layer Security) encryption the moment card details are submitted. TLS 1.2 with strong cipher suites is the PCI DSS 4.0 minimum; TLS 1.3 is preferred for new deployments. See our post on TLS 1.2 and TLS 1.3.

How Does a Payment Gateway Work?

1. Card data submission: the customer enters card details. The gateway encrypts this data using TLS before it leaves the browser, so the card number never travels in plaintext.
2. Tokenization: the gateway replaces the PAN with a non-sensitive token and forwards the encrypted transaction data to the processor. The raw card number is stored in the gateway’s secure vault.
3. Authorization relay: after the processor communicates with the banks, the issuing bank’s decision returns through the processor to the gateway.
4. Customer notification: the gateway displays the approval or decline to the customer.

Types of Payment Gateway

• Hosted gateway: the customer is redirected to an external, gateway-hosted checkout page. Card data never enters the merchant’s environment, minimizing PCI DSS scope. Common for small and medium businesses.
• Self-hosted gateway: card data passes through the merchant’s servers, giving full checkout control. Significantly expands PCI DSS scope and requires robust encryption, key management, and security controls on the merchant side.

What Is a Payment Processor?

A payment processor is the financial intermediary between the payment gateway and the banks. It receives authorized transaction data from the gateway, communicates with the card network (Visa, Mastercard, American Express), coordinates with the acquiring bank and issuing bank to verify the card and authorize payment, and manages the settlement that moves funds to the merchant account.

How Does a Payment Processor Work?

1. Receives data from gateway: the processor receives the tokenized transaction data.
2. Routes to acquiring bank: the processor forwards the transaction to the merchant’s acquiring bank.
3. Acquiring bank contacts issuing bank: via the card network, the acquiring bank requests authorization from the customer’s issuing bank.
4. Issuing bank responds: the issuing bank sends an approval or rejection back through the network.
5. Processor relays decision: the authorization response travels back to the gateway, which notifies the customer.
6. Customer completes checkout: if approved, the customer proceeds to confirmation.
7. Settlement: at end of day, the processor batches approved transactions. The issuing bank transfers funds through the card network to the acquiring bank and into the merchant account, minus fees.

Payment Gateway vs Payment Processor: Side-by-Side

Dimension	Payment Gateway	Payment Processor
Primary function	Encrypts and routes card data from checkout to the payment network	Authorizes and settles the transaction between banks
Customer relationship	Direct: customer enters card details via the gateway interface	Indirect: customer never interacts with the processor
Fund movement	Does not move funds; handles data routing	Coordinates transfer of funds between card network, issuing bank, and acquiring bank
Encryption role	Encrypts card data in transit (TLS) and initiates tokenization	Receives already-encrypted data; handles secure communication with card networks
PCI DSS scope	Hosted gateway reduces merchant scope; self-hosted expands it	Processor handles card network compliance directly
Merchant account	Does not provide merchant account	Sets up or connects the merchant account that receives settled funds

Encryption and Security in Payment Processing

• TLS encryption in transit: PCI DSS 4.0 Requirement 4.2 mandates strong cryptography (TLS 1.2 minimum; TLS 1.3 recommended) for all cardholder data transmitted over public networks. Plain HTTP at any point is a PCI DSS violation.
• Tokenization: replaces the PAN with a token that has no mathematical relationship to the actual card number. A breach of the token store does not expose usable card data. This differs from encryption: a token cannot be reversed without the vault; an encrypted PAN can be decrypted with the key.
• Key management: TLS sessions depend on certificates and private keys. A compromised TLS private key allows impersonation of the gateway or decryption of intercepted sessions. Keys should be protected in a hardware security module (HSM). See HSM as a Service.

Deployment Example: E-commerce Store Payment Flow

1. Customer checkout: the retailer’s page displays a payment form, but the card entry fields are served as an iFrame from the gateway’s PCI DSS-certified environment. The retailer’s servers never receive the raw card number.
2. Gateway encryption and tokenization: card details are encrypted via TLS 1.3 and the PAN is tokenized. A token is returned to the retailer’s order management system.
3. Processor authorization: the gateway forwards the transaction to the processor, which routes it through the card network to the issuing bank for authorization.
4. Settlement: at end of day, the processor batches approved transactions. Funds move to the merchant account within one to two business days, minus fees.
5. Token for future use: the retailer stores the token, not the raw PAN. Repeat transactions process using the token without re-entering card details or expanding PCI DSS scope.

How Encryption Consulting Can Help

• Encryption Advisory Services: our Encryption Advisory Services assess TLS configuration of payment-handling infrastructure, identify weak cipher suites or expired certificates, and provide remediation aligned to PCI DSS 4.0 Requirements 3 and 4.
• CertSecure Manager: payment gateways must manage TLS certificate renewals. With certificate lifetimes heading toward 47 days by 2029, automation is required. CertSecure Manager automates certificate discovery, renewal, and policy enforcement.
• HSM as a Service: TLS private keys in payment infrastructure belong in FIPS 140-2 Level 2+ HSM hardware. HSM as a Service provides hardware-backed key protection without on-premises HSM overhead.
• Compliance Advisory: our Compliance Advisory Services help merchants and payment service providers map existing controls against PCI DSS 4.0 and identify gaps before an assessment.

Conclusion

The payment gateway and the payment processor are two distinct roles in the card payment chain. The gateway encrypts card data at checkout using TLS and routes the payload to the financial network. The processor authorizes the transaction with the banks and settles the funds. Most online businesses need both. The choice of gateway model determines how much PCI DSS compliance falls on the merchant: hosted gateways keep raw card data out of the merchant’s systems and dramatically reduce scope; self-hosted gateways expand it. For security teams, the gateway’s TLS configuration, certificate management, and key protection are the merchant-side controls that matter most. For related reading, see our posts on TLS 1.2 and TLS 1.3 and Developing an Enterprise Encryption Policy.

Frequently Asked Questions

What is a payment gateway?

The software layer that encrypts card data at checkout using TLS and transmits it to the payment processor. It routes data and relays authorization decisions but does not move funds.

What is a payment processor?

The financial intermediary that receives transaction data from the gateway, communicates with the card network and issuing bank to authorize the charge, and coordinates fund transfer to the merchant’s account.

Do I need both?

For online card payments, yes. Some providers bundle both but the roles remain distinct. The gateway handles secure data transmission; the processor handles authorization and settlement.

What encryption does a payment gateway use?

TLS (Transport Layer Security), minimum TLS 1.2 per PCI DSS 4.0, with TLS 1.3 recommended. Gateways also tokenize the card PAN after the first transmission, replacing it with a non-sensitive token.

What is the role of PCI DSS?

PCI DSS v4.0 governs cardholder data protection. Hosted gateways reduce merchant scope (often to SAQ A). Self-hosted gateways expand scope because card data passes through merchant systems, requiring broader compliance with Requirements 3, 4, and others.

What is tokenization?

Replacing the customer’s actual card number (PAN) with a randomly generated token that cannot be reversed without the vault. Merchants store tokens rather than PANs, reducing PCI DSS scope. Unlike encryption, there is no key to decrypt: the token is only useful via a vault lookup.