{"id":4530,"date":"2026-10-06T11:31:08","date_gmt":"2026-10-06T11:31:08","guid":{"rendered":"https:\/\/whitelotto.com\/?p=4530"},"modified":"2026-10-06T11:31:08","modified_gmt":"2026-10-06T11:31:08","slug":"lottery-kyc-integration-guide","status":"publish","type":"post","link":"https:\/\/whitelotto.com\/es\/lottery-kyc-integration-guide\/","title":{"rendered":"Integraci\u00f3n KYC de loter\u00eda: estados, datos y revisi\u00f3n manual"},"content":{"rendered":"\n

Una integraci\u00f3n KYC para loter\u00eda debe convertir las decisiones del proveedor de verificaci\u00f3n en permisos claros y controlados de la cuenta del jugador. Define estados, revisi\u00f3n manual, tratamiento de actualizaciones y l\u00edmites de datos antes de conectar la primera pantalla. Completar una carga de documentos no equivale a aprobar al solicitante.<\/p>\n

Esta gu\u00eda aborda requisitos t\u00e9cnicos y operativos, no asesoramiento jur\u00eddico para un pa\u00eds ni documentaci\u00f3n real de la API de WhiteLotto. El operador y sus asesores deben definir comprobaciones aplicables y acciones permitidas. La gu\u00eda del recorrido KYC<\/a> relaciona la experiencia del jugador con los controles.<\/p>\n\n

Relaciona estados del proveedor con decisiones del operador<\/h2>\n

Distingue el estado del flujo del proveedor, el resultado de la decisi\u00f3n y los permisos internos de cuenta. \u00abCompletado\u00bb puede describir una revisi\u00f3n terminada tanto con aprobaci\u00f3n como con rechazo. \u00abRequiere acci\u00f3n\u00bb puede pedir otro documento, sin ser un rechazo final.<\/p>\n

\n
Correspondencia de estados independiente del proveedor<\/caption>
Estado interno<\/th>Significado a definir<\/th>Acci\u00f3n del operador<\/th><\/tr><\/thead>
Sin iniciar<\/th>No se ha iniciado el recorrido de verificaci\u00f3n requerido.<\/td>Mostrar el siguiente paso y las restricciones configuradas.<\/td><\/tr>\n
Esperando al solicitante<\/th>Falta informaci\u00f3n o una nueva presentaci\u00f3n.<\/td>Solicitarla de forma clara y segura sin revelar l\u00f3gica interna de riesgo.<\/td><\/tr>\n
Pendiente de revisi\u00f3n<\/th>Proveedor o revisor no ha producido una decisi\u00f3n utilizable.<\/td>Mantener el estado pendiente; no aprobar por timeout.<\/td><\/tr>\n
Revisi\u00f3n manual<\/th>Se necesita una decisi\u00f3n humana autorizada.<\/td>Asignar responsable, l\u00edmites de acceso y escalado.<\/td><\/tr>\n
Aprobado<\/th>Se han superado las comprobaciones acordadas para ese nivel y momento.<\/td>Aplicar solo permisos autorizados por la pol\u00edtica del operador.<\/td><\/tr>\n
Rechazado o restringido<\/th>Un resultado final o una restricci\u00f3n posterior exige actuar.<\/td>Aplicar restricciones controladas y comunicaci\u00f3n permitida.<\/td><\/tr>\n<\/tbody><\/table><\/div>\n

La documentaci\u00f3n de estados de Sumsub<\/a> ilustra la diferencia entre revisi\u00f3n completada, aprobaci\u00f3n y rechazo con posibilidad de reintento. Es un ejemplo de un proveedor, no una afirmaci\u00f3n de que WhiteLotto utilice Sumsub o tenga estados id\u00e9nticos.<\/p>\n\n

Procesa de forma segura las actualizaciones y cambios de decisi\u00f3n<\/h2>\n

Relaciona la referencia del solicitante con el jugador y nivel de verificaci\u00f3n correctos. Valida el origen del evento mediante el mecanismo documentado. Conserva metadatos suficientes para detectar duplicados e investigar tiempos, sin incluir documentos de identidad en registros rutinarios.<\/p>\n

Un solicitante puede recibir una decisi\u00f3n posterior a la primera finalizaci\u00f3n. La gu\u00eda de resultados de Sumsub<\/a> describe eventos finales posteriores y recuperaci\u00f3n de entregas perdidas. Acuerda c\u00f3mo determinar la decisi\u00f3n vigente, tratar actualizaciones antiguas y reevaluar permisos tras un cambio leg\u00edtimo. Una aprobaci\u00f3n almacenada para siempre no es un modelo completo.<\/p>\n

Prepara una ruta soportada para recuperar notificaciones ausentes. Utiliza consultas de estado o repetici\u00f3n del proveedor como alternativa seg\u00fan el contrato, no sondeos continuos de todos los solicitantes sin motivo. Relaciona este dise\u00f1o con la arquitectura general de integraci\u00f3n<\/a>.<\/p>\n\n

Minimiza los datos copiados a la plataforma<\/h2>\n

Identifica qu\u00e9 necesita cada sistema: referencia del proveedor, decisi\u00f3n, nivel, marcas temporales y c\u00f3digos de motivo permitidos pueden servir sin copiar todos los documentos. Define acceso al panel del proveedor, conservaci\u00f3n local y propagaci\u00f3n de instrucciones de borrado o retenci\u00f3n.<\/p>\n

Utiliza solicitantes ficticios en desarrollo y demostraciones. No pidas pasaportes reales para un entorno de pruebas no aprobado. Aplica acceso por roles a la revisi\u00f3n manual y evita identificadores sensibles en URL, eventos anal\u00edticos y seguimiento general de errores. Resuelve los derechos contractuales por separado con la gu\u00eda de propiedad de datos de jugadores<\/a>.<\/p>\n\n

Define la gesti\u00f3n manual antes del lanzamiento<\/h2>\n

Nombra revisor, responsable de escalado y acciones permitidas para casos ambiguos. Especifica c\u00f3mo tratar cuentas duplicadas, referencias discordantes, proveedores no disponibles y verificaciones reabiertas. Distingue un fallo t\u00e9cnico de una decisi\u00f3n negativa, evitando decir al cliente que no super\u00f3 una comprobaci\u00f3n cuando falt\u00f3 una respuesta.<\/p>\n

Soporte necesita mensajes seguros, referencias de caso y acceso a un revisor autorizado, no acceso documental sin l\u00edmites. Acuerda expectativas y antig\u00fcedad de excepciones con el checklist de soporte y SLA<\/a>.<\/p>\n\n

Casos de aceptaci\u00f3n de la integraci\u00f3n KYC<\/h2>\n