Payment gateway vs PSP vs acquirer vs orchestration

“Gateway”, “PSP”, “acquirer”, “processor” and “orchestration platform” are often used interchangeably, but they are distinct roles in a card payment. Some providers bundle several roles behind one contract and one API; others specialise. To choose an architecture, separate the money flow (who moves and settles funds) from the data flow (who carries the authorisation message), then decide which roles you buy from one partner and which you keep independent. This guide defines each role and shows how they connect.

Merchant

The merchant is the business accepting payment — you. Your obligations include collecting payment data securely, presenting transactions correctly, and settling with your customers and suppliers. Everything below exists to move a customer’s payment to you and to carry the data that authorises it.

Gateway

A payment gateway is the entry point that captures payment details and transmits them into the payment system. It is primarily a data component: it securely collects card or payment data from the checkout and forwards an authorisation request. A gateway does not itself settle money; it connects your checkout to the parties that do.

PSP

A payment service provider (PSP) is a broad term for a company that lets merchants accept payments. Providing payment services in the EU sits within a regulated framework 1. In practice a PSP may bundle the gateway, connections to acquirers, and value-added services. The label alone does not tell you which underlying roles are performed in-house versus through partners — ask.

Acquirer

The acquirer is the regulated entity that holds the merchant relationship with the card networks and receives the funds from a card transaction on your behalf before settling them to you. The acquirer carries settlement and much of the financial risk. Acquiring is where interchange, scheme fees and acquirer margin arise — see merchant acquiring pricing.

Processor

A processor performs the technical work of routing authorisation, clearing and settlement messages between the acquirer and the card networks. Some acquirers process in-house; others use a separate processor. Processing is largely invisible to the merchant but determines reliability, message features and how quickly new capabilities appear.

Card network

The card network (scheme) operates the rails that connect acquirers and issuers, sets scheme rules and fees, and defines message standards. Networks do not lend to the cardholder or hold the merchant relationship; they route and govern. Interchange fees for certain card-based transactions are regulated 2.

Issuer

The issuer is the cardholder’s bank or card programme that authorises or declines a transaction against the customer’s account and funds it. If you also plan to issue cards, the issuing side is a separate build — see card issuing explained.

Orchestration platform

A payment orchestration platform sits above gateways, PSPs and acquirers and provides a single integration to many of them. It routes transactions, manages failover, normalises data and consolidates reporting. Orchestration is a control and routing layer; it does not usually become the regulated acquirer itself. The build multi-acquirer payment orchestration stack covers this pattern.

Token vault

A token vault stores sensitive payment credentials and returns a token that your systems use instead of raw card data. Keeping card data out of your systems reduces the surface area you must protect. Whether the vault is provided by a gateway, PSP or orchestration layer affects portability if you later switch providers.

Fraud provider

A fraud provider scores transactions and applies rules or models to accept, challenge or decline them. It may be built into a PSP or integrated separately through orchestration. Fraud decisioning interacts with strong customer authentication, which is governed by regulatory technical standards 3.

Alternative payment method

Alternative payment methods (APMs) are non-card options such as account-to-account transfers or wallets. Each APM may have its own connection, settlement path and reconciliation model. Orchestration layers often add APMs behind one integration, but the money and data flows for each still differ.

Payout provider

A payout provider moves funds out — to sellers, suppliers or customers. Payouts are a distinct capability from acceptance, with their own rails, timing and reconciliation. For cross-border payouts, see comparing cross-border payment providers and the accept payments globally stack.

Data flow and money flow

Separate the two paths. The data flow carries the authorisation request from checkout → gateway → acquirer/processor → network → issuer, and the decision back. The money flow moves funds from issuer → network → acquirer → merchant during clearing and settlement, which happens after authorisation. A provider can sit on one path and not the other, which is why “who authorises” and “who settles” are different questions.

One-provider versus multi-provider architecture

