El ciclo de vida de un boleto de evento en el wallet

Nace con el evento

Un boleto digital no aparece suelto: pertenece a un evento con fecha, lugar y localidades. Defines el evento una vez —niveles de boleto incluidos: general, preferencial, palco— y emites boletos contra esa estructura. Cada boleto 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 el boleto queda en Apple Wallet o Google Wallet según su teléfono. No descarga apps ni imprime nada.

Un código único por boleto

Cada boleto lleva un código irrepetible: no hay dos boletos 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 del boleto — 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. Una foto del código deja de servir casi de inmediato, porque lo que la puerta espera ya cambió.

Antes del evento

El boleto no se queda quieto 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— el boleto 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 el boleto por su código y lo marca como usado en esa misma operación: validar y quemar el boleto 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 —el boleto reenviado 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 código también abre una página de verificación en cualquier navegador, con el estado del boleto en vivo. 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é boleto 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 del boleto también son estados de primera clase: un reembolso deja el boleto inválido para la puerta, y un boleto que nunca se usó queda expirado 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. El boleto deja de ser un archivo que circula y pasa a ser un estado que se consulta.