ISO, PSP, acquirer, and processor describe different positions in the payments value chain. An ISO usually sells and supports merchant services for an acquirer, a PSP is a broad provider category, an acquirer is the institution responsible for acquiring a merchant’s transactions, and a processor supplies the technology and operations that move transaction data. One company may perform several of these functions, so the contract and funds flow matter more than the label alone.
Table of Contents
- ISO vs PSP vs acquirer: the short answer
- What is an ISO in payment processing?
- What is a PSP?
- What is an acquirer?
- What is a payment processor?
- How the four roles fit together in one transaction
- ISO vs PSP vs acquirer: the commercial relationships to check
- When one company performs several roles
- Practical examples of the differences
- A merchant checklist for evaluating the structure
- Limitations of these definitions
- Frequently Asked Questions
ISO vs PSP vs acquirer: the short answer
The cleanest way to separate these terms is to ask what each party contributes. An independent sales organization, or ISO, is primarily a commercial distribution and merchant-service channel. A payment service provider, or PSP, is a broad business label for a provider that enables payment services, which may include acquiring, authorization, processing, authentication, onboarding, and other functions. The European Central Bank uses PSP in this broad sense rather than as one single technical job title. [5]
An acquirer is the merchant-side financial institution in a card transaction. The PCI Security Standards Council describes it as the merchant bank, acquiring bank, or acquiring financial institution that processes card transactions for merchants and is subject to payment-brand rules concerning merchant compliance. [3] A processor is the technology and operations layer that handles payment messages and related work such as authorization routing, capture, clearing, settlement processing, reconciliation, reporting, or exception handling. A processor may be owned by an acquirer, contracted by one, or operated by a PSP that combines multiple roles.
This means “ISO vs PSP vs acquirer” is not a comparison of four mutually exclusive company types. ISO describes a channel and service relationship. PSP describes a broad provider category. Acquirer describes a merchant-side acquiring function and relationship. Processor describes an operational capability. The same provider can legitimately appear in more than one column.
What is an ISO in payment processing?
An ISO is an independent sales organization authorized to act for an acquiring client, usually by finding merchants, explaining acceptance services, helping with applications, and supporting the merchant relationship. Visa’s acquiring description says an ISO-M may solicit or refer merchants for Visa acceptance and may perform sales, onboarding support, customer service, or the sale or lease of acceptance devices or services. [1]
Visa’s current functional description draws an important operational boundary: an ISO-M does not process transactions, receive settlement funds, or access Visa account data or the merchant’s payment environment. If an organization performs those functions, it may also qualify under another third-party-agent category. [1] In practical terms, an ISO can sell or white-label a payment solution while another registered provider operates the underlying processing service.
That boundary explains why an ISO’s sales promise should be checked against the merchant agreement. The ISO may explain the offer while a different acquiring bank, processor, payment facilitator, or service provider controls underwriting, the merchant identifier, statements, disputes, or reserves.
An ISO is also not automatically a payment facilitator. Visa says a payment facilitator may sign a merchant acceptance contract on behalf of an acquirer and receive settlement proceeds for a sponsored merchant. [2] Those are materially different powers from referring a merchant to an acquirer or supporting that merchant as a sales channel.
What is a PSP?
A PSP, or payment service provider, is best understood as an umbrella term. The ECB defines a PSP as a natural or legal person providing services such as issuing, acquiring, transaction authorization, or end-user authentication that enable value transfer between end users. [5]
In commercial usage, PSP can therefore describe a provider that packages several payment capabilities rather than one narrowly defined processing function.
The word PSP does not answer every commercial question. It does not tell you whether the merchant receives an individual merchant account, whether transactions are sponsored under a payment-facilitator model, whether the provider is the acquiring institution, or which entity holds funds before payout. It also does not by itself establish a provider’s licensing status in every jurisdiction. Those facts depend on the provider’s structure, the payment method, the merchant’s location, and the written terms.
Visa’s older registration FAQ is useful but requires careful reading. It describes “payment facilitator” as the newer term for entities formerly known as payment service providers in that network context. [2] That historical terminology should not be treated as proof that every business calling itself a PSP is a Visa payment facilitator today. Mastercard separately defines a payment facilitator as a service provider registered by an acquirer to facilitate transactions for submerchants, and says the acquirer must register it with Mastercard. [4]
The safest approach is to treat PSP as a functional description and then identify the underlying roles. Ask whether the provider is acting as acquirer, processor, payment facilitator, gateway operator, merchant servicer, or some combination. This avoids assuming that a broad marketing label settles questions about contracts, settlement, or accountability.
What is an acquirer?
An acquirer is the merchant-side institution that enables a merchant to accept a card brand and receive the proceeds of accepted transactions, subject to the applicable rules and agreement. PCI SSC identifies the acquirer as typically a financial institution and notes that acquirers are subject to payment-brand procedures concerning merchant compliance. [3] Adyen similarly describes an acquirer as a bank or financial institution that receives funds for its merchant and says the acquirer must be licensed by the relevant card networks, either partnering with a processor or processing transactions itself. [6]
On the transaction side, the acquirer is the merchant-side endpoint for authorization and clearing messages. A card payment involves an issuer on the cardholder side and an acquirer on the merchant side. The processor may carry and transform the messages, but that does not necessarily make the processor the acquiring institution. The acquirer’s identity can matter when a merchant investigates settlement, disputes, account restrictions, network registration, or the terms of its acceptance agreement.
“Acquirer” is not identical to “merchant account.” A merchant account is the account relationship or ledger arrangement used to identify and settle a merchant’s card activity. The acquirer is the institution or acquiring entity behind that relationship. A merchant may interact with a PSP, ISO, or payment facilitator and rarely see the acquirer’s operational systems, but the acquiring relationship still exists somewhere in the structure.
An acquirer may also outsource substantial technology work. Visa describes acquiring processing as including authorization processing, transaction capture, clearing and settlement processing, transaction routing, reconciliation, batch or real-time data exchange, and related reporting. [1] Thus, the bank or other acquiring institution can remain the acquirer while a processor performs much of the day-to-day technical work.
What is a payment processor?
A payment processor is the party that performs transaction-processing functions. Those functions can include receiving a payment request, validating and formatting data, applying routing or risk controls, sending an authorization message toward the network and issuer, returning the response, handling capture instructions, producing files for clearing and settlement, and supplying reports or exception workflows.
The ECB’s glossary describes processing as information-technology services and network communication services, including authentication and authorization, that enable payment-system operators and participating PSPs to provide payment services. [5] Visa’s acquiring document adds the operational detail of capture, clearing, settlement, routing, reconciliation, data exchange, and reporting. [1] These descriptions show why “processor” is primarily an operational role rather than a simple synonym for the company that sells the service.
A processor may be an in-house division of an acquirer, a third-party processor contracted by an acquirer, or part of an integrated PSP platform. A provider may also process for multiple acquirers. Therefore, the processor’s name on an API response, terminal, dashboard, or support email may not be the same as the legal entity that acquired the merchant’s transactions.
Processor responsibilities can continue after an approval. A successful authorization usually reserves or confirms funds for a later capture, while capture sends the transaction into the completion and settlement process. Adyen’s lifecycle documentation separates authorization, capture, settlement, and payout statuses, and specifically notes that a settled payment is not necessarily already paid out to the merchant. [7] This distinction is operationally important when a merchant reconciles sales, expected deposits, refunds, or delayed payouts.
How the four roles fit together in one transaction
Consider a small online retailer that signs up through an ISO. The ISO explains available acceptance options and helps the retailer submit its legal, ownership, banking, and processing information. The ISO may remain the relationship contact, but the acquirer or its sponsored payment facilitator makes the merchant-approval decision under the applicable arrangement. Visa’s registration materials indicate that an entity discussing merchant pricing, terms, applications, and contracts may fall within ISO activity requiring registration. [2]
After approval, the retailer sends a checkout payment through its chosen acceptance integration. A processor receives the transaction data and performs the technical processing needed to route an authorization request. The card network carries the message between the merchant side and the issuer side. The issuer approves or declines the request. The response travels back through the processing chain to the merchant’s payment application.
If the merchant captures the approved payment, the processor handles the capture instruction and prepares the transaction for clearing and settlement. The acquirer receives or accounts for the merchant-side funds according to the arrangement, subtracts applicable amounts under the contract, and funds the merchant directly or through the payment facilitator’s payout process. Adyen’s documentation describes authorization as reserving funds and capture as transferring the reserved funds into the completion flow. [7]
If the retailer uses a payment facilitator, the merchant may contract with that facilitator rather than directly with the acquirer. Mastercard’s definition makes registration by an acquirer central to the payment-facilitator relationship. [4] Visa’s FAQ likewise describes a facilitator that contracts with an acquirer, contracts with sponsored merchants, monitors sponsored activity, and receives settlement proceeds on behalf of a sponsored merchant. [2]
The ISO may still support the retailer in this example, but it is not necessarily the party operating authorization or holding settlement. The processor may run the systems, but it is not necessarily the party that signed the merchant agreement. The PSP may present the whole service as one product, but it may use an external acquirer in the retailer’s market. The labels become clear only when the parties and functions are mapped.
ISO vs PSP vs acquirer: the commercial relationships to check
The first relationship to identify is the merchant contract. Is the merchant signing with an acquirer, a PSP, a payment facilitator, or another provider acting on an acquirer’s behalf? A sales organization can introduce or support the relationship without becoming the contracting institution. A payment facilitator can contract with sponsored merchants under an acquirer’s sponsorship. A direct merchant account typically identifies the merchant and acquiring relationship more explicitly.
The second relationship is the settlement relationship. Ask who receives funds from the acquiring side, who calculates the payout, and who can debit refunds, disputes, fees, or reserves. Visa distinguishes service providers that do not settle directly from payment facilitators that may receive settlement proceeds for sponsored merchants. [2] This does not tell a merchant what its particular contract says, but it shows why the question is worth asking.
The third relationship is the support and escalation path. The ISO may be the day-to-day contact for sales or account management. The processor may handle technical incidents. The PSP may operate the dashboard and payment API. The acquirer or payment facilitator may make decisions about underwriting, restrictions, reserves, or account termination. A clear escalation matrix helps prevent a merchant from sending a technical issue to an underwriting contact or a settlement issue to a sales representative.
The fourth relationship is the data and compliance boundary. A party that stores, processes, or transmits cardholder data may have responsibilities under the applicable security standards and contracts. PCI SSC says its standards apply across entities involved in payment processing, and its glossary distinguishes merchants, acquirers, processors, and service providers. [3] A merchant should ask which systems receive card data, which provider supplies the relevant compliance documentation, and which obligations remain with the merchant.
When one company performs several roles
Integrated payments have made role overlap common. A PSP may provide the merchant-facing account, the API, risk controls, reporting, and payout experience while also acting as acquirer in some countries and using partner acquirers elsewhere. Adyen explicitly notes that a PSP can operate as an acquirer in certain regions, which illustrates why a global provider’s role can change by market. [6]
An acquirer may own or operate its processor. A processor may offer merchant-facing services through a branded PSP or ISO. An ISO may resell a gateway or acceptance product while another registered provider runs the service. None of these combinations is automatically misleading; the issue is whether the provider clearly states which entity performs each function.
The practical consequence is that a merchant should not compare providers only by brand name. Compare the contracting entity, acquiring entity, processor, settlement path, support owner, and permitted business activity. A single dashboard can conceal several contractual relationships, while two different brands can rely on the same underlying processor or acquirer.
Practical examples of the differences
Example 1: PSP with an external acquirer
An online business signs one PSP agreement and uses the PSP’s API, reporting, fraud tools, and payout dashboard. The PSP connects the business to an acquiring partner in the relevant country. The PSP is the merchant-facing provider, but the acquiring institution and processing infrastructure may be separate. The contract should identify how funds, disputes, refunds, reserves, and account decisions are handled.
Example 2: Payment facilitator for many submerchants
A software platform enables independent sellers to accept cards inside a common application. It onboards sellers as submerchants, aggregates transaction data, and pays sellers out. The platform may be a payment facilitator registered by an acquirer, while a processor runs the underlying transaction systems. Mastercard expressly describes the payment facilitator as an acquirer-registered service provider facilitating transactions for submerchants. [4]
Example 3: One provider, multiple roles
A global provider can operate a payment platform, act as PSP, perform processing, and act as acquirer in one jurisdiction. In another jurisdiction it may use a licensed acquiring partner. The merchant experience can look identical even though the legal and operational structure differs. That is why location, payment method, and product terms should be checked before assuming the same role applies everywhere.
A merchant checklist for evaluating the structure
Before signing or migrating, ask for a plain-language role map. The answers should identify:
- The legal entity signing the merchant agreement and the entity responsible for merchant approval.
- The acquiring institution or sponsor, the processor, and any payment facilitator involved.
- Whether the merchant has an individual merchant identifier or is onboarded as a sponsored submerchant.
- Who receives settlement, who pays the merchant, and how payout timing is calculated.
- Who handles authorization errors, refunds, disputes, compliance questions, and account reviews.
- Which entity controls reserves, rolling holds, transaction limits, or termination rights under the agreement.
- What happens to tokens, transaction history, reports, and recurring billing data if the relationship ends.
These questions do not guarantee approval, a particular price, uninterrupted service, or a specific payout schedule. They simply make the operational structure visible. For background on the broader acquiring relationship and setup process, see Numus Payments’ merchant account setup guide. For the model in which a platform sponsors submerchants rather than opening direct accounts for each seller, see payment facilitator vs. merchant account.
A merchant should also confirm that the provider’s description matches its actual risk and business model. An ISO’s sales representation, a PSP’s product page, and the acquirer’s underwriting terms may use different language. If the business sells regulated, restricted, subscription, cross-border, or otherwise elevated-risk products, the merchant should disclose that accurately and obtain the relevant written approval. This article is educational and is not legal, tax, compliance, underwriting, or financial advice.
Limitations of these definitions
The terminology is not globally uniform. “PSP” can be a broad commercial label, a regulated category in one jurisdiction, or legacy network terminology in another. “Processor” can mean a third-party transaction processor, an acquirer’s processing division, or a platform that exposes processing capabilities to merchants. “Acquirer” can refer to a bank or another eligible acquiring institution under a card brand’s rules.
Network rules, licensing requirements, data-security obligations, funds-flow rules, and contract rights can change. The authoritative answer for a particular merchant is the current agreement, program registration, network rule set, and applicable local requirements. The sources cited here explain common structures; they do not determine a merchant’s legal status or compliance duties.
Frequently Asked Questions
Is an ISO the same as a payment processor?
No. An ISO usually sells, refers, onboards, or supports merchants for an acquirer. A processor performs transaction-processing and related technical operations. One company can perform both functions, but the merchant should verify the actual contract, systems, and network registration rather than assuming the terms are interchangeable.
Is a PSP always the acquirer?
No. PSP is a broad provider label. A PSP may act as an acquirer in some regions, use an external acquirer in others, or combine acquiring and processing with merchant-facing services. The provider’s agreement and market-specific disclosures should identify who acquires transactions and who controls settlement.
What should a merchant ask before choosing an ISO, PSP, or acquirer?
Ask which entity signs the agreement, underwrites the account, processes transactions, receives settlement, pays out funds, handles disputes, and controls reserves or restrictions. Also confirm whether the merchant has a direct merchant account or is a sponsored submerchant, and identify the support and escalation path for technical and account issues.
