El ciclo de vida de una entrada de evento en el wallet

El ciclo completo en una línea: la entrada nace atada a su evento, lleva un código único que se valida —y se quema— una sola vez en la puerta, y cada validación le avisa a tu sistema en tiempo real por webhook. Aquí está pieza por pieza, de la emisión al conteo final.

Nace con el evento

Una entrada digital no aparece suelta: pertenece a un evento con fecha, lugar y localidades. Defines el evento una vez —niveles de entrada incluidos: general, preferencial, palco— y emites entradas contra esa estructura. Cada entrada sale con su titular, su localidad y, si aplica, su fila y asiento visibles en el pase.

El comprador recibe un enlace, toca un botón y la entrada queda en Apple Wallet o Google Wallet según su teléfono. No descarga apps ni imprime nada. En ambas plataformas la entrada usa el tipo nativo de entrada, así que el teléfono la muestra con el layout propio de una entrada: evento, lugar y fecha en el encabezado, asiento a la vista.

Un código único por entrada

Cada entrada lleva un código irrepetible: no hay dos entradas con el mismo código en la plataforma. Ese código es lo que el lector escanea en la puerta, y es la identidad operativa de la entrada — no el nombre del titular, no el número de orden de compra.

Para eventos donde una captura de pantalla del QR es un riesgo real, existe una capa adicional: el código dinámico, que rota cada pocos segundos en el pase — disponible hoy en las entradas de Google Wallet. Una foto del código deja de servir casi de inmediato, porque lo que la puerta espera ya cambió.

Antes del evento

La entrada no se queda quieta esperando la fecha. El pase sabe cuándo y dónde es el evento, así que aparece en el momento relevante — el teléfono lo sugiere cuando la fecha y el lugar coinciden. Y el recordatorio previo al evento llega directo al pase: fecha, hora y acceso a la mano, sin depender de que el comprador encuentre el correo de hace un mes.

Si el evento cambia —de hora, de puerta, de fecha— la entrada se actualiza en todos los teléfonos a la vez. Nadie llega con la versión vieja porque no existe una versión vieja.

En la puerta

El lector escanea exactamente lo que muestra el wallet. La plataforma resuelve la entrada por su código y lo marca como usado en esa misma operación: validar y quemar la entrada son un solo movimiento, no dos pasos que puedan quedar a medias.

El segundo intento con el mismo código recibe una respuesta distinta: ya usada. Ahí muere el fraude más común de los eventos —la entrada reenviada a tres personas— sin cartelera, sin lista impresa y sin discusión en la puerta: el primero entra, los demás no.

¿Y si una puerta no tiene lector integrado? El mismo código se lee desde el teléfono del staff: la estación de escaneo de AVEX corre en el navegador con sesión de operador, apunta la cámara al código —o lo escribe a mano si la cámara no puede leerlo— y quema la entrada en el mismo movimiento. Sirve como plan B o como única herramienta en eventos pequeños.

Después de la puerta

Cada validación le avisa a tu sistema mediante un webhook: qué entrada entró, cuándo y por cuál operación. Para la ticketera o el organizador eso significa ver el ingreso en tiempo real desde su propio sistema, sin esperar el cierre del evento para saber cuánta gente llegó.

Los otros finales de la entrada también son estados de primera clase: un reembolso deja la entrada inválida para la puerta, y una entrada que nunca se usó queda expirada cuando el evento pasa. En todos los casos, el estado que ve la puerta es el estado real.

Lo que este flujo evita

Vale la pena nombrar la alternativa: PDFs reenviados sin control, listas de asistentes impresas la tarde anterior, verificación a ojo en la entrada y conteos que aparecen dos días después. Cada pieza del ciclo —código único, un solo uso, estado en vivo, aviso a tu sistema— existe para eliminar uno de esos dolores. La entrada deja de ser un archivo que circula y pasa a ser un estado que se consulta.