Requirement 3.3 carries no retention period — it is a flat prohibition. Sensitive authentication data may not be stored after authorisation, encrypted or not. Req. 3.3.1 names three classes: the full track or chip content, the card verification value, and the PIN or PIN block. Req. 3.3.2 allows such data to exist only before authorisation, and only encrypted. A printed slip sometimes carries these fields anyway. UK GDPR Art. 5(1)(c) calls that excessive: only adequate, relevant data may be kept. anonym.plus clears those fields from the slip on your device.
When this applies
A café keeps printed slips for its till reconciliation. On some slips, next to the truncated card number, sits a verification code that should never have survived the sale under Req. 3.3.1. That value needs to leave the archive.
How anonym.plus handles it
- Open the slip in anonym.plus on your device.
- Local OCR (Tesseract) reads a scanned or photographed slip.
- The tool flags account digits, names, and codes.
- Confirm each flag on faint thermal prints.
- Black out or swap the confirmed items.
- Save the clean slip locally.
What you need to provide
- The receipt (image scan, PDF, or TXT).
- An operator (Redact suits a printed slip).
- Optional batch of up to 20 receipts per run.
PII & financial identifiers detected
| Category | anonym.plus entity type | Example |
|---|---|---|
| Account | CREDIT_CARD | ending 1111 → [CARD] |
| Names | PERSON | buyer M. Shaw → [BUYER] |
| Amount | MONEY | £42.18 → [AMOUNT] |
| Dates | DATE_TIME | 12/06/2026 14:02 → [DATE] |
| Org | ORGANIZATION | Bramley Café → [MERCHANT] |
| Contact | PHONE_NUMBER | +44 161 496 0142 → [PHONE] |
Compliance achieved
- Removes sensitive authentication data that must never survive authorisation — PCI DSS v4.0 Req. 3.3.1.
- Treats the three named classes separately: track/chip content, verification value, and PIN or PIN block.
- Follows the data-minimisation duty in UK GDPR Art. 5(1)(c): a kept verification value is excessive by definition.
- Local OCR reads thermal and photographed slips.
- Offline handling keeps the slip on your machine — no upload.
Anonymise payment receipts offline — see plans & start free →
Limitations & cautions
Faint thermal ink can defeat OCR on a low-quality scan. Check the flags on weak images. The tool marks named fields but cannot read smudged digits reliably.
Frequently asked questions
What must a receipt never store under Req. 3.3.1?
The full track or chip content, the card verification value, and the PIN or PIN block. All three are barred from storage once the sale has been authorised, and anonym.plus flags the visible account and name fields too so you can clear the whole slip in one pass.
Can a value like this ever exist encrypted before the sale is authorised?
Only in the narrow pre-authorisation window Req. 3.3.2 describes, and only encrypted. A printed receipt is generated after authorisation, so nothing from that list belongs on it at all — its presence there is the compliance gap this task closes.
Is a black-out reversible?
A true Redact removes the pixels. If you need to re-link later, use Replace with a name map and guard that map — but never for the sensitive-authentication fields themselves, which should not be recoverable once removed.