{"id":4528,"date":"2026-10-06T11:31:06","date_gmt":"2026-10-06T11:31:06","guid":{"rendered":"https:\/\/whitelotto.com\/?p=4528"},"modified":"2026-10-07T05:23:53","modified_gmt":"2026-10-07T05:23:53","slug":"lottery-draw-results-api-integration","status":"publish","type":"post","link":"https:\/\/whitelotto.com\/es\/lottery-draw-results-api-integration\/","title":{"rendered":"API de sorteos y resultados de loter\u00eda: integraci\u00f3n y liquidaci\u00f3n"},"content":{"rendered":"\n

Una integraci\u00f3n API de sorteos y resultados debe conservar la relaci\u00f3n entre el sorteo correcto, el boleto aceptado, el resultado autorizado y su liquidaci\u00f3n. El trabajo decisivo consiste en definir cierres de venta, zonas horarias, revisiones de resultados y recuperaci\u00f3n de mensajes ausentes o repetidos, no solo en mostrar n\u00fameros ganadores.<\/p>\n

Esta es una gu\u00eda de requisitos independiente del proveedor, no una especificaci\u00f3n de endpoints reales de WhiteLotto ni una promesa de que todas las interfaces descritas est\u00e9n incluidas. Empieza por la gu\u00eda de arquitectura API de loter\u00eda<\/a> y acuerda el contrato real con el equipo de implementaci\u00f3n.<\/p>\n\n

Utiliza identificadores estables, no solo fechas<\/h2>\n

La fecha no identifica de forma fiable un sorteo cuando un producto tiene varios sorteos diarios, cambios de horario o m\u00faltiples zonas horarias. Relaciona los identificadores del producto, del sorteo del proveedor y del sorteo de la plataforma. Conserva esas referencias en boletos e informes. Decide si un sorteo reprogramado mantiene su identidad y c\u00f3mo una cancelaci\u00f3n afecta a los boletos aceptados.<\/p>\n

\n
Contrato de la interfaz de sorteos y resultados<\/caption>
Registro<\/th>Definir antes de implementar<\/th>Evidencia de aceptaci\u00f3n<\/th><\/tr><\/thead>
Calendario de sorteos<\/th>ID estable, producto, hora prevista, cierre de ventas y zona horaria aplicable.<\/td>Una trazabilidad entre cat\u00e1logo, compra e informe.<\/td><\/tr>\n
Aceptaci\u00f3n del boleto<\/th>Hora autoritativa de aceptaci\u00f3n, regla de cierre y respuestas inciertas.<\/td>Casos justo antes, en el l\u00edmite y despu\u00e9s del cierre.<\/td><\/tr>\n
Resultado<\/th>Fuente autoritativa, estado, publicaci\u00f3n, versi\u00f3n e integridad.<\/td>Resultados no publicados, preliminares y definitivos.<\/td><\/tr>\n
Correcci\u00f3n<\/th>Referencia de revisi\u00f3n, motivo, aprobaci\u00f3n y tratamiento de boletos afectados.<\/td>Historial que relaciona el resultado anterior con el corregido.<\/td><\/tr>\n
Liquidaci\u00f3n<\/th>Disparador, responsable del c\u00e1lculo, referencias de apuntes y conciliaci\u00f3n.<\/td>Un efecto financiero por cada liquidaci\u00f3n prevista.<\/td><\/tr>\n<\/tbody><\/table><\/div>\n\n

Acuerda el significado del tiempo y el cierre de ventas<\/h2>\n

Guarda un instante inequ\u00edvoco junto con la zona horaria local identificada que utilizan la presentaci\u00f3n al cliente y las reglas del negocio. El formato de marcas temporales RFC 3339<\/a> es una referencia para representar un instante con desplazamiento horario. El desplazamiento por s\u00ed solo no describe las futuras reglas regionales de cambio de hora.<\/p>\n

Especifica si la aceptaci\u00f3n depende de la llegada a la plataforma, de la aceptaci\u00f3n por un proveedor o de otro evento contractual. Una cuenta atr\u00e1s en pantalla es informativa: no debe decidir si existe el boleto. Prueba sincronizaci\u00f3n, desfase de relojes, solicitudes retrasadas y cambios de hora. Muestra un resultado claro cuando las ventas hayan cerrado.<\/p>\n

Un timeout cerca del cierre necesita una consulta del resultado o un proceso de excepci\u00f3n con responsable. Reintentar sin comprobar puede crear un duplicado o un boleto para otro sorteo. Conserva la operaci\u00f3n original y el sorteo solicitado.<\/p>\n\n

Trata las correcciones como cambios controlados<\/h2>\n

Distingue resultados recibidos, validados, definitivos y corregidos en el modelo acordado. No interpretes un campo ausente como un boleto perdedor. Define qui\u00e9n aprueba la liquidaci\u00f3n y c\u00f3mo se autentica la fuente. Si se corrige un resultado, conserva la versi\u00f3n anterior y relaciona el ajuste con su motivo y aprobador.<\/p>\n

Repetir una notificaci\u00f3n no debe liquidar un boleto dos veces. Un resultado antiguo que llegue tarde no debe sustituir una revisi\u00f3n autorizada m\u00e1s reciente. Las correcciones financieras deben ser trazables, no reescribir silenciosamente el historial contable. La gu\u00eda de integraci\u00f3n de pagos<\/a> aborda esta disciplina para eventos financieros as\u00edncronos.<\/p>\n\n

Haz visibles los eventos ausentes<\/h2>\n