Conceptos clave

Desarrollo

Para enviar y recibir solicitudes, su backend del emisor debe implementar el API de Pasarela del Emisor.

Su backend del emisor debe soportar cifrado a nivel de aplicación PKCS#7. Úselo para proteger datos sensibles, como el PAN y la fecha de caducidad. Los detalles se explican en Cifrado de datos y seguridad.

Use estas claves de la configuración de su Entorno Sandbox:

• Clave pública de Thales. Cifre los datos sensibles enviados a Thales.

• Clave privada del Sandbox. Descifre los datos sensibles recibidos de Thales.

En el Entorno de Producción, el emisor genera y almacena la clave privada. Proporcione el certificado del emisor a Thales en el portal de configuración de producción.

Glosario y modelo de datos

El diagrama y la tabla a continuación describen los principales identificadores intercambiados a través del API de Pasarela del Emisor.

Parámetro del API de Pasarela del Emisor	Descripción
issuerCardRefId	Identificar el FPAN en el backend del emisor. Use este identificador en futuras llamadas al API de Pasarela del Emisor para casos de uso a nivel de tarjeta. Actualice este identificador si el PAN es reemplazado (por ejemplo, reemplazo o renovación de la tarjeta).
virtualCardId	Identificador único del token.
walletCardRefId	Identifique la tarjeta tal como la referencia el proveedor de la cartera. Use este identificador en futuras llamadas al API entre el proveedor de la cartera y Thales. Para co-badging, la red de pago puede generar este identificador. Asigne este valor a walletCardRefId en el API de Pasarela del Emisor y envíelo al backend del emisor. Asigne este valor a cardRefId en el API del TSP y envíelo al TSP.
walletVirtualCardId	Identifique el PAN tokenizado (DPAN). Use este identificador en futuras llamadas al API entre el proveedor de la cartera y Thales. Para co-badging, la red de pago genera este identificador para el token primario. Thales lo genera para el token auxiliar.
tokenStorageId	Identifique la ubicación de almacenamiento del token en el dispositivo: ID del elemento seguro para dispositivos basados en elemento seguro. ID de instancia de la aplicación para HCE-basadas en aplicaciones. Comparta este valor con el backend del emisor a través del API de Pasarela del Emisor en tokenStorageId.

Digitalización de tarjeta

La digitalización de tarjeta convierte una tarjeta física en un token. El token representa una tarjeta digital. Esto también se llama inscripción de tarjeta.

Este proceso involucra cuatro actores principales:

• El usuario final que desea digitalizar una tarjeta.

• El proveedor de la cartera conectado a la red de pago.

• El TSP (proveedor de servicios de token) que emite el token.

• El emisor que posee la cuenta de la tarjeta.

Thales TIG también participa en el flujo. TIG actúa como una pasarela entre las redes de pago y el backend del emisor. Expone el API de Pasarela del Emisor y abstrae las APIs de la red de pago.

Cada inscripción de tarjeta requiere una decisión del emisor. El emisor puede:

• Aceptar la solicitud sin autenticación adicional.

• Aceptar la solicitud con autenticación escalonada usando ID&V (identificación y verificación).

• Rechazar la solicitud.

La imagen a continuación muestra un flujo básico de digitalización de tarjeta.

Cada flujo tiene un “color”. Representa la recomendación del proveedor de la cartera y la decisión del emisor.

Para flujos de extremo a extremo, vea Casos de uso.

Colores de flujo

Dependiendo del proveedor de la cartera y la red de pago, el proveedor de la cartera puede enviar una recomendación para:

• digitalizar (VERDE)

• digitalizar con autenticación escalonada (AMARILLO)

• digitalizar con sospecha de fraude (NARANJA)

Basado en esta recomendación y la puntuación de riesgo, el emisor responde con una decisión para:

• digitalizar (VERDE)

• digitalizar con autenticación escalonada (AMARILLO)

• detener la inscripción (ROJO)

El API de Pasarela del Emisor gestiona los colores usando el levelOfTrust parámetro. Este parámetro está presente en la solicitud del API de digitalización de tarjeta (proveedor de la cartera) y en la respuesta (emisor). Las secciones a continuación describen los casos comunes.

Recomendación del proveedor de la cartera

VERDE

• Recomendar confiar en el usuario final (por ejemplo, Tarjeta en archivo (COF) o emparejamiento de dispositivo). El emisor normalmente puede confiar en la solicitud.

AMARILLO

• Recomendar usar un flujo de ID&V para autenticar al usuario final. El emisor debe requerir ID&V.

NARANJA

• Indicar sospecha de fraude o un problema de integridad del dispositivo (por ejemplo, un dispositivo rooteado). El emisor puede rechazar la solicitud o requerir ID&V (por ejemplo, a través del servicio al cliente).

Decisión del emisor

El emisor recibe la recomendación del proveedor de la cartera y la información de puntuación. El emisor entonces devuelve su propio levelOfTrust. Los siguientes casos son típicos:

VERDE

• Confiar en la solicitud y no requerir verificación adicional. No se desencadena ningún flujo de ID&V.

AMARILLO

• Requerir verificación adicional. Usar cuando la solicitud carece de señales de confianza. Ejemplo: CVV faltante o recomendación AMARILLO. El emisor devuelve los métodos de ID&V compatibles.

ROJO

• Rechazar la solicitud. Usar cuando las señales indican alto riesgo. Ejemplo: CVV inválido, fallos repetidos de CVV o recomendación NARANJA.