Visión General

¡Bienvenido a la documentación de las API REST de la plataforma Unico IDCloud! En esta página, encontrarás todo lo que necesitas saber para mejorar la seguridad y la calidad de tus aplicaciones utilizando nuestra API REST.

Leer más

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Después de crear y configurar una cuenta de servicio, tu aplicación debe completar las siguientes etapas:

1. Crear un JSON Web Token (JWT), que incluye el encabezado, el payload y la firma.

2. Solicitar un token de acceso (AccessToken) a la plataforma de autenticación OAuth2.

3. Procesar la respuesta JSON que la plataforma de autenticación devolverá.

Si en la respuesta está incluido un token de acceso, podrás utilizarlo para hacer solicitudes a las APIs de los productos de Unico a los que la cuenta de servicio tenga permisos de acceso. (Si en la respuesta no se incluye un token de acceso, tu JWT y la solicitud para obtener el token pueden estar incorrectos o la cuenta de servicio puede no tener los permisos necesarios para acceder a los recursos solicitados).

El token de acceso generado en la solicitud mencionada anteriormente tiene una validez predeterminada de 3600 segundos, aunque puede variar según la configuración de seguridad establecida para tu empresa. Cuando el token de acceso expire, tu aplicación deberá generar un nuevo JWT, firmarlo y solicitar un nuevo token de acceso a la plataforma de autenticación.

1 - Creando el JWT

Un JWT está compuesto por tres partes: un encabezado, un payload y una firma. El encabezado y el payload son objetos JSON. Estos objetos JSON se serializan en UTF-8 y luego se codifican utilizando codificación Base64url¹. Esta codificación proporciona resistencia contra alteraciones de codificación en casos de operaciones repetidas de codificación. El encabezado, el payload y la firma se concatenan con un carácter de punto final (".").

Un JWT se compone de la siguiente forma:

{Encabezado en Base64url}.{Payload en Base64url}.{Firma en Base64url}

El texto base para la firma se compone de la siguiente manera:

{Encabezado en Base64url}.{Payload en Base64url}

1.1 - Formando el encabezado JWT

El encabezado consiste en dos campos que indican el algoritmo de firma y el formato del token. Ambos campos son obligatorios y cada campo tiene solo un valor. Las cuentas de servicio dependen del algoritmo RSA SHA-256 y del formato de token JWT. Como resultado, la representación JSON del encabezado es la siguiente:

{"alg":"RS256","typ":"JWT"}

La representación en Base64url es la siguiente:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

1.2 - Formando el payload JWT

El payload JWT contiene información sobre el JWT, incluyendo los permisos solicitados (alcances), la cuenta que solicita el acceso, el emisor, el momento en que se emitió el token y el tiempo de vida del token. La mayoría de los campos son obligatorios. Al igual que el encabezado JWT, el payload es un objeto JSON y se utiliza en la composición de la firma.

1.3 - Campos Obligatorios

Los campos obligatorios en el JWT se muestran en la siguiente tabla. Pueden aparecer en cualquier orden dentro del payload.

Entienda cómo funciona la conversión de los campos de emisión (iat) y expiración (exp) del JWT, y vea también ejemplos de uso de los valores de los campos aquí. Además, el campo "iat" debe ser la hora actual en el formato requerido y el "exp" debe seguir la fórmula a continuación:

exp = iat + 3600

La representación de los campos JSON obligatorios en el payload del JWT se muestra de la siguiente manera:

{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, // Este es solo un ejemplo. Utilice el valor generado actualmente.
  "iat": 1626293376 // Este es solo un ejemplo. Utilice el valor generado actualmente.
}

1.4 - Calculando la firma

La especificación JSON Web Signature (JWS)² es la mecánica que guía el cálculo de la firma para un JWT. El contenido de entrada para el cálculo de la firma es el array de bytes del siguiente contenido:

{Encabezado en Base64url}.{Payload en Base64url}

El mismo algoritmo indicado en el encabezado del JWT debe ser utilizado para el cálculo de la firma. El único algoritmo de firma soportado por la plataforma de autenticación OAuth2 es RSA utilizando SHA-256. Este se expresa como RS256 en el campo alg del encabezado del JWT.

Firme la representación UTF-8 del contenido de entrada utilizando SHA256withRSA (también conocido como RSASSA-PKCS1-V1_5-SIGN con el hash SHA-256) con la clave privada que fue creada y asociada con la cuenta de servicio (archivo .key.pem generado por la solicitud recibida por correo electrónico). El contenido de salida será un array de bytes.

La firma debe ser luego codificada en Base64url. El encabezado, el payload y la firma deben ser concatenados con el carácter de punto final. El resultado es el JWT. Debe ser de la siguiente forma:

{Encabezado en Base64url}.{Payload en Base64url}.{Firma en Base64url}

A continuación se muestra un ejemplo del token JWT antes de la codificación en Base64url:

{"alg":"RS256","typ":"JWT"}.
{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, // Este es solo un ejemplo. Utilice el valor generado actualmente.
  "iat": 1626293376 // Este es solo un ejemplo. Utilice el valor generado actualmente.
}.
[byte array de la firma]

A continuación se muestra un ejemplo del JWT que ha sido firmado y está listo para la transmisión:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY291bnRf
bmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb
3BlIjoiKiIsImV4cCI6MTYyNjI5Njk3NiwiaWF0IjoxNjI2MjkzMzc2fQ.JsymP3NZdgCSqeNlgsOM2
-AQ7M450NxFnZnnaKSu4Q8g12QGEIvvM4EhCokUHfwk5s7pOpm2UD_Ng3Hb5g_wgrjfiVSLWH5Q2wYg1AvfLqo
YSoJWaMHm9KL0kpv32XdDD8TZVR-MVd2VBHmCMVbV6gvk8buUoK1HZDN7g84PaY3bfgcB3RKU-
H55lR8yyJjZxToIv17-wfla2G99uaMEFNGX0ZSE7ETn5Z8-WypmFrNAK0TM58upzvfVI6_-
gY4cj4iQvmRbuvxsAaGiHA2xd0RVm2Mrx-gQtdPqtbZPuQcH7k64Z_EOQBgiGTgVjucyHD6zBijr_P-
2mhIxuecNSw

También es posible utilizar bibliotecas previamente establecidas para realizar la creación del JWT. Como referencia, es posible encontrar una lista de bibliotecas en el sitio jwt.io.

2 - Haciendo la solicitud de un token de acceso

Después de la generación del JWT firmado, una aplicación puede utilizarlo para solicitar un token de acceso (Access Token). La solicitud del token de acceso es una solicitud POST HTTPS y el cuerpo debe ser URL encoded. La URL es la mostrada a continuación:

https://identityhomolog.acesso.io/oauth2/token

Los parámetros a continuación son obligatorios en la solicitud POST HTTPS:

POST /oauth2/token HTTP/1.1
Host: identityhomolog.acesso.io
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-
bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY
291bnRfbmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsInN1YiI6InVzZXJfaWRlbnRpZmllciIs
ImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb3BlIjoiKiIsImV4cCI
6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.TjH-mTtwP6tBB93O1sDPaAA6yUF7N2-HZDlpIPz
bf_dxO8A6KZuRWG8ZnICrxX56qj0HREiMlYy27XJgxowrUa0JHvbqc8HJkT7-6Mh7J67UnubZKG1-hi
6jDtkC9BIXBcOhtkNUfZvZetXjLzsRsSDkqxdMtzYZwkRlocvaxL5QXiQhweeEwK_Ux81Adh3z0EIhT
yl7CKJLJ69PuHS7s9IdrjUl79owipp4LF1FvtMhoe7YIL69ohPgFqSv_-Y9qpPdW6be3OEAyKlOM08S
ZBbHBwW4XMvw3uZjTY1sgJ4cBoxrftDpjYOw34oPOKxirqc5-90uOCYe1O1hRtG45w

3 - Tratando la respuesta de la plataforma de autenticación

Si el JWT y la solicitud del token de acceso fueron formados adecuadamente y la cuenta de servicio tiene los permisos necesarios, la respuesta de la plataforma de autenticación devuelve un objeto JSON que contiene un token de acceso. A continuación se muestra un ejemplo de respuesta de la plataforma:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": "3600"
}

El token de acceso devuelto en el campo “access_token” del objeto JSON también es un token JWT que debe ser utilizado en las APIs de los productos de unico. Si se devuelve un error en la solicitud, es posible consultar el tipo de error en la tabla de errores haciendo clic aquí.

4 - Duración del token de acceso

La duración del token de acceso es variable. Su duración es especificada en el campo “expires_in”, devuelto junto con el token de acceso. Se debe utilizar el mismo token de acceso durante su validez para todas las llamadas a las APIs de los productos.

No solicite un nuevo token de acceso hasta que la validez del token actual esté llegando a su fin. Sugerimos un margen de 600 segundos (10 minutos). Para ello, ejecute el cálculo: token decodificado:

token decodificado:
new Date(token.exp - 600)

Siendo que token.exp es el timestamp de expiración del token.

Ejemplos:

Escenario estándar:
expires_in: 3600 (1h) - Generación del token a las 14:42

Solicitar un nuevo token solo a las 15:32, es decir, 14:42 + (3600 - 600)

Escenario con duración alterada:
expires_in: 7200 (2h) - Generación del token a las 14:42

Solicitar un nuevo token solo a las 16:32, es decir, 14:42 + (7200 - 600)

Un nuevo token de acceso puede ser solicitado cuando queden 10 minutos para su expiración.

• ¹ De acuerdo con la RFC 4648 de codificación BaseN, el formato Base64url es similar al formato Base64, con la excepción de que el carácter = debe ser omitido, y los caracteres + y / deben ser reemplazados por - y _, respectivamente.

• ² JSON Web Signature: https://tools.ietf.org/html/rfc7515.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Para utilizar la plataforma IDCloud es necesario autenticarte mediante un token de acceso, utilizando el sistema de autenticación conocido como OAuth2.

El sistema de autenticación OAuth2 de Unico soporta la interacción server-to-server entre una aplicación web y los servicios de Unico.

Para este escenario, necesitarás una cuenta de servicio, que es una cuenta impersonal que pertenece a tu aplicación y no a un usuario individual. Tu aplicación llama las APIs de Unico en nombre de la cuenta de servicio, por lo que los usuarios no están directamente involucrados. Este escenario se denomina "two-legged OAuth", o "2LO". Típicamente, una aplicación utiliza una cuenta de servicio cuando llama a las APIs de Unico para trabajar con sus propios datos en lugar de los datos del usuario.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

A continuación, verás detalladamente cómo funciona cada capacidad:

Prueba de vida

Cuando es necesario identificar si la persona es real y está viva en el momento de la operación. Puede utilizarse de forma aislada o en conjunto con las capacidades de Verificación de Identidad, Alerta de comportamiento, Score de riesgo y Validación (1:1). Debe ser siempre utilizada junto con los SDKs.

Las posibilidades de respuesta son:

• SÍ: indica que el usuario está vivo en el momento de la captura de la selfie;

• NO: indica que el usuario no está vivo en el momento de la captura de la selfie.

Verificación de Identidad

Cuando es necesario garantizar que el usuario que está realizando el proceso es quien dice ser. Por defecto, siempre se utiliza en conjunto con la capacidad de Prueba de vida.

Las posibilidades de respuesta son:

• SÍ: indica que la cara es la del verdadero titular del CURP;

• NO: indica que la cara no es la del verdadero titular del CURP;

• INCONCLUSO: indica que no tenemos suficientes pruebas para garantizar si la cara es o no la del verdadero titular del CURP.

Alerta de Comportamiento

El Alerta de Comportamiento complementa la respuesta de Verificación de Identidad, aportando el componente de comportamiento que asegura un riesgo relacionado con esa identidad, debido a un comportamiento fraudulento previo. Solo puede ser utilizado en conjunto con la capacidad de Verificación de Identidad.

Las posibilidades de respuesta son:

• SÍ: indica que la cara ya estuvo involucrada en transacciones fraudulentas de identidad;

• SOSPECHOSO: indica que la cara ya ha tenido al menos una coincidencia en nuestra base con otro identificador;

• INCONCLUSO: indica que no tenemos suficientes indicios para confirmar si la cara está involucrada en transacciones fraudulentas en nuestra base.

Validación (1:1)

Cuando es necesario reconocer si la persona en la operación es la misma que realizó el registro. Por defecto, siempre se utiliza en conjunto con la capacidad de Prueba de vida. Solo puede ser utilizado en casos donde ya se haya realizado un proceso de Verificación de Identidad.

Las posibilidades de respuesta son:

• SÍ: indica que la cara que está realizando la transacción es la misma que realizó el proceso utilizado como referencia;

• NO: indica que la cara que está realizando la transacción no es la misma que realizó el proceso utilizado como referencia.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Para utilizar interacciones server-to-server, es necesario solicitar la creación de la cuenta de servicio al gerente de proyectos responsable de tu empresa enviando los siguientes datos: nombre de la empresa, nombre de la aplicación, nombre, correo electrónico y teléfono móvil del responsable de la aplicación en la empresa. Es necesario crear cuentas diferentes para los entornos de Homologación y Producción.

Tras recibir estos datos, se creará una cuenta de servicio responsable de autenticar tu aplicación y te enviaremos un correo electrónico para que se genere el par de claves para la cuenta.

Una credencial de cuenta de servicio incluye un nombre único de cuenta, un identificador de la empresa (Tenant ID) y al menos un par de claves (pública y privada). Al final de la generación de las claves, solo recibirás la clave privada (archivo .key.pem), así como el payload que debe utilizarse para generar el JWT. Este payload tendrá el siguiente formato:

Si necesitas la clave pública para configurar en tu sistema, contacta al gerente de proyectos responsable de tu cuenta. También es posible generar una clave pública mediante el siguiente comando openssl:

openssl req -x509 -new -nodes -sha256 -days 720 \
-key fileName.key.pem -out fileName.cert.pem

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Visión general de la integración

¿Dudas?

¿Dudas?

Los errores devueltos en la solicitud pueden ser identificados a través de los códigos a continuación y tienen la siguiente estructura:

¿Dudas?

¿Qué es la plataforma Unico IDCloud?

IDCloud es la única plataforma de verificación de identidad que combina seguridad con precisión garantizada. Con ella, es posible validar la identidad de los usuarios de manera simple e intuitiva, utilizando solo una selfie, garantizando fluidez y protección en tus procesos de verificación.

La plataforma es versátil y se puede adaptar a diferentes casos de uso, permitiéndote ajustarla según las necesidades de tu escenario. Para ello, ofrecemos diversas capacidades: funcionalidades de nuestra plataforma que atienden a una amplia gama de operaciones y demandas. Para saber más sobre nuestras capacidades, accede a la siguiente página:

¿Dudas?

Las APIs de la plataforma Unico IDCloud ofrecen total libertad para que el cliente utilice las soluciones de validación de identidad de la plataforma de la manera que prefiera.

Su objetivo es proporcionar una variedad de posibilidades en el uso de las capacidades de la plataforma IDCloud, ofreciendo una solución que puede integrarse con tu back-end y brindar libertad a los clientes que deseen controlar la experiencia de los usuarios con un front-end propio (para ello, consulta el Estándar de Captura) o a través de nuestros SDKs.

Las APIs de Unico IDCloud permiten que los clientes se integren de la manera que prefieran, combinando o no las capacidades según sus necesidades. Este medio de integración proporciona los recursos necesarios para realizar la validación de Prueba de Vida, Verificación de Identidad, Alerta de Comportamiento y Validación (1:1).

Puedes combinar las capacidades como desees, incluso en los casos de uso más diversos. Sin embargo, para ello, debes contar con API Keys configuradas con las capacidades que deseas utilizar.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Descargue el archivo a continuación, impórtelo en Postman y sustituya los valores de los parámetros "service_account", "tenant_id" y "secret_key" para probar la llamada.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Introdución

La plataforma IDCloud utiliza códigos de respuesta HTTP convencionales para indicar el éxito o fracaso de una solicitud de API.

Como regla general:

• Los códigos en el rango 2xx indican éxito en la solicitud;

• Los códigos en el rango 4xx indican parámetros incorrectos o incompletos (por ejemplo, un parámetro obligatorio fue omitido o una operación falló con terceros, etc.);

• Los códigos en el rango 5xx indican que hubo un error en los servidores de la plataforma Unico IDCloud.

La plataforma Unico IDCloud también genera un mensaje de error y un código de error formateado en JSON:

{
    "error": {
        "code": "0000",
        "description": "error description"
    }
}

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Es esencial que todos los clientes mantengan una rutina de actualización del SDK, ya que constantemente se desarrollan nuevas formas de ataque. La mejor manera de proteger su negocio contra nuevos tipos de fraudes de Inyección y Liveness es utilizar la versión más actualizada del SDK de Unico.

Es responsabilidad del cliente mantener una rutina adecuada de actualización del SDK, asegurando la versión mínima necesaria para el buen funcionamiento de nuestras soluciones en sus operaciones. Así como es responsabilidad de Unico ofrecer versiones actualizadas en relación con las amenazas que surgen en el mercado y mantener informados a nuestros clientes sobre el tema. Con esto en mente, Unico ha creado una Política de actualización del SDK.

¿Por qué tenemos una política de actualizaciones del SDK?

Con el SDK desactualizado, nuestros clientes están vulnerables a ataques de fraudes. Considerando que Unico prioriza la máxima seguridad de sus clientes, además de la urgencia del tema y la necesidad de un proceso ágil de actualizaciones, se creó la política de actualización del SDK para salvaguardar a nuestros clientes de los fraudes más nuevos que aparecen constantemente en el mercado. La única forma de estar seguro es estar actualizado.

Categorías de Actualizaciones

Unico categoriza todas las actualizaciones del SDK entre Críticas y No Críticas, basadas en la criticidad de los fraudes que bloqueamos con la nueva versión.

• Actualizaciones Críticas: Son actualizaciones que buscan proteger a nuestros clientes contra fraudes y ataques recientes en el mercado. Deben ser implementadas en un plazo de 5 (cinco) días corridos, debido a la amenaza real a la que está expuesta la operación. A partir de este plazo, no brindaremos más soporte a versiones anteriores. En la práctica, el cliente que se comunique con nosotros con una versión anterior a la última deberá obligatoriamente actualizar el SDK para que podamos atenderlo.

• Actualizaciones No Críticas: Son actualizaciones más simples, de mejora tecnológica. Pueden ser implementadas en un plazo de hasta 60 (sesenta) días corridos. Vale la pena enfatizar que, cuanto más actual sea la versión, más posibilidades de evitar errores y fallos. Por eso, recomendamos que se realice la actualización lo más rápido posible. Después de este período, no brindaremos más soporte técnico y el cliente deberá actualizar su SDK para que podamos actuar en los casos.

Identificamos las actualizaciones críticas en las Release Notes con una etiqueta justo debajo de la versión, como se muestra en el siguiente ejemplo:

Estos plazos aplican para todos los clientes de Unico, independientemente de la capacidad utilizada.

¿Cómo actualizar?​

Puedes seguir el proceso estándar de actualización o instalación según la versión que estés utilizando: Web, iOS, Android y Flutter.

¿Puede haber ruptura de contrato de API debido a esta política?

Las rupturas de contrato de API están restringidas únicamente a las versiones de releases Major (consulta más sobre versionado semántico aquí). Esto significa que cambios significativos en el contrato de la API solo pueden ocurrir con grandes cambios en el SDK, y no en revisiones menores. Nuestra práctica es evitar al máximo cualquier ruptura en una versión Major, ya que impacta en grandes cambios en la integración con el cliente, lo cual no es nuestro objetivo. Solo lo haremos en casos de extrema necesidad y siempre con el objetivo de garantizar la seguridad en todas las operaciones.

¿Dónde puedo ver las novedades de las versiones?

Cada una de las versiones tiene sus propios release notes según los enlaces a continuación, presentando nuevas funcionalidades o correcciones de errores / bloqueos de fraudes: Android, iOS, Flutter y Web.

¿Cómo sé cuándo se lanza una nueva versión?

Cada vez que haya una nueva versión del SDK, el sitio https://unicoidtech.gitbook.io/idcloud/integracao/sdk será actualizado. Si eres cliente de Unico, recibirás un correo electrónico con las actualizaciones e información sobre los cambios. Si no estás recibiendo estos correos, contacta a tu CSM.

• Para actualizaciones críticas: Enviaremos un correo electrónico tan pronto como la nueva versión esté disponible, con un refuerzo por parte del equipo de Customer Success, informando sobre la urgencia del tema y el plazo de 5 (cinco) días corridos para la actualización.

• Para actualizaciones no críticas: Para evitar la sobrecarga de los equipos de los clientes, enviaremos un correo electrónico mensual con un resumen de las actualizaciones no críticas. Informaremos los principales puntos de cambio y el plazo de 60 (sesenta) días corridos para la actualización.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Introducción

En esta sección, encontrarás la documentación detallada sobre el funcionamiento del endpoint para crear un proceso en la plataforma Unico IDCloud.

Se trata de un servicio con retorno síncrono, es decir, toda la integración ocurre utilizando un único endpoint y la respuesta se devolverá en el response de este mismo endpoint.

Las capacidades de la plataforma Unico IDCloud se gestionan a través de API Keys, utilizadas como un parámetro en el header de las solicitudes, que definen el alcance de acceso.

Como requisito previo, es necesario contar con una API Key configurada con las capacidades que utilizarás.

Antes de comenzar

Tus solicitudes a la API se autentican mediante un access-token. Cualquier solicitud que no incluya un access-token válido retornará un error.

Puedes ver más información sobre cómo generar un access-token aquí.

Creación de proceso

POST/processes/v1

Endpoint para crear un nuevo proceso

Headers

Request Body Schema

{
    "subject": {
        "code": "HLEK990624MYNHOF25",
        "name": "",
        "email": "",
        "phone": ""
    },
    "useCase": "Apertura de cuenta",
    "imageBase64":"/9j/[...]"
}

Response

{
  "id": "80371b2a-3ac7-432e-866d-57fe37896ac6",
  "status": 3,
  "idCloud": {
    "result": "yes",
    "details": "identity: isDocumentOwner: yes, isConsistent: yes; behavior: isTrustworthy: yes"
  }
}

Response parameters

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Este guía fue elaborada para ayudarlo a implementar el SDK Android de manera rápida y sencilla. A continuación, vea el paso a paso de todo el proceso de integración. Después de eso, si desea personalizar la experiencia, no deje de ver la sección Personalización Android.

Inicializar el SDK

Cree una instancia del builder (Generado a través de la interfaz IAcessoBioBuilder), proporcionando como parámetro el contexto y el ambiente en cuestión, y la implementación de la clase AcessoBioListener.

La implementación de esta clase es muy simple y se puede hacer con pocas líneas de código. Lo único que necesita hacer es instanciar el builder proporcionando el contexto correspondiente y sobrescribir los métodos de callback con la lógica de negocio de su aplicación:

public class MainActivity extends AppCompatActivity {

    private AcessoBioListener callback = new AcessoBioListener() {
        @Override
        public void onErrorAcessoBio(ErrorBio errorBio) { }

        @Override
        public void onUserClosedCameraManually() { }

        @Override
        public void onSystemClosedCameraTimeoutSession() { }

        @Override
        public void onSystemChangedTypeCameraTimeoutFaceInference() { }
    };

    private IAcessoBioBuilder acessoBioBuilder = new AcessoBio(this, callback);
}

internal class MainActivity : AppCompatActivity() {

    private val callback = object : AcessoBioListener {
        override fun onErrorAcessoBio(errorBio: ErrorBio?) { }
    
        override fun onUserClosedCameraManually() { }
    
        override fun onSystemClosedCameraTimeoutSession() { }
    
        override fun onSystemChangedTypeCameraTimeoutFaceInference() { }
    }

    private val acessoBioBuilder: IAcessoBioBuilder = AcessoBio(this, callback)
}

Configuración de ambientes

Configure el ambiente que se utilizará en la ejecución del SDK. Utilice el enumerado Environment que contiene los siguientes valores enumerados:

• Environment.PROD: para ambiente de Producción;

• Environment.UAT: para ambiente de Homologación.

Vea cómo implementarlo en el siguiente ejemplo:

acessoBioBuilder.setEnvironment(Environment.UAT);

acessoBioBuilder.setEnvironment(Environment.UAT);

Implementar las funciones de callback

Tenga en cuenta que el trabajo de implementación de la clase AcessoBioListener es, en su mayoría, la configuración de los métodos de callback. Cada método se llama en una situación específica de retorno del SDK.

Basta con sobrescribir los métodos ejemplificados en el paso anterior con la lógica de negocio de su aplicación.

Este método se invoca siempre que ocurra cualquier error de implementación al utilizar alguno de nuestros métodos:

Configurar modo de cámara

El SDK tiene configurado y habilitado por defecto el encuadre inteligente y la captura automática. Por lo tanto, debe configurarse el modo de cámara en su builder de la siguiente manera:

UnicoCheckCamera unicoCheckCamera = acessoBioBuilder
    .setAutoCapture(true)
    .setSmartFrame(true)
    .build();

val unicoCheckCamera: UnicoCheckCamera = acessoBioBuilder
    .setAutoCapture(true)
    .setSmartFrame(true)
    .build()

Implementar listeners para eventos de la cámara

El método de apertura de la cámara, que se llama en la siguiente etapa, necesita saber qué hacer al lograr capturar una imagen con éxito o si ocurre algún error en el proceso. Es necesario especificar "qué hacer" al método de apertura de la cámara mediante la implementación de listeners que se llaman en situaciones de éxito o error.

A través de la configuración de los listeners, puede especificar qué sucede en su App en situaciones de error (Método onErrorSelfie) o éxito (Método onSuccessSelfie) durante la captura de imágenes.

Para la configuración de los listeners, es necesario implementar:

iAcessoBioSelfie cameraListener = new iAcessoBioSelfie() {
    @Override
    public void onSuccessSelfie(ResultCamera result) { }

    @Override
    public void onErrorSelfie(ErrorBio errorBio) { }
};

unicoCheckCamera.prepareCamera(unicoConfig, new CameraListener() {
    @Override
    public void onCameraReady(UnicoCheckCameraOpener.Camera cameraOpener) {
        cameraOpener.open(cameraListener);
    }

    @Override
    public void onCameraFailed(String message) {
        Log.e(TAG, message);
    }
});

val cameraListener: iAcessoBioSelfie = object : iAcessoBioSelfie {
    override fun onSuccessSelfie(result: ResultCamera?) {}

    override fun onErrorSelfie(errorBio: ErrorBio?) {}
}

unicoCheckCamera.prepareCamera(unicoConfig, object : CameraListener {
    override fun onCameraReady(cameraOpener: UnicoCheckCameraOpener.Camera?) {
        cameraOpener?.open(cameraListener)
    }

    override fun onCameraFailed(message: String?) {
        Log.e(TAG, message)
    }
})

Preparar y abrir cámara

Para continuar con la apertura de la cámara, primero es necesario prepararla utilizando el método prepareCamera. Este método recibe como parámetro la implementación de la clase CameraListener, la clase o el JSON con las credenciales, generados en esta etapa.

Cuando la cámara esté preparada, se dispara el evento onCameraReady, que recibe como parámetro un objeto del tipo UnicoCheckCameraOpener.Camera.

Es necesario sobrescribir este método, realizando la apertura de la cámara con el objeto recibido a través del método open(). El método open() debe recibir como parámetro los listeners configurados en los pasos anteriores.

Método onSuccessSelfie

Al realizar una captura de imagen con éxito, este método es invocado y retorna un objeto del tipo ResultCamera, que se utiliza posteriormente en la llamada a las APIs REST:

public void onSuccessSelfie(ResultCamera result) { }

El objeto ResultCamera retorna 2 atributos: base64 y encrypted:

• El atributo base64 puede ser utilizado si se desea mostrar una vista previa de la imagen en su app.

• El atributo encrypted debe ser enviado en la llamada a las APIs REST del IDCloud.

Método onErrorSelfie

Cuando ocurre algún error en la captura de imagen, este método es invocado y retorna un objeto del tipo ErrorBio:

public void onErrorSelfie(ErrorBio errorBio) { }

Realizar una solicitud POST en la API REST

La captura de las imágenes es solo la primera parte del proceso. Después de capturar la imagen, es necesario enviar el encrypted generado por el SDK a las APIs REST. Infórmese más en la sección Creación de proceso.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Objeto ErrorBio​

Este objeto es retornado siempre que ocurre un error en el SDK Android.

Métodos disponibles

A continuación se presenta la lista de posibles códigos de error del SDK Android:

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Ofuscación de código

La ofuscación es un proceso que transforma el bytecode en una forma menos legible por humanos, dificultando así la ingeniería inversa.

Este proceso consiste en eliminar información relacionada con la depuración, como tablas de variables, números de líneas, y renombrar paquetes, clases y métodos.

Al integrar el SDK Android en la aplicación, pueden ocurrir fallos.

Ofuscación a través de DexGuard

Cuando la ofuscación se realiza mediante DexGuard, en caso de fallo, utilice las siguientes reglas:

-keep class kotlin.coroutines.**
-keep class kotlinx.coroutines.**

-keep class com.facetec.sdk.** { *; }
-keep class com.acesso.acessobio_android.** { *; }
-keep class io.unico.** { *; }

-keep class br.com.makrosystems.haven.** { *; }
-keep class HavenSDK.**{ *; }
-keep class HavenSDK** { *; }

Ofuscación a través de ProGuard

Cuando la ofuscación se realiza mediante ProGuard, en caso de fallo, utilice las siguientes reglas:

-keep class kotlin.coroutines.**
-keep class kotlinx.coroutines.**

-keep class com.facetec.sdk.** { *; }
-keep class com.acesso.acessobio_android.** { *; }
-keep class io.unico.** { *; }

-keep class br.com.makrosystems.haven.** { *; }
-keep class HavenSDK.**{ *; }
-keep class HavenSDK** { *; }

Actualización del SDK - versión 4.3.x

A partir de la versión 4.4.x del SDK, Unico comenzó a usar su propio repositorio Maven para distribuir el SDK de Android y cambió el nombre de la dependencia del SDK, además de realizar ajustes en las reglas de ProGuard y DexGuard para los clientes que utilizan la biblioteca de GuardSquare, como se describe en la sección de Ofuscación de código arriba.

Cambia el repositorio Maven:

Cambia el repositorio Maven al nuevo repositorio en el archivo build.gradle del proyecto.

La implementación se hacía de la siguiente manera:

// Top-level build file where you can add configuration options common to all sub-projects/modules.
allprojects {
    repositories {
        google()
        jcenter()
        maven { url 'https://jitpack.io'}
    }
}

Ahora debe actualizarse al nuevo repositorio:

// Top-level build file where you can add configuration options common to all sub-projects/modules.
allprojects {
    repositories {
        google()
        jcenter()
        maven { 
            url "https://maven-sdk.unico.run/sdk-mobile" 
        }
    }
}

Cambiar la dependencia del SDK

Cambia la dependencia del SDK a la nueva dependencia en el archivo app/build.gradle del proyecto.

La implementación se hacía de la siguiente manera:

/* unico */
dependencies {
    implementation 'com.github.acesso-io:acessobio-android:$version'
}

Ahora debe actualizarse a la nueva dependencia:

/* unico */
dependencies {
    implementation "io.unico:capture:$version"
}

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Versión 5.30.1​ - 27/02/2025

• Ajustes de dependencias internas garantizando la compatibilidad con la versión de Kotlin 1.6.0.

Versión 5.30.0​ - 25/02/2025

• Soporte para la cámara trasera en flujos de tiendas físicas;

• Actualización del SDK y servidor de Liveness con interacción;

• Mejoras internas del producto. Estas mejoras no afectan directamente la experiencia del usuario final, manteniendo la interfaz y funcionalidades externas sin cambios.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Esta guía ha sido elaborada para ayudarlo a implementar el SDK iOS de forma rápida y fácil. A continuación, verá el paso a paso de todo el proceso de integración. Después de esto, si desea personalizar la experiencia, no deje de consultar la sección Personalización iOS.

Inicializar el SDK

Para comenzar con el SDK iOS de Unico Check, importe el SDK e implemente la interfaz AcessoBioManagerDelegate dentro del ViewController en el que desea utilizarlo.

La implementación de esta clase es bastante simple y puede realizarse con pocas líneas de código. Solo necesita instanciar el builder proporcionando el contexto y el entorno en cuestión, y sobrescribir los métodos de callback con las lógicas de negocio de su aplicación:

.m:
#import "ViewController.h"
#import <AcessoBio/AcessoBio.h>

@implementation ViewController: UIViewController
- (void)viewDidLoad {
    [super viewDidLoad];  
    unicoCheck = [[AcessoBioManager alloc]initWithViewController:self];
}

- (void)onErrorAcessoBioManager:(ErrorBio *)error {
  // your code
}

- (void)onSystemChangedTypeCameraTimeoutFaceInference {
  // your code
}

- (void)onSystemClosedCameraTimeoutSession {
  // your code
}

- (void)onUserClosedCameraManually {
  // your code
}
@end

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate {
  var unicoCheck: AcessoBioManager!

  override func viewDidLoad() {
    super.viewDidLoad()      
    unicoCheck = AcessoBioManager(viewController: self)
  }

  func onErrorAcessoBioManager(_ error: ErrorBio!) {
      // your code
  }

  func onUserClosedCameraManually() {
      // your code
  }

  func onSystemClosedCameraTimeoutSession() {
      // your code
  }

  func onSystemChangedTypeCameraTimeoutFaceInference() {
      // your code 
  }
}

Configuración de entornos

Configure el entorno que se utilizará durante la ejecución del SDK. Utilice el enumerado Environment que contiene los siguientes valores:

• PROD: para entorno de Producción;

• UAT: para entorno de Homologación.

Vea cómo implementarlo en el siguiente ejemplo:

 [unicoCheck setEnvironment:UAT];

unicoCheck.setEnvironment(.UAT);

Implementar las funciones de callback

Tenga en cuenta que, conforme al ejemplo anterior, el trabajo de implementación de la interfaz AcessoBioManagerDelegate consiste en gran parte en configurar los métodos de callback. Cada método es llamado en una situación específica del retorno del SDK.

Basta con sobrescribir los métodos ejemplificados en el paso anterior con la lógica de negocio de su aplicación:

Configurar el modo de cámara

El SDK tiene configurado y habilitado por defecto el encuadre inteligente y la captura automática. Debido a esto, se debe configurar el modo de cámara en su builder de la siguiente manera:

.m:
- (IBAction)configureSmartCamera:(UIButton *)sender {
   // Objeto unicoCheck da classe AcessoBioManager
   [unicoCheck setSmartFrame:true];
   [unicoCheck setAutoCapture:true];
}

@IBAction func configureSmartCamera(_ sender: Any) {
    // Objeto unicoCheck da classe AcessoBioManager
    unicoCheck.setSmartFrame(true)
    unicoCheck.setAutoCapture(true)    
}

Implementar delegados para eventos de la cámara

El método de apertura de la cámara necesita saber qué hacer al conseguir capturar una imagen con éxito o al tener algún error en el proceso. Se informa "qué hacer" al método de apertura de la cámara a través de la configuración de delegados que son llamados en situaciones de éxito o error.

A través de la configuración de los delegados, puedes especificar qué sucede en tu aplicación en situaciones de error (método onErrorSelfie) o éxito (método onSuccessSelfie) en la captura de imágenes.

Para la configuración de los delegados, debes implementar las interfaces SelfieCameraDelegate y AcessoBioSelfieDelegate:

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate, SelfieCameraDelegate,
   AcessoBioSelfieDelegate> {
  AcessoBioManager *unicoCheck;
  // Your code from previous and next steps here
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate,
                      SelfieCameraDelegate, AcessoBioSelfieDelegate {    
  //Your code from previous and next steps here
}

Método onSuccessSelfie

Al realizar una captura de imagen con éxito, este método es invocado y retorna un objeto del tipo SelfieResult, que se utiliza posteriormente en la llamada a las APIs REST.

- (void)onSuccessSelfie:(SelfieResult *)result {
    NSLog(@"%@", result.base64);
} 

func onSuccessSelfie(_ result: AcessoBio.SelfieResult!) {
    // Your code
 }

El objeto ResultCamera retorna 2 atributos: base64 y encrypted:

• El atributo base64 puede ser utilizado si deseas mostrar una vista previa de la imagen en tu app;

• El atributo encrypted debe ser enviado en la llamada a las APIs REST.

Método onErrorSelfie

Cuando ocurre un error en la captura de la imagen, este método es invocado y retorna un objeto del tipo ErrorBio:

- (void)onErrorSelfie:(ErrorBio *)errorBio {
  // Your code
}

func onErrorSelfie(_ errorBio: ErrorBio!) {
  // Your code
 }

Configurar entornos

Es posible configurar el entorno que se utilizará en la ejecución del SDK. Utiliza el enumerado EnvironmentEnum, que contiene los siguientes valores:

• EnvironmentEnum.PROD: para el entorno de Producción

• EnvironmentEnum.UAT: para el entorno de Homologación

Mira cómo implementarlo en el siguiente ejemplo:

[unicoCheck setEnvironment:PROD];

unicoCheck.setEnvironment(.PROD);

Preparar y abrir la cámara

Para continuar con la apertura de la cámara, primero debes prepararla utilizando el método prepareSelfieCamera. Este método recibe como parámetro la implementación de la clase SelfieCameraDelegate y el JSON con las credenciales, generado en la etapa anterior.

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate,
SelfieCameraDelegate, AcessoBioSelfieDelegate> {
    AcessoBioManager *unicoCheck;
}

.m:
- (IBAction)openCamera:(UIButton *)sender {
    [[unicoCheck build] prepareSelfieCamera:self config:[YourUnicoConfigClass new]];
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate,
  SelfieCameraDelegate, AcessoBioSelfieDelegate {
    @IBAction func openCamera(_ sender: Any) {
        unicoCheck.build().prepareSelfieCamera(self, config: YourUnicoConfigClass())
    }
}

Cuando la cámara esté preparada, el evento onCameraReady se dispara y recibe como parámetro un objeto del tipo AcessoBioCameraOpenerDelegate.

Debes sobrescribir este método, realizando la apertura de la cámara con el objeto recibido a través del método open():

- (void)onCameraReady:(id)cameraOpener {
    [cameraOpener open:self];
}

- (void)onCameraFailed:(ErrorPrepare *)message {
    // Your code
}

func onCameraReady(_ cameraOpener: AcessoBioCameraOpenerDelegate!) {
    cameraOpener.open(self)
 }
 
func onCameraFailed(_ message: ErrorPrepare!) {
    // Your code
 }

Si ocurre algún error al preparar la cámara, el evento onCameraFailed se dispara. Debes implementar este método aplicando las reglas de negocio de tu aplicación.

Realizar una solicitud POST en la API REST del by Client

La captura de las imágenes es solo la primera parte del proceso. Después de capturar la imagen, es necesario enviar el encrypted generado por el SDK a las APIs REST del by Client. Infórmate más en la sección Creación de proceso.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Introducción

Los SDK de la plataforma Unico IDCloud tienen como objetivo potenciar la seguridad de su negocio y de sus clientes, permitiendo incluso personalizar la experiencia de uso aplicando la identidad visual de su marca. Los SDK abstraen la complejidad de manipulación de la cámara del dispositivo de los usuarios y la captura de imágenes (Selfie y documento), facilitando la vida del desarrollador y reduciendo el tiempo de entrega del producto final. Otras ventajas:

• Prueba de vida: Los SDK se utilizan junto con la capacidad de Prueba de vida para garantizar que el usuario esté en vivo en el momento de la captura de la selfie.

• Precisión en la captura de imágenes: Los SDK cuentan con recursos que ayudan al usuario a obtener fotos biométricamente válidas, reduciendo el abandono de imágenes cuando se comparan con la captura realizada por las cámaras estándar de los dispositivos. Se agregan SmartFrames, “elementos clave” que se ajustan automáticamente a la silueta y proporción de la pantalla del usuario, permitiendo una mejor captura de la imagen.

• Seguridad reforzada: Recursos de cifrado y seguridad contra la inyección de imágenes, también con funcionalidades que previenen fraudes adaptadas a diferentes modos de cámara. Capas de seguridad que funcionan de forma complementaria, tanto a nivel de la aplicación como en relación a los datos que se transmiten entre los SDK y el backend. El SDK también incluye ofuscación de código, bloqueo de emuladores y verificación del paquete de la aplicación que lo está ejecutando.

La captura de las imágenes mediante los SDK es solo la primera parte de su viaje. Por lo tanto, es de extrema importancia que comprenda los conceptos básicos y el funcionamiento de las APIs del motor biométrico. Para más información, consulte la API REST IDCloud.

Diagrama de Funcionamiento

El SDK (Client-side) es responsable de simplificar su integración con la plataforma Unico IDCloud, absorbiendo toda la complejidad de la manipulación de la cámara y la captura de imágenes.

Si la captura se realiza con éxito, el SDK devuelve un objeto que debe ser enviado a la API del motor biométrico, completando así la validación biométrica, según el diagrama ejemplificado a continuación:

Requisitos soportados por cada Client SDK

A continuación, se presentan la información y los requisitos necesarios, oficialmente soportados por cada Client SDK de Unico:

Versionado de los SDKs

Los SDKs de la plataforma Unico IDCloud siguen un versionado semántico, por lo que la numeración de la versión es "MAJOR.MINOR.PATCH", descrita de la siguiente manera:

• Versión Mayor (MAJOR): Cuando se realizan cambios incompatibles en la API;

• Versión Menor (MINOR): Cuando se agregan funcionalidades manteniendo la compatibilidad;

• Versión de Corrección (PATCH): Cuando se corrigen fallas manteniendo la compatibilidad.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Requisitos previos del entorno de desarrollo

Es necesario que su entorno de desarrollo cumpla con los siguientes requisitos previos:

Dispositivos compatibles

El SDK Android es compatible con la gran mayoría de dispositivos que tengan Android 5.0 (API de nivel 21) o versiones superiores.

La siguiente tabla lista los dispositivos probados en laboratorio, además de la disponibilidad de las extensiones del proveedor/fabricante. Algunas extensiones listadas pueden estar sujetas a APIs o SKUs específicos del fabricante. Haga clic a continuación para ver los dispositivos probados:

Instalando el SDK Android

Para implementar el SDK Android de la plataforma Unico IDCloud en su aplicación Android, siga los pasos listados a continuación:

// Top-level build file where you can add configuration options common to all sub-projects/modules.
allprojects 
{
    repositories {
        google()
        maven { 
            url "https://maven-sdk.unico.run/sdk-mobile" 
        }
    }
}

# Project-wide Gradle settings.
# https://developer.android.com/topic/libraries/support-library/androidx-rn
android.useAndroidX=true
# Automatically convert third-party libraries to use AndroidX
android.enableJetifier=true

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.INTERNET" />

/* unico */
implementation 'io.unico:capture:$version'

android { 
    compileOptions { 
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8 
      } 
}

package <package_name>

import com.acesso.acessobio_android.onboarding.AcessoBioConfigDataSource;

public class UnicoConfig implements AcessoBioConfigDataSource {
    @Override
    public String getBundleIdentifier() {
        return BUNDLE_IDENTIFIER;
    }
        
    @Override
    public String getHostKey() {
        return SDK_KEY;
    }
}

import com.acesso.acessobio_android.onboarding.AcessoBioConfigDataSource

class UnicoConfig : AcessoBioConfigDataSource {
    override fun getBundleIdentifier(): String {
        return BUNDLE_IDENTIFIER
    }

    override fun getHostKey(): String {
        return SDK_KEY
    }
}

package <package_name>

import com.acesso.acessobio_android.onboarding.AcessoBioConfigDataSource;

public class UnicoConfig implements AcessoBioConfigDataSource {
    @Override
    public String getProjectNumber() {
        return PROJECT_NUMBER;
    }
    
    @Override
    public String getProjectId() {
        return PROJECT_ID;
    }
    
    @Override
    public String getMobileSdkAppId() {
        return MOBILE_SDK_APP_ID;
    }
    
    @Override
    public String getBundleIdentifier() {
        return BUNDLE_IDENTIFIER;
    }
    
    @Override
    public String getHostInfo() {
        return HOST_INFO;
    }
    
    @Override
    public String getHostKey() {
        return HOST_KEY;
    }
}

package <package_name>

import com.acesso.acessobio_android.onboarding.AcessoBioConfigDataSource

class UnicoConfig : AcessoBioConfigDataSource {
    override fun getProjectNumber(): String {
        return PROJECT_NUMBER
    }

    override fun getProjectId(): String {
        return PROJECT_ID
    }

    override fun getMobileSdkAppId(): String {
        return MOBILE_SDK_APP_ID
    }

    override fun getBundleIdentifier(): String {
        return BUNDLE_IDENTIFIER
    }

    override fun getHostInfo(): String {
        return HOST_INFO
    }

    override fun getHostKey(): String {
        return HOST_KEY
    }
}

Listo. Una vez finalizada la instalación del SDK, continúe con la implementación leyendo el material Guía de uso e integración a continuación:

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Este guía ha sido elaborada para ayudarlo a implementar el SDK Android de manera rápida y sencilla. A continuación, vea el paso a paso de todo el proceso de integración. Después de eso, si desea personalizar la experiencia, no deje de consultar la sección Personalización Android.

Marcos de documentos disponibles

En este modo de cámara, existe un marco de captura para ayudar al usuario a posicionar correctamente el documento. Después de posicionar el documento de manera correcta, el usuario debe hacer clic en el botón para realizar la captura de la foto del documento.

En este modo de cámara es posible capturar los documentos:

• CPF: Captura del frente del CPF;

• CNH: Captura de la CNH abierta;

• CNH frente: Captura del frente de la CNH;

• CNH verso: Captura del reverso de la CNH;

• RG frente: Captura del frente del RG;

• RG verso: Captura del reverso del RG;

• Otros: Captura de cualquier otro documento.

Inicializar el SDK

Cree una instancia del builder (Generado a través de la interfaz IAcessoBioBuilder), proporcionando como parámetro el contexto en cuestión y la implementación de la clase AcessoBioListener.

La implementación de esta clase es bastante simple y se puede hacer con pocas líneas de código. Todo lo que necesita hacer es instanciar el builder proporcionando el contexto correspondiente y sobrescribir los métodos de callback con las lógicas de negocio de su aplicación:

public class MainActivity extends AppCompatActivity {

    private AcessoBioListener callback = new AcessoBioListener() {
        @Override
        public void onErrorAcessoBio(ErrorBio errorBio) { }

        @Override
        public void onUserClosedCameraManually() { }

        @Override
        public void onSystemClosedCameraTimeoutSession() { }

        @Override
        public void onSystemChangedTypeCameraTimeoutFaceInference() { }
    };

    private IAcessoBioBuilder acessoBioBuilder = new AcessoBio(this, callback);
}

internal class MainActivity : AppCompatActivity() {

    private val callback = object : AcessoBioListener {
        override fun onErrorAcessoBio(errorBio: ErrorBio?) { }
    
        override fun onUserClosedCameraManually() { }
    
        override fun onSystemClosedCameraTimeoutSession() { }
    
        override fun onSystemChangedTypeCameraTimeoutFaceInference() { }
    }

    private val acessoBioBuilder: IAcessoBioBuilder = AcessoBio(this, callback)
}

Implementar las funciones de callback

Tenga en cuenta que el trabajo de implementación de la clase AcessoBioListener consiste en gran parte en la configuración de los métodos de callback. Cada método se llama en una situación específica de retorno del SDK.

Basta con sobrescribir los métodos ejemplificados en el paso anterior con las lógicas de negocio de su aplicación:

Implementar listeners para eventos de la cámara

El método de apertura de la cámara, que se llama en la siguiente etapa, necesita saber qué hacer cuando logre capturar una imagen con éxito o si ocurre algún error en el proceso. Es necesario especificar "qué hacer" al método de apertura de la cámara mediante la implementación de listeners que se llaman en situaciones de éxito o error.

A través de la configuración de los listeners, puede especificar qué ocurre en su App en situaciones de error (Método onErrorDocument) o éxito (Método onSuccessDocument) durante la captura de imágenes.

El siguiente ejemplo ilustra la configuración de los listeners, el build y la apertura de la cámara:

iAcessoBioDocument cameraListener = new iAcessoBioDocument() {
    @Override
    public void onSuccessDocument(ResultCamera result) { }

    @Override
    public void onErrorDocument(ErrorBio errorBio) { }
};

unicoCheckCamera.prepareDocumentCamera(unicoConfig, new DocumentCameraListener() {
    @Override
    public void onCameraReady(UnicoCheckCameraOpener.Document cameraOpener) {
        cameraOpener.open(DocumentType.CNH, cameraListener);
    }

    @Override
    public void onCameraFailed(String message) {
        Log.e(TAG, message);
    }
});

val cameraListener: iAcessoBioDocument = object : iAcessoBioDocument {
    override fun onSuccessDocument(result: ResultCamera?) {}

    override fun onErrorDocument(errorBio: ErrorBio?) {}
}

unicoCheckCamera.prepareDocumentCamera(unicoConfig, object : DocumentCameraListener {
    override fun onCameraReady(cameraOpener: UnicoCheckCameraOpener.Document?) {
        cameraOpener?.open(DocumentType.CNH, cameraListener)
    }

    override fun onCameraFailed(message: String?) {
        Log.e(TAG, message)
    }
})

Preparar y abrir la cámara

Es necesario crear una instancia del builder a través del método build(). Este método está disponible a través del objeto generado con la interfaz IAcessoBioBuilder y la clase AcessoBio:

UnicoCheckCamera unicoCheckCamera = acessoBioBuilder.build();  

val unicoCheckCamera = acessoBioBuilder.build()

El siguiente paso es preparar la cámara utilizando el método prepareDocumentCamera() con el objeto retornado por el builder (nombrado como UnicoCheckCamera en el ejemplo anterior).

El método prepareDocumentCamera() genera un objeto del tipo UnicoCheckCameraOpener.Document, que se utiliza para abrir la cámara con su método open(), recibiendo los parámetros del tipo de documento a capturar, siendo estos:

Método onSuccessDocument

Al realizar una captura de imagen con éxito, este método es invocado y retorna un objeto del tipo ResultCamera, que se utiliza posteriormente en la llamada a las APIs REST:

public void onSuccessDocument(ResultCamera result) { }

El objeto ResultCamera retorna 2 atributos: base64 y encrypted:

• El atributo base64 puede ser utilizado si desea mostrar una vista previa de la imagen en su app.

• Tanto el atributo encrypted como el atributo base64 pueden enviarse en la llamada a las APIs REST.

Método onErrorDocument

Cuando ocurre un error en la captura de imagen, este método es invocado y retorna un objeto del tipo ErrorBio:

public void onErrorDocument(ErrorBio errorBio) { }

Realizar una solicitud POST en la API REST

La captura de las imágenes es solo la primera parte del proceso. Después de capturar la imagen, es necesario enviar el base64 generado por el SDK a las APIs REST. Infórmese más en la sección Creación de proceso.

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

El SDK Android permite que se realicen algunas personalizaciones. A continuación, vea todas las personalizaciones posibles para este SDK.

Personalizar idioma

Es posible configurar la experiencia de los mensajes informativos de los marcos de captura cambiando su idioma. Utilice el enumerado LocaleTypes, que contiene los siguientes valores:

• LocaleTypes.PT_BR: para Portugués (Brasil);

• LocaleTypes.ES_MX: para Español (México);

• LocaleTypes.ES_ES: para Español (España);

• LocaleTypes.EN_US: para Inglês (EUA).

Vea cómo implementarlo en el siguiente ejemplo:

unicoCheck.setLocale(LocaleTypes.EN_US);

unicoCheck.setLocale(LocaleTypes.EN_US);

Personalizar la experiencia del proceso de captura

Personalizar la experiencia de captura de la Selfie

Esta es una etapa opcional, pero muy recomendada para que el proceso de captura tenga la identidad visual de su empresa.

Es posible personalizar algunos objetos del marco de acuerdo con el modo de cámara utilizado, mediante el método setTheme().

Todos los métodos están disponibles a continuación:

IAcessoBioTheme unicoTheme = new IAcessoBioTheme() {
    @Override
    public Object getColorBackground() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorBoxMessage() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorTextMessage() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorBackgroundPopupError() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorTextPopupError() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorBackgroundButtonPopupError() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorTextButtonPopupError() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorBackgroundTakePictureButton() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorIconTakePictureButton() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorBackgroundBottomDocument() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorTextBottomDocument() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorSilhouetteSuccess() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorSilhouetteError() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorProgressBar() { 
        return R.color.your_color;
    }
};
    
acessoBioBuilder.setTheme(unicoTheme); 

val unicoTheme = object: IAcessoBioTheme {

    override fun getColorBackground() = R.color.your_color
    override fun getColorBoxMessage() = R.color.your_color
    override fun getColorTextMessage() = R.color.your_color
    override fun getColorBackgroundPopupError() = R.color.your_color
    override fun getColorTextPopupError() = R.color.your_color
    override fun getColorBackgroundButtonPopupError() = R.color.your_color
    override fun getColorTextButtonPopupError() = R.color.your_color
    override fun getColorBackgroundTakePictureButton() = R.color.your_color
    override fun getColorIconTakePictureButton() = R.color.your_color
    override fun getColorBackgroundBottomDocument() = R.color.your_color
    override fun getColorTextBottomDocument() = R.color.your_color
    override fun getColorSilhouetteSuccess() = R.color.your_color
    override fun getColorSilhouetteError() = R.color.your_color 
    override fun getColorSilhouetteNeutral() = R.color.your_color
    override fun getColorProgressBar() = R.color.your_color
}

acessoBioBuilder.setTheme(unicoTheme)

También es posible realizar personalizaciones de forma estática. En su archivo colors.xml, agregue el siguiente código:

<color name="unico_color_background"> #YourColor </color> 
<color name="unico_color_silhouette_success"> #YourColor </color> 
<color name="unico_color_silhouette_error"> #YourColor </color> 
<color name="unico_color_silhouette_neutral"> #YourColor </color> 
<color name="unico_color_box_message"> #YourColor </color> 
<color name="unico_color_text_message"> #YourColor </color> 
<color name="unico_color_background_popup_error"> #YourColor </color> 
<color name="unico_color_text_popup_error"> #YourColor </color> 
<color name="unico_color_background_button_popup_error"> #YourColor </color> 
<color name="unico_color_text_button_popup_error"> #YourColor </color> 
<color name="unico_color_background_take_picture_button"> #YourColor </color> 
<color name="unico_color_icon_take_picture_button"> #YourColor </color> 
<color name="unico_color_background_bottom_document"> #YourColor </color> 
<color name="unico_color_text_bottom_document"> #YourColor </color> 
<color name="unico_color_button_cancel"> #YourColor </color> 
<color name="unico_color_progress_bar_capture"> #YourColor </color> 

A continuación, consulte la especificación de campos de personalización:

Personalizar la experiencia de captura del documento

Esta es una etapa opcional, pero muy recomendada para que el proceso de captura tenga la identidad visual de su empresa.

Es posible personalizar algunos objetos del marco de acuerdo con el modo de cámara utilizado, mediante el método setTheme().

Todos los métodos están disponibles a continuación:

IAcessoBioTheme unicoTheme = new IAcessoBioTheme() {
    @Override
    public Object getColorBackground() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorBoxMessage() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorTextMessage() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorBackgroundPopupError() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorTextPopupError() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorBackgroundButtonPopupError() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorTextButtonPopupError() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorBackgroundTakePictureButton() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorIconTakePictureButton() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorBackgroundBottomDocument() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorTextBottomDocument() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorSilhouetteSuccess() { 
        return R.color.your_color;
    }
    @Override
    public Object getColorSilhouetteError() { 
        return R.color.your_color;
    }

    @Override
    public Object getColorProgressBar() { 
        return R.color.your_color;
    }
};
    
acessoBioBuilder.setTheme(unicoTheme); 

val unicoTheme = object: IAcessoBioTheme {
    override fun getColorBackground() = R.color.your_color
    override fun getColorBoxMessage() = R.color.your_color
    override fun getColorTextMessage() = R.color.your_color
    override fun getColorBackgroundPopupError() = R.color.your_color
    override fun getColorTextPopupError() = R.color.your_color
    override fun getColorBackgroundButtonPopupError() = R.color.your_color
    override fun getColorTextButtonPopupError() = R.color.your_color
    override fun getColorBackgroundTakePictureButton() = R.color.your_color
    override fun getColorIconTakePictureButton() = R.color.your_color
    override fun getColorBackgroundBottomDocument() = R.color.your_color
    override fun getColorTextBottomDocument() = R.color.your_color
    override fun getColorSilhouetteSuccess() = R.color.your_color
    override fun getColorSilhouetteError() = R.color.your_color
    override fun getColorSilhouetteNeutral() = R.color.your_color
    override fun getColorProgressBar() = R.color.your_color
}
acessoBioBuilder.setTheme(unicoTheme)

También es posible realizar personalizaciones de forma estática. En su archivo colors.xml, agregue el siguiente código:

<color name="unico_color_background"> #YourColor </color> 
<color name="unico_color_silhouette_success"> #YourColor </color> 
<color name="unico_color_silhouette_error"> #YourColor </color> 
<color name="unico_color_silhouette_neutral"> #YourColor </color> 
<color name="unico_color_box_message"> #YourColor </color> 
<color name="unico_color_text_message"> #YourColor </color> 
<color name="unico_color_background_popup_error"> #YourColor 
<color name="unico_color_text_popup_error"> #YourColor </color> 
<color name="unico_color_background_button_popup_error"> #YourColor 
<color name="unico_color_text_button_popup_error"> #YourColor </color> 
<color name="unico_color_background_take_picture_button"> #YourColor </color> 
<color name="unico_color_icon_take_picture_button"> #YourColor </color> 
<color name="unico_color_background_bottom_document"> #YourColor </color> 
<color name="unico_color_text_bottom_document"> #YourColor </color> 
<color name="unico_color_button_cancel"> #YourColor </color> 
<color name="unico_color_progress_bar_capture"> #YourColor </color> 

A continuación, consulte la especificación de campos de personalización:

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Requisitos previos del entorno de desarrollo

Es necesario que su entorno de desarrollo cumpla con los siguientes requisitos:

Instalando el SDK iOS

Para implementar el SDK iOS de la plataforma Unico IDCloud en su aplicación iOS, siga los pasos a continuación:

pod ‘unicocheck-ios’

pod install

<uses-dependencies: [
    .package(url: "https://github.com/acesso-io/unico-check-ios.git", .upToNextMajor(from: "2.12.0"))
]

<key>NSCameraUsageDescription</key>
<string>Camera usage description</string>

.h:
#import <AcessoBio/AcessoBioManager.h>
#import <AcessoBio/AcessoBio-Swift.h>

@interface YourUnicoConfigClass: AcessoBioConfigDataSource {}
@end

.m:
@implementation YourUnicoConfigClass

- (NSString * _Nonnull)getBundleIdentifier {
    return @"<YOUR_MOBILE_BUNDLE_IDENTIFIER>";
}

- (NSString * _Nonnull)getHostKey {
    return @"<YOUR_SDK_KEY>";
}

@end

import AcessoBio

class YourUnicoConfigClass: AcessoBioConfigDataSource {
          
    func getBundleIdentifier() -> String {
        return "<YOUR_MOBILE_BUNDLE_IDENTIFIER>"
    }
        
    func getHostKey() -> String {
        return "<YOUR_SDK_KEY>"
    }
}

.h:
#import <AcessoBio/AcessoBioManager.h>
#import <AcessoBio/AcessoBio-Swift.h>

@interface YourUnicoConfigClass: AcessoBioConfigDataSource {}
@end

.m:
@implementation YourUnicoConfigClass

- (NSString * _Nonnull)getBundleIdentifier {
    return @"<YOUR_MOBILE_BUNDLE_IDENTIFIER>";
}

- (NSString * _Nonnull)getHostInfo {
    return @"<YOUR_HOST_INFO>";
}

- (NSString * _Nonnull)getHostKey {
    return @"<YOUR_HOST_KEY>";
}

- (NSString * _Nonnull)getMobileSdkAppId {
    return @"<YOUR_MOBILE_SDK_APP_ID>";
}

- (NSString * _Nonnull)getProjectId {
    return @"<YOUR_PROJECT_ID>";
}

- (NSString * _Nonnull)getProjectNumber {
    return @"<YOUR_PROJECT_NUMBER>";
}

@end

import AcessoBio

class YourUnicoConfigClass: AcessoBioConfigDataSource {
        
    func getProjectNumber() -> String {
        return "<YOUR_PROJECT_NUMBER>"
    }
    
    func getProjectId() -> String {
        return "<YOUR_PROJECT_ID>"
    }
    
    func getMobileSdkAppId() -> String {
        return "<YOUR_MOBILE_SDK_APP_ID>"
    }
    
    func getBundleIdentifier() -> String {
        eturn "<YOUR_MOBILE_BUNDLE_IDENTIFIER>"
    }
    
    func getHostInfo() -> String {
        return "<YOUR_HOST_INFO>"
    }
    
    func getHostKey() -> String {
        return "<YOUR_HOST_KEY>"
    }
}

Listo. Una vez finalizada la instalación del SDK, continúe con la implementación leyendo el material Guía de uso e integración a continuación:

¿Dudas?

¿No encontraste algo o aún necesitas ayuda? Si ya eres cliente o socio, puedes ponerte en contacto a través del Centro de Ayuda.

Para obtener mejores resultados en la captura de imágenes, se ha definido un estándar de captura. La imagen debe ser nítida, con suficiente iluminación frontal. El rostro debe estar recto, mirando hacia la cámara, sin objetos u obstrucciones, y con una expresión neutral.

Normalmente, las imágenes capturadas presentan los siguientes problemas:

• Iluminación detrás del cliente: Es necesario que la iluminación frontal sea lo suficientemente buena para obtener una captura nítida del rostro.

• Iluminación excesiva: La iluminación frontal debe ser adecuada para una captura clara del rostro.

• Rostro muy cerca de la cámara + iluminación: El rostro debe estar centrado en la cámara y la iluminación frontal debe ser suficiente.

• Imágenes borrosas: El rostro de la persona debe estar bien enfocado al momento de la captura.

• Imágenes movidas: Estabilizar la cámara durante la captura.

• Cliente con gafas: El cliente debe estar sin gafas o cualquier objeto que pueda impedir la visualización completa de su rostro.

Cómo obtener una buena captura de imagen

Para la obtención y envío de imágenes, se utiliza el estándar ICAO. El estándar ICAO (Organización Internacional de Aviación Civil) establece características para que una fotografía cumpla con los requisitos y recomendaciones definidos para configuraciones de captura y envío de imágenes:

• Posicionamiento del rostro e información adicional:

  • La foto debe ser tomada de frente: mirar directamente a la cámara y mantener la cabeza erguida. El rostro debe estar centrado. Los hombros deben estar alineados y paralelos al plano de la cámara.

  • Los ojos deben estar abiertos naturalmente: las pupilas e iris deben ser visibles.

  • Gafas: la foto debe ser tomada sin gafas.

  • Sin sombrero, gorra ni máscara: la región de la cara debe ser claramente visible.

  • Expresión facial neutral: el rostro debe tener una expresión neutral, sin sonreír, levantar las cejas, apretar los ojos ni fruncir el ceño.

  • Peinado: el cabello no debe cubrir la zona de visibilidad de los ojos.

• Iluminación y fondo:

  • El fondo debe ser claro, liso y sin textura. No debe contener manchas, líneas o curvas que queden visibles en la imagen. Colores claros como azul claro o blanco pueden usarse, siempre que haya suficiente distinción entre el rostro/cabello y el fondo. No debe haber sombra detrás de la imagen del rostro, ni objetos visibles al fondo, como personas, muebles, papeles tapiz, plantas.

  • La iluminación debe ser adecuada y uniforme, distribuida igualmente en el rostro, sin diferencias entre el lado izquierdo y derecho. La foto debe tener brillo y buen contraste entre cabello, rostro y fondo. Las fotos con mala iluminación son aquellas donde la luz está solo en los laterales, arriba o abajo.

  • Formato de imagen: JPEG, PNG o JWT;

  • Imágenes capturadas en color.

Tamaños / Proporciones

Selfies:

• Tamaño recomendado: Proporción 1920x1080 o 1080x1920;

• Orientación: Retrato;

• Tamaño: Máximo 800kb, si es necesario, puede comprimirse a JPEG92.

Documentos:

• Tamaño recomendado: Proporción HD - 1280x720 o 720x1280;

• Tamaño mínimo: Proporción VGA - 640x480 o 480x640;

• Orientación: Si se usa tipificación/OCR, es recomendable capturar en la orientación de lectura.

• Tamaño: Máximo 800kb, si es necesario, puede comprimirse a JPEG92.

• Enmarcado: Se recomienda que la imagen no tenga espacios sobrantes (sin bordes). Cuanto mayor sea el área libre (borde), peor será para la tipificación de documentos.

La foto debe tener:

• Color.

• Enmarcado.

• Enfoque nítido y claro, sin marcas de tinta o pliegues.

• Mirar directamente a la cámara.

• Mostrar el tono de piel natural.

• Tener brillo y contraste apropiados.

• Expresión facial neutra y ojos claramente visibles y abiertos.

• Sin cabello sobre los ojos.

• Frente a la cámara, sin mirar por encima del hombro ni inclinar la cabeza, mostrando claramente los dos lados del rostro.

• Con un fondo simple de color claro, preferentemente blanco.

• Con iluminación uniforme, sin sombras o reflejos de flash en el rostro y sin ojos rojos.

• Sin lentes de contacto de color.

• Sin maquillaje.

El uso de gafas no es recomendado, pero en casos donde sea necesario usarlas:

• Los ojos deben estar nítidos, sin reflejo del flash o luz ambiental en las gafas y sin lentes de color.

• La montura no debe cubrir ninguna parte de los ojos.

Consejos

Añadir orientaciones antes de la captura para el usuario:

Utilice "marcos" de captura para orientar el posicionamiento del cliente frente al rostro:

¿Dudas?

Ofuscación de código

La ofuscación es un proceso que transforma el bytecode en una forma menos legible para los humanos, dificultando así la ingeniería inversa.

Este proceso consiste en eliminar información relacionada con la depuración, como tablas de variables, número de líneas, y renombrar los paquetes, clases y métodos.

Al integrar el SDK iOS en la aplicación, pueden ocurrir fallas.

Ofuscación mediante iXGuard

Cuando la ofuscación se realice con la herramienta iXGuard, se sugiere utilizar la versión 4.12.6 o superior.

Sombra al final del flujo después de la actualización a la versión 2.4.0

La responsabilidad del control del flujo se delega a quien llama al SDK. Por lo tanto, si aparece alguna forma de sombra o la pantalla no se cierra después de la finalización exitosa de la captura, se sugiere implementar una forma de liberar esta pantalla. Esta liberación puede variar según el apilamiento de navegación implementado. Para esta implementación, agregue el método adecuado para la liberación preferiblemente dentro del método delegado onSuccessSelfie. A continuación, algunos ejemplos de liberación que pueden ser utilizados: