GDPR Right to Erasure Article 17 on PrestaShop: Account Deletion Without Breaking the Tax Trace in 2026

GDPR Article 17: an obligation simple to state, complex to execute

“The customer can request the deletion of their data.” The phrase in GDPR Article 17 is lapidary. Its implementation on a 5-year-old PrestaShop or WooCommerce store is anything but simple. Because a properly done “account deletion” must navigate between four contradictory requirements:

• The customer’s right to erasure (GDPR Article 17).
• The 10-year accounting retention obligation (in France, Commercial Code L.123-22; similar obligations exist in most European jurisdictions).
• Tax traceability of sales (FEC and equivalent reporting frameworks).
• The right to respond to a potential dispute (Consumer Code, legal guarantees up to 2 years after purchase).

The practical issue: a module that deletes everything brutally puts the company in accounting violation. A module that deletes nothing puts the company in GDPR violation (fine up to 4% of global revenue). The good practice is selective pseudonymisation — delete what isn’t necessary to a legal obligation, retain the rest in a form not attributable to an identified person.

What GDPR Article 17 actually says

Article 17.1 enumerates six grounds justifying a deletion request:

1. The data is no longer necessary for the purpose for which it was collected.
2. The person withdraws consent and no other legal basis exists.
3. The person objects to processing and no compelling legitimate ground exists.
4. The data has been subject to unlawful processing.
5. The data must be erased to comply with a legal obligation.
6. The data was collected as part of an offer of services to a child.

But Article 17.3 provides five exceptions frequently applicable to e-commerce:

1. Exercise of freedom of expression and information.
2. Compliance with a legal obligation (e.g. accounting retention).
3. Public interest in the field of public health.
4. Archiving purposes, scientific or historical research, statistics.
5. Establishment, exercise or defence of legal claims.

Exception (b) — legal obligation — is the one applicable to accounting data. But it doesn’t cover all data of a customer account: only those strictly necessary to keeping accounts and respecting the retention period (10 years in France).

Mapping customer account data

On a PrestaShop store with 5 years of history, a customer account typically contains:

Data category	Examples	Article 17 deletion	Legal retention
Identification	name, first name, email, phone	Pseudonymise	10 years (accounting)
Addresses	shipping, billing	Retain billing address, delete old shipping	10 years for billing
Orders	number, date, amounts, items	Retain	10 years (accounting) + 2 years (legal guarantee)
Payments	Stripe/PayPal tokens, last digits	Delete if no longer used	No obligation, but useful for dispute
Passwords	bcrypt hash	Delete immediately	None
Preferences	newsletter, marketing, cookies	Delete	None (except consent proof useful 3 years)
Browsing history	visit logs, abandoned carts	Delete	None
Reviews and comments	product reviews, support messages	Anonymise (“Anonymous customer”)	Variable depending on public display
Loyalty programme	points, statuses	Delete	None
Wishlist	favourite products	Delete	None

The sorting rule: is this data necessary to accounting traceability or a potential dispute? If yes, retain in pseudonymised form. If no, delete.

Pseudonymisation: the central mechanism

Pseudonymising is not anonymising. The difference is legal and technical:

• Anonymisation: irreversible removal of the link between data and person. The data can never again be attributed. Anonymisation takes the data out of the GDPR perimeter.
• Pseudonymisation: replacement of direct identifiers by a pseudonym, but the link remains theoretically reconstructable (e.g. via an encrypted lookup table). The data remains in the GDPR perimeter, but the processing is considered lower risk.

For e-commerce, we generally aim for strong pseudonymisation close to practical anonymisation:

• customer.firstname → "Customer"
• customer.lastname → "#" + id_customer (e.g. "#42851")
• customer.email → "deleted-" + id_customer + "@invalid" (special prefix, invalid domain)
• customer.phone → NULL
• customer.passwd → random bytes (account effectively unusable)
• customer.note → NULL
• address.firstname, address.lastname on old addresses → pseudonym
• address.firstname, address.lastname on billing addresses of existing orders → retain (necessary for the invoice)

The key is in the nuance: keep the invoice as it was issued (accounting obligation), but delete everything no longer needed.

Architecture of a compliant deletion module

A serious module for PrestaShop like DfAccountDelete implements five layers:

Layer 1 — Request identification

Three possible channels:

• Button in customer area — “Delete my account” accessible from “My information”. Self-service UX.
• Request form — for old customers who can no longer log in. Identity verification by email with confirmation link.
• Request to DPO/GDPR contact — by email or post, handled manually with transcription into the system.

Layer 2 — Identity verification

Before deletion, verify that the person is indeed the account holder. For logged-in customers: being logged in + password entry or email validation (second magic link). For non-logged-in customers: send confirmation email with single-use validation link with limited duration (1 hour typically). For postal requests: copy of ID retained 1 year then destroyed.

Layer 3 — Cooling-off period

Optional but recommended: a 7 to 30 day period between request and effective execution. The user receives an email “your request will be processed on [date], click here to cancel”. This avoids accidental deletions and regrets. It’s CNIL good practice.

Layer 4 — Pseudonymisation execution

The module executes in atomic MySQL transaction:

1. Pseudonymises ps_customer (name, email, phone, etc.).
2. Pseudonymises ps_address not attached to finalised orders.
3. Deletes abandoned ps_cart, ps_compare, ps_wishlist.
4. Deletes loyalty programme entries, price alerts, stock alerts.
5. Anonymises public reviews (“Anonymous customer”) or deletes them per policy.
6. Deletes session logs, magic link tokens, saved carts.
7. Deletes newsletter subscriptions (and propagates to Mailchimp, Brevo via API if connected).
8. Marks account as deleted (active=0, deleted=1, deleted_at = now).
9. Keeps orders, invoices, credit notes intact (ps_orders, ps_order_invoice, ps_order_slip).

Layer 5 — Audit log and notification

An entry in a GDPR audit journal:

• Request date, execution date.
• Original email (before pseudonymisation).
• Customer ID.
• Identity verification method.
• List of tables touched and number of rows affected.

This log is retained 3 years (duration recommended by CNIL to demonstrate compliance). It serves in case of CNIL inspection or person request (“did you really delete my data?”).

A confirmation email is sent to the original address, with mention that data has been deleted except those necessary to accounting (GDPR Article 12 transparency).

The bridge with the FEC: what must absolutely be preserved

As explained in our article on FEC and accounting export, certain data is necessary for producing a compliant FEC:

• Customer identification on the issued invoice (name + billing address at issue time). But you don’t need this name to always be retrievable from the live customer base — it’s in the archived PDF invoice and in ps_orders.
• Ex-tax, VAT, shipping, total amounts inc. tax — pure accounting data, to retain intact.
• Order, invoice, payment dates — idem.
• Payment method (Stripe, PayPal, transfer) — useful for bank reconciliation.

The practical pattern: pseudonymise ps_customer, but leave ps_orders.firstname, ps_orders.lastname, ps_orders.email as they were at order time. That’s what appears on the issued invoice. The invoice is the accounting record, immutable. The customer account is a live aggregate, which can be anonymised.

On PrestaShop, this logic is facilitated by the fact that the invoice is handled by ps_order_invoice with its own fields (the name isn’t only referenced by id_customer, it’s also frozen on the order). On WooCommerce, it’s trickier: WC orders store the customer ID and reconstruct info at display. You must therefore freeze the name and billing address on the order at pseudonymisation time, otherwise the regenerated invoice displays “Anonymous customer”.

Reviews and comments: a special case

A product review publicly displayed with the customer name is personal data (GDPR Article 4). Its deletion on request poses two problems:

• The review content has value for other customers (consumer information).
• Review history serves the rating average.

The standard legal resolution: anonymise the name (“Anonymous customer” or “A.C.”), retain the review content and rating. It’s statistical processing within the meaning of Article 17.3.d. If the customer explicitly requests complete deletion of the review (“I don’t want this text to exist anymore”), then delete completely, but you can re-evaluate the average without the lost data.

This nuance must be presented to the user in the form: “Do you want to delete your reviews or make them anonymous?”.

Difficult special cases

Customer account with ongoing dispute

If an order is in dispute (return blocked, contestation, warranty action), deleting customer data compromises the company’s defence. Article 17.3.e covers this case: you can refuse deletion until dispute resolution, informing the customer of this reason. Retention happens under “in dispute” status, with restricted access.

B2B account with multi-users

On a B2B account with multiple users, deleting one user’s account must not delete the company. Delete the user (who has an individual right), retain orders in the company name (which has no right to erasure, being a legal entity).

Newsletter without account (anonymous)

