Payment data and GDPR: what a merchant can keep, and for how long

Every online payment leaves a trail of personal data: a name, an email address, a card reference, an IP address, an order. Finance wants it kept for the auditors, the fraud team wants it kept for pattern matching, and the customer may ask you to delete all of it. Those three demands do not have to conflict, but they do have to be sorted out before the request arrives.

This article sets out what payment data a merchant typically holds, the lawful basis for each use, how long regulators accept it being kept, who is controller and who is processor, how transfers work, and what to do when a deletion request meets a card scheme rule. It is general information, not legal advice. For what to collect in the first place, see our article on collecting customer data at checkout.

What payment data does a merchant actually hold?

Less than many teams assume on the card side, and more on the customer side. With a hosted checkout, the card number may never reach your systems. You still hold the order, the customer’s contact details, a transaction reference and whatever the provider returns.

Data	Who usually holds it	Typical purpose
Name, email, delivery address	Merchant	Fulfilling the order
Order and invoice	Merchant	Accounting and tax
Card number (PAN), expiry	Provider or token vault, or merchant if host to host	Taking the payment
Card security code	Nobody, after authorisation	One authorisation only
Token or masked card	Merchant and provider	Saved cards, reconciliation, refunds
IP address, device data	Merchant and fraud tools	Fraud prevention
Dispute evidence	Merchant	Answering chargebacks

The CNIL, France’s data protection authority, says the data needed for a remote card payment is the card number, the expiry date and the security code. It adds that the cardholder’s identity should not be collected by the payment system unless a defined purpose such as fraud prevention justifies it, and that a merchant or its provider cannot ask for a photo or copy of the card, even with digits masked. It also says the card number cannot be used as a commercial identifier.

Which lawful basis applies to each use?

GDPR needs a basis for each purpose, not one for “payments” as a whole. The CNIL’s 2018 recommendation, the most detailed regulator text on this, says the basis can vary by purpose, by the type of transaction and by how it is carried out.

Purpose	Lawful basis	Source
Taking a one-off payment	Contract	CNIL
Subscription with repeated payments	Contract	CNIL
Keeping a card for future purchases, one-off sale	Consent	EDPB; CNIL
Keeping a card for a paid membership with extra services	Legitimate interest, with a visible way to object	CNIL
Fraud prevention	Legitimate interest	CNIL; GDPR Recital 47
Keeping tax and accounting records	Legal obligation, where national law requires it	GDPR Article 17(3)

The saved card row matters most for online stores. The European Data Protection Board adopted Recommendations 02/2021 on 19 May 2021. Its annual report summarises them: for a customer who pays once on a website or app, consent appears to be the sole appropriate basis for storing card data for future purchases. That consent must be given by a clear affirmative action, such as a checkbox that is not ticked in advance. It must be separate from accepting the terms of sale, and it cannot be a condition of completing the purchase.

There is one difference between the two regulators. The CNIL accepts legitimate interest for a subscription that gives access to extra services, such as fast delivery or private sales, because the customer shows an intention to buy regularly. It says a simple customer account or loyalty scheme is not enough. The EDPB’s recommendations cover one-off transactions, so the two can sit side by side, but a merchant relying on the CNIL’s route outside France should take advice.

How long can payment data be kept?

GDPR sets a principle, not a number. Article 5(1)(e) says data must be kept for no longer than necessary for its purpose. National law and regulators fill in the detail, so periods differ by country. Luxembourg’s CNPD says payment service providers keep data after a relationship ends to comply with legal obligations or to protect themselves during limitation periods, and applies the same principle.

The CNIL gives the clearest figures for card data, for merchants in France:

Data and purpose	How long	Source
Card details for a one-off payment	Until payment is complete, including delivery and any withdrawal period	CNIL
Card details for a subscription	Until the last instalment, or until cancellation if it renews automatically	CNIL
Card number and expiry for claims	13 months after the debit date, or 15 months for deferred debit cards, in restricted archive	CNIL
Card kept for future purchases	Until consent is withdrawn or the card expires	CNIL
Security code	Never after the first transaction, in any case	CNIL; PCI DSS

The claims period is the one finance teams should note. The CNIL says the data must go to an intermediate archive, must be used only if a transaction is contested, and must be protected against reuse. In other words, a live customer database is the wrong place for it.

