Cámara o foto, sin librería pesada
El escaneo usa el reconocimiento nativo del propio navegador donde está disponible, y recurre a subir una foto en cualquier otro caso, sin ninguna librería de escaneo empaquetada en ningún camino.
QR y Control de Acceso
Un escaneo, una entrada. Siempre.
El canje es una sola escritura condicional en la base de datos, no una lectura seguida de una escritura. Dos puertas que escanean el mismo código en el mismo segundo igual solo dejan pasar a una persona.
- 1 actualización condicional Canjear es una sola escritura SQL protegida por el estado actual del ticket, nunca una lectura seguida de una escritura
- Deshacer vive fuera del escáner Revertir un canje es una acción exclusiva del back office, nunca disponible en la propia pantalla de escaneo
- Anular es definitivo Un ticket anulado no tiene camino de vuelta. No existe "desanular"
Cuatro piezas de la puerta.
Cada una protege una parte distinta de lo que pasa en el instante en que se escanea un código.
Canjear, de forma atómica
Marcar un ticket como usado es una sola escritura, condicionada a que siga en estado emitido. Dos escaneos casi simultáneos del mismo código, desde dos puertas distintas, nunca tienen éxito los dos.
Anular y deshacer, separados a propósito
Solo el back office puede anular un ticket o deshacer un canje, nunca la pantalla de escaneo. Darle ambos poderes al personal de puerta permitiría "deshacer" un ticket usado en el acto para dejar entrar a una segunda persona con el mismo código.
Vouchers externos, descargados de forma segura
Un archivo de voucher nunca se sirve desde una URL pública. Cada descarga pasa por una ruta autenticada que también verifica que el archivo realmente pertenece al ticket solicitado.
Así se convierte un escaneo en una decisión en la puerta
Cinco pasos, cada vez que se escanea o se ingresa un código manualmente.
- 1
Se busca el código
Un código escaneado o ingresado manualmente se resuelve hasta su ticket, o devuelve un claro "no encontrado" sin insinuar si ese código alguna vez existió.
- 2
El estado se verifica dentro de la misma escritura
El canje es un solo UPDATE con una condición que exige que el ticket siga en estado emitido. Si no se afecta ninguna fila, nada cambió, y el motivo se reporta a partir de una lectura nueva justo después.
- 3
Solo un escaneo gana la carrera
Como la verificación del estado y la escritura ocurren como una sola operación atómica, dos puertas compitiendo por escanear el mismo código en el mismo instante nunca pueden tener éxito las dos.
- 4
Un evento queda registrado en cualquier caso
Cada transición, exitosa o no, escribe quién la disparó, desde dónde, escaneo o acción del back office, y cuándo, así una entrada disputada siempre puede reconstruirse.
- 5
Deshacer y anular quedan detrás de su propia puerta
Revertir un canje o anular un ticket existe solo como una acción del back office detrás de su propio permiso, completamente separado del permiso que permite escanear en la puerta.
Lo que realmente ve la puerta
Producto, opción, tipo de entrada, fecha, posición en el pedido, nombre del comprador y estado de cumplimiento. Nunca un precio, nunca un margen, nunca nada que el personal de puerta no necesite para decidir.
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 Ticket canjeado
Cero filas afectadas igual cuenta toda la historia
Cuando la actualización condicional no toca ninguna fila, eso por sí solo no dice por qué. El sistema vuelve a leer el ticket de inmediato para reportar la causa real, ya canjeado, con marca de tiempo y quién lo hizo, o anulado, en lugar de un fallo genérico. Esa verificación ocurre después de la escritura a propósito: hacerla antes reabriría exactamente la carrera que la escritura atómica existe para cerrar.
Preguntas frecuentes
No. El canje es una sola escritura en la base de datos condicionada a que el ticket siga en estado emitido. El escaneo que llegue primero a la base de datos gana esa condición; el segundo encuentra cero filas afectadas y recibe "ya canjeado" en su lugar.
No desde la pantalla de escaneo. Deshacer un canje existe solo como una acción del back office detrás de su propio permiso. Dejar que el mismo personal que escanea también pueda deshacer abriría un camino real para dejar entrar a una segunda persona con un código ya usado.
No. Anular es terminal por diseño; no existe "desanular" en ningún punto del sistema. Un anulado por error necesita un ticket nuevo, no una reversión.
No. La respuesta de canje se limita deliberadamente a lo que necesita el personal de puerta para decidir: producto, opción, tipo de entrada, fecha, nombre del comprador, posición dentro del pedido y estado de cumplimiento.
Nunca se sirven desde una URL pública. Cada descarga pasa por una ruta autenticada que también verifica que el archivo realmente pertenece al ticket solicitado, no solo que quien lo pide tiene sesión iniciada.
Más reservas. Más canales. La misma calma.
Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.