> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Verificar con el Widget

> Deja que el widget de Fluz maneje la verificación de identidad como un paso incorporado, sin que los datos de identidad pasen por tus sistemas.

Si incrustas el widget de Fluz, la verificación viene incluida. No construyes un flujo de verificación, no recopilas campos de identidad ni manejas documentos: el widget presenta la verificación como una puerta y la habilita antes de permitir que el cliente continúe.

Esta es la única vía en la que la información de identidad del cliente nunca toca tu infraestructura, lo cual suele ser el factor decisivo para elegirla.

<Info>
  **Requisitos previos**

  * Una aplicación de widget configurada en el Portal de Desarrolladores, con los ajustes de OAuth listos. Consulta [Configurar App Widget](/developers/configure-app-widget).
  * El scope `VERIFY_KYC` habilitado en tu aplicación por Fluz. Consulta [Scope requerido](/user-kyc-verification#required-scope).
  * Un endpoint de webhook registrado. Consulta [Verificar Clientes](/user-kyc-verification#set-up-a-webhook).
</Info>

## Dónde encaja la verificación

La verificación es un paso en la secuencia normal del widget, no una integración separada:

<Steps>
  <Step title="Tu página llama a FluzEmbedded.init()">
    El widget se abre en un iframe.
  </Step>

  <Step title="El cliente inicia sesión o se registra">
    Si aún no tiene una cuenta de Fluz, el widget crea una.
  </Step>

  <Step title="El widget verifica el estado de verificación">
    Si el cliente ya está verificado, continúa de inmediato. Si no, la verificación se ejecuta aquí.
  </Step>

  <Step title="El cliente completa cualquier paso pendiente">
    Configuración de PIN y autorización de scopes de OAuth.
  </Step>

  <Step title="El cliente completa su transacción">
    Confirmación y luego finalización.
  </Step>
</Steps>

Como la verificación se sitúa antes de la transacción, un cliente que no pueda verificarse no llegará al paso de la transacción.

## Qué experimenta el cliente

Cuando un cliente no verificado llega a la puerta, el widget primero intenta verificarlo silenciosamente en segundo plano. Muchos clientes superan la puerta en este punto sin que se les pida nada.

Si eso no se resuelve, el widget presenta un formulario de verificación dentro del iframe, prellenado con lo que Fluz ya tiene. El cliente lo revisa, aporta lo que falte y envía. Luego el widget muestra un estado de espera mientras se procesa el resultado y avanza automáticamente una vez que se resuelve.

Si la verificación aún no tiene éxito, el widget escala al cliente a verificación por documentos — capturando su identificación oficial y una selfie — dentro del mismo iframe.

<Note>
  Todo esto sucede dentro del widget. No necesitas detectar en qué etapa está un cliente ni activar tú mismo la escalada.
</Note>

## Scopes

Las aplicaciones de widget solicitan automáticamente los scopes que necesitan durante el paso de autorización de OAuth, incluido `VERIFY_KYC`. No tienes que agregarlo manualmente a la lista de scopes del widget.

Aún necesitas que `VERIFY_KYC` esté habilitado en la aplicación por Fluz. Si no lo está, el widget no se cargará y mostrará un error de permisos faltantes, en lugar de omitir la verificación.

<Warning>
  Al generar el token de corta duración que pasas al widget como `patToken`, usa tu **API Key** para el encabezado `Authorization: Basic` — no tu ID de cliente de OAuth ni tu `app_id`. Usar el valor incorrecto es la causa más común de que un widget no se cargue. Consulta [Obtener tus credenciales de API](/get-started/api-credentials).
</Warning>

## Conocer el resultado

El widget le comunica el resultado directamente al cliente, pero tu aplicación no debe inferir el estado de verificación a partir del cierre del widget. En su lugar, confía en los webhooks.

Fluz emite `WIDGET_KYC_INITIATION` cuando un cliente **inicia** la verificación en el widget. Esto requiere el scope `VERIFY_KYC`.

```json theme={null}
{
  "eventType": "WIDGET_KYC_INITIATION",
  "userId": "550e8400-e29b-41d4-a716-446655440000",
  "accountId": "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
  "externalReferenceId": "your-reference-123"
}
```

<Note>
  Este evento marca el **inicio** de la verificación, no el resultado. Usa `externalReferenceId` para mapear el evento con el registro de tu cliente, y suscríbete también a los eventos de resultado de verificación para saber cómo se resolvió. Consulta [Webhooks](/fluz-dashboard/webhooks).
</Note>

## Combinar el widget con la API

El widget y la API comparten un único estado de verificación por cliente, por lo que ambos enfoques se combinan limpiamente:

* Un cliente verificado a través de la API pasará directamente por la puerta del widget.
* Un cliente verificado en el widget también está verificado para tus llamadas a la API.
* Un cliente que agotó sus intentos en un canal los ha agotado en ambos.

Esto importa si verificas clientes con la API durante el onboarding y luego los entregas al widget: verifica el estado de verificación actual del cliente en lugar de asumir que el widget le ofrecerá otro intento.

## Pruebas

Ejecuta el flujo completo del widget en staging contra las identidades de prueba publicadas, incluyendo un rechazo deliberado para que puedas ver la escalada a verificación por documentos. Los widgets de staging apuntan al entorno de staging en lugar de producción: confirma que estás cargando el script del widget de staging y la URL base. Consulta [Probar Flujos de KYC](/test-kyc-flows) y [Entorno de Staging vs. Live](/concepts/environments).