A merchant’s contract may name a gateway, processor, PSP and acquiring partner, yet when a transaction fails, nobody seems sure which company is responsible. The confusion exists because payment providers often use overlapping labels, and one company can perform several roles at once.
This guide separates the main payment functions, explains who usually owns each responsibility, and shows what changes when a merchant switches one layer of its payment stack.
Key takeaways
- A payment gateway is primarily the technical connection between checkout software and payment services.
- A payment processor handles authorization messaging and transaction data between the merchant, networks and financial institutions.
- A PSP is usually a packaged service combining gateway access, processing, onboarding, risk tools and sometimes acquiring.
- An acquirer maintains the merchant-side card acceptance relationship and supports settlement.
- A payment orchestration layer coordinates multiple gateways, PSPs, processors, acquirers and alternative-payment providers.
- The product label is not enough. The contract determines who underwrites the merchant, holds funds, manages disputes and provides support.
Why payment roles blur together
The terminology is confusing for three main reasons.
First, one company can occupy multiple roles. A provider may offer a gateway, processor, merchant onboarding, fraud tools and acquiring access under one commercial brand.
Second, product names are not always legal or regulatory classifications. “Payment platform” or “payment solution” may describe a bundle rather than a single function.
Third, the structure varies by market. A PSP may contract directly with a merchant in one region while using a sponsor acquirer or local payment partner elsewhere.
The practical rule is simple: do not ask only, “What does this company call itself?” Ask, “Which legal entity performs each responsibility in this payment flow?”
Who does what in the payment stack?
The merchant’s checkout or platform
The merchant’s own website, mobile application or marketplace creates the payment request. It determines the order amount, currency, customer details, refund logic and business rules.
The merchant is also responsible for accurately describing its business, products and markets during onboarding. It must manage fulfilment, refunds, customer service, fraud controls, privacy obligations and dispute evidence.
The merchant’s platform may connect directly to a gateway API, use a hosted payment page or send requests through an orchestration layer.
Payment gateway
A payment gateway is the technical connection point between the merchant’s checkout and downstream payment services.
It may provide:
- A payment gateway API
- Hosted payment pages
- Secure payment-data transmission
- Tokenization or links to a token vault
- Authorization and capture requests
- Refund and recurring-payment functions
- Transaction responses and webhooks
A gateway does not normally decide whether the cardholder has sufficient funds or credit. That decision is generally made by the issuing bank. The gateway also does not automatically hold the merchant’s settlement funds or become the merchant’s acquirer.
A gateway may be standalone, or it may be embedded inside a PSP or acquiring service.
Payment processor
A payment processor handles the operational movement of authorization messages and transaction data.
It may connect the merchant or PSP to card networks, issuers, acquirers and settlement systems. Processing functions can include authorization messaging, capture, clearing support, reconciliation data and transaction-status updates.
The term “processor” can describe different functions, so the contract matters. A processor is not necessarily the merchant’s acquirer. It may work for an acquirer, PSP or multiple acquiring institutions without having a direct merchant relationship.
For the search query payment gateway vs payment processor, the simplest distinction is:
- The gateway provides the technical connection.
- The processor moves and manages transaction messages behind that connection.
Payment service provider (PSP)
A PSP is usually a packaged payment service rather than one isolated technical component.
A PSP may combine:
- Gateway access
- Payment processing
- Merchant onboarding and verification
- Acquiring relationships
- Fraud and risk tools
- Refunds and disputes
- Reporting
- Payouts
- Customer support
Some PSPs are also payment facilitators or operate with a sponsor acquirer. Others provide technology while relying on separate acquiring partners.
A merchant should ask a PSP:
- Who is the acquiring institution?
- Who holds or controls settlement funds?
- Who signs the merchant agreement?
- Which entity performs underwriting?
- Who manages chargebacks and reserves?
- Which entity is regulated in the relevant market?
- Who owns the token vault and payment data?
Acquirer or merchant acquirer
The acquirer is the merchant-side card acceptance relationship.
The acquirer, or a PSP acting within an acquiring arrangement, typically supports merchant onboarding, connects transactions to the relevant card network, receives settlement from the issuer side and credits funds to the merchant according to the approved agreement.
The acquiring agreement may define:
- Permitted business activities
- Merchant category and processing markets
- Fees and settlement currencies
- Reserve requirements
- Refund and chargeback obligations
- Security and data requirements
- Termination rights
- Post-termination liabilities
The acquirer does not usually make the cardholder’s final credit decision. The issuer normally approves or declines the authorization request.
For businesses expanding internationally, Payvea’s global acquiring service connects merchants with supported acquiring relationships through partners. Availability remains subject to underwriting, provider approval and supported markets.
Card network
A card network routes authorization and clearing messages between issuers and acquirers and maintains the operating rules for the card system.
The network does not generally act as the merchant’s bank or decide whether a consumer has enough available credit. It facilitates communication and settlement while applying rules covering security, disputes, data, retries and acceptance.
The merchant normally receives its network obligations through its acquirer or PSP agreement rather than through a direct commercial contract with the card network.
Payment orchestration layer
Payment orchestration is a control layer above multiple payment connections. It can coordinate gateways, PSPs, processors, acquirers, wallets and alternative-payment providers through one integration.
Its role is to centralize provider connectivity, transaction visibility and decisioning. It does not become an acquirer, issuer or card network merely because it manages the payment flow.
For a fuller explanation of the architecture and use cases, see Payment Orchestration: The Complete Guide for Global Merchants.
The master comparison
| Role | What it does | What it does not necessarily do | Typical agreement or documentation | Main accountability |
|---|---|---|---|---|
| Merchant platform | Creates payment requests, manages orders and customer experience | Does not authorize cards or settle funds | Platform, software and payment-integration terms | Accurate transaction data, fulfilment, refunds and customer obligations |
| Gateway | Connects checkout software with payment services; transmits payment data | Does not normally approve credit or act as acquirer | Gateway/API terms, security and data-processing documentation | Technical availability, data handling and integration support |
| Processor | Moves authorization and transaction messages; supports processing and reconciliation | Is not necessarily the merchant’s acquirer | Processor or subcontractor terms | Message handling, transaction status and processing operations |
| PSP | Bundles gateway, processing, onboarding, risk, reporting and sometimes acquiring | Is not always the acquirer or funds holder | Merchant services agreement and incorporated network rules | Support, onboarding, risk controls and services defined in the contract |
| Acquirer | Maintains merchant-side acceptance relationship and supports settlement | Does not normally make the issuer’s credit decision | Merchant acquiring agreement | Underwriting, settlement arrangements, reserves, disputes and scheme obligations |
| Card network | Routes messages and operates scheme rules | Is not normally the merchant’s bank or issuer | Rules flow through acquirer or PSP agreement | Network operations, standards and dispute framework |
| Orchestration layer | Coordinates multiple providers and payment routes | Does not replace acquiring or guarantee authorization | Orchestration, API, data and support terms | Routing controls, provider connectivity, reporting and operational coordination |
Who is responsible when something happens?
| Situation | Usually responsible first | What the merchant should check |
|---|---|---|
| A transaction declines | The issuer makes the approval decision; the acquirer, processor or PSP returns the response | Decline code, issuer response, risk decision and whether the failure was technical |
| A gateway or provider goes offline | The affected gateway, processor or PSP | Incident process, status reporting and whether another approved route exists |
| Settlement is late | The acquirer or PSP responsible for the approved settlement arrangement | Settlement calendar, reserves, reconciliation and any compliance hold |
| A dispute arrives | The acquirer or PSP manages the formal process; the merchant supplies evidence | Evidence deadlines, dispute fees and who owns customer communications |
| A local payment method is needed | The PSP, acquirer or payment-method provider must support it | Market availability, technical integration and merchant approval |
| Routing rules need to change | The merchant or its orchestration operator, depending on the agreement | Who can change rules, test changes and audit route decisions |
| The merchant agreement ends | The contracting PSP, acquirer or payment provider | Token portability, refunds, reserves, data export and post-termination obligations |
How money moves through a card transaction
The terminology becomes clearer when the payment stages are separated:
- Authorization: The merchant requests approval. The acquirer or processor sends the message through the card network to the issuer. The issuer approves or declines.
- Capture: The merchant confirms that an approved transaction should be completed.
- Clearing: Transaction details are exchanged and prepared for financial settlement.
- Settlement: Funds move through the network and acquiring structure.
- Payout: The merchant receives funds according to the acquiring or PSP agreement, after applicable fees, reserves or adjustments.
A gateway may support several of these actions technically, but that does not mean it is the entity responsible for settlement or underwriting.
What changes when orchestration is added?
An orchestration layer can give a merchant one technical connection to several supported providers. That may reduce the need to build and maintain separate integrations for every gateway, PSP or alternative-payment method.
It can also centralize reporting, provider monitoring, routing controls and payment operations. However, the underlying contracts do not disappear. The merchant may still need approved relationships with multiple PSPs or acquirers, and each provider may have different settlement, refund, token and dispute procedures.
Payvea provides unified payment gateway infrastructure, not banking or direct acquiring services. Through supported partners, businesses can connect to payment service providers, acquiring relationships and alternative payment methods through one integration. Its available methods and currencies depend on provider capabilities, merchant profile, underwriting and supported markets.
Common misconceptions corrected
“A gateway and processor are the same thing.”
They can be offered by the same company, but their functions differ. The gateway is the connection point; the processor handles transaction messaging and processing operations.
“A PSP is always the acquirer.”
Not necessarily. A PSP may be the acquiring service, an agent of an acquirer, a payment facilitator or a technology provider using third-party acquiring.
“An orchestrator means the merchant no longer needs acquiring.”
No. Orchestration coordinates approved payment relationships. It does not replace the merchant-side acquiring arrangement.
“Changing gateways means changing the merchant account.”
Not always. A merchant may replace a gateway while keeping the same acquirer and processor. However, token formats, APIs, credentials, refunds and recurring payments may require migration work.
“One provider is always simpler and better.”
One provider can be appropriate for a focused business. Global or complex merchants may need multiple providers because of market coverage, payment methods, operational resilience or provider concentration risk.
A short self-audit for the payment stack
A merchant should document the following for every payment method and market:
- Who is the contracting entity?
- Who performs underwriting?
- Who is the acquirer?
- Who holds or controls settlement funds?
- Who owns the token vault?
- Who manages disputes and reserves?
- Who can change routing rules?
- Which provider is responsible for technical incidents?
- Can transaction data, tokens and customer records be exported?
- What happens if the relationship ends?
If internal teams cannot answer these questions, the payment stack is not fully mapped.
Frequently asked questions
Is a payment gateway the same as a payment processor?
No. A gateway connects the merchant’s checkout to payment services. A processor handles authorization messaging and transaction data. One company may provide both.
What does PSP stand for, and does a PSP acquire?
PSP means payment service provider. A PSP may provide acquiring directly or through a sponsor acquirer and other partners. The merchant should verify the legal and contractual structure.
Can one company be both gateway and processor?
Yes. Many providers combine technical gateway services with processing, onboarding, risk management and acquiring access.
Do merchants need a gateway if they use a PSP?
Usually, the PSP includes gateway functionality or provides another technical connection. The merchant may not need a separate gateway contract, but it should confirm what is included.
What is the difference between a payment gateway and an acquirer?
A gateway is primarily a technology connection. An acquirer maintains the merchant-side acceptance relationship and supports settlement under the merchant agreement.
Who owns the merchant account?
Usually, the merchant account or acceptance relationship is held through the acquirer or PSP arrangement. The exact legal structure depends on the contract and market.
Is payment orchestration a type of gateway?
Orchestration can include gateway functionality, but it is broader. It coordinates multiple payment connections rather than serving only as one technical route.
Does switching a gateway mean switching the merchant account?
Not necessarily. The acquirer may remain the same, but integration credentials, tokens, refunds and recurring billing may need to be migrated.
Conclusion
The payment gateway, processor, PSP, acquirer, card network and orchestration layer perform different jobs, even when one company provides several of them.
The gateway connects systems. The processor moves transaction messages. The PSP packages payment services. The acquirer manages the merchant-side acceptance and settlement relationship. The card network operates the payment scheme. Orchestration coordinates multiple providers above these underlying relationships.
Understanding that responsibility map helps merchants negotiate better contracts, resolve incidents faster and avoid unexpected dependency. For businesses managing multiple markets, payment methods or acquiring relationships, Payvea’s payment gateway infrastructure provides a unified connection to supported payment partners, reporting tools and payment operations.
For broader payment infrastructure context, read the complete payment orchestration guide. Related cluster topics include smart payment routing, payment cascading, payment failover and acquiring redundancy.
