How GDPR Works
GDPR is built on a set of core principles that define how personal data must be handled at every stage of its lifecycle. Understanding these principles is not optional — they are legally binding obligations that flow through every part of a payment operation, from checkout form to data deletion. The regulation places responsibility on both data controllers (merchants, platforms) and data processors (payment gateways, SaaS tools).
Establish a Lawful Basis
Before collecting any personal data, you must identify a lawful basis under GDPR Article 6. For payments, the most common bases are contract performance (processing a transaction) and legal obligation (AML/KYC requirements). Consent is rarely the right basis for core payment processing but applies to marketing communications.
Publish a Compliant Privacy Notice
Customers must be informed — at or before the point of data collection — what data you collect, why, how long you keep it, and who you share it with. For payment pages this means a clear, plain-language privacy notice linked directly from checkout. Vague or buried notices are a common enforcement trigger.
Sign Data Processing Agreements
Every third-party vendor that touches personal data on your behalf — payment gateways, fraud tools, analytics platforms, orchestration providers — requires a signed Data Processing Agreement (DPA) under Article 28. Without one, both you and the vendor are exposed to regulatory action.
Honour Data Subject Rights
GDPR grants individuals eight rights, including access, rectification, erasure, and portability. Payment businesses must have workflows to respond to these requests within 30 days. Erasure requests are particularly complex where AML retention obligations conflict with the right to be forgotten — a documented legal hold policy is essential.
Report Breaches Within 72 Hours
If a data breach involves personal data and poses a risk to individuals, GDPR Article 33 requires notification to the relevant supervisory authority within 72 hours of becoming aware. High-risk breaches also require direct notification to affected individuals. A tested incident response plan is not optional.
Maintain Records of Processing Activities
Article 30 requires most organizations to maintain a Record of Processing Activities (RoPA) — an internal inventory of what data you process, for what purpose, on what legal basis, and with whom it is shared. For payment businesses processing at scale, this document is often the first thing regulators request during an investigation.
Why GDPR Matters
GDPR is not a theoretical risk — it is one of the most actively enforced regulatory frameworks in the world, with cumulative fines exceeding €4.5 billion since enforcement began in May 2018 according to DLA Piper's annual GDPR enforcement tracker. Payment businesses are disproportionately represented among enforcement targets because they handle high volumes of sensitive financial data.
The regulation's reach extends well beyond Europe. Any merchant accepting EU customers is in scope, meaning a US-based ecommerce store, a Southeast Asian payments platform, or a Latin American fintech all face the same obligations as a Frankfurt bank. The Irish Data Protection Commission alone issued fines totalling over €1.3 billion in 2023, with Meta accounting for the largest single penalty. For payment businesses, the stakes are compounded: a processing ban — regulators' nuclear option — can immediately suspend the ability to take payments, making compliance an operational continuity issue, not just a legal one.
72-Hour Clock
The breach notification window starts when your organization becomes aware of the incident — not when you have full details. File a preliminary notification within 72 hours, then supplement with complete information as the investigation progresses. Missing this window has triggered standalone fines separate from any underlying breach penalty.
GDPR vs. PCI DSS
GDPR and PCI compliance are often conflated, but they address different problems with different enforcement mechanisms. Merchants typically need to comply with both simultaneously.
| Dimension | GDPR | PCI DSS |
|---|---|---|
| Scope | Any personal data of EU residents | Payment card data globally |
| Who sets it | EU legislature (law) | Card network consortium (contract) |
| Enforcement | National data protection authorities | Card brands, acquirers, fines, card termination |
| Lawful basis required | Yes — must document before processing | No equivalent concept |
| Breach notification | 72 hours to regulator | Varies; acquirer notification required |
| Fines | Up to €20M or 4% global turnover | Up to $500,000 per incident (Visa/MC scale) |
| Data deletion rights | Explicit right to erasure | Retention mandated for audit; no deletion rights |
| Encryption requirement | Implied via Article 32 security obligation | Explicit technical standards (TLS, tokenization) |
The key practical overlap is that strong PCI compliance controls — tokenization, encryption, access controls — also satisfy many of GDPR's Article 32 security requirements. A compliant PCI environment is a strong foundation for GDPR technical compliance, but it does not cover GDPR's transparency, consent, or data subject rights obligations.
Types of GDPR Obligations
GDPR is a single regulation but its obligations fall into distinct categories that require different operational responses.
Controller obligations apply when you determine the purpose and means of processing — typically the merchant. These include publishing privacy notices, establishing lawful bases, responding to data subject requests, and maintaining the RoPA.
Processor obligations apply when you process data on behalf of a controller — typically a payment gateway or orchestration platform. These include processing only on documented instructions, maintaining security standards, and notifying the controller of breaches without undue delay.
Joint controller arrangements arise when two parties jointly determine the purpose of processing — common in marketplace payment flows where both the platform and the seller have a stake in transaction data. Joint controllers must document their respective responsibilities in a written arrangement.
Cross-border transfer requirements apply whenever personal data leaves the EEA. Post-Schrems II, this requires either an adequacy decision for the destination country, Standard Contractual Clauses (SCCs), or another approved transfer mechanism. US-based payment processors with EU customers must operate under the EU-US Data Privacy Framework or SCCs.
Best Practices
GDPR compliance in payments is an operational discipline, not a one-time project. The following practices reflect what mature, well-prepared payment businesses implement at both the merchant and technical levels.
For Merchants
Map your data flows before anything else. Create a data flow diagram that traces personal data from checkout form through payment gateway, fraud tool, CRM, and analytics stack. You cannot protect data you do not know you have.
Align retention schedules with AML law. The right to erasure conflicts with AML and customer due diligence retention obligations. Document a legal hold policy that specifies which data must be retained, under which law, for how long — and delete everything outside those windows.
Audit your vendor DPAs annually. Third-party processors change their sub-processors and data practices. Annual DPA reviews catch gaps before regulators do.
Train checkout and support teams. The most common GDPR failures in payment businesses are operational: support agents emailing sensitive data unencrypted, checkout forms collecting unnecessary fields, or sales teams ignoring data subject access requests.
For Developers
Apply data minimisation at the schema level. Do not collect fields you do not need. Remove unused database columns rather than leaving them populated. GDPR's minimisation principle is most cheaply enforced at design time.
Implement pseudonymisation in analytics pipelines. Replace direct identifiers (email, card last four) with internal tokens before data reaches analytics tools. This reduces the risk profile of analytics breaches and limits GDPR exposure on those systems.
Build deletion APIs, not just deletion scripts. Data subject erasure requests will come at scale. A repeatable, auditable deletion API is far more defensible than manual database queries during a regulatory investigation.
Log lawful basis alongside each data collection event. Store the lawful basis code and timestamp with collected data. When a regulator asks why you processed a specific record, you need a machine-readable answer, not a best guess.
Common Mistakes
Payment businesses make predictable GDPR errors. Most enforcement actions stem from a small set of recurring failures.
Relying on consent as the lawful basis for transaction processing. Consent must be freely given, specific, and withdrawable at any time. Using it as the basis for processing a payment creates an operational absurdity: a customer could withdraw consent mid-transaction. Contract performance is almost always the correct basis for payment processing.
Failing to update privacy notices when adding new tools. Every time you add a new payment tool, fraud provider, or analytics platform, your privacy notice must be updated to disclose the new data sharing. Most merchants treat the privacy notice as a legal formality written once and forgotten.
No process for data subject access requests. GDPR gives individuals the right to receive a copy of all personal data you hold about them within 30 days. Many payment businesses have no documented process, meaning requests go unanswered or are handled inconsistently — both of which are enforceable violations.
Ignoring cross-border transfer requirements. Merchants using US-based payment gateways, fraud tools, or KYC providers are transferring EU personal data internationally. Without SCCs or an adequacy decision in place, this is an unlawful transfer — a Tier 2 violation.
Treating a data breach as an IT problem, not a regulatory event. The 72-hour notification clock starts running the moment your organization becomes aware of a breach, not when IT finishes its investigation. Delayed notification — even by a few hours past the deadline — has resulted in standalone fines.
GDPR and Tagada
Tagada operates as a payment orchestration platform, which means it processes personal data — cardholder names, email addresses, transaction records — on behalf of merchant customers. This places Tagada in the role of a data processor under GDPR Article 4(8), with the merchant acting as data controller.
DPA Included by Default
Tagada's merchant agreement includes a GDPR-compliant Data Processing Agreement covering sub-processor disclosures, security obligations, breach notification timelines, and data subject request handling. Merchants do not need to negotiate a separate DPA — it is embedded in the standard contract. Review it with your DPO to ensure it reflects your specific data flows across orchestrated payment routes.
When Tagada routes transactions across multiple PSD2-regulated payment service providers, personal data may cross jurisdictional boundaries. Tagada maintains Standard Contractual Clauses with sub-processors in non-adequate countries and provides merchants with a current sub-processor list on request — a requirement under Article 28(3)(d). Merchants should factor Tagada's sub-processor geography into their own cross-border transfer documentation.