If you process payments through Stripe, Paddle, Braintree, or any similar provider, you are handling personal data. Names, email addresses, billing addresses, card metadata, and purchase history are all personal data under GDPR — and they come with specific compliance obligations that differ from the obligations around marketing data or analytics.
This guide is for SaaS founders and operators who want to handle billing data correctly: understand what you're responsible for, how your payment processor fits into the picture, and what to document and disclose.
What Billing Data Counts as Personal Data Under GDPR
Under GDPR, personal data is any information that relates to an identified or identifiable natural person. Your billing system almost certainly processes all of the following:
- Full name — used for card verification and invoices
- Email address — used for receipts, dunning emails, and account communication
- Billing address — collected for tax calculation and fraud prevention
- Card metadata — last four digits, card brand, expiry date (not the full card number, which you never see if you use Stripe or Paddle correctly)
- IP address at time of purchase — often captured for fraud detection
- Purchase history — every transaction, plan change, upgrade, and refund
- Subscription status — active, trialling, paused, cancelled
- Payment method status — whether a card is expiring, declined, or active
All of this is personal data. It needs a lawful basis for processing, needs to appear in your privacy policy and Record of Processing Activities (ROPA), and is subject to data subject rights requests.
The Lawful Basis for Processing Payment Data
For billing data, the lawful basis is almost always contract performance under Article 6(1)(b) of GDPR.
When a customer signs up for your SaaS and enters a paid plan, they are entering into a contract with you. Processing their billing data — their name, email, card details, and purchase history — is necessary to perform that contract. You cannot process a payment, issue an invoice, or manage a subscription without this data. That's what makes it contract basis rather than consent.
This matters for a few reasons:
- You do not need a consent checkbox for billing data. Asking customers to consent to processing their payment information implies they could decline — and then you couldn't charge them.
- You cannot rely on contract basis for marketing. Contract performance only covers what is strictly necessary to fulfil the contract. Upsell emails, lookalike audiences, or behavioural profiles need a separate lawful basis.
- Legal obligation covers tax and financial records. Article 6(1)(c) applies here — you can't simply delete invoice records at a customer's request if tax law requires retention.
Using Stripe, Paddle, or Braintree as Data Processors
When you use a payment processor, you are the data controller. Your payment provider is a data processor — they process personal data on your behalf, according to your instructions.
Under GDPR Article 28, you must have a Data Processing Agreement (DPA) in place with every data processor you use.
Stripe: Accept Stripe's DPA through your account dashboard under Settings → Legal.
Paddle: Paddle operates as a Merchant of Record. When Paddle is the MoR, they become the data controller for payment data — your obligations are reduced, but you still need to disclose Paddle's role in your privacy policy.
Braintree: Accept Braintree's DPA through your account. Review their sub-processor list (Braintree is owned by PayPal).
Key steps:
- Accept the DPA with your payment processor
- Add your payment processor to your privacy policy as a third-party processor
- Add them to your ROPA as a processor
- Review their sub-processor lists
Storing Card Data vs. Using Tokenisation
If you use Stripe, Paddle, or Braintree in their standard integration, you should never be storing raw card data yourself. These providers use tokenisation: the customer's card number is transmitted directly to the processor (never touching your servers), and you receive back a token.
What you typically do store locally:
- The token/customer ID (not sensitive)
- Last four digits of the card
- Card brand and expiry date
- Billing name and address
These are still personal data under GDPR. They need to appear in your ROPA and privacy policy.
Do not store:
- Full card numbers
- CVV/CVC codes
- Full magnetic stripe data
Subscription Analytics and Customer Profiling
Most subscription analytics — MRR by plan tier, churn by cohort — is legitimate and falls under legitimate interest, provided you're working with aggregated or pseudonymised data.
The GDPR concern arises when you start profiling individual subscribers — building per-customer profiles that include payment behaviour, predicted churn risk, or willingness to pay.
Under GDPR Article 22, if you make decisions that significantly affect customers solely based on automated processing (including profiling), customers have the right to object and request human review.
Billing Email Compliance: Receipts, Dunning, and Upsell Emails
Not all billing-related emails are created equal under GDPR.
Transactional receipts and invoices
Lawful basis: Contract performance. You don't need marketing consent to send invoices and payment confirmations. These emails must be sent regardless of marketing preferences.
Dunning emails (failed payment recovery)
Lawful basis: Contract performance and legitimate interest. You can send dunning emails without separate marketing consent. Keep them focused on the payment issue — don't bundle marketing content.
Upsell and promotional emails
Lawful basis: Legitimate interest (with opt-out) or consent. This is marketing. In the EU, the ePrivacy Directive generally requires prior consent or a soft opt-in for existing customers.
The safest approach: obtain marketing consent at signup with an unticked checkbox, honour opt-outs promptly, and segment your email lists so dunning and transactional emails always go out regardless of marketing preference.
Handling Payment Data in Your ROPA
For your billing processing activities, document:
- Activity name: Payment processing, invoice management, subscription management
- Controller: Your company name and contact
- Processor: Stripe / Paddle / Braintree (and their DPA reference)
- Data categories: Names, email addresses, billing addresses, card metadata, transaction history
- Data subjects: Customers (paying subscribers)
- Purpose: Fulfilling subscription contracts, issuing invoices, preventing fraud
- Lawful basis: Contract performance (Art. 6(1)(b)); Legal obligation for financial records (Art. 6(1)(c))
- Retention: Duration of subscription plus N years for financial record-keeping
- International transfers: If your payment processor routes data outside the EEA, note the mechanism (SCCs, adequacy decision)
Stripe processes data in the US and relies on Standard Contractual Clauses (SCCs) for EU-to-US transfers.
Customer Rights in the Billing Context
Right of access (Article 15)
A customer can request all the personal data you hold on them, including their full billing history, saved payment method metadata, and subscription log.
Right to erasure (Article 17)
A customer who cancels their subscription can request deletion of their personal data — but the right to erasure is not absolute.
You can refuse erasure for billing data if:
- You have a legal obligation to retain financial records (most jurisdictions require 5–7 years)
- The data is necessary for the establishment, exercise, or defence of legal claims
Best practice: Delete or anonymise what you can (marketing data, product usage data), and explain that financial records are retained for N years as required by law.
Right to portability (Article 20)
Customers can request their billing history in a machine-readable format (JSON or CSV).
Right to object (Article 21)
If you process billing-related data under legitimate interest, customers can object. You must then demonstrate compelling legitimate grounds or stop the processing.
Handling Chargebacks and Fraud Data
When a customer initiates a chargeback, your payment processor will request evidence — order records, delivery confirmation, communication history, account activity. This is covered by legitimate interest (defending legal claims) or legal obligation.
Fraud prevention data (IP addresses, device fingerprints, Stripe Radar risk scores) is personal data processed under legitimate interest. You should:
- Mention fraud prevention processing in your privacy policy
- Document internal blocklists in your ROPA
- Define a retention period for fraud-related data
Billing Compliance Checklist
Data Processing Agreements
- [ ] DPA accepted with your primary payment processor
- [ ] DPA reviewed and stored
- [ ] Secondary billing tools also have DPAs in place
Privacy Policy
- [ ] Payment processor named as a third-party data processor
- [ ] Billing data categories listed
- [ ] Lawful basis stated (contract performance)
- [ ] Financial record retention period stated
- [ ] International transfer mechanism noted if applicable
ROPA
- [ ] Payment processing listed as a processing activity
- [ ] Lawful basis documented for each sub-activity
- [ ] Processor and sub-processor chain documented
Customer Rights
- [ ] Ability to export a customer's billing data on request
- [ ] Documented response for erasure requests
- [ ] Marketing and transactional emails segmented
Tokenisation
- [ ] Confirm raw card numbers are never stored in your database
- [ ] Card metadata documented as personal data
- [ ] Marketing consent collected separately from transactional consent
- [ ] Unsubscribe mechanism in all marketing emails
- [ ] Dunning emails remain focused on payment recovery
Fraud and chargebacks
- [ ] Fraud prevention processing mentioned in privacy policy
- [ ] Retention period defined for fraud-related data
- [ ] Process documented for chargeback disputes
Start With What Your Website Is Actually Collecting
Getting billing data handling right is important, but it's only part of the picture. Before or alongside your billing compliance work, you should understand what else is running on your website — analytics tools, advertising pixels, live chat widgets, and other third-party scripts that may be collecting and transmitting personal data in ways you haven't fully mapped.
Scan your website free at app.custodia-privacy.com/scan to get a complete picture of what's collecting data, what consent you're capturing, and where your disclosures don't match reality.
This post provides general information about GDPR as it applies to SaaS billing and payment processing. It does not constitute legal advice. Consult a qualified data protection lawyer or DPO for advice specific to your situation.
Top comments (0)