Fotocamera o foto, nessuna libreria pesante
La scansione funziona con il riconoscimento nativo del browser dove disponibile, e ricade sul caricamento di una foto ovunque altrove, senza alcuna libreria di scansione integrata in nessuno dei due casi.
QR e controllo accessi
Una scansione, un ingresso. Ogni volta.
Il riscatto è una singola scrittura condizionale nel database, non una lettura seguita da una scrittura. Due porte che scansionano lo stesso codice nello stesso secondo fanno comunque entrare una sola persona.
- 1 aggiornamento condizionale Riscattare è una singola scrittura SQL protetta dallo stato attuale del biglietto, mai una lettura seguita da una scrittura
- L'annullamento vive fuori dallo scanner Invertire un riscatto è un'azione riservata al back office, mai disponibile sulla schermata di scansione stessa
- L'invalidazione è definitiva Un biglietto invalidato non ha via di ritorno. Non esiste un "annulla invalidazione"
Quattro pezzi della porta.
Ognuno protegge una parte diversa di ciò che accade nel momento in cui un codice viene scansionato.
Riscatta, in modo atomico
Segnare un biglietto come usato è una singola scrittura, condizionata al fatto che sia ancora nello stato emesso. Due scansioni quasi simultanee dello stesso codice, da due porte diverse, non hanno mai successo entrambe.
Invalidazione e annullamento, tenuti separati apposta
Solo il back office può invalidare un biglietto o annullare un riscatto, mai la schermata di scansione. Dare entrambi i poteri allo staff al varco permetterebbe di "annullare" sul momento un biglietto già usato per far entrare una seconda persona con lo stesso codice.
Voucher esterni, scaricati in sicurezza
Un file voucher non viene mai servito da un URL pubblico. Ogni download passa da una rotta autenticata che verifica anche che il file appartenga davvero al biglietto richiesto.
Come si risolve
Come una scansione diventa una decisione alla porta
Cinque passaggi, ogni volta che un codice viene scansionato o inserito manualmente.
- 1
Il codice viene cercato
Un codice scansionato o inserito manualmente si risolve nel proprio biglietto, oppure restituisce un chiaro "non trovato" senza suggerire se quel codice sia mai esistito.
- 2
Lo stato viene verificato all'interno della stessa scrittura
Il riscatto è un unico UPDATE con una condizione che richiede che il biglietto sia ancora nello stato emesso. Se zero righe vengono toccate, nulla è cambiato, e il motivo viene riportato da una lettura fresca subito dopo.
- 3
Solo una scansione vince la corsa
Poiché la verifica dello stato e la scrittura avvengono come un'unica operazione atomica, due porte che gareggiano a scansionare lo stesso codice nello stesso istante non possono mai avere successo entrambe.
- 4
Un evento viene registrato in ogni caso
Ogni transizione, riuscita o no, registra chi l'ha innescata, da dove, scansione o azione da amministrazione, e quando, così un ingresso contestato può sempre essere ricostruito.
- 5
Annullamento e invalidazione restano dietro il proprio varco
Invertire un riscatto o invalidare un biglietto esiste solo come azione da back office dietro un proprio permesso, del tutto separato dal permesso che consente a qualcuno di scansionare alla porta.
L'API, così com'è
Cosa vede davvero la porta
Prodotto, opzione, tipo di biglietto, data, posizione nell'ordine, nome dell'acquirente e stato di evasione. Mai un prezzo, mai un margine, mai nulla di cui lo staff al varco non abbia bisogno per decidere.
POST /api/v1/tickets/redeem
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
{
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"redeemed_at": "2026-08-14T10:00:00Z",
"position": 2,
"quantity": 3,
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"fulfillment_status": "not_required"
}200 Biglietto riscattato
Il dettaglio che quasi nessuno spiega
Zero righe toccate racconta comunque tutta la storia
Quando l'aggiornamento condizionale non tocca alcuna riga, questo da solo non dice perché. Il sistema rilegge immediatamente il biglietto per riportare la causa reale, già riscattato, con un timestamp e da chi, oppure invalidato, invece di un errore generico. Quel controllo avviene apposta dopo la scrittura: farlo prima riaprirebbe esattamente la corsa che la scrittura atomica esiste per chiudere.
Domande frequenti
No. Il riscatto è una singola scrittura nel database condizionata al fatto che il biglietto sia ancora nello stato emesso. Qualunque scansione raggiunga per prima il database vince quella condizione; la seconda trova zero righe toccate e riceve "già riscattato".
Non dalla schermata di scansione. Annullare un riscatto esiste solo come azione da back office dietro un proprio permesso. Lasciare che chi scansiona possa anche annullare aprirebbe un percorso reale per far entrare una seconda persona con un codice già usato.
No. L'invalidazione è terminale per progettazione; non esiste un "annulla invalidazione" da nessuna parte nel sistema. Un'invalidazione per errore richiede un nuovo biglietto, non un ripristino.
No. La risposta al riscatto è deliberatamente limitata a ciò di cui lo staff al varco ha bisogno per decidere: prodotto, opzione, tipo di biglietto, data, nome dell'acquirente, posizione nell'ordine e stato di evasione.
Non vengono mai serviti da un URL pubblico. Ogni download passa da una rotta autenticata che verifica anche che il file appartenga davvero al biglietto richiesto, non solo che il richiedente abbia effettuato l'accesso.
Più prenotazioni. Più canali. La stessa calma.
Tiqory mantiene disponibilità, prezzi, pagamenti e accessi allineati mentre la tua operazione cresce. Dicci dove vuoi arrivare: ti mostriamo come farlo senza ricominciare da zero.