GDPR and Payments: A Guide to Data Protection Compliance

Updated: July 2026

Every card transaction your business processes carries personal data that GDPR protects: a name, a card number, a CVV, sometimes a fingerprint used to authorise the payment. Non-compliance can reach €20 million or 4% of global annual turnover, and the ICO’s £20 million fine against British Airways over a 2018 payment card breach shows regulators treat payment data as a genuine enforcement priority, not a paperwork afterthought. This guide sets out what GDPR actually requires when your business handles payments.

Key Takeaways

• GDPR has applied to payment processing since 25 May 2018, and payment data, including card numbers and bank details, counts as personal data requiring the regulation’s full protections.

• Most payment transactions rely on contract performance as their legal basis, not consent, though storing a card for future use or using payment data for marketing needs separate consent.

• The ICO fined British Airways £20 million in 2020 after a breach exposed the payment card numbers and CVV codes of hundreds of thousands of customers, illustrating how payment data breaches translate into real penalties.

• The right to erasure does not override tax and accounting retention obligations, so payment records needed for VAT compliance must be kept for their legally required period even after a customer requests deletion.

What Counts as Payment Data Under GDPR?

Payment data falls squarely within GDPR’s scope because it is personal data that identifies or can identify a person. That includes card numbers, expiry dates, CVV codes, and cardholder names; bank details such as IBANs, sort codes, and account numbers; transaction histories and purchase patterns; biometric data such as fingerprints used for mobile payment authentication; and IP addresses or device identifiers captured during checkout.

Any business handling payments within the EU digital economy needs to treat this information with the same rigour GDPR applies to any other category of personal data, from lawful basis through to security and retention.

What Legal Basis Applies to Payment Data Processing?

Processing payment data needs a valid legal basis under GDPR. Our comprehensive GDPR compliance guide covers the six lawful bases in full detail; for payments, most transactions rely on one of these grounds:

• Contract performance (Article 6(1)(b)): covers standard payment transactions necessary to fulfil an order or service.

• Legal obligation (Article 6(1)(c)): applies to processing required for anti-money laundering checks and other regulatory requirements.

• Legitimate interests (Article 6(1)(f)): commonly used for fraud prevention and risk assessment.

• Consent (Article 6(1)(a)): required for additional services such as storing a payment method for future use.

• Vital interests and public task: rarely relevant to commercial payment processing.

Most day-to-day payment operations sit under contract performance, since processing card data is typically necessary to complete a transaction the customer initiated. Using that same payment data for marketing, though, needs its own separate consent beyond what completing the transaction requires.

How Do Data Minimisation and Purpose Limitation Apply to Payments?

Data minimisation means collecting only the payment data a specific purpose actually needs. In practice, that means not storing full card numbers after a transaction has been authorised. Tokenisation, replacing sensitive payment data with non-sensitive tokens, is the standard way businesses achieve this. Each type of payment data collected should have a defined purpose, and data should be deleted once it no longer serves that purpose.

A business processing one-time payments has no justification for retaining complete card details once the transaction is finished.

What Transparency Does GDPR Require for Payment Data?

GDPR requires clear disclosure of how payment data is collected and used. A compliant approach includes a privacy notice that explains payment data collection and processing purposes, is easily accessible from checkout and payment pages, discloses retention periods for payment information, and names the third-party payment processors handling customer data. Every payment processing activity needs a valid legal basis behind it.

Transparency here does double duty: it satisfies GDPR’s disclosure requirements and gives customers a reason to trust the checkout process with their card details.

What Technical Security Measures Does GDPR Require for Payment Data?

What Encryption Standards Apply to Payment Data?

GDPR’s Article 32 security requirement translates into specific technical practices for payment data: end-to-end encryption for payment data in transit, typically TLS 1.2 or higher; AES-256 encryption for payment data at rest; secure key management for the certificates and keys involved; and consistent encryption across every storage and processing environment the data passes through, not just the primary database.

These measures reduce the practical impact of a breach even where an attacker gains some level of system access, since encrypted data without the keys is far less useful to steal.

What Access Controls Protect Payment Data?

Restricting who can reach payment data is a separate but equally important control. Multi-factor authentication on payment systems and databases, role-based access limiting payment data to staff who actually need it, secure protocols such as OAuth 2.0 for payment API integrations, session management controls, and regular review of who still needs access all reduce the risk of an internal breach specifically, as opposed to an external attack.

What Rights Do Individuals Have Over Their Payment Data?

Right	Application to Payment Data	Timeframe
Access	Customers can request copies of their payment transaction data	30 days
Rectification	Individuals can correct inaccurate payment information	30 days
Erasure	Customers can request deletion of payment data no longer needed	30 days
Data portability	Lets customers transfer payment history between service providers	30 days
Object	Lets customers opt out of certain types of processing	30 days

