A payment gateway captures and securely transmits payment data, a payment processor routes transaction messages between the merchant and financial institutions, and a payment service provider can bundle gateway, processing, acquiring, payment methods, reporting, and merchant support into one service. The terms sometimes overlap, so merchants must verify contractual responsibility rather than rely on the provider’s marketing label.
The payment industry does not use these terms consistently in every country or commercial model. One company may describe itself as a gateway while also providing processing and merchant settlement. Another provider may sell only the technical connection while a separate acquiring bank holds the merchant relationship and transfers funds.
The practical question is therefore not only, “Is this company a gateway, processor, or PSP?” A merchant should determine who collects payment credentials, who sends authorization requests, who contracts with the merchant, who receives settlement, who pays the merchant, who handles disputes, and who is accountable when the service fails.
Payment Gateway vs Payment Processor vs PSP at a Glance
| Criterion | Payment gateway | Payment processor | Payment service provider |
|---|---|---|---|
| Primary function | Captures and securely transmits payment information | Routes and processes transaction messages | Provides a commercial package of payment-acceptance services |
| Main relationship | Usually connects the checkout or application to processing infrastructure | Usually connects merchants or acquirers to issuers and payment networks | Usually contracts directly with the merchant |
| Handles customer payment data | Commonly, especially in e-commerce | Yes, when required for transaction processing | Depends on the service design and hosted-payment model |
| Moves or settles funds | Usually not when acting only as a gateway | May support settlement processing but is not automatically the acquirer | May arrange acquiring and merchant payouts directly or through partners |
| Provides a merchant account | Usually no | Not necessarily | May provide a direct merchant account or an aggregated submerchant arrangement |
| Typical services | Hosted checkout, tokenization, routing, authentication, fraud tools, and transaction responses | Authorization routing, clearing files, network connectivity, transaction switching, and reporting | Gateway, processing, acquiring, alternative payment methods, settlement, dashboards, support, and risk management |
| Best suited to | Businesses that already have acquiring and need a secure technical interface | Banks, acquirers, platforms, and larger merchants that need processing infrastructure | Merchants seeking one integration and one commercial relationship |
The boundaries are not fixed. The PCI Security Standards Council notes that a payment processor may sometimes be called a payment gateway or payment service provider. The same PCI glossary also states that a processor is not automatically an acquirer unless a payment brand defines the entity as one.
This terminology overlap is not merely a language problem. The label can obscure which provider holds the financial responsibility, which company can change merchant reserves, and which organization must resolve a settlement discrepancy.
Expert Insight: Payment-provider selection should begin with a responsibility map, not a product label. Two companies can both market a “payment gateway” while one supplies only software and the other controls onboarding, processing, settlement, reserves, disputes, and merchant payouts.
What Is a Payment Gateway?
A payment gateway is the technical service that captures a payment instruction and converts it into a secure message that the payment-processing chain can accept.
For an online card payment, the gateway may:
- present a hosted checkout page or payment form;
- collect card or payment-method information;
- encrypt or tokenize sensitive data;
- send transaction data to a processor or acquirer;
- support customer authentication;
- apply initial fraud and validation rules;
- return authorization and error responses;
- provide transaction status and merchant dashboards;
- support voids, captures, and refunds through an interface.
A World Bank review of payment intermediaries compared official gateway definitions from several authorities. The Reserve Bank of India described payment gateways as technology infrastructure that routes and facilitates online payment processing without handling funds. The World Bank description similarly explains that a gateway securely transmits online payment data to a processor and is not directly involved in the money flow.
This narrow definition is the clearest way to understand the role: the gateway is the controlled entrance to the payment system. The gateway protects and formats payment information but does not necessarily own the merchant relationship or receive settlement.
Hosted Payment Gateway
A hosted payment gateway directs the customer to a payment page or embedded component controlled by the provider. The merchant’s own systems may avoid direct contact with sensitive card data when the implementation is designed correctly.
Hosted checkout can reduce technical and security scope, but it does not eliminate merchant responsibility. The merchant must protect the website, prevent malicious redirection, control access to the provider account, and monitor changes to payment-page integrations.
Direct or Integrated Gateway
A direct payment gateway allows the merchant to control more of the checkout interface and send transaction data through an API. The approach can create a more customized experience, but the merchant may assume greater security, testing, and compliance obligations.
The merchant should understand exactly which system receives the original payment credential. A tokenized API does not create the same security exposure as an integration that sends raw card data through the merchant’s servers.
Gateway Routing and Orchestration
A modern payment gateway platform may connect to several processors, acquirers, or payment methods. The gateway can route a transaction based on country, currency, payment method, cost, authorization performance, or provider availability.
Routing can improve resilience and acceptance, but it adds state-management and reconciliation complexity. The gateway must preserve one transaction identity even when the request moves between providers.
What Is a Payment Processor?
A payment processor is an entity or technology platform that handles payment transactions on behalf of merchants, acquirers, financial institutions, or other payment providers.
In card payments, processing commonly includes:
- receiving authorization requests;
- validating transaction-message formats;
- routing messages to an acquirer, card network, or issuer;
- returning approval and decline responses;
- producing clearing and settlement records;
- maintaining network connectivity;
- applying transaction and security controls;
- providing operational files and reports;
- supporting reversals, refunds, and disputes.
The European Central Bank defines card processors as companies positioned in the transaction chain between the merchant’s acquirer and the card issuer. The ECB states that processors perform critical tasks involved in authorizing and processing card payments.
An ECB survey identified 111 processing entities reported by national central banks across EU member states in 2024. After removing separately counted subsidiaries of processors active in several countries, the report estimated 80 effective processors. The finding demonstrates that payment processing is a specialized infrastructure layer rather than one universal network.
Front-End Processing
Front-end processing handles the transaction close to the moment of payment. The processor receives the request, checks required fields, communicates with relevant networks, and returns the authorization response.
Back-End Processing
Back-end processing prepares clearing records, calculates transaction positions, supports settlement reporting, and manages post-authorization activity. One processor may provide both front-end and back-end functions, while different providers may divide the responsibilities.
Issuer Processing vs Acquirer Processing
An issuer processor supports the institution that provides the card or payment account. The issuer processor can maintain card records, apply authorization logic, manage limits, and communicate with payment networks.
An acquirer processor supports the merchant side. The acquirer processor receives merchant transactions, routes authorization requests, prepares clearing data, and supports merchant reporting.
The same company can provide both services to different institutions, but the financial and contractual roles remain distinct.
What Is a Payment Service Provider?
A payment service provider, or PSP, is a company that gives merchants access to one or more payment services through a commercial and technical relationship.
A PSP may bundle:
- payment gateway services;
- payment processing;
- merchant acquiring;
- card and account-to-account payment methods;
- digital wallets and local payment methods;
- tokenization and stored credentials;
- fraud prevention and customer authentication;
- currency conversion;
- merchant settlement and payout reports;
- refund and dispute management;
- technical support and compliance assistance.
The term payment service provider can also have a formal legal meaning under a jurisdiction’s payment-services regulation. A regulated PSP can include banks, payment institutions, electronic-money institutions, or other authorized entities.
Commercial usage is often narrower. Merchants commonly use PSP to describe a provider that supplies one integration for several payment capabilities.
Full-Service PSP
A full-service PSP manages most of the merchant-acceptance stack. The merchant signs one primary contract and uses one platform for onboarding, gateway access, processing, acquiring, payouts, and reporting.
The full-service model simplifies implementation, but the PSP becomes a concentrated dependency. A pricing change, risk decision, reserve, outage, or account restriction can affect every supported payment method.
Technical PSP
A technical PSP may integrate several payment providers but leave acquiring contracts and settlement relationships with the merchant. This model gives the merchant more control and provider diversification, but the merchant must manage several contracts and reconciliations.
What Is Merchant Acquiring?
Merchant acquiring is the payment service in which an acquirer contracts with a merchant to accept and process payment transactions that result in funds being transferred to the merchant.
The acquiring bank or acquiring institution normally:
- approves the merchant for card acceptance;
- creates or sponsors the merchant relationship;
- connects merchant transactions to card schemes;
- receives settlement obligations from the payment system;
- funds the merchant directly or through an agreed provider;
- manages merchant risk, reserves, and compliance;
- handles financial responsibility under card-scheme rules.
PCI SSC defines an acquirer as the financial institution that processes payment-card transactions for merchants and is recognized by the payment brand as an acquirer. The legal and scheme-recognized status matters because processing technology alone does not create acquiring authority.
Merchant Account
A merchant account is the commercial arrangement that allows a business to accept card payments through an acquirer. The merchant account is not usually a normal operating bank account. It is part of the acceptance and settlement relationship.
Some PSPs give each merchant a direct acquiring relationship and merchant identifier. Other PSPs operate through aggregation or payment-facilitator models.
Payment Facilitator and Payment Aggregator
A payment facilitator contracts with an acquirer and enables submerchants to accept payments under the facilitator’s sponsored structure. The merchant can often begin accepting payments faster than through an individual acquiring relationship.
The World Bank identifies direct involvement in settlement as an important distinction of a payment facilitator. A facilitator can receive settlement or contract with an acquirer on behalf of sponsored merchants, reducing the need for each small business to open a traditional merchant account.
A payment aggregator is a broader term that can describe a provider that combines many merchants, payment methods, or transactions through one acceptance structure. In some markets, payment facilitator and payment aggregator are treated as similar models; in others, the terms carry different regulatory or scheme obligations.
Direct Merchant vs Submerchant
| Criterion | Direct acquiring merchant | Submerchant under a facilitator |
|---|---|---|
| Contract structure | Direct relationship with the acquirer | Primary relationship with the payment facilitator or PSP |
| Onboarding | Often more detailed and institution-specific | Often faster and standardized |
| Merchant identifier | Usually a dedicated merchant identity | May operate under the facilitator’s sponsored structure |
| Pricing | Can be negotiated for larger volume | Often packaged into simple blended pricing |
| Risk controls | Managed directly by the acquirer | Shared between the facilitator and sponsoring acquirer |
| Account action | Acquirer can impose limits or termination | Facilitator may impose reserves, holds, or suspension under its program |
How the Providers Work Together
A typical online card payment may involve the following structure:
- The merchant’s website sends the customer to a hosted payment gateway or loads a secure gateway component.
- The gateway captures and protects the payment details.
- The gateway sends a payment request to the PSP or payment processor.
- The processor routes the request through the acquirer and card network to the issuer.
- The issuer approves or declines the payment.
- The processor returns the response through the chain.
- The acquirer and processor later support clearing and settlement.
- The PSP or acquirer pays the merchant according to the merchant agreement.
The detailed transaction lifecycle—including authorization, capture, clearing, settlement, merchant funding, and reconciliation—is covered in our guide to payment processing systems.
The main point for this comparison is that every provider operates at a different boundary. A gateway controls the entry point, a processor controls transaction handling, an acquirer controls the merchant’s access to the card scheme, and a PSP can package several boundaries into one service.
Who Actually Handles the Money?
| Provider role | Usually handles payment data? | Usually receives settlement? | Usually pays the merchant? |
|---|---|---|---|
| Gateway-only provider | Yes | No | No |
| Processor-only provider | Yes | Not necessarily | Not necessarily |
| Acquirer | Yes, directly or through a processor | Yes | Usually |
| Full-service PSP | Yes or through a hosted interface | May receive or arrange settlement | Often, directly or through an acquiring partner |
| Payment facilitator | Yes or through partners | Can receive settlement for submerchants | Often distributes funds to submerchants |
A merchant should identify the full money flow before signing a contract. The provider that supplies the dashboard may not be the provider holding settlement funds. The provider that transfers the payout may rely on a separate acquirer, sponsor bank, or processing company.
Practical Note: Ask every payment provider to draw two separate diagrams: one for transaction data and one for money movement. The diagrams should identify the legal entities involved, because payment data and settlement funds often follow different paths.
Security and PCI DSS Responsibility
PCI DSS applies to entities that store, process, or transmit cardholder data or can affect the security of the cardholder-data environment. Merchants, gateways, processors, acquirers, and service providers can therefore have different PCI responsibilities within the same payment chain.
A hosted gateway can reduce the merchant’s exposure to card data, but the merchant still needs to:
- use the provider’s integration correctly;
- protect website administration and deployment access;
- prevent malicious scripts and payment-page changes;
- control API and dashboard credentials;
- verify that the provider maintains required validation;
- document which responsibilities remain with the merchant;
- respond to security incidents and suspicious transactions.
“PCI compliant” is not a permanent property of a product. PCI SSC explains that formal compliance validation represents a point in time, while organizations must maintain applicable controls continuously.
Pricing Differences
Pricing is often difficult to compare because providers combine several cost layers.
Gateway Fees
A gateway provider may charge:
- setup or integration fees;
- a monthly platform fee;
- a per-transaction gateway fee;
- tokenization or stored-credential fees;
- fraud-tool fees;
- routing or orchestration fees.
Processing and Acquiring Fees
Processing and acquiring costs can include:
- processor fees;
- interchange paid to the issuer;
- card-scheme or network fees;
- acquirer margin;
- cross-border and currency fees;
- refund and chargeback fees;
- merchant reserves or risk holds.
Blended PSP Pricing
A full-service PSP may combine several components into one percentage and fixed transaction fee. Blended pricing is easy to understand but can conceal differences between low-cost and high-cost transactions.
Interchange-Plus Pricing
Interchange-plus pricing separates the issuer interchange, network fees, and provider margin. The model provides greater transparency but requires more detailed analysis.
The cheapest headline price is not always the lowest total cost. Merchants should include authorization performance, failed-payment recovery, payout timing, foreign-exchange margins, refunds, chargebacks, reporting, staff time, and integration maintenance.
Contractual Responsibility: Questions Merchants Should Ask
| Question | Why it matters |
|---|---|
| Which legal entity contracts with the merchant? | The brand and contracting entity may be different |
| Who is the acquirer? | The acquirer controls access to card schemes and financial settlement responsibilities |
| Is the merchant direct or a submerchant? | The answer affects onboarding, reserves, termination, and account portability |
| Who receives settlement funds? | The merchant must understand where money is held before payout |
| Who can impose a reserve or hold? | Unexpected reserves can create a serious cash-flow problem |
| Who handles chargebacks and evidence? | Dispute deadlines and responsibilities must be clear |
| Who stores payment credentials or tokens? | The answer affects security, portability, and recurring payments |
| Can transaction tokens be transferred? | Non-portable tokens can make provider migration difficult |
| What happens during provider failure? | The merchant needs access to transaction status, funds, and customer support |
| How are reports reconciled? | Every payout should be traceable to transactions, fees, refunds, and adjustments |
Which Model Is Best for Different Merchants?
Small Business or New Online Store
A full-service PSP is usually the best default. One provider can supply checkout, acquiring, processing, payment methods, payouts, and support. The business should still verify payout timing, reserve rules, account suspension procedures, and export capability.
Growing E-Commerce Business
A growing merchant may benefit from a PSP with multiple acquiring connections, strong reporting, stored-payment support, and routing options. The merchant should negotiate transparent pricing and preserve the ability to export customer tokens where permitted.
Large Enterprise
A large enterprise may separate gateway, orchestration, processing, and acquiring relationships. The structure can improve negotiation, routing, and provider resilience, but it requires strong internal payment operations and reconciliation.
Marketplace or Platform
A marketplace usually needs a payment-facilitator or platform-payment model that supports submerchant onboarding, split payments, compliance, reserves, and merchant payouts. A basic gateway is not enough.
Subscription Business
A subscription business needs reliable tokenization, recurring-payment indicators, account updating, retry controls, and payment-method portability. The cheapest one-time checkout provider may perform poorly for recurring revenue.
International Merchant
An international merchant needs local acquiring, currencies, alternative payment methods, foreign-exchange transparency, tax-compatible reporting, and cross-border settlement support. The merchant should determine whether the PSP uses one global acquirer or several local entities.
A Practical Provider-Selection Framework
- Map the payment methods. Identify cards, bank transfers, wallets, recurring payments, currencies, and countries.
- Map the legal roles. Record the gateway, processor, PSP, acquirer, payment facilitator, sponsor bank, and settlement entity.
- Map data flow. Identify where payment credentials, tokens, customer details, and transaction records are stored.
- Map money flow. Identify settlement accounts, merchant payouts, reserves, fees, refunds, and disputes.
- Test the complete lifecycle. Test approvals, declines, timeouts, duplicate requests, captures, refunds, chargebacks, and reporting.
- Calculate total cost. Include commercial fees, fraud, failed payments, support, accounting, and technical maintenance.
- Review concentration risk. Check whether several branded services depend on the same processor, acquirer, or cloud provider.
- Plan provider exit. Confirm data export, token migration, notice periods, and access to historical reports.
This framework should be integrated with the wider third-party controls described in fintech solutions and integrations. A payment provider is not only a software supplier; the provider can become part of the merchant’s financial operating model.
Common Payment Provider Failures and Misunderstandings
Assuming the Gateway Pays the Merchant
A gateway-only provider transmits payment data but may have no role in settlement. The merchant expects the gateway support team to resolve a missing payout, but the acquirer or PSP controls the funds.
Assuming the Processor Is the Acquirer
A processor can perform critical transaction functions without holding the formal acquiring relationship. The merchant should identify the institution recognized by the card scheme as the acquirer.
Using One Label for Several Contracts
A merchant calls every provider “the PSP” even though gateway, processing, acquiring, fraud, and payout services are supplied under different agreements. Incident escalation becomes unclear.
Ignoring Reserve and Hold Terms
A provider advertises fast onboarding but retains the contractual right to delay payouts or create a rolling reserve after risk changes. The merchant discovers the term only when cash flow is affected.
Building Around Non-Portable Tokens
The merchant stores customer payment credentials as provider-specific tokens. Migration requires customers to enter payment details again, increasing churn and operational risk.
Failing to Reconcile Gross and Net Amounts
The merchant compares sales totals directly with bank deposits without accounting for processor fees, refunds, chargebacks, currency conversion, and timing differences.
Treating a Backup Gateway as Full Redundancy
Two gateway brands may depend on the same acquirer, processor, card-network connection, or cloud platform. Real resilience requires independent critical paths, not only a second API endpoint.
Misunderstanding Security Outsourcing
The merchant uses a hosted checkout and assumes all payment security is outsourced. A compromised website can still redirect customers, alter payment scripts, or steal provider credentials.
Frequently Asked Questions
What is the difference between a payment gateway and payment processor?
A payment gateway captures and securely transmits payment information from the customer-facing checkout to payment-processing infrastructure. A payment processor routes authorization and transaction messages between merchants, acquirers, networks, and issuers. One company can provide both services, which is why the contractual role must be verified.
What is a payment service provider?
A payment service provider gives merchants access to payment acceptance through one commercial and technical relationship. A PSP may bundle gateway, processing, acquiring, payment methods, fraud tools, settlement, reporting, refunds, disputes, and merchant support. The exact service package varies by provider and jurisdiction.
Is a payment gateway a payment service provider?
A payment gateway can be part of a payment service provider’s product, but a gateway-only company may provide only technical payment-data capture and transmission. Industry terminology overlaps, so a provider calling itself a gateway may also act as a PSP, processor, or payment facilitator.
Does a payment gateway handle money?
A payment gateway acting only as a gateway normally does not receive or settle merchant funds. The gateway captures and routes payment data. An acquirer, payment service provider, facilitator, bank, or other settlement entity handles the money flow and merchant payout.
What is a merchant acquiring bank?
A merchant acquiring bank is the financial institution that contracts with a merchant to accept card payments, connects transactions to card schemes, receives settlement obligations, and funds the merchant. A processor can support the acquirer technically without being the scheme-recognized acquirer.
What is the difference between a PSP and payment facilitator?
PSP is a broad term for a provider of payment services. A payment facilitator is a specific acceptance model in which the facilitator works with an acquirer and onboards merchants as submerchants. A PSP may operate as a facilitator or may give merchants direct acquiring relationships.
Do businesses need both a payment gateway and processor?
Businesses need gateway and processing functions for online card acceptance, but the functions do not need separate providers. A full-service PSP can combine gateway, processing, acquiring, and settlement through one integration. Larger merchants may separate providers to gain routing control, pricing leverage, or resilience.
Which is more important: payment gateway or payment processor?
Neither role is more important because the gateway and processor solve different problems. The gateway secures the customer-facing payment entry point, while the processor routes and manages transaction messages. A merchant needs every critical function assigned to a reliable and accountable provider.
Conclusion
A payment gateway, payment processor, payment service provider, and acquirer are not interchangeable roles, even though one company may perform several of them.
The gateway controls the payment-data entry point. The processor handles transaction messages and network connectivity. The acquirer provides the merchant’s formal access to card acceptance and settlement. The PSP packages one or more of these functions into a merchant-facing service. A payment facilitator can further simplify acceptance by onboarding merchants as submerchants.
The best provider model depends on the merchant’s size, payment methods, countries, technical capability, and risk tolerance. Small merchants usually benefit from a full-service PSP, while larger businesses may separate gateway, processor, and acquiring relationships for greater control.
The final decision rule is simple: ignore the marketing title and map responsibility. A merchant should know who controls payment data, authorization routing, acquiring, settlement, payouts, disputes, security, and provider exit before processing the first transaction.
