Skip to main content
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 que FluzEmbedded 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 a init() 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 de init().
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.
No liquides desde onSuccess. Se ejecuta en el navegador del visitante, no lleva un registro verificable de la transacción y cualquiera puede llamarlo desde la consola. Úsalo para lo que ve el usuario: una confirmación, un redirect, quitar un spinner. Acredita cuentas, libera fulfillment o escribe en tu ledger solo desde tu servidor, activado por un webhook o una transacción que hayas obtenido y verificado tú mismo.

Cómo se comportan los callbacks

  • onSuccess es 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.
  • onError reporta 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. onError puede dispararse más de una vez en una sesión, y un onSuccess posterior aún puede llegar.
  • Ninguno de los callbacks cierra el widget. El usuario permanece en pantalla hasta que lo cierre, lo cual dispara onClose.
Trata la sesión como terminada solo cuando se dispara 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.
  • externalReferenceId proviene 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. onError recibe solo code y message.
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.
email y phoneNumber requieren un Origin registrado. Fluz dirige los mensajes de resultado al Origin en la pestaña OAuth de tu app e incluye datos de contacto solo cuando ese origin está configurado y utilizable. Sin un origin registrado, aún recibes los tres ids.Mantén el Origin apuntando a la página que integra el widget. Si nombra un host desde el que ya no integras, el navegador se niega a entregar los mensajes, por lo que onSuccess y onError dejan de dispararse. onOpen, onClose y el control de cierre no se ven afectados. El único rastro es una discrepancia de target-origin de postMessage en la consola del navegador. Consulta Configurar App Widget.

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)

La opción container está disponible solo en staging. Las integraciones en producción deben usar el modal a pantalla completa predeterminado hasta que esté disponible allí.
De forma predeterminada, el widget monta una superposición fija de todo el viewport en tu página. Pasa un container 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(): container no es ni un elemento ni un string no vacío. El widget queda sin configurar y un open() 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 contenedor irresoluble nunca recurre al modal a pantalla completa.
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.