An email subscribed to the newsletter without a customer account: deletion is immediate, no pseudonymisation. No accounting obligation attached. One exception: if marketing consent is tracked as proof, you can retain consent history (date, IP, opt-in) for 3 years after unsubscribe. Beyond, complete deletion.

Recurring service subscribers (subscription)

For subscription stores, account deletion requires first stopping the subscription (impossible to debit a card from an account that no longer exists). The module must sequence: cancel subscriptions → wait for a cycle for confirmation → pseudonymisation. Skipping the sequence causes orphan debits and customer disputes.

The response deadline imposed by GDPR

GDPR Article 12.3: the response to a request must be given within 1 month, extendable to 2 or 3 months for complex requests (with notification of the extension to the requester). In practice for e-commerce:

• Simple request via the “delete my account” button: immediate execution (per optional cooling-off period) — well under the legal deadline.
• Request via email/post requiring identity verification: 1 to 2 weeks of handling, under the month.
• Request in complex context (dispute, active subscription, multi-accounts): 1 month with information to the requester on status.

Non-compliance with the deadline exposes to CNIL sanctions. An automated module responding within 24-48h widely covers the risk.

Cost and ROI

The ROI of a compliant account deletion module is measured differently from a conversion module:

• Module cost: €39 licence for PrestaShop.
• Avoided cost of CNIL sanction: variable, but 2023-2025 e-commerce sanctions range from €5,000 for SMEs to several million for large chains. The cost/risk ratio is extremely favourable.
• Avoided cost of manual reprocessing: on a 50,000-customer store, handling 5 to 10 requests/month manually represents 2 to 4 hours/month of internal work — about €1,200/year.
• Trust benefit: displaying a clearly visible “delete my account” button has become a strong trust signal in 2026, measurable in account creation rate (+3 to 6% observed).

FAQ

Do you really have to keep orders 10 years after account deletion?

Yes, it’s the accounting obligation (Commercial Code L.123-22). GDPR doesn’t exempt from tax law. The resolution: orders remain in the database in pseudonymised form (the customer name is no longer attached to a live account but still appears on the issued invoice, as necessary). At the end of 10 years, complete deletion is possible.

What if Mailchimp or Brevo continues sending the newsletter?

GDPR Article 19 requires propagation of deletion to recipients of the data. If you’ve synced your database with Mailchimp/Brevo/Klaviyo, the module must call their API to delete the contact (and not just unsubscribe). It’s a point to validate at installation: all marketing connectors must receive the deletion signal.

How to handle deletion with subcontractors (Stripe, PayPal)?

Stripe and PayPal retain payment tokens and transaction history per their policy (typically 10 years for tax compliance + anti-money laundering). You can’t force their deletion — it’s their legal obligation, distinct from yours. The mention in your privacy policy must indicate that payment subcontractors retain data per their own legal duration.

Can you delete an account without informing the customer?

If the customer requested the deletion: inform them of execution. If the company deletes on its own initiative (prolonged inactivity, for example): this policy must be foreseen in T&Cs/privacy policy, and ideally notify 30 days before deletion to allow objection. Deletion without notification is risky.

How long after a deletion request can a customer come back to us?

Right to erasure isn’t a right to reversal. Once data is deleted (or pseudonymised), the returning customer creates a new account ex nihilo. History remains in the GDPR audit log (which serves to prove execution of the request), but cannot be reused to rebuild the initial account.

In summary

Account deletion compliant with GDPR Article 17 is a balancing exercise between four contradictory legal obligations. The resolution passes through selective pseudonymisation: delete or anonymise everything not covered by a retention obligation, intactly retain the accounting trace necessary to FEC and tax audit.

The DfAccountDelete module for PrestaShop implements this logic with the five layers of a compliant workflow: identification, identity verification, optional cooling-off period, atomic pseudonymisation, audit log. It integrates with FEC export to not break the accounting chain and with the main marketing tools (Mailchimp, Brevo, Klaviyo) to propagate deletion.

The right reflex in 2026: display a clearly visible “delete my account” button in the customer area (trust signal, explicit compliance), document the workflow in the privacy policy (Article 12 transparency), retain the audit log 3 years to demonstrate compliance in case of CNIL inspection.

For stores wanting a complete GDPR compliance audit, our PrestaShop audit covers the six critical points: cookies and consent, customer data processing basis, configured retention periods, right of access and portability, right to erasure, Article 30 processing register.