Every business that accepts online payments processes financial personal data. Card numbers, billing addresses, transaction histories, stored payment methods — these are all personal data under GDPR, and the regulation applies in full.
The good news is that payment providers like Stripe and PayPal are sophisticated data processors with strong GDPR compliance programmes, EU infrastructure options, and published Data Processing Agreements. The challenge is that using a compliant processor does not make you compliant. You remain the data controller. The obligations sit with you.
This guide covers everything online businesses need to know: who controls what data, what you actually receive versus what stays with your processor, your DPA obligations, data retention rules, what you can and cannot do with payment data, stored payment methods, chargebacks, international transfers, the relationship between PCI DSS and GDPR, and what your privacy policy must say.
You Are the Data Controller. Stripe Is the Processor.
Under GDPR, the data controller determines the purposes and means of processing personal data. The data processor processes data on behalf of the controller, following their instructions.
When your customer enters their card details to complete a purchase on your website, you are the data controller. You decided to collect that data, for that purpose (processing a payment), using that tool (Stripe, PayPal, etc.). Stripe processes the data on your behalf, following your instructions (charge this card, issue a refund, store this payment method).
This matters because as the data controller you are responsible for:
- Having a lawful basis for the processing
- Providing transparent information to customers about the processing (in your privacy policy)
- Entering into a Data Processing Agreement with Stripe before you begin processing
- Ensuring data is only used for its stated purpose
- Responding to data subject rights requests that involve payment data
Stripe's own compliance posture — their ISO 27001 certification, their SOC 2 reports, their GDPR commitments — does not transfer to you. These are table stakes for using Stripe, not a compliance certificate for your business.
What Data You Receive vs. What Stays with the Processor
This is where most businesses misunderstand the architecture.
What Stripe stores (not you):
- Full card numbers (PANs)
- Card verification values (CVV/CVC)
- The raw card data entered by your customer
Stripe uses tokenisation. The moment a card number is entered, Stripe converts it into a token — a random string that references the underlying card details in Stripe's vault. Your systems only ever see the token, not the card number.
What you typically receive and store:
- A payment token or payment intent ID
- The last four digits of the card (for display purposes)
- The card brand (Visa, Mastercard, etc.)
- The billing name and address (if you collect it)
- Transaction IDs and amounts
- Payment status and timestamps
- Customer email address
- Any metadata you attach to the payment
This split is deliberate — it is the foundation of PCI DSS scope reduction. Because you never touch raw card numbers, your PCI DSS obligations are significantly lighter (typically SAQ A). But it does not eliminate your GDPR obligations for the data you do receive.
Your DPA Obligations with Payment Providers
GDPR Article 28 requires a written contract between controller and processor covering specific mandatory terms: what data is processed, for what purpose, the duration, the nature of the processing, the obligations and rights of the controller.
Stripe provides a standard Data Processing Agreement. So does PayPal, Adyen, Braintree, and every other major payment processor. These are typically found in your account settings or incorporated by reference into the standard terms.
Action required: You must ensure a DPA is in place before you begin processing payment data. For most businesses using Stripe, this means accepting Stripe's DPA (which many accept by accepting Stripe's general terms) and verifying this is documented.
Check that your Stripe DPA covers:
- The categories of personal data processed (name, email, billing address, card brand, transaction data)
- The purposes of processing (payment processing, fraud detection, dispute management)
- Subprocessor disclosure and notification obligations
- Data subject rights assistance obligations
- Security and breach notification commitments
- Data deletion on termination
If you use a payment provider that does not offer a GDPR-compliant DPA, that is a compliance risk you need to address.
Transaction Data Retention: Legal Obligation vs. GDPR Minimisation
This is one of the most frequently misunderstood areas of payment data compliance.
The GDPR principle: Data minimisation and storage limitation. Keep data only as long as necessary for the purpose for which it was collected.
The competing legal obligation: Tax law and accounting regulations in most jurisdictions require you to retain records of financial transactions for 5–7 years. In the UK, HMRC requires 6 years. In Germany, the retention period is 10 years for accounting documents. In the US, the IRS recommends 3–7 years depending on the nature of the filing.
How to reconcile them:
Retention for tax and accounting purposes is a legal obligation — and GDPR recognises legal obligations as a lawful basis. You are not in breach of data minimisation by retaining transaction records for 7 years if your national tax law requires it. But you must:
- Be clear about which data is retained and why
- Limit retention to what the legal obligation actually requires (you need the transaction amount, date, and customer reference — you probably do not need to retain the full billing address for tax purposes if you do not need it for that purpose)
- Delete or anonymise data once the legal retention period expires
- Document the legal basis for retention in your Records of Processing Activities (ROPA)
What this means in practice: Your transaction records (order ID, amount, date, customer ID, payment status) can be retained for the duration of your tax retention obligations. Granular behavioural data layered onto those transactions — detailed browsing paths, device fingerprints, marketing attribution data linked to the transaction — should be subject to shorter retention periods.
Using Payment Data for Other Purposes
Just because you have transaction data does not mean you can use it for anything.
Fraud detection: Using purchase history, transaction patterns, and payment behaviour to detect and prevent fraud is generally considered compatible with the original purpose of processing (completing a transaction). It can also be justified under legitimate interests, given the mutual benefit to both business and customer. Document this in your ROPA and legitimate interests assessment if you rely on it.
Transaction history for marketing: This requires more care. If you want to use a customer's purchase history to send them targeted marketing — "you bought X, here's Y" — you need either their consent or a solid legitimate interests basis. For existing customers, the soft opt-in rule in many jurisdictions allows email marketing about similar products to customers who purchased from you, provided they were given a clear opportunity to opt out. But this is not an unlimited licence. Profiling based on transaction history for marketing purposes requires disclosure in your privacy policy and a lawful basis.
Selling or sharing transaction data: Not permitted without explicit consent or a compelling legal basis.
Analytics: Aggregate, anonymised transaction analytics (total revenue by product category, average order value, etc.) are generally fine. Individually identifiable transaction profiling requires more justification.
Stored Payment Methods: Consent and the Right to Delete
When a customer saves their card for future purchases — "remember my card" — this is a significant GDPR moment.
Why it matters: Storing a payment method (even as a token) means Stripe retains the underlying card data linked to a customer profile that you control. You are enabling ongoing access to that payment method. This is not implicit in completing a one-time transaction.
What you need:
- Explicit consent: The customer must actively choose to save their payment method. A pre-ticked "save my card" box is not valid consent under GDPR.
- Clear disclosure: Tell them what "saving" means — that their card details will be stored securely with your payment provider for future purchases.
- Easy withdrawal: They must be able to remove saved payment methods at any time. If you offer a customer portal, payment method management must be part of it.
- Right to deletion: If a customer exercises their right to erasure, you must delete saved payment methods (by instructing Stripe to detach and delete the payment method from the customer record). Be aware this may affect subscription billing — have a process for notifying the customer.
Stripe's customer portal feature handles much of this, but the obligation to configure it correctly and link it to your data subject rights process rests with you.
Chargeback Dispute Data
When a customer disputes a charge, you typically need to provide evidence: order details, delivery confirmation, correspondence, terms of service acceptance. This data is shared with your payment processor and, via the card network, potentially with the issuing bank.
GDPR considerations:
- Responding to chargebacks is a legitimate interest basis for processing — you have a clear, legitimate reason to process this data.
- The data shared in dispute processes should be limited to what is necessary to resolve the dispute.
- Retain dispute records for as long as chargebacks can be raised (typically 120 days for card disputes, longer in some cases) plus your standard document retention period.
- Document the processing in your ROPA.
International Transactions and Data Transfers
If you use Stripe and have EU customers, pay attention to where payment data is processed and stored.
Stripe's EU infrastructure: Stripe operates data centres in the EU and offers EU data residency for many products. If you are subject to GDPR, you should review whether your Stripe configuration routes EU customer data through EU infrastructure or US infrastructure.
Standard Contractual Clauses: Stripe's DPA includes Standard Contractual Clauses for transfers of personal data from the EU to the US. This provides the legal mechanism for the transfer, but you should be aware it exists and that it is covered by your DPA.
Practical steps:
- Log in to your Stripe dashboard and review your data residency settings
- Confirm that your DPA with Stripe is in place and covers international transfers
- If you are processing significant volumes of EU payment data, consider whether EU data residency is appropriate for your risk profile
- Document the transfer mechanism (SCCs, adequacy decision, etc.) in your ROPA
PCI DSS and GDPR: Complementary, Not Redundant
PCI DSS (Payment Card Industry Data Security Standard) is a security standard for handling cardholder data. GDPR is a data protection regulation. They overlap in practice but cover different ground.
PCI DSS focuses on:
- Security controls for card data
- Network security, access controls, encryption
- Audit trails and testing
- Primarily technical security requirements
GDPR adds:
- Lawful basis for processing
- Data subject rights (access, erasure, portability, objection)
- Data minimisation and purpose limitation
- Privacy notices and transparency
- Breach notification (72 hours to the supervisory authority)
- Records of processing activities
- DPAs with processors
Being PCI DSS compliant does not make you GDPR compliant. Being GDPR compliant does not satisfy PCI DSS requirements. Both apply if you accept payment cards from EU residents.
The good news: the security requirements under PCI DSS — encryption, access controls, logging — directly support your GDPR security obligations. Think of PCI DSS as the technical security baseline and GDPR as the broader data protection framework built on top of it.
What Your Privacy Policy Must Say About Payment Data
Your privacy policy must clearly explain how you handle payment data. Customers have a right to know, and regulators will check.
Required disclosures:
- What payment data you collect: Billing name, billing address, card brand, last four digits, transaction amounts and dates, transaction IDs
- What you do not store: Full card numbers (stored securely by your payment processor)
- Who processes it: Name your payment processor(s) (Stripe, PayPal, etc.) and describe their role as data processors
- Lawful basis: Contract performance (processing the payment the customer requested) and legal obligation (financial record keeping)
- Retention period: How long you keep transaction records and why (tax/accounting legal obligations)
- Stored payment methods: If you offer this, explain what is stored, where, and how customers can manage or delete saved methods
- Data subject rights: How customers can access, correct, or request deletion of their payment data, and any limitations (e.g., some data must be retained for legal reasons)
- International transfers: If applicable, note that payment data may be transferred to countries outside the EEA and the mechanism used (SCCs, adequacy, etc.)
Plain language matters. "We use Stripe to process payments. Stripe stores your card details securely — we only receive a payment token and the last four digits of your card number" is better than three paragraphs of legal boilerplate.
A Quick Compliance Checklist
- [ ] DPA signed with your payment processor before you began processing
- [ ] Lawful basis documented for each category of payment processing
- [ ] Privacy policy updated with clear payment data disclosures
- [ ] Stored payment method consent is explicit, not pre-ticked
- [ ] Self-service payment method deletion available to customers
- [ ] Data retention policy covers transaction data with legal retention justification
- [ ] International transfer mechanism confirmed and documented
- [ ] Breach notification process includes payment data incidents
- [ ] ROPA includes all payment processing activities
Know What Your Website Is Collecting
Payment processing is one of the most clearly scoped areas of GDPR compliance — the data flows are predictable, the processors are reputable, and the legal obligations are well-understood. What is less predictable is everything else happening on your website.
Third-party scripts, analytics tools, and marketing pixels often collect and transmit customer data alongside your payment flows in ways you may not have fully mapped. A customer completing a checkout may have their behaviour tracked by a dozen scripts before they see the confirmation page.
Run a free scan at https://app.custodia-privacy.com/scan to see exactly what is running on your website, what data it is collecting, and whether your privacy disclosures match reality.
This post provides general information about GDPR as it applies to payment processing. It does not constitute legal advice. Data protection obligations vary by jurisdiction and business model. Consult a qualified data protection lawyer or DPO for advice specific to your situation.
Top comments (0)