Summary

Many payment processors are joint controllers with their merchant clients for certain processing activities, which requires a specific contractual arrangement under Article 26 GDPR. Payment processors typically rely on a network of subprocessors — acquiring banks, card networks, fraud screening vendors, cloud infrastructure providers. GDPR requires you to: Following the Schrems II ruling, you must conduct a Transfer Impact Assessment (TIA) for each transfer to assess whether the destination country’s laws undermine the protection offered by SCCs. For payment processors routing data through US-based card networks, this is a mandatory exercise, not optional.

GDPR Complete Guide for Payment Processors: Everything You Need to Know

Payment processors occupy a uniquely sensitive position in the data ecosystem. Every transaction you facilitate involves personal financial data, behavioral patterns, and sensitive identifiers that fall squarely within GDPR’s scope. Getting compliance wrong doesn’t just mean regulatory fines — it means losing merchant trust, card network certifications, and ultimately your business.

This guide breaks down exactly what GDPR means for payment processors, who is responsible for what, and the practical steps you need to take to operate lawfully across the EU and EEA.

What Makes Payment Processors Different Under GDPR

Most GDPR guides are written for generic businesses. Payment processors face a distinct set of challenges:

You process data on behalf of multiple controllers (your merchant clients) simultaneously
You handle special category-adjacent data including spending patterns and financial behavior
You operate across multiple jurisdictions with cross-border data transfers as a core function
You’re subject to overlapping regulatory frameworks including PCI DSS, PSD2, and AML regulations

Understanding these intersections is critical before you can build a compliant program.

Are You a Controller or a Processor?

This is the foundational question, and the answer is almost always: both, depending on the context.

When You’re a Data Processor

When you process cardholder data strictly on behalf of a merchant client to execute a transaction they’ve initiated, you are acting as a data processor. The merchant is the controller. In this role, you must:

Act only on documented instructions from the controller
Implement appropriate technical and organizational security measures
Assist controllers in fulfilling data subject rights requests
Notify controllers of data breaches without undue delay
Delete or return data upon contract termination

When You’re a Data Controller

Payment processors become data controllers when they:

Process transaction data for their own fraud detection and risk scoring models
Use aggregated data for product development or analytics
Maintain their own customer records for KYC/AML compliance
Market additional services to merchant clients or cardholders

Many payment processors are joint controllers with their merchant clients for certain processing activities, which requires a specific contractual arrangement under Article 26 GDPR.

Legal Bases for Processing Payment Data

Under GDPR Article 6, you must identify a valid legal basis for every processing activity. For payment processors, the most relevant bases are:

Contractual necessity (Article 6(1)(b)): Processing cardholder data to execute a payment transaction falls under this basis when the data subject is a party to the contract.

Legitimate interests (Article 6(1)(f)): Fraud prevention, security monitoring, and network integrity checks can typically rely on legitimate interests, provided you conduct and document a Legitimate Interests Assessment (LIA).

Legal obligation (Article 6(1)©): AML transaction monitoring, record retention for tax purposes, and regulatory reporting requirements are covered here.

Consent: Rarely the appropriate basis for core payment processing, but may apply to optional services like marketing communications or behavioral analytics programs.

Data Processing Agreements: Your Most Critical Document

Every relationship between a payment processor and a merchant client must be governed by a Data Processing Agreement (DPA) that meets Article 28 GDPR requirements.

Your DPA must specify:

The subject matter, duration, and purpose of processing
The type of personal data and categories of data subjects
The obligations and rights of the controller
Subprocessor authorization and notification procedures
Security measures in place
Assistance obligations for data subject rights and breach notification
Deletion or return of data provisions

Managing Your Subprocessor Chain

Payment processors typically rely on a network of subprocessors — acquiring banks, card networks, fraud screening vendors, cloud infrastructure providers. GDPR requires you to:

Maintain a current list of all subprocessors
Notify merchant clients of subprocessor changes (with adequate notice periods)
Ensure subprocessors are bound by equivalent data protection obligations
Remain fully liable to controllers for subprocessor failures

Cross-Border Data Transfers in Payment Processing

International payment processing almost inevitably involves transferring personal data outside the EEA. GDPR Chapter V restricts these transfers unless appropriate safeguards are in place.

Approved Transfer Mechanisms

Adequacy decisions: Transfers to countries the European Commission has deemed adequate (e.g., UK, Japan, South Korea)
Standard Contractual Clauses (SCCs): The 2021 SCCs are the most commonly used mechanism for processor-to-processor transfers
Binding Corporate Rules (BCRs): Suitable for intra-group transfers within large payment organizations

Transfer Impact Assessments

