France Stopped Printing Receipts by Default. Where the Code Goes Now
Walk into a French shop and the till no longer spits out a receipt. The cashier asks whether you want one, and if you say no the transaction simply ends. Ask for the dematerialised version and you may be asked for an email address, which is where a rule about paper quietly turns into a question about personal data.
This is a French-only mechanism, and it has a genuinely good answer involving a code. It is worth understanding both halves before designing anything.
What the loi AGEC actually banned
The loi n° 2020-105 du 10 février 2020, known as the loi anti-gaspillage pour une économie circulaire or AGEC, inserted the rule into the IV of article L. 541-15-10 du code de l'environnement. Its application was set by décret n° 2022-1565 du 14 décembre 2022, modified by décret n° 2023-237 du 31 mars 2023, and it took effect on 1 August 2023.
Four things stopped being printed automatically:
- Till receipts in shops and in establishments open to the public.
- Card payment slips.
- Tickets issued by automated machines.
- Promotional tickets and discount vouchers handed out in shops.
Read the verb carefully. Nothing was prohibited outright. What was prohibited is printing and handing them over systematically. If the customer asks, the merchant prints. That distinction is the whole design constraint: you are not replacing paper, you are replacing the default.
What still prints, whatever you build
Article D. 541-371 du code de l'environnement keeps a list of cases where systematic printing remains required. In broad terms:
- Goods whose sale carries the legal guarantee information required by the code de la consommation: appliances, computers, phones, cameras, power tools, toys and games, sports goods, watches, lighting, furniture and similar.
- Tickets produced by an automated weighing operation.
- Documents whose printing is required by other regulations, and card slips for cancelled, failed or pre-authorised transactions.
- Tickets that are themselves needed to obtain a good or a service, or to compute what is owed.
Hospitality sits outside the whole problem for a separate reason. Under arrêté n° 83-50/A du 3 octobre 1983, a service priced at 25 euros or more including tax requires a note handed to the customer as soon as the service is rendered and before payment, and below that threshold the note must be given on request. A restaurant note is therefore required by another text, so a restaurant keeps printing.
The CNIL got there before the retailers did
The regulator published its own guidance on the end of systematic printing, and it reads like a design brief rather than a warning. Its stated preference is for solutions that let people retrieve their receipt without transmitting their contact details at all. Where a server is involved, it points at access tokens and time limits as the way to secure the link.
Where an email address or a phone number is collected, the usual obligations arrive with it: data minimisation, retention limited to what is strictly necessary, security measures, and a mechanism through which the person can consent or object. Reusing that address for marketing is a separate purpose needing its own basis, and the CNIL has been explicit that dematerialising a receipt does not justify it. The regulator has also run checks in this area, so this is not theoretical.
Which means the compliant-by-design option is the one that collects nothing. A code does that.
Four designs, and only one of them works
| Design | What the customer gets | Personal data collected | Verdict |
|---|---|---|---|
| Fixed code printed on a sticker at the till | A generic page, or a login | None | Useless: a receipt is per transaction |
| Fixed code plus a typed transaction number | The right receipt, after typing | None | Works, slowly, and people mistype |
| Per-transaction code on the till display | The right receipt, one scan | None | This is the one |
| Code that opens a form asking for an email | An email, eventually | Email address | Worst of both: data collected and friction added |
The third row is the design the CNIL's preference points at. The till already knows the transaction; it generates a one-time token, renders a code on the customer-facing display, and the phone fetches that receipt and nothing else. No account, no address, no marketing list, no subject access request to answer in two years.
The token is a credential, so treat it like one
A receipt is a document about a purchase: what was bought, where, when, and often on which card ending in four digits. A URL that opens it without authentication is functionally a password, so the token needs the properties of one.
- Unguessable. Random, long. Sequential transaction identifiers in the URL let anyone walk the day's sales.
- Short-lived. The scan happens at the till or on the way out. An hour is generous. The CNIL explicitly mentions time limitation as a security measure.
- Single-purpose. It opens a receipt. It does not identify a customer, join a loyalty profile, or set anything durable in the browser.
- Free of anything the paper would not have carried. If the ticket never printed the full card number, the page must not show it either.
There is a second question sitting behind this one: the redirect that resolves the code produces a log line before the page exists, so a consent banner on the page cannot cover it. Our piece on scan tracking, consent and retention works through that in general terms, and it applies here with one extra edge, which is that the request is tied to a specific purchase.
The paper you still print, and what the code does on it
Plenty of tickets keep coming out of the printer, either because the customer asked or because they fall in the D. 541-371 list. A code on that paper is doing a different job from the one on the screen: the customer keeps the ticket, sometimes for the length of a guarantee, and may scan it months later.
That changes the requirements. The destination has to still exist, which argues for a code whose target you can repoint rather than a URL frozen in a receipt template. The printed line of text underneath matters more than usual, because it is the only fallback once the thermal print has faded in a wallet.
Thermal printing is the real constraint. It is low resolution, the dots spread, and contrast degrades with heat, light and time. Practical consequences: keep the code generously sized rather than squeezed into the footer, keep the full quiet zone clear of the cut line and of the printed text above it, and never place it across a perforation or a fold. Our guide to print resolution and DPI covers why a code that looks fine on screen dissolves on a till roll.
A short test before you deploy anything
- Buy something. Scan the code on the display with a stock camera app on an old phone, standing where a customer stands, not leaning over the terminal.
- Try the same token twice, and again an hour later. Confirm it behaves the way you decided it should.
- Change the URL by one character and confirm you get nothing rather than someone else's receipt.
- Print a ticket, put it in a pocket for a week, and scan it again.
- Ask a colleague who has never seen the till to get their receipt without being told how. If they end up giving an email address, the design has failed at the thing the CNIL actually prefers.
The rule that started all this was about paper. The reason to do it with a code rather than an address field is that it gets you out of holding data you never wanted.
