Payment terminology can be confusing because different companies group responsibilities in different ways. Gateway, PSP, acquirer, and sub-acquirer often appear in the same conversation, but they do not necessarily represent the same function.
Understanding those responsibilities is more useful than memorizing commercial categories. When a company knows who carries the request, who manages the processing relationship, and where each decision happens, designing integrations, investigating failures, and evaluating vendors becomes easier.
Why are there so many names?
Payments involve a chain of multiple participants. Over time, companies have offered different combinations of technology, processing, financial services, risk, and checkout experience.
As a result, two platforms called PSPs may have different scopes, while a product called a gateway may offer capabilities beyond its historical definition.
Commercial boundaries change. Architectural responsibilities remain a more stable way to understand the system.
What is a payment gateway?
A gateway is the technology layer connecting a company's application to the infrastructure needed to send and receive payment information.
It may offer a common API, checkout components, tokenization, integrations, and other features, depending on the product.
A gateway should not be defined solely by its visible interface. It is important to understand which participants it forwards operations to and which responsibilities it takes on throughout the payment lifecycle.
What is a PSP?
PSP stands for Payment Service Provider. Broadly, it describes a provider of payment services that helps businesses access the capabilities they need to accept payments.
The scope varies considerably. A PSP may combine a gateway, acquirer integrations, alternative methods, operational management, and other services.
That is why asking only whether a company is a PSP is rarely enough. The useful question is which functions it performs and which relationships remain the merchant's responsibility.
What is an acquirer?
In the card ecosystem, an acquirer participates in transaction processing and connects merchants to the infrastructure needed to route authorizations and other operations in the flow.
The regulatory and operating models vary by market, but acquiring serves a distinct function from the software layer that simply carries API calls.
An integration may reach the acquirer directly or through other participants.
What is a sub-acquirer?
In simplified terms, a sub-acquirer acts as an intermediary that allows merchants to access acceptance and processing capabilities through its own relationships with other participants in the chain.
The terminology and actual responsibilities depend on the market and business model.
Again, the commercial classification should be complemented by an analysis of the actual flow: who contracts with whom, who processes, who settles, and who retains which responsibilities.
Are gateways and PSPs competitors?
Not necessarily. A PSP may include a gateway in its offering. A gateway may connect to multiple PSPs or acquirers. A platform may combine functions traditionally assigned to different categories.
This means comparing vendors by label alone can lead to an unfair comparison.
The evaluation should break down capabilities and responsibilities.
Are PSPs and acquirers the same thing?
Again, not necessarily. PSP is a broad category of service provider. Acquiring represents a specific function in the card ecosystem.
A platform may facilitate access to acquirers without itself acting as the acquirer in that flow.
Understanding the architecture requires identifying who fills each role in the actual transaction.
Where does checkout fit in?
Checkout is the experience in which customers enter or select the information needed to pay. It can be hosted, embedded, or built in other ways.
Checkout should not be confused with processing. It is an experience layer connected to payment infrastructure.
Depending on the architecture, the same checkout experience may work with different routes behind the scenes.
Where does tokenization fit in?
Tokenization replaces sensitive data with a representation that can be used within a specific context.
Different participants may offer it. Vault location and token portability are important architectural questions, especially in multi-PSP strategies.
If a tokenized credential can only be used with one provider, switching the processing route may not be as simple as it seems.
Where does fraud prevention fit in?
Fraud prevention assesses risk and may participate before or during different stages of the flow, depending on the architecture.
It may be a separate product, a capability integrated into a PSP, or part of a broader solution.
The position of fraud prevention affects which data is available and when a decision can stop or allow a transaction to move forward.
Where does 3DS fit in?
3DS is an authentication protocol associated with card payments. It introduces additional interaction and information exchange among ecosystem participants.
Authentication is not the same as authorization. A transaction may go through authentication and still proceed to other processing stages.
In multi-PSP architectures, the authentication context must also be considered when the route can change.
Where does orchestration fit in?
Orchestration adds a coordination layer between the payment intent and its possible execution paths.
Depending on the implementation, it can centralize routing, normalization, state, observability, and failure-handling policies.
Instead of checkout being tightly tied to a single provider, an orchestration layer can allow different routes to be managed in a common way.
Does an orchestrator replace a PSP or acquirer?
No. Orchestration coordinates paths; it does not remove the need for participants that actually perform the ecosystem's functions.
A useful analogy is that the orchestrator decides and coordinates while connectors and providers execute specific capabilities.
The exact boundary varies by platform, but coordination does not make the coordinated components disappear.
What does direct integration mean?
Direct integration generally means the application connects to a provider's API without an intermediate abstraction or orchestration layer for that responsibility.
This can be simple and efficient when there is only one path.
As the number of integrations grows, however, the application may accumulate specific rules, different error models, distinct webhooks, and custom logic for each vendor.
The hidden cost of multiple integrations
The work does not end when the first authorization succeeds. APIs change, certificates expire, versions are retired, webhooks need processing, and behavior needs monitoring.
Every new integration expands the operational surface.
A common layer may reduce some of that coupling, but it also needs maintenance. No abstraction is free.
How do you compare two providers?
Start with the capabilities the business needs. Methods, markets, currencies, integration models, tokenization, authentication, observability, and operational requirements may all be part of the analysis.
Then identify which responsibilities each vendor takes on and which remain with your team.
Price matters, but comparing price alone without comparing scope can put different products on the same spreadsheet row.
Who controls the data and state?
This question is especially important for portability. If payment state, tokens, or essential information are available only within one vendor, changing the architecture may require additional work.
A well-designed integration makes clear which identifiers belong to the internal domain and which belong to each provider.
This also makes reconciliation and investigation easier when multiple participants are involved.
Who receives the webhooks?
Asynchronous events are part of the payment lifecycle. In a direct integration, the application may receive events specific to each provider.
With an intermediate layer, these events may be normalized before reaching the application's domain.
What matters is preserving enough information to trace their origin and ensuring normalization does not hide details needed for diagnosis.
How does this work in a multi-PSP architecture?
An application may use a common layer that knows different connectors. Each connector translates operations for a specific PSP or acquirer.
A routing engine decides which eligible route will receive the attempt. State management and observability record what happened, regardless of the path.
This architecture separates the payment domain from each integration's specifics without pretending all providers are identical.
Which model is best?
There is no universal answer. A direct integration may be better for a simple operation. A full-service PSP may reduce the number of relationships and integrations. A multi-PSP strategy may matter for operations with specific resilience, market, or control requirements.
The architecture should be proportional to the problem.
Adding unnecessary participants also adds cost, failure points, and operational complexity.
Questions to ask before signing up
Instead of asking only which category describes the vendor, investigate the flow. Who processes the authorization? Who holds the token? How does portability work? Which methods and markets are supported? How are errors represented? How do webhooks and reconciliation work? Can more than one route be used?
These answers reveal more about the architecture than the label on the sales page.
Where does AZPay fit into this map?
AZPay approaches payments as infrastructure that needs to be understandable, integrable, and able to evolve. This makes the separation of responsibilities especially important.
The roles described in this article represent general ecosystem concepts and should not be interpreted as a claim that AZPay necessarily performs every function mentioned.
Product features and responsibilities should be evaluated against the actual implementation and documentation.
Understand responsibilities, not just acronyms
Gateway, PSP, acquirer, and sub-acquirer help organize the conversation, but they do not replace mapping the flow.
When we examine who receives the intent, who chooses the route, who processes, who authenticates, who stores credentials, and who observes state, the architecture becomes much clearer.
Ultimately, understanding payments means understanding responsibilities and the connections between participants.