Prova delle accettazioni

Versione 1.0 — 8 agosto 2026

Scopo: poter dimostrare quale testo l'utente ha accettato e quali condizioni, prezzi e informazioni ha visto per ogni ordine o prenotazione, senza affidarsi alla versione corrente della pagina.

Dati da conservare

Per ogni evento di accettazione:

• identificativo univoco dell'evento;
• identificativo utente o sessione e, se esiste, ordine/prenotazione/Operatore;
• tipo di documento o consenso;
• versione, data di efficacia e hash SHA-256 del documento esatto;
• copia immutabile del testo oppure riferimento a un archivio versionato non modificabile;
• etichetta della checkbox/pulsante mostrata e valore espresso;
• data e ora UTC lato server;
• lingua, dominio, percorso e versione dell'interfaccia;
• IP e user-agent limitati a quanto necessario per prova e sicurezza;
• per checkout: Operatore, articoli/servizi, quantità, prezzo totale, costi, valuta, soggetto che incassa, modalità, data/orario, regole di cancellazione/rimborso, eccezione al recesso e stato della richiesta;
• identificativo della ricevuta tecnica e della successiva conferma/rifiuto dell'Operatore.
• prova che l’account appartiene alla base utenti Jonia e che nessun altro Operatore era destinatario;
• data e ora della comunicazione, operator_id, campi effettivamente resi visibili e versione dell’informativa dell’Operatore.

Il consenso marketing, quello per allergie/dati sanitari e l'accettazione dei termini devono essere eventi separati. Una sola checkbox cumulativa non è sufficiente.

Flusso obbligatorio

1. Pubblicare ogni documento con una versione immutabile e calcolarne l'hash lato server.
2. Prima dell'invio mostrare riepilogo e link alla versione applicabile.
3. Usare un'azione positiva non preselezionata per consensi facoltativi e dati sanitari.
4. Al submit, il server ricalcola prezzi e versione: non deve fidarsi dei dati del browser.
5. In un'unica transazione, salvare ordine, Operatore destinatario, campi comunicati e record di prova.
6. Generare una ricevuta tecnica con identificativo e inviarla all'utente; precisare se non è ancora la conferma dell'Operatore.
7. Salvare come nuovo evento la conferma, il rifiuto, la modifica autorizzata o il rimborso; non sovrascrivere la storia.

Schema logico minimo

acceptance_evidence (
  id UUID PRIMARY KEY,
  occurred_at_utc TIMESTAMP NOT NULL,
  subject_id VARCHAR NULL,
  session_id_hash VARCHAR NULL,
  order_id VARCHAR NULL,
  operator_id VARCHAR NULL,
  disclosed_fields_json JSON NULL,
  disclosed_at_utc TIMESTAMP NULL,
  evidence_type VARCHAR NOT NULL,
  document_code VARCHAR NOT NULL,
  document_version VARCHAR NOT NULL,
  document_sha256 CHAR(64) NOT NULL,
  document_archive_uri VARCHAR NOT NULL,
  action_label TEXT NOT NULL,
  accepted BOOLEAN NOT NULL,
  locale VARCHAR NOT NULL,
  host VARCHAR NOT NULL,
  path VARCHAR NOT NULL,
  interface_version VARCHAR NOT NULL,
  checkout_snapshot_json JSON NULL,
  ip_evidence VARCHAR NULL,
  user_agent VARCHAR NULL,
  previous_event_id UUID NULL,
  created_by VARCHAR NOT NULL
)

checkout_snapshot_json deve essere firmato o incluso in un hash server-side. Il database deve impedire UPDATE e DELETE agli account applicativi ordinari; rettifiche e revoche diventano nuovi eventi collegati.

Integrità e accessi

• archivio append-only o log con protezione WORM/versioning;
• hash dei documenti e snapshot calcolati lato server;
• ruoli separati per consultazione, esportazione e amministrazione;
• log di ogni accesso/esportazione;
• backup cifrato e test di ripristino;
• orologio server sincronizzato;
• nessun dato carta o CVV;
• token e identificativi non prevedibili.

Conservazione

Le prove collegate a contratti, pagamenti, cancellazioni e contestazioni possono essere conservate fino a 10 anni, da validare con il professionista in base al rapporto concreto. Il consenso marketing resta documentato per la durata del trattamento e il periodo necessario a difendere la liceità; dopo la revoca si conserva la minima prova e l'informazione necessaria a non contattare nuovamente l'interessato.

IP e user-agent non devono essere conservati automaticamente per dieci anni se non necessari: si può usare minimizzazione, pseudonimizzazione o un hash con chiave separata, documentando la scelta.

Stato di implementazione

Questa è una specifica, non prova che il framework la implementi. Prima della produzione servono migrazione database, servizio server-side, archivio versioni, integrazione checkout, test di immutabilità e verifica delle retention. Un normale log applicativo o una email isolata non sostituiscono l'intero record.