Following the Schrems II ruling, you must conduct a Transfer Impact Assessment (TIA) for each transfer to assess whether the destination country’s laws undermine the protection offered by SCCs. For payment processors routing data through US-based card networks, this is a mandatory exercise, not optional.

Data Subject Rights in a Payment Context

Cardholders have GDPR rights that you must be prepared to support, even when you’re acting as a processor.

Right	Processor Obligation
Access	Assist merchant controller; provide data you hold as controller
Erasure	Complex — retention obligations under AML/tax law often override erasure requests
Rectification	Correct inaccurate data; notify downstream subprocessors
Portability	Provide structured, machine-readable transaction data where applicable
Restriction	Flag data and limit processing while disputes are resolved

Important: Retention obligations under AML regulations (typically 5 years), PCI DSS requirements, and tax laws frequently create lawful grounds to refuse erasure requests. You must document these conflicts clearly.

Security Requirements for Payment Processors

Article 32 GDPR requires “appropriate technical and organisational measures.” For payment processors, this overlaps significantly with PCI DSS but is not identical.

Technical Measures

End-to-end encryption and tokenization of cardholder data
Network segmentation and access controls
Pseudonymization where possible
Continuous monitoring and intrusion detection systems
Regular penetration testing and vulnerability assessments

Organizational Measures

Mandatory staff training on data protection
Data protection policies and procedures
Vendor due diligence processes
Incident response plans with defined breach notification timelines

Breach Notification Obligations

Payment processors face a 72-hour notification window to report personal data breaches to the relevant supervisory authority (when acting as controller). When acting as processor, you must notify the merchant controller without undue delay — your contract should define this as 24-48 hours to give controllers time to meet their own obligations.

Your breach response plan should include:

Immediate containment and assessment procedures
Internal escalation paths and decision authority
Template notifications for supervisory authorities and controllers
Communication protocols for affected data subjects

Records of Processing Activities (ROPA)

Article 30 requires payment processors to maintain detailed records of all processing activities. Your ROPA should document:

Processing purposes and legal bases
Categories of data and data subjects
Recipient categories including subprocessors
International transfer mechanisms
Retention periods
Security measure descriptions

Payment processors with complex subprocessor chains often need separate ROPA entries for controller activities versus processor activities.

Frequently Asked Questions

Does GDPR apply to my payment processing business if I’m based outside the EU?

Yes. GDPR has extraterritorial scope under Article 3. If you process data of EU/EEA residents — which any processor handling European transactions does — GDPR applies to you regardless of where your company is incorporated. You may also need to appoint an EU representative.

What’s the difference between PCI DSS and GDPR compliance for payment processors?

PCI DSS focuses specifically on the security of cardholder data (card numbers, CVVs, PINs) and is a contractual requirement from card networks. GDPR is a legal framework covering all personal data and grants individuals rights over their data. Both apply simultaneously, and compliance with PCI DSS does not automatically mean GDPR compliance — and vice versa.

Can cardholders request deletion of their transaction history?

Cardholders can submit erasure requests, but payment processors typically have lawful grounds to retain transaction data. AML regulations require retention of transaction records for at least five years. Tax and accounting obligations create similar retention requirements. You must respond to the request, explain the legal basis for retention, and document your decision.

Do I need a Data Protection Officer (DPO)?

Payment processors almost certainly qualify for mandatory DPO appointment under Article 37, as core processing activities involve large-scale processing of personal data requiring regular and systematic monitoring. Even if not strictly mandatory, appointing a DPO is strongly recommended given the volume and sensitivity of data involved.

How should I handle GDPR compliance for merchant clients who are themselves non-compliant?

Your DPA obligations require you to process only on lawful instructions. If a merchant client instructs you to process data in a way that would violate GDPR, you must inform them and refuse the instruction. Continuing to process unlawful instructions can expose you to regulatory liability as a joint controller.

Build Your GDPR Compliance Program Faster

Understanding GDPR requirements is the first step — but implementation requires precise, legally sound documentation that stands up to regulatory scrutiny.

Our ready-to-use GDPR compliance template bundle for payment processors includes:

✅ Article 28-compliant Data Processing Agreement template
✅ Subprocessor agreement and notification templates
✅ Legitimate Interests Assessment (LIA) template for fraud prevention
✅ Transfer Impact Assessment (TIA) framework
✅ Records of Processing Activities (ROPA) template
✅ Data breach notification templates (72-hour authority notification + controller notification)
✅ Data subject rights request response templates

Stop spending thousands on legal fees drafting documents from scratch. Our templates are drafted by compliance professionals, regularly updated to reflect regulatory guidance, and ready to customize for your specific processing environment.

[Download the Payment Processor GDPR Compliance Template Bundle →]

Get compliant faster, reduce legal risk, and give your merchant clients the documentation confidence they need.