Lista de verificación de integración

Empresa, personas y aplicación

• Cuenta nominativa de administrador activada mediante la invitación (o Esqueceu sua senha?); correo electrónico verificado y autenticador completado.
• Cada paso de Início está realmente en Concluída, no solo enviado o en Aprovada.
• La membresía/el rol vigentes y la aplicación/el entorno exactos coinciden con la integración.
• Los orígenes permitidos del sitio web son orígenes HTTPS exactos, sin rutas, puertos ni comodines.
• Configurar a coleta web usa uno de los orígenes de la aplicación y el dominio base de su propiedad; su colector generado es collect.<base-domain>.
• Integração e saúde › Origens das páginas enumera todos los orígenes de página que capturan (por ejemplo, el apex y www), todos bajo el dominio de captura, como máximo 10.
• Los pasos automáticos de release/política/admisión y de retención técnica están completos en Início; Aguardando revisão no equivale a completado.
• Los demás miembros usan cuentas nominativas y el rol mínimo necesario para su trabajo.
• Los datos emitidos están completos y provienen de la configuración real/la entrega verificada.
• La prueba de DNS/titularidad/certificado/salud de collect.<your-domain> está vigente; preparar los registros no es la activación.
• El secreto HMAC se recibió una sola vez en la consola y se guardó en el gestor de secretos del backend; ninguna solicitud de credencial sigue en Aguardando você receber o segredo.
• Los permisos reales del cliente y el límite de tasa vigente del cliente de servidor (nivel estándar: 5 solicitudes por segundo, ráfaga de 10; consulte los límites) coinciden con la configuración del backend.
• Su credencial de servidor está instalada con admisión activa y su dominio de captura está activo; la API firmada está operativa en producción en modo shadow y la captura del Web SDK está desplegada allí (estado).
• Están confirmadas las pruebas aplicables de seguridad/aislamiento, las de retención/eliminación técnicas aplicadas y las operativas/de recuperación.
• El release, la política y la admisión calificados y activos, y la activación explícita de la aplicación, están registrados antes de los datos reales.

Backend

• El HMAC usa los 32 bytes decodificados del gestor de secretos del backend, nunca el texto hexadecimal de 64 caracteres.
• Salvo su única visualización en la consola, ningún secreto real aparece en el chat, el navegador, el correo electrónico, argumentos/salida de comandos, archivos locales ni el repositorio.
• La autocomprobación de firma reproduce su vector sintético público en el Node.js del backend (24.16.0 o posterior en la serie 24; en Vercel, Node.js 24.x).
• El reloj del backend está sincronizado; X-FTID-Timestamp está en segundos.
• Cada intento tiene un request_id UUIDv7, una marca de tiempo y una firma nuevos, incluso después de 429/503.
• La solicitud cerrada se serializa una sola vez con JSON.stringify; los reintentos usan exactamente los mismos bytes y el mismo token, incluido null.
• Los idempotency_key/external_event_id lógicos son únicos, se conservan y nunca se regeneran después de un resultado incierto.
• Un 410 assessment-result-expired definitivo detiene la conciliación y nunca crea una operación histórica de reemplazo.
• Content-Type, ruta y encabezados exactos; sin Content-Encoding, Expect, selector de tenant/cliente ni alias de nonce.
• La identidad/hora del evento confiables provienen del backend; las referencias son seudónimos con clave opacos y estables, sin datos personales, account_ref siempre viaja con el mismo subject_ref, y la clave HMAC y el prefijo nunca cambian sin aviso (referencias de persona y de cuenta).
• Las integraciones nuevas envían la solicitud v1.1, aceptada en producción, con una etiqueta por punto de llamada; una integración que se queda en v1 usa solo LOGIN, WITHDRAWAL y TRADE, sin cambios.
• Las etiquetas no contienen datos personales y contienen como máximo diez dígitos; un reintento repite la misma etiqueta.
• La ubicación del inicio de sesión sigue a la autenticación de servidor completada/el MFA requerido; en v1, el registro/la recuperación no inventan recorridos.
• La respuesta/el Problem se valida contra el contrato descargado del perfil enviado; se comprueban el evento esperado y la etiqueta (v1.1) o el recorrido (v1).
• Una puntuación nula se trata como ausencia de puntuación; se conservan la recomendación, la base y las versiones efectivas devueltas.
• Su sistema ejecuta su propia decisión/contingencia; el SHADOW inicial no bloquea usuarios automáticamente.
• La rotación puede mantener dos credenciales, cambiar a la nueva y retirar la anterior dentro del solapamiento aprobado.
• La rotación ordinaria conserva los permisos/la tasa vigentes y nunca supera un solapamiento de 24 horas; cambiar los permisos requiere una configuración revisada aparte.
• Las correlaciones de soporte se conservan sin tokens, cookies, datos personales ni payloads completos en los logs.
• El origen del backend está configurado como https://api.fingertrackid.com, exactamente como está escrito.
• Cada inicio de sesión completado se evalúa, incluso con event_context_token: null y en los inicios de sesión sociales/OAuth (guía de integración).
• Los fallos de integración nunca bloquean el inicio de sesión, y los errores de configuración (authentication-failed, forbidden, validation-failed, codificación de secreto inválida) producen un log de error claro o una alerta.
• Un 409 binding-conflict registra un error y genera una alerta, y el inicio de sesión continúa.
• La integración está detrás de su propio feature flag, habilitado primero para cuentas internas.