A single bundled provider is simpler to integrate and reconcile but concentrates dependency and can limit routing choice. A multi-provider architecture, usually via orchestration, adds resilience and negotiating leverage but increases integration and reconciliation complexity. The right choice depends on volume, geography and how much operational capacity you have.

Smart routing

Smart routing sends each transaction to the connection expected to perform best — by cost, approval likelihood, currency or geography. Routing only adds value if you have more than one viable path and reliable data to decide between them. Poorly configured routing can reduce approval rates rather than improve them.

Failover

Failover reroutes transactions when a primary connection is degraded or unavailable. It requires at least two capable paths, health signals, and rules for when to switch. Failover protects revenue during incidents but must be tested; a failover path that is never exercised tends to fail when it is finally needed.

Reconciliation

Reconciliation matches authorisations, captures, settlements, refunds and fees back to your ledger. With multiple providers, reconciliation is harder because each reports differently. Confirm how each provider’s settlement files and reports map to transactions before you add connections, not after.

PCI scope as a consideration

How you capture and store card data affects the scope of the security obligations that apply to you. Using hosted fields, a gateway or a token vault can reduce how much card data touches your systems. This guide flags PCI scope as something to plan for with your provider and qualified assessor; it does not and cannot make a compliance determination for your setup.

Responsibility matrix

Role	Primary function	Money flow	Data flow
Merchant	Accept payment	Receives settlement	Originates request
Gateway	Capture and transmit data	No	Yes
PSP	Bundle acceptance services	Sometimes	Yes
Acquirer	Hold merchant relationship, settle	Yes	Yes
Processor	Route scheme messages	No (technical)	Yes
Network	Operate rails, set rules	Routes	Yes
Issuer	Authorise and fund	Yes	Yes
Orchestration	Route and normalise across providers	No	Yes

Provider selection checklist

• Each role in your intended flow identified and assigned to a provider
• Money flow and data flow diagrammed end to end
• One-provider vs multi-provider decision made with volume and geography in mind
• Routing and failover requirements defined and testable
• Token vault portability understood before committing
• Reconciliation output reviewed for every connection
• PCI scope discussed with provider and qualified assessor
• SCA and fraud decisioning responsibilities mapped

Questions to ask providers

• Which of these roles do you perform in-house, and which through partners?
• Are you the regulated acquirer, or do you connect to one?
• How does authorisation data flow, and separately, how do funds settle to us?
• What routing and failover options exist, and how are they configured and tested?
• Where are card credentials tokenised, and can we take the tokens if we leave?
• How do your settlement files and reports reconcile to individual transactions?
• How do you support strong customer authentication and fraud decisioning?
• How does your setup affect our PCI scope?

Common failure modes

• Treating “PSP” as one thing and never learning who actually acquires and settles.
• Adding orchestration without the data needed to route intelligently.
• Building failover paths that are never tested and fail during a real incident.
• Locking card tokens into one provider, making later migration costly.
• Discovering reconciliation complexity only after connecting multiple providers.

What this does not cover

This guide does not assess any specific provider, set prices, determine your PCI scope or make any compliance determination. It complements — but does not replace — advice from your acquirer, qualified security assessor and legal advisers.

FAQ

Is a gateway the same as a PSP?

Not necessarily. A gateway captures and transmits payment data; a PSP is a broader provider that may bundle a gateway, acquiring connections and other services. Ask which underlying roles a PSP performs itself.

Do I always need an orchestration platform?

No. Orchestration adds value when you use multiple providers and need routing, failover and consolidated reporting. With a single provider and modest volume, it can add complexity without benefit.

Who actually settles the money to me?

The acquirer holds the merchant relationship with the networks and settles card funds to you. A gateway or orchestration layer typically does not settle funds itself.

How does strong customer authentication fit in?

Strong customer authentication is governed by regulatory technical standards 3 and is applied during the authorisation journey. Your gateway, PSP and fraud provider all interact with it.

Can this guide tell me if I am PCI compliant?

No. PCI scope depends on how you capture and store card data across your specific systems. Plan it with your provider and a qualified assessor; this guide only flags it as a design consideration.