PCI DSS points the same way from the security side. Its self-assessment questionnaire for merchants says account data storage must be kept to a minimum through retention and disposal policies with a defined period and a documented business justification. Sensitive authentication data, including the card verification code, must not be retained after authorisation, even if encrypted, and the card number must be unreadable wherever it is stored. Our guide to PCI DSS and hosted checkouts covers scope.

Tax and accounting periods come from national law and vary, so set them with your accountant, not from a blog. What applies to an invoice does not automatically apply to the card behind it.

Who is controller and who is processor?

It depends on who decides what, so one provider can be both. The EDPB’s Guidelines 07/2020 say purposes are always for the controller, and that essential means, such as which data, how long and who gets access, are reserved to the controller. A processor can decide practical detail such as software.

Its examples map well onto payments. A payroll administrator following detailed instructions is a processor. But the bank that carries out the payment decides independently which data it needs and how long to keep it, for its banking activity, so the EDPB treats it as a controller, and the transfer as a disclosure between two controllers.

Yet the CNIL says a merchant that outsources the management of its payment system must choose a processor with sufficient guarantees and sign an Article 28 contract. Both statements are right, because they describe different activities.

Activity	Likely role of the provider	What to have in place
Running a hosted payment page on your instructions	Processor, if it acts only on your instructions	Article 28 contract
Storing tokens for your saved cards	Processor, if it acts only on your instructions	Article 28 contract, deletion terms
Bank or acquirer meeting its own legal duties	Controller	Disclosure in your privacy notice
Provider’s own fraud models and financial crime checks	May be controller	Check the provider’s terms

These are likely roles, not rulings. Read each provider’s data processing terms and list the outcome in your records. A merchant using several providers should do this for each one, since roles may differ.

How do international transfers work?

Sending personal data outside the EEA needs a transfer tool, and cross-border payments often do. The first question is whether the destination has an adequacy decision. The European Commission’s list includes Andorra, Argentina, Brazil, Canada (commercial organisations), the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, the United Kingdom, Uruguay and the European Patent Organisation. The Commission renewed the UK decisions on 19 December 2025.

The United States is listed only for commercial organisations in the EU-US Data Privacy Framework, so check that a US provider is actually certified. This could change. The General Court dismissed a challenge to the framework on 3 September 2025 and an appeal was lodged on 31 October 2025. WilmerHale’s note on the appeal advises companies to keep alternative mechanisms ready, such as standard contractual clauses.

Without adequacy, GDPR Article 46 requires appropriate safeguards, such as standard contractual clauses. For markets where data has to stay in the country, see our article on data localisation.

What do you do with a deletion request?

Answer item by item. Article 12(3) gives you one month, extendable by two further months with reasons given in the first month. Article 17(3) says the right to erasure does not apply to the extent that processing is necessary for a legal obligation or for the establishment, exercise or defence of legal claims. Those are limits on specific data, not a reason to refuse the whole request.

Card scheme rules matter here because they create a real need for evidence. They do not, however, replace the legal test. Visa’s rules give an issuer 120 calendar days from the processing date to raise a card-absent fraud dispute, so evidence for recent payments has a clear purpose. For stored credentials, Visa says the merchant must retain the agreement information for the duration of the agreement and provide it on written request. Each of these supports keeping specific records for a specific time.

1. Identify the data across your store, CRM, support tool, fraud tool and each provider.
2. Delete what has no remaining purpose: marketing data, saved cards and tokens, stale profiles.
3. Restrict what must stay: invoices and dispute evidence, moved out of everyday use.
4. Check open matters. A pending chargeback, refund or fraud review is a reason to hold those records until it closes.
5. Tell your processors and confirm that tokens were deleted.
6. Reply to the customer with what was deleted, what was kept, why, and for how long.
7. Set an end date so retained data really does go when the period ends.

Example figures, for illustration only. A customer in France asks for deletion on 1 March. Her last order was debited on 10 January, on a standard card. The store deletes her saved card token and marketing profile, keeps the invoice under its accounting rules, and keeps the masked card reference in restricted archive until 10 February of the next year, 13 months after the debit date. Her reply explains all three.

How does Omno fit into a GDPR programme?

With Omno’s hosted checkout, card data never touches merchant servers, and Omno forms collect and store extra provider fields so the merchant does not have to keep them. That reduces what a merchant holds. Saved cards and accounts are available, so a merchant still needs consent where it applies, and it should confirm roles and deletion steps in its own contracts with Omno and each provider. The hosted checkout page explains how it works.