Ciclo de vida del boleto de lotería: aceptación, liquidación y recuperación
Un boleto de lotería es más que una línea en el historial de compras del jugador. Conecta un producto, un sorteo, una operación financiera y el derecho a un resultado. Cuando esos registros no coinciden, atención al cliente no puede explicar si la compra se completó, finanzas no puede conciliar el saldo y el operador […]
Un boleto de lotería es más que una línea en el historial de compras del jugador. Conecta un producto, un sorteo, una operación financiera y el derecho a un resultado. Cuando esos registros no coinciden, atención al cliente no puede explicar si la compra se completó, finanzas no puede conciliar el saldo y el operador puede liquidar dos veces la misma transacción.
Esta guía para operadores explica el ciclo de vida del boleto, desde la selección hasta la liquidación. Úsala para definir requisitos de una plataforma de lotería y convertir una demostración comercial en pruebas concretas de aceptación.
Define el boleto antes de definir sus estados
Documenta el juego, el identificador del sorteo, la selección, el importe, la moneda, el canal de venta y la versión de las reglas aplicables. El boleto debe tener un identificador estable vinculado a la operación financiera. Distingue el boleto que contiene varias líneas de cada participación individual; de lo contrario, una compra parcialmente rechazada resulta difícil de representar.
El sistema de referencia debe definir también el cierre de ventas, el reloj oficial y la marca temporal que determina la aceptación. Una solicitud recibida antes del cierre no equivale necesariamente a una participación aceptada. Esa diferencia debe aparecer en la interfaz y los procedimientos operativos, no solo en la documentación técnica.
Crea una matriz de estados y movimientos de fondos
Las etiquetas deben explicar qué ocurrió, quién puede actuar después y qué pasó con el dinero. El siguiente ejemplo define requisitos, no una nomenclatura obligatoria.
| Estado | Vista del jugador | Tratamiento financiero | Evidencia necesaria |
|---|---|---|---|
| Borrador | La selección no se ha comprado | Sin débito | Selección y precio indicado |
| Enviado | Confirmación pendiente | Reserva, si el diseño la utiliza | ID de solicitud y hora de envío |
| Aceptado | Participación en el sorteo indicado | Débito de compra registrado | ID del boleto, sorteo y hora de aceptación |
| Rechazado | Participación no aceptada | Liberar reserva; revertir cualquier débito asociado | Motivo y ajuste financiero vinculado |
| Liquidado | Resultado y premio disponibles | Abono del premio cuando corresponda | Versión del resultado e ID de liquidación |
| Cancelado | Participación sin validez | Reembolso según las reglas aplicables | Autorización, motivo y referencia del reembolso |
No sustituyas la compra por el reembolso. Conserva la operación original y un ajuste vinculado. La arquitectura de pagos debe mostrar esa relación durante la conciliación.
Escenario: la compra agota el tiempo cerca del cierre
El jugador envía una compra y el servidor la acepta, pero se pierde la respuesta de confirmación. El jugador reintenta después del cierre. Un diseño seguro necesita una respuesta explícita para cada paso:
- El reintento lleva la misma clave de operación y recupera el resultado existente sin crear otro boleto.
- El boleto aceptado conserva su sorteo y hora de aceptación originales; el reintento no lo traslada a otro sorteo.
- El monedero muestra un único débito de compra y resuelve cualquier reserva temporal.
- La interfaz muestra el resultado final y atención al cliente puede consultar la secuencia de eventos sin modificarla.
Pide al proveedor que demuestre esta secuencia, incluido el caso de solicitud rechazada. Una captura de una compra correcta no prueba la recuperación.
Pruebas de aceptación que debe solicitar el operador
- Una solicitud repetida no puede crear participaciones ni débitos duplicados.
- Una compra de varias líneas parcialmente rechazada tiene un precio y un resultado explicables.
- La cancelación de un sorteo sigue el reembolso aprobado sin borrar el historial.
- Un resultado corregido genera un ajuste de liquidación trazable, no una sustitución invisible.
- Los canales web, móvil y presencial aplican las mismas reglas de aceptación y muestran estados coherentes.
Incluye permisos, responsables de escalado y conservación de evidencias en la lista de seguridad y servicio. Vincula los cambios de resultados con la integridad del sorteo y sus registros de auditoría.
Especifica las evidencias de integración y entrega
Documenta identificadores de solicitudes, consultas de estado, entrega de eventos, reintentos y exportaciones de conciliación en los requisitos de la API de lotería. Define cómo encontrar solicitudes sin resolver y quién puede resolverlas. En una migración de plataforma, conserva identificadores de boletos, referencias históricas de sorteos y obligaciones pendientes; migrar solo los saldos no basta.
Preguntas sobre el ciclo de vida del boleto
¿Confirmar el pago equivale a aceptar el boleto?
No necesariamente. El pago y la aceptación son eventos distintos, salvo que la arquitectura documentada los una en una operación controlada.
¿Todas las plataformas deben utilizar estos nombres?
No. Pueden variar, pero aceptación, rechazo, liquidación y cancelación deben tener significados inequívocos.
¿Puede un administrador modificar un boleto?
Define acciones permitidas, aprobaciones y evidencias de auditoría. Ningún cambio debe ocultar el registro original aceptado.
¿Qué debe incluir una demostración técnica?
Una compra normal, un reintento, un rechazo por cierre, una cancelación y una corrección de resultados, vinculados a sus registros financieros.
Consulta tu flujo de boletos
Prepara los tipos de juego, canales, reglas de cierre y límites de integración actuales. CONTACTO con WhiteLotto para revisar el ciclo de vida requerido y las evidencias que solicitar en una demostración.