A payment gateway vs PSP comparison starts with scope. A gateway carries payment data. A payment service provider usually bundles more of the transaction stack. An orchestration layer sits above one or more providers and decides where a payment attempt should go. The labels overlap in sales material, so the contract and data flow matter more than the name.
The short version
| Layer | Main job | What it may include | What it does not settle by itself |
|---|---|---|---|
| Payment gateway | Securely transmits payment details from checkout to the processing side | Hosted fields, tokenization, checkout integrations and connections to processors or acquirers | The full acquiring, merchant-account and settlement relationship |
| Payment service provider | Gives a merchant a broader package for accepting and managing payments | Gateway, processing, acquiring connections, risk tools, reporting and settlement services | Neutral access to every external provider or automatic multi-provider routing |
| Payment orchestration | Coordinates payment flows across processors, acquirers or PSPs | Routing rules, retries, failover, unified monitoring and provider selection | The underlying processing contracts, provider fees, settlement duties or dispute operations |
These are functional descriptions, not legal categories. One supplier can cover more than one row. Stripe’s explanation separates the gateway that passes transaction data from the processor that authorizes and moves funds. Adyen’s PSP guide describes a broader service that can bring gateway, processing, merchant-account infrastructure, fraud controls, reporting and settlement together.
Where a gateway stops
A payment gateway is the entry point between checkout and the payment-processing chain. It collects or receives payment information, protects it in transit and sends the transaction request onward. A modern gateway may also provide tokenization, hosted payment fields, recurring-payment support and connections to several acquiring routes.
That still does not make every gateway the merchant’s processor or acquirer. Stripe distinguishes the gateway’s information-transfer role from the processor’s work of communicating with banks and payment networks to authorize and move funds. In a merchant’s architecture, those roles may come from separate vendors or from one vendor that bundles them.
This distinction matters during procurement. A gateway quote can look inexpensive if processing, merchant-account fees, fraud tooling, settlement, chargeback operations and local payment methods sit elsewhere. Compare the complete flow, not just the checkout component.
What a PSP usually bundles
A payment service provider, or PSP, is usually the broader commercial package. Adyen defines a PSP as a company that helps businesses accept and manage payments by connecting them to payment methods, networks and financial institutions. Its guide says the service commonly combines gateway technology, processing, merchant-account infrastructure, fraud prevention, reporting and settlement support.
“Usually” is doing important work here. PSP scope varies. Some providers are also acquirers in certain markets. Others connect merchants to separate acquiring partners. Some offer a single contract and dashboard; others still require additional agreements for particular countries or payment methods.
The practical test is to map responsibility for six jobs:
- Checkout and payment-data capture
- Tokenization and storage
- Authorization routing
- Merchant acquiring
- Settlement and reconciliation
- Disputes, refunds and fraud operations
If a proposal leaves any job outside the package, name the vendor, contract and system that owns it. The answer is more useful than arguing about whether the supplier “counts” as a PSP.
What orchestration adds
Payment orchestration adds a control layer across payment providers. Adyen describes it as a centralized layer between a business and its PSPs. The layer can apply routing rules, send transactions to different providers and switch paths when one route underperforms or becomes unavailable.
Stripe’s current Payments Orchestration documentation describes a similar multi-processor model. Its private-preview product can route payments between Stripe and third-party processors, retry declined attempts and monitor performance in one place. Stripe also says that a third-party processor remains the processor for payments it handles; that processor’s pricing, settlement terms and other obligations still apply.
Orchestration is therefore about choice and coordination. It can be valuable when a merchant has several processors, needs local acquiring in multiple markets, wants explicit routing rules or requires an operational failover path. It is not automatically useful for a business with one provider and a simple payment mix.
For a fuller look at the layer, see our payment orchestration guide. If provider selection is the immediate task, compare the best payment orchestration platforms against your actual regions and payment methods.
What orchestration does not remove
An orchestration layer does not erase the underlying provider relationships. Stripe’s documentation says third-party-processed payments remain subject to that processor’s agreement. It also notes current boundaries: its orchestration preview does not cover non-card payment methods or third-party disputes, refunds, payouts, reporting and settlement in the same way as Stripe-processed payments.
Adyen’s orchestration guide highlights the broader operational trade-off. Connecting more providers can improve routing flexibility, but it can also add integrations, contracts, fee models, reconciliation work and fragmented data. The orchestration platform itself becomes another dependency that needs monitoring.
Ask who owns each failure state:
- A processor times out after authorization.
- A retry creates a duplicate authorization risk.
- A refund must be issued through the original provider.
- Settlement reports disagree with the orchestration dashboard.
- A dispute arrives through a third-party processor.
If ownership is unclear before launch, orchestration will not make it clearer after launch.
How the three fit in one stack
A merchant can use all three layers without duplication:
- The gateway or checkout component captures payment details and creates a protected payment request.
- A PSP or processor handles authorization, acquiring and settlement for the selected route.
- The orchestration layer chooses the route, applies retry or failover logic and collects operational signals across providers.
The exact boundaries depend on the product. A PSP can include its own gateway. An orchestration provider can also sell gateway services. A single full-stack provider can expose routing features that resemble orchestration without becoming a neutral control plane across every external processor.
Draw the flow using named systems and contracts. Put the checkout, token vault, routing decision, authorization request, settlement file, refund and dispute in the diagram. The overlaps become visible quickly.
A procurement checklist
Before choosing a gateway, PSP or orchestration platform, ask:
- Which entity processes each transaction and which entity acquires it?
- Who holds the merchant account or equivalent settlement relationship?
- Which payment methods and countries are supported under the quoted contract?
- Can existing processor contracts be reused?
- Who controls tokens, and are they portable?
- How are routing rules tested and changed?
- What happens when the preferred route times out or declines?
- Where are refunds and disputes managed?
- How are provider reports reconciled to the orchestration view?
- Which fees apply at the gateway, orchestration, processing and acquiring layers?
- Which service-level commitments cover each dependency?
For marketplace-specific liability, our guide to marketplace chargebacks explains why the platform’s payment model affects where dispute debits land.
