{"id":4529,"date":"2026-10-06T11:31:07","date_gmt":"2026-10-06T11:31:07","guid":{"rendered":"https:\/\/whitelotto.com\/?p=4529"},"modified":"2026-10-06T11:31:07","modified_gmt":"2026-10-06T11:31:07","slug":"lottery-payment-gateway-integration","status":"publish","type":"post","link":"https:\/\/whitelotto.com\/es\/lottery-payment-gateway-integration\/","title":{"rendered":"Pasarela de pagos de loter\u00eda: webhooks, reintentos y reembolsos"},"content":{"rendered":"\n

Una integraci\u00f3n de pasarela de pagos para loter\u00eda est\u00e1 lista cuando los pagos, los apuntes del monedero y los informes de liquidaci\u00f3n coinciden, incluso despu\u00e9s de reintentos, timeouts, reembolsos y notificaciones retrasadas. Una pantalla de pago correcto no demuestra que el operador haya recibido fondos o acreditado una sola vez la cuenta adecuada.<\/p>\n

Esta gu\u00eda describe requisitos de integraci\u00f3n, no campos reales de la API de WhiteLotto ni soporte garantizado de un procesador concreto. La elegibilidad, los productos admitidos y las condiciones comerciales deben confirmarse por separado. Consulta la gu\u00eda del stack de pagos de loter\u00eda<\/a> para entender el alcance operativo y los costes.<\/p>\n\n

Distingue los registros del procesador, monedero y finanzas<\/h2>\n

Acuerda qu\u00e9 sistema controla el intento de pago, el resultado final del proveedor, el apunte del monedero, la instrucci\u00f3n de retirada y la conciliaci\u00f3n contable. Relaciona sus identificadores sin tratarlos como equivalentes. Define importes, moneda, redondeo y comisiones en cada frontera.<\/p>\n

\n
Estados de pago que debe resolver el contrato de integraci\u00f3n<\/caption>
Situaci\u00f3n<\/th>Comportamiento requerido<\/th>Evidencia a conservar<\/th><\/tr><\/thead>
Creado o pendiente<\/th>No confundir una operaci\u00f3n iniciada con un ingreso completado.<\/td>ID de operaci\u00f3n, referencia del proveedor y estado actual.<\/td><\/tr>\n
Autorizado o capturado<\/th>Aplicar la regla acordada de abono para el m\u00e9todo de pago real.<\/td>Evento verificado y apunte contable vinculado.<\/td><\/tr>\n
Respuesta incierta<\/th>Determinar el resultado original antes de crear otra operaci\u00f3n.<\/td>Historial de consultas o reintentos y resoluci\u00f3n final.<\/td><\/tr>\n
Reembolso o reversi\u00f3n<\/th>Vincular el ajuste al pago original y evitar efectos duplicados.<\/td>Referencia del ajuste, importe, motivo y aprobaci\u00f3n.<\/td><\/tr>\n
Disputa o diferencia de liquidaci\u00f3n<\/th>Crear una excepci\u00f3n con responsable y respuesta de finanzas.<\/td>Informe del proveedor, registro interno y trazabilidad de resoluci\u00f3n.<\/td><\/tr>\n<\/tbody><\/table><\/div>\n\n

Dise\u00f1a los webhooks para repetici\u00f3n y retrasos<\/h2>\n

Verifica el origen del evento con el mecanismo documentado por el proveedor antes de confiar en su contenido. Valida cuenta, pago, importe y moneda referenciados. Guarda el evento u operaci\u00f3n aceptados antes de devolver la respuesta que confirma la entrega. Procesa el trabajo prolongado mediante una ruta recuperable.<\/p>\n

No supongas que los eventos llegan una sola vez ni ordenados. Stripe documenta verificaci\u00f3n de firmas, duplicados y ausencia de garant\u00eda de orden<\/a>. Adyen documenta sus reglas de confirmaci\u00f3n y tratamiento de duplicados<\/a>. Son referencias espec\u00edficas de esos proveedores, no evidencias de una integraci\u00f3n de WhiteLotto con ellos.<\/p>\n

Elige claves de deduplicaci\u00f3n y reglas de transici\u00f3n seg\u00fan el contrato real. Un nuevo identificador de entrega puede representar el mismo evento de negocio. Un evento retrasado no debe hacer retroceder una operaci\u00f3n resuelta. Mant\u00e9n fallos visibles en una cola de excepciones y ofrece una repetici\u00f3n controlada.<\/p>\n\n

Define reintentos seguros y resultados inciertos<\/h2>\n

Supongamos que el proveedor completa un ingreso pero la plataforma no recibe la respuesta. Iniciar otro pago puede cobrar al jugador dos veces. Reutiliza la referencia soportada o el mecanismo de idempotencia y consulta el resultado original.<\/p>\n

La documentaci\u00f3n de idempotencia de Stripe<\/a> muestra c\u00f3mo un proveedor define el comportamiento de repetici\u00f3n. No traslades sus plazos de conservaci\u00f3n ni su sem\u00e1ntica de errores a otro procesador. Tu contrato necesita el periodo de protecci\u00f3n, la respuesta ante contenido conflictivo y la recuperaci\u00f3n despu\u00e9s de ese periodo.<\/p>\n

Prueba concurrencia adem\u00e1s de repetici\u00f3n: dos procesos pueden recibir el mismo evento simult\u00e1neamente. Una protecci\u00f3n que solo funciona en una sesi\u00f3n de navegador no basta para un registro contable compartido.<\/p>\n\n

Concilia movimientos brutos y diferencias<\/h2>\n

Relaciona operaciones del proveedor con apuntes del monedero e informes de liquidaci\u00f3n. Explica por separado comisiones, reembolsos parciales, disputas, diferencias de cambio y desfases temporales. Los dep\u00f3sitos no son ventas de boletos; un ingreso correcto no demuestra que se haya aceptado una compra posterior.<\/p>\n

Finanzas debe investigar cada importe no conciliado mediante referencias permitidas, marcas temporales e historial. Utiliza el marco de KPI<\/a> para mostrar importe y antig\u00fcedad pendientes sin ocultar diferencias opuestas al compensarlas.<\/p>\n\n

Checklist de aceptaci\u00f3n de pagos<\/h2>\n