Payment Gateway

August 31, 2024 Banking

A payment gateway protects, formats, and transmits payment requests and responses between merchant checkout systems and payment-processing services.

On this page

A payment gateway is a technology service that protects, formats, and transmits payment requests and responses between a merchant’s checkout and payment-processing services. It commonly handles card and wallet transactions for websites and apps, and it can also connect in-person or omnichannel payment systems.

A gateway does not necessarily hold the merchant account, issue the card, make the issuer’s credit decision, or settle funds. Providers often bundle gateway, processor, acquiring, fraud, tokenization, and reporting services, so the contract and transaction records determine the actual roles.

Key Takeaways

The gateway is the merchant-facing transaction interface, not the entire payment network.
It can collect or receive payment data, tokenize it, route requests, return responses, and send later status notifications.
Authorization, capture, clearing, settlement, refund, and chargeback are different lifecycle events.
A gateway response or webhook must be authenticated, linked to the correct order, and processed safely more than once.
Outsourcing payment collection can reduce direct data exposure but does not remove all merchant security and compliance duties.

Common Gateway Integration Models

Model	Customer interaction	Merchant exposure and control
Hosted payment page	Customer is redirected to a provider-hosted page	Provider handles the payment page; merchant still protects redirects, account access, and order logic
Hosted fields or iframe	Provider-controlled payment fields appear within merchant checkout	Merchant controls surrounding page while sensitive fields can originate from the provider
Direct API integration	Merchant application sends transaction data to gateway APIs	Greater checkout control can create broader data, software, and security scope
Payment link or invoice	Customer opens a provider-hosted checkout from a link	Useful for remote collection; link integrity and order matching still matter
Omnichannel gateway	One service connects store, app, web, or call-center channels	Central reporting can help reconciliation but creates provider and integration concentration

The exact PCI DSS scope depends on the complete implementation. A merchant should not infer scope reduction from a product label alone.

What a Gateway Does

Depending on the service, a gateway may:

create a secure payment session;
collect or receive card, wallet, bank-payment, or token data;
encrypt, tokenize, or otherwise protect payment information;
add merchant, order, currency, device, and risk fields;
route an authorization, capture, void, refund, or verification request;
translate among merchant, processor, acquirer, or payment-method formats;
return synchronous status and later asynchronous updates;
screen transactions using configurable fraud controls; and
provide transaction search, reporting, and reconciliation exports.

Not every gateway performs every function. For example, tokenization may be provided by the gateway, processor, network, wallet, or another service.

Authorization Is Not Settlement

Gateway status	What it generally means	What it does not prove
Created or pending	A transaction object or request exists	That the issuer received or approved it
Authorized	An approval was returned under the transaction rules	That the merchant captured or received funds
Captured or submitted	The merchant requested completion or batch submission	That clearing and settlement are final
Settled or funded	The provider reports a settlement or merchant-funding event	That no refund, reserve, dispute, or chargeback can follow
Voided or reversed	An authorization or unsettled transaction was canceled	That every temporary account hold disappeared immediately
Refunded	A merchant refund was initiated or completed at a stated stage	That the customer’s account already shows the credit

Status vocabulary differs by provider. Integrations should map each provider state to the merchant’s order, accounting, and fulfillment states explicitly.

Worked Example: Checkout Timeout

An online customer submits a $95 order. The merchant’s browser times out before displaying confirmation, but the gateway has already sent the authorization request and later sends an approved status notification.

If the customer submits again, the merchant can create a duplicate authorization unless the integration uses a stable order reference or idempotency control. A reliable workflow should:

create one merchant order identifier before payment submission;
attach that identifier to the gateway request;
authenticate the gateway’s later notification;
retrieve current status from the gateway when the browser result is uncertain;
fulfill only after the merchant’s required payment state is reached; and
reconcile any duplicate, reversal, capture, refund, or failed notification.

The browser page is not the authoritative payment record. Merchant and gateway server records should determine the outcome.

Gateway vs. Processor vs. Acquirer

Party	Primary role	Can the roles overlap?
Gateway	Merchant integration, data protection, routing, and response handling	Yes, a provider may also process or acquire
Processor	Processes or routes transactions for merchants, acquirers, issuers, or other parties	Yes, a processor may offer a gateway
Acquirer	Contracts to provide merchant acceptance and settlement under payment-brand rules	Yes, an acquirer may operate processing and gateway services
Issuer	Provides the card or account and makes authorization decisions	In some payment models one institution performs several roles
Payment network	Supplies rules and routing infrastructure among participants	Network structure varies by payment method

How to Evaluate a Gateway

Identify supported payment methods, currencies, countries, channels, and transaction types.
Map gateway, processor, acquirer, network, issuer, token, fraud, and settlement responsibilities.
Review hosted-page, iframe, JavaScript, API, mobile, and webhook security boundaries.
Require authenticated API calls and status notifications and protect merchant credentials.
Use stable order and transaction identifiers with duplicate-prevention controls.
Test authorization, decline, timeout, capture, partial capture, void, refund, dispute, and outage paths.
Reconcile gateway records to orders, processor batches, merchant funding, fees, refunds, and the ledger.
Review data retention, logs, exports, portability, incident notification, and service termination.
Measure availability and recovery, but also test whether status remains correct after retries and delayed events.

Risks and Common Mistakes

Treating the checkout success page as proof of payment.
Trusting an unauthenticated webhook or accepting the amount supplied by a customer’s browser.
Retrying a request without a stable idempotency or duplicate-control design.
Shipping on authorization when the merchant’s policy requires capture or another status.
Storing sensitive authentication data or full account numbers unnecessarily.
Assuming tokenization removes every system from security scope.
Ignoring gateway fees, currency conversion, reserves, dispute tools, and data-export costs.
Depending on one provider without tested outage and migration procedures.

Official Resources

PCI SSC: PCI DSS describes baseline controls for entities that store, process, transmit, or can affect payment account data.
PCI SSC: Maintaining Payment Security covers payment software, devices, networks, and point-to-point encryption.
PCI SSC: E-commerce Outsourcing FAQ discusses hosted pages, iframes, merchant-page integrity, and outsourced processing context.
EMVCo: Payment Tokenisation explains how constrained payment tokens can reduce the value of compromised account data.

Gateway features and legal responsibilities vary by provider, payment method, contract, payment brand, and jurisdiction.

FAQs

Is a payment gateway the same as a payment processor?

No, although one provider may perform both roles. The gateway typically provides the merchant integration and transaction interface, while the processor handles or routes payment transactions for participants.

Does a gateway approval mean the merchant has been paid?

No. Approval is an authorization-stage result. Capture, clearing, settlement, merchant funding, refunds, and disputes are separate events.

Does using a hosted gateway remove PCI DSS responsibility?

Not necessarily. It may reduce the systems that directly handle card data, but the merchant still needs to assess its checkout, account access, redirects, integrations, service providers, and applicable validation requirements.

Payment Processor: Service provider that processes or routes payment transactions.
Acquiring Bank: Entity providing merchant card acceptance and settlement.
Card Authorization: Issuer approval or decline before capture and settlement.
Digital Wallet: Wallet systems commonly present tokenized payment credentials in gateway transactions.
Credit Card Processing: Full card-payment lifecycle around gateway requests.
PCI DSS: Payment-card security standard for covered environments.

Educational Use

This article provides general financial education. It is not gateway-selection, payment-security, merchant, legal, or compliance advice.

mPOS

Payment Processor