Businesses need systems that can fulfil these requests within the timeframe. If a customer requests their payment history, that data needs to arrive in a structured, commonly used, machine-readable format within a month of the request.

Does the Right to Erasure Cover Payment Data Without Exception?

No. The right to erasure, often called the right to be forgotten, is not absolute. A customer can request deletion of their payment data, but other legal requirements can override that request. Tax law, particularly VAT rules, requires businesses to retain invoices and transaction records for several years for auditing purposes. Even after a customer closes their account, the payment data needed for VAT documentation has to stay stored securely for whatever period the law requires. GDPR itself permits this: retention for a legal obligation is a valid basis under Article 6(1)(c), and it does not conflict with the erasure right.

What Do Third-Party Payment Processors Change About GDPR Compliance?

Using a processor like Stripe, PayPal, or Square does not remove your GDPR obligations. It adds to them. A compliant setup includes a Data Processing Agreement with every payment service provider, confirmation that the processor holds current GDPR compliance certifications, specific clauses covering international transfers and adequacy decisions, periodic audits of the processor’s ongoing compliance, and Standard Contractual Clauses wherever payment data crosses borders outside the EEA.

Your business stays responsible for these third parties regardless of how reputable they are. That means genuine due diligence before signing with a payment provider, not just at onboarding, but throughout the relationship.

What Does GDPR Require After a Payment Data Breach?

A payment data breach triggers specific, time-bound obligations: notifying the relevant supervisory authority within 72 hours of discovering the breach, informing affected individuals without undue delay where the breach poses a high risk, documenting every aspect of the breach and the response taken, coordinating with card networks and banks during notification, and implementing remediation to prevent the same failure recurring. Our guide to data breach notification requirements covers this process in more detail.

What Happened When British Airways’ Payment Data Was Breached?

On 16 October 2020, the UK’s Information Commissioner’s Office fined British Airways £20 million over a 2018 cyberattack that exposed the personal data of more than 400,000 customers and staff, including payment card numbers and CVV codes for around 244,000 customers. The ICO had originally announced its intention to fine BA £183.39 million in 2019, a figure reduced substantially after considering the airline’s cooperation with the investigation, the steps it had taken to notify affected customers promptly, and the financial impact of the COVID-19 pandemic on the business.

The case remains one of the clearest examples of what happens when payment card data specifically, rather than personal data in general, is exposed in a breach: the presence of card numbers and CVV codes was central to how the ICO assessed the severity of the incident.

What Are Data Protection Impact Assessments Used for in Payment Systems?

Data Protection Impact Assessments are required under GDPR for high-risk processing, which frequently includes payment processing. Businesses should run a DPIA before implementing a new payment processing system, when assessing biometric payment authentication specifically, and when evaluating cross-border transfers of payment data and their effect on data subjects’ rights. Risk mitigation measures need to be documented, and DPIAs need periodic review as payment systems and processes change.

What Are the Best Practices for GDPR-Compliant Payment Processing?

• Build data protection into payment systems from the outset, rather than adding it after the system is live.

• Run periodic compliance audits of payment processing activities.

• Train staff who handle payment data on their specific GDPR responsibilities.

• Keep detailed records of processing activities, legal bases, and security measures.

• Map how payment data flows through the organisation, from checkout through to storage and any third parties involved.

• Assess and monitor third-party payment processors on an ongoing basis, not just at onboarding.

• Apply encryption, access controls, and other technical measures appropriate to the actual risk involved.

• Set clear retention schedules defining how long each type of payment information is kept, tied to business need and legal requirement.

Conclusion

GDPR compliance for payment processing comes down to four things: knowing what counts as personal data in your payment flow, having a valid legal basis for each use of it, applying security measures proportionate to the risk, and honouring the rights individuals have over their own data. The British Airways case shows what happens when the security piece fails specifically for payment card data. Starting with a payment data audit, mapping what you collect, where it goes, and how long you keep it, is the practical first step toward closing whatever gaps that audit reveals.

Frequently Asked Questions

How long can payment data be stored under GDPR?

Retention periods depend on the legal requirement behind them, typically 6 to 10 years for tax and accounting purposes depending on the jurisdiction, but payment data must be deleted once it is no longer necessary for the purpose it was collected for.

Is consent required for all payment data processing?

No. Most payment processing relies on contract performance as its legal basis. Consent is specifically required for storing a payment method for future use or using payment data for marketing purposes.

What happens if a payment processor has a data breach?

Both the payment processor and the merchant can be liable, depending on whether each is acting as a controller or a processor for the data involved, and both need to notify the relevant supervisory authority within 72 hours of discovering the breach.

Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.