Antes de comenzar: tu servidor debe generar un
patToken para cada sesión y ponerlo a disposición de tu página. Consulta Configura tu servidor.1. Cargar el script del widget
Agrega este cargador a tu página. Inyecta el script del widget y se resuelve una vez queFluzEmbedded está listo, por lo que el resto de tu código nunca se ejecuta antes de que el widget exista.
2. Inicializar el widget
Una vez que el script haya cargado, llama ainit() con tu clave de API, los detalles de la transacción y el patToken desde tu servidor.
init() recibe transaction_type en snake case. La claim dentro del patToken firmado es transactionType. Ambas deben describir la misma transacción.3. Abrir el widget
Elige cómo el usuario lanza el widget. Ambas opciones se ejecutan después deinit().
- Usar tu propio botón
- Usar el botón de Fluz
Vincula
open() a un botón que ya exista en tu página.Opciones de Init
init() verifica solo lo que el script en sí necesita: apiKey, patToken, transaction_type y un container resoluble. Todo lo demás se valida contra tu token firmado, por lo que un transaction_type incorrecto o un amount faltante llega a ti a través de onError, no como un mensaje de consola que tu código no puede ver.Métodos
Manejar el resultado
onOpen y onClose solo te indican que el widget apareció y desapareció, no si el usuario terminó. Para saber cómo terminó el flujo, pasa onSuccess y onError. Ambos son opcionales; si no pasas ninguno, el widget igual funciona, solo que no recibirás resultados.
Cómo se comportan los callbacks
onSuccesses final. Se dispara como máximo una vez y no se entrega ningún resultado después de él, por lo que un flujo completado nunca también reporta un error.onErrorreporta un intento, no un veredicto. Un usuario cuya verificación de identidad falla o cuyo pago es rechazado sigue en el widget y puede volver a intentar.onErrorpuede dispararse más de una vez en una sesión, y unonSuccessposterior aún puede llegar.- Ninguno de los callbacks cierra el widget. El usuario permanece en pantalla hasta que lo cierre, lo cual dispara
onClose.
onSuccess o el usuario cierra el widget.
Qué reciben los callbacks
Ambos callbacks incluyen, cuando se conozcan, los ids que vinculan la sesión con tus registros y los datos de contacto en la cuenta de Fluz que la ejecutó. Fluz los completa del lado del servidor a partir de tu token firmado y la sesión del usuario, por lo que son los valores que Fluz registró, no algo que la página haya armado.
Lee cada campo por separado; no asumas que el conjunto está completo.
externalReferenceIdproviene de tu token, por lo que sobrevive a fallas que ocurren antes de que un usuario inicie sesión.- Los otros cuatro provienen de la cuenta de Fluz y solo aparecen una vez que la sesión llegó hasta ese punto.
- Una falla antes de que tu token se valide (un token expirado, un permiso de app faltante) no lleva nada.
onErrorrecibe solocodeymessage.
email y phoneNumber describen la cuenta de Fluz en la que el usuario inició sesión, que puede diferir de los valores que pasaste en el patToken.
Estos campos identifican la sesión; no son un registro de lo que sucedió. Usa externalReferenceId para encontrar la fila correcta en tu sistema y luego confirma el resultado con un webhook o una llamada de API antes de actuar.
Códigos de error
onError recibe un code estable para ramificar y un message legible para registrar. US-0005 y G-0004 son intentos fallidos que el usuario puede reintentar; cualquier otro código significa que la sesión no puede continuar.
Trata cualquier código no reconocido como
G-0001. Con el tiempo se lanzan nuevos códigos sin cambios disruptivos.
Renderizar el widget inline (solo staging)
De forma predeterminada, el widget monta una superposición fija de todo el viewport en tu página. Pasa uncontainer y se renderiza dentro de un elemento que tú posicionas y dimensionas, sin overlay, bloqueo de scroll ni toma de control de la página.
Dimensionamiento
El widget llena tu contenedor al 100% de ancho y alto y nunca lo redimensiona. El contenido más alto que el contenedor hace scroll dentro del widget, no de tu página.- Configura un ancho y alto explícitos en el contenedor en tu CSS. Sin una altura, el widget recurre a la altura predeterminada de iframe del navegador de 150 px, el error más común en esta integración. El script registra una advertencia en la consola si el contenedor es demasiado pequeño cuando se abre el widget.
- El tamaño mínimo compatible es 320 × 480 px. Todas las pantallas, incluyendo captura de documentos, 2FA y entrada de PIN, están soportadas en ese tamaño. Diseños más pequeños no están soportados.
- No hay máximo. Los contenedores anchos obtienen el layout de escritorio, incluido el panel de resumen de la transacción; los estrechos obtienen el layout móvil.
Diferencias con el modal
Planea para esa última fila: cuando el usuario cierra un widget inline, se dispara
onClose y tu contenedor se vacía, así que renderiza su reemplazo desde onClose.
Errores del contenedor
Si el contenedor no puede usarse, no se renderiza nada,onOpen no se dispara y el script registra un error:
- En
init():containerno es ni un elemento ni un string no vacío. El widget queda sin configurar y unopen()posterior se rechazará. - En
open(): el selector no coincide con nada, no es CSS válido o el elemento no está adjunto al documento.
Un selector de
container se resuelve cuando se llama a open(), no en init(), por lo que está bien llamar a init() antes de que el elemento exista.