Category: Payment Ecosystem

Payment Service Provider

Also known as: PSP, payment services provider

Simply put

A payment service provider (PSP) is a third-party company that helps merchants accept electronic payments, such as credit and debit card transactions, from their customers. It acts as an intermediary connecting the parties involved in a payment, including customers, businesses, and banks. Some PSPs bundle multiple payment functions together so a merchant can work with a single provider instead of contracting each service separately.

Formal definition

A PSP is a third-party entity that facilitates electronic payment transactions between parties such as cardholders, merchants, acquirers, and payment networks. Depending on the provider, a PSP may combine functions that are otherwise distinct, for example acting as both a payment gateway and a payment processor, and may connect to multiple acquiring and payment networks. The specific services offered, the connections supported, and the contractual and compliance responsibilities assumed vary by provider and by implementation; the term itself describes a role in the payment flow rather than a fixed set of functions. Because a PSP handles or transmits payment data, its involvement can affect the PCI DSS scope and validation obligations of both the PSP and the merchants it serves, but the precise impact depends on the transaction and data flows rather than on the label alone.

Why it matters

Payment service providers occupy a central position in the payment flow, connecting cardholders, merchants, acquirers, and payment networks. Because many merchants rely on a single PSP to bundle functions that would otherwise be contracted separately, the PSP becomes a concentration point for both operational dependency and payment data handling. Understanding what a specific PSP actually does, rather than assuming a fixed set of functions from the label, is essential for scoping security and compliance obligations correctly.

Since a PSP handles or transmits payment data, its involvement can affect the PCI DSS scope and validation obligations of both the PSP itself and the merchants it serves. The precise impact depends on the transaction and data flows in a given implementation, not on the term alone. Two merchants using nominally similar PSP arrangements may face different scoping outcomes depending on how payment data is captured, transmitted, and where it comes to rest. Compliance teams should confirm responsibilities against the current published PCI DSS standard and the contractual allocation of duties between the parties rather than assuming the PSP absorbs all obligations.

Because the term describes a role in the payment flow rather than a specific product, misunderstanding the division of responsibility between a merchant and its PSP is a common source of compliance gaps. A merchant that treats a PSP relationship as fully outsourcing its own obligations may leave portions of its environment unassessed. Clear documentation of which entity performs which function, and where cardholder data is handled, helps both parties define and validate their respective scope.

Who it's relevant to

Merchants and Merchant Risk Teams

Merchants rely on PSPs to accept electronic payments and often to consolidate multiple payment functions under a single provider. They need to understand which functions their PSP performs, how payment data flows through the arrangement, and which compliance responsibilities remain with the merchant versus the provider, since a PSP relationship does not automatically remove all of the merchant's own obligations.

Compliance Officers

Because a PSP handles or transmits payment data, its involvement can affect the PCI DSS scope and validation obligations of both the PSP and the merchants it serves. Compliance officers should document the division of responsibility, map the actual transaction and data flows, and confirm applicable requirements against the current published standard rather than assuming the PSP label determines scope.

Acquirers and Payment Processors

Acquirers and processors interact with PSPs as intermediaries in the payment flow and, in some cases, a PSP may itself perform processing functions and connect to multiple acquiring and payment networks. Understanding where a given PSP sits in the flow helps these parties define the relationships, connections, and responsibilities involved.

Security Engineers

Security engineers designing or reviewing payment integrations need to know how a PSP captures, transmits, and routes payment data, since these implementation details — not the provider label — determine which systems fall within the cardholder data environment and how controls should be applied and validated.

Inside PSP

Merchant onboarding and underwriting

The processes a PSP uses to evaluate, approve, and provision merchants for payment acceptance, including risk assessment, know-your-customer checks, and assignment of merchant identifiers. Practices and obligations here are shaped by acquirer relationships and applicable card brand and network rules, which vary by region and change over time.

Transaction processing and routing

The handling of authorization, capture, and settlement messages between merchants, acquirers, and card networks. A PSP may route card-present or card-not-present transactions and typically handles cardholder data (such as PAN, cardholder name, expiration date, and service code) and, transiently during authorization, sensitive authentication data that must not be stored after authorization.

PCI DSS scope and responsibilities

Because a PSP stores, processes, or transmits cardholder data on behalf of merchants, it typically falls within PCI DSS scope and may act as a service provider. Requirement wording and numbering differ between PCI DSS versions, so responsibilities should be confirmed against the current published standard rather than a fixed requirement number.

Data protection mechanisms

Controls a PSP may apply to cardholder data, including encryption, tokenization, truncation, masking, and hashing. These transform or reduce data differently, and their effect on PCI DSS scope depends on implementation and validation rather than the label alone. Sensitive authentication data must not be retained after authorization, even when encrypted.

Authentication and fraud controls

Support for controls such as 3-D Secure, strong customer authentication, and multi-factor authentication, which address different risks at different points in a transaction. A PSP may also offer fraud-screening tools that involve false-positive and false-negative trade-offs; no single control eliminates fraud.

Chargeback and dispute handling

Services for managing disputes, including chargeback and friendly or first-party fraud cases. Liability shift and chargeback rules are governed by card brand and network rules, which vary by region and change over time.

Common questions

Answers to the questions practitioners most commonly ask about PSP.

Is a PSP the same thing as a payment gateway?

Not necessarily. The terms are often used interchangeably, but a payment gateway is more narrowly the technical component that transmits transaction data between a merchant and the acquiring or processing infrastructure, while a Payment Service Provider is a broader commercial role that may bundle gateway functionality with merchant onboarding, acquiring relationships, settlement, and value-added services. A given PSP may operate its own gateway, integrate a third-party gateway, or offer functions well beyond a gateway. Confirm the specific services and contractual responsibilities of any provider rather than assuming the labels are equivalent.

Does using a PSP remove all of my PCI DSS responsibilities?

No. Engaging a PSP can reduce and shift some of your obligations, but it does not eliminate your responsibility. Your applicable requirements and the way you validate compliance depend on how you integrate with the PSP, how cardholder data flows through or around your environment, and how responsibilities are divided between you and the provider. Even integrations that minimize your handling of cardholder data typically leave you with obligations, such as managing the integration, overseeing the provider relationship, and validating your remaining scope. Responsibility for controls should be documented between the parties, and you should confirm your obligations against the current published standard.

How does the way I integrate with a PSP affect my PCI DSS scope?

The integration method influences how much cardholder data enters your environment and therefore how much of your environment is in scope. Approaches that keep the merchant systems from receiving or processing account data, such as redirects or provider-hosted fields, generally reduce scope compared with methods where cardholder data passes through merchant-controlled systems. The effect on scope depends on the actual data flows and how the integration is validated, not on the description of the method alone. Map your data flows and confirm the resulting scope and applicable validation approach against the current standard.

What should I clarify about division of responsibilities before onboarding with a PSP?

Establish which party is responsible for each applicable control, ideally in a written responsibility matrix, covering areas such as data handling, encryption or tokenization services, storage, logging, incident response, and support of your compliance validation. Clarify whether the PSP will provide evidence of its own compliance status for the services it delivers, and how that evidence maps to the controls you are relying on them to perform. Ambiguity here can leave gaps where neither party is managing a required control.

How can I verify a PSP's own compliance posture for the services I use?

Request documentation of the PSP's compliance status for the specific services you consume, and confirm that the documentation covers those services rather than an unrelated part of their business. Because different functions may be governed by different standards, verify that any relevant standards beyond PCI DSS are addressed where applicable to the services provided. Review the currency of the documentation, since a provider's status reflects a point in time, and reassess periodically as part of ongoing third-party oversight.

If cardholder data flows through a PSP, how should I confirm sensitive authentication data is handled correctly?

Confirm with the PSP how sensitive authentication data is treated during and after authorization. Sensitive authentication data, such as full track data, card verification values, and PIN data, must not be stored after authorization, even when encrypted, and this obligation applies to the party that handles that data. Where the PSP performs authorization on your behalf, understand what data they receive, how it is protected in transit, and what they retain versus discard after authorization, and ensure your own systems are not inadvertently retaining such data.

Common misconceptions

Using a PSP removes a merchant's PCI DSS obligations entirely.

A PSP can reduce or shift some of a merchant's PCI DSS scope depending on the integration model and validation, but the merchant generally retains responsibilities. Actual scope reduction depends on implementation and how cardholder data flows, and should be confirmed against the current published standard and the responsibility split with the provider.

A PSP that tokenizes card data has encrypted it, so the terms are interchangeable.

Tokenization, encryption, truncation, masking, and hashing are distinct techniques that transform or reduce data differently. Their effect on PCI DSS scope depends on implementation and validation, not on the label used, and none of them permits storing sensitive authentication data after authorization.

Enabling 3-D Secure or another authentication feature through a PSP prevents fraud.

Authentication controls such as 3-D Secure, strong customer authentication, and multi-factor authentication address different risks at different points in a transaction and may help reduce certain fraud, but no single control eliminates fraud, and detection tools carry false-positive and false-negative trade-offs.

Best practices

Confirm the division of PCI DSS responsibilities between your organization and the PSP in writing, and validate it against the current published version of the standard rather than assuming a fixed requirement number.

Understand how cardholder data flows through the PSP integration to accurately determine your PCI DSS scope, and verify any claimed scope reduction from tokenization, truncation, or hosted payment pages against actual implementation and validation.

Ensure that neither your systems nor the PSP integration retain sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) after authorization, even in encrypted form.

Evaluate available authentication options such as 3-D Secure, strong customer authentication, and multi-factor authentication based on the specific risks and transaction points they address, recognizing that no single control eliminates fraud.

Assess PSP fraud-screening and detection tools for their false-positive and false-negative trade-offs, and tune them to your risk tolerance and transaction profile.

Track applicable card brand and network rules governing liability shift, chargebacks, and dispute handling, since these vary by region and change over time, and align your PSP-supported processes accordingly.