Navegador

• La versión exacta y aprobada del SDK privado se descargó en la consola, y su SHA-256/SHA-512 se cotejó con la consola antes de la instalación.
• Una sola copia del SDK, inicializada solo en código del navegador para el ciclo de vida actual del documento/la cuenta.
• El origen de captura activo exacto está en connect-src de la CSP; ninguna URL de script supuesta ni colector de respaldo.
• Ninguna instrumentación de la página (Sentry, Datadog, OpenTelemetry u otro wrapper de fetch) añade encabezados a las solicitudes al origen de captura; sus solicitudes OPTIONS piden solo los encabezados propios del SDK y reciben 204 (encabezados de rastreo).
• Los dos CNAME emitidos siguen siendo solo DNS y el TXT de titularidad conserva su valor emitido; si la verificación caducó, Verificar agora la renovó.
• La página usa createActionContextHelper (receta): prefetch() en la primera intención sobre el formulario de la acción evaluada (focusin/pointerdown, nunca al cargar la página) después del consentimiento aplicable, un take() por acción, y ningún valor de formulario/contraseña/código de recuperación llega al SDK; minRemainingMs se mantiene por encima del margen de su backend (ciclo de vida).
• Un inicio de sesión que redirige a Google o a otro proveedor OAuth captura antes de la redirección o en una página posterior al callback (inicio de sesión con redirecciones); el backend registra cuando un inicio de sesión llega sin token, y por qué.
• Cada página que captura está en uno de esos orígenes permitidos; cualquier otro origen recibe TRANSPORT_ERROR. La continuidad del dispositivo es por origen: el mismo navegador en www y en el apex cuenta como dos instalaciones.
• El navegador envía el token con su expiresAt; el backend envía null cuando queda demasiado poco tiempo y, ante 400 event-context-invalid, evalúa una vez más como una operación nueva con null.
• Al enviar, la página espera el contexto con take(), que se resuelve dentro de su tope waitMs y nunca aborta el SDK; un formulario clásico retiene su navegación hasta entonces, y una aplicación de una sola página mantiene el SDK fuera de los componentes que se desmontan al enviar.
• El SDK se prepara solo en páginas con una acción evaluada, y close() sigue a la respuesta de negocio del backend, de modo que las sesiones sin cerrar no ocupan el límite de 1000 sesiones.
• El SDK instalado es la versión que ofrece la consola (0.3.0 o posterior para el helper), y la captura de su aplicación está configurada para esa versión; con 0.1.1, una captura nueva usa un cliente nuevo, y el anterior se cierra solo cuando no queda pendiente ningún token suyo (SDK 0.1.1).
• Su política de privacidad describe la captura (datos recopilados y tratamiento), validada por su DPO.
• Un handle/contexto conservado por cada acción evaluada nueva; los reintentos mantienen el resultado capturado, incluido null.
• Los fallos de inicialización, de captura, de contexto síncrono y de red dejan la autenticación normal en funcionamiento.
• El cliente sigue activo durante el primer intento acotado de evaluación; un desmontaje pendiente de la página no amplía la validez del token.
• El cierre de sesión/cambio de cuenta llama a close() y descarta los handles sin retrasar el cierre de sesión normal.

Feedback y verificación

• Las capacidades de feedback solicitadas están realmente activas antes de las llamadas de acción/resultado.
• El feedback firma la ruta/el ID exactos de la evaluación y valida su propio contrato de solicitud/comprobante/Problem.
• La acción informada refleja lo que su producto hizo realmente; un bloqueo/una puntuación no es la verdad sobre el fraude.
• El análisis en modo shadow registra los ID de evaluación, las recomendaciones y sus propias decisiones, y conserva la alineación de los comprobantes de feedback.
• La corrección de un resultado hace referencia a la hoja actual y añade un hecho sin reescribir el historial.
• En la consola, Acessos y Integração e saúde reflejan el alcance previsto; los resultados no disponibles, truncados o vencidos siguen siendo explícitos.
• Con account_ref enviado, el primer inicio de sesión de una cuenta con una captura del navegador completada muestra Primeira vez: ainda sem histórico en Contexto do acesso (sin ella, Sem coleta concluída do navegador), y un inicio de sesión posterior de esa cuenta con contexto del navegador, dentro de los 90 días siguientes a un inicio de sesión anterior que también tuvo una captura del navegador con una instalación del navegador vinculada, muestra Dispositivo novo para esta conta evaluado (Sim o Não) en lugar de Conta não informada pelo sistema da empresa; ningún 409 binding-conflict aparece en sus logs.
• La membresía revocada, el origen/la clave cruzados y el estado de solicitud desconocido se han probado con entradas sintéticas.
• Una solicitud pendiente se puede cancelar con Cancelar a solicitação pendente; los artefactos existentes se mantienen y un resultado incierto se comprueba con Recarregar o estado en la misma solicitud.
• Uso se interpreta como estimaciones y las exportaciones como datos acotados/enmascarados/con caducidad, no como facturas ni captura en bruto.