{"id":3678,"date":"2026-10-05T23:35:45","date_gmt":"2026-10-05T23:35:45","guid":{"rendered":"https:\/\/whitelotto.com\/?p=3678"},"modified":"2026-10-05T23:35:52","modified_gmt":"2026-10-05T23:35:52","slug":"ciclo-vida-boleto-loteria","status":"publish","type":"post","link":"https:\/\/whitelotto.com\/es\/ciclo-vida-boleto-loteria\/","title":{"rendered":"Ciclo de vida del boleto de loter\u00eda: aceptaci\u00f3n, liquidaci\u00f3n y recuperaci\u00f3n"},"content":{"rendered":"\n

Un boleto de loter\u00eda es m\u00e1s que una l\u00ednea en el historial de compras del jugador. Conecta un producto, un sorteo, una operaci\u00f3n financiera y el derecho a un resultado. Cuando esos registros no coinciden, atenci\u00f3n al cliente no puede explicar si la compra se complet\u00f3, finanzas no puede conciliar el saldo y el operador puede liquidar dos veces la misma transacci\u00f3n.<\/p>\n

Esta gu\u00eda para operadores explica el ciclo de vida del boleto, desde la selecci\u00f3n hasta la liquidaci\u00f3n. \u00dasala para definir requisitos de una plataforma de loter\u00eda<\/a> y convertir una demostraci\u00f3n comercial en pruebas concretas de aceptaci\u00f3n.<\/p>\n

Define el boleto antes de definir sus estados<\/h2>\n

Documenta el juego, el identificador del sorteo, la selecci\u00f3n, el importe, la moneda, el canal de venta y la versi\u00f3n de las reglas aplicables. El boleto debe tener un identificador estable vinculado a la operaci\u00f3n financiera. Distingue el boleto que contiene varias l\u00edneas de cada participaci\u00f3n individual; de lo contrario, una compra parcialmente rechazada resulta dif\u00edcil de representar.<\/p>\n

El sistema de referencia debe definir tambi\u00e9n el cierre de ventas, el reloj oficial y la marca temporal que determina la aceptaci\u00f3n. Una solicitud recibida antes del cierre no equivale necesariamente a una participaci\u00f3n aceptada. Esa diferencia debe aparecer en la interfaz y los procedimientos operativos, no solo en la documentaci\u00f3n t\u00e9cnica.<\/p>\n

Crea una matriz de estados y movimientos de fondos<\/h2>\n

Las etiquetas deben explicar qu\u00e9 ocurri\u00f3, qui\u00e9n puede actuar despu\u00e9s y qu\u00e9 pas\u00f3 con el dinero. El siguiente ejemplo define requisitos, no una nomenclatura obligatoria.<\/p>\n

\n
Ejemplo de matriz de control del ciclo de vida del boleto<\/caption>
Estado<\/th>Vista del jugador<\/th>Tratamiento financiero<\/th>Evidencia necesaria<\/th><\/tr><\/thead>
Borrador<\/td>La selecci\u00f3n no se ha comprado<\/td>Sin d\u00e9bito<\/td>Selecci\u00f3n y precio indicado<\/td><\/tr>\n
Enviado<\/td>Confirmaci\u00f3n pendiente<\/td>Reserva, si el dise\u00f1o la utiliza<\/td>ID de solicitud y hora de env\u00edo<\/td><\/tr>\n
Aceptado<\/td>Participaci\u00f3n en el sorteo indicado<\/td>D\u00e9bito de compra registrado<\/td>ID del boleto, sorteo y hora de aceptaci\u00f3n<\/td><\/tr>\n
Rechazado<\/td>Participaci\u00f3n no aceptada<\/td>Liberar reserva; revertir cualquier d\u00e9bito asociado<\/td>Motivo y ajuste financiero vinculado<\/td><\/tr>\n
Liquidado<\/td>Resultado y premio disponibles<\/td>Abono del premio cuando corresponda<\/td>Versi\u00f3n del resultado e ID de liquidaci\u00f3n<\/td><\/tr>\n
Cancelado<\/td>Participaci\u00f3n sin validez<\/td>Reembolso seg\u00fan las reglas aplicables<\/td>Autorizaci\u00f3n, motivo y referencia del reembolso<\/td><\/tr>\n<\/tbody><\/table><\/div>\n

No sustituyas la compra por el reembolso. Conserva la operaci\u00f3n original y un ajuste vinculado. La arquitectura de pagos<\/a> debe mostrar esa relaci\u00f3n durante la conciliaci\u00f3n.<\/p>\n

Escenario: la compra agota el tiempo cerca del cierre<\/h2>\n

El jugador env\u00eda una compra y el servidor la acepta, pero se pierde la respuesta de confirmaci\u00f3n. El jugador reintenta despu\u00e9s del cierre. Un dise\u00f1o seguro necesita una respuesta expl\u00edcita para cada paso:<\/p>\n

  1. El reintento lleva la misma clave de operaci\u00f3n y recupera el resultado existente sin crear otro boleto.<\/li>
  2. El boleto aceptado conserva su sorteo y hora de aceptaci\u00f3n originales; el reintento no lo traslada a otro sorteo.<\/li>
  3. El monedero muestra un \u00fanico d\u00e9bito de compra y resuelve cualquier reserva temporal.<\/li>
  4. La interfaz muestra el resultado final y atenci\u00f3n al cliente puede consultar la secuencia de eventos sin modificarla.<\/li><\/ol>\n

    Pide al proveedor que demuestre esta secuencia, incluido el caso de solicitud rechazada. Una captura de una compra correcta no prueba la recuperaci\u00f3n.<\/p>\n

    Pruebas de aceptaci\u00f3n que debe solicitar el operador<\/h2>\n