> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/classic-tokenization/es/comenzar/conceptos-clave.md).

# Conceptos clave

## Desarrollo <a href="#development" id="development"></a>

Para enviar y recibir solicitudes, su backend del emisor debe implementar el [API de Pasarela del Emisor](/classic-tokenization/es/referencia-de-la-api/api-de-la-pasarela-del-emisor.md).

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](/classic-tokenization/es/comenzar/conceptos-basicos-de-la-api/cifrado-y-seguridad-de-datos.md).

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 <a href="#glossary-and-data-model" id="glossary-and-data-model"></a>

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

<figure><img src="/files/477b1efed4783028d307b8d1de11d5e4097ca11e" alt=""><figcaption></figcaption></figure>

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

## Digitalización de tarjeta <a href="#card-digitization" id="card-digitization"></a>

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.

<figure><img src="/files/631e1afab8c9db067e380bc9c537bd2c4e4af6bc" alt=""><figcaption></figcaption></figure>

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](/classic-tokenization/es/casos-de-uso/alta-de-tarjeta.md).

## Colores de flujo <a href="#what-is-flow-colors" id="what-is-flow-colors"></a>

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 <a href="#recommendation-from-the-wallet" id="recommendation-from-the-wallet"></a>

#### VERDE <a href="#green" id="green"></a>

* 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 <a href="#yellow" id="yellow"></a>

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

#### NARANJA <a href="#orange" id="orange"></a>

* 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 <a href="#decisions-from-the-issuer" id="decisions-from-the-issuer"></a>

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 <a href="#green-1" id="green-1"></a>

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

#### AMARILLO <a href="#yellow-1" id="yellow-1"></a>

* 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 <a href="#red" id="red"></a>

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.payments.thalescloud.io/classic-tokenization/es/comenzar/conceptos-clave.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.