> 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/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only/device-binding-flow.md).

# Vinculación del token

Normalmente, un solicitante de token, como un comerciante, inicia una solicitud de vinculación de token porque el usuario final está listo para pagar con un token. La vinculación de token restringe el uso del token y aumenta la confianza en su legitimidad.

D1 recibe la solicitud y orquesta el flujo de trabajo utilizando los datos registrados. El backend del emisor no requiere nuevas API. El nivel de implicación del backend del emisor depende del modelo de integración seleccionado por el emisor.

Como la vinculación de token implica un dispositivo, el emisor puede definir tipos de dispositivos no confiables durante la incorporación en D1. D1 utiliza estos datos para rechazar una solicitud de vinculación cuando el TSP proporciona la información del dispositivo requerida.

La siguiente tabla enumera la información que el emisor puede usar para definir dispositivos no confiables:

| Nombre de la regla                                | Descripción                                                                                                        |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Tipos de dispositivos no confiables               | El emisor puede seleccionar tipos de dispositivos en los que no confía. Por ejemplo, dispositivos de tipo `RELOJ`. |
| Fabricante del dispositivo                        | El emisor puede enumerar los fabricantes de dispositivos en los que no confía.                                     |
| Fabricante del dispositivo - versión del SO       | Si se conoce, el emisor puede especificar una versión del sistema operativo en la que no confía.                   |
| Fabricante del dispositivo - versión del firmware | Si se conoce, el emisor puede especificar una versión del firmware en la que no confía.                            |

Sin reglas para dispositivos no confiables, D1 siempre requiere **autenticación reforzada** para cada solicitud de vinculación.

### Diagramas de secuencia

Los siguientes diagramas de secuencia muestran el flujo completo orquestado por D1 y el nivel de participación del backend del emisor.

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FPKFjXkkxTM703j5MdeH8%2Fimage.png?alt=media&amp;token=8b378b34-75cf-471f-94f1-91105b268473" alt=""><figcaption></figcaption></figure>

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FFU1aa303qlrDhgsC8tby%2Fimage.png?alt=media&amp;token=409428ab-c688-40a2-b246-d1252ecd9c78" alt=""><figcaption></figcaption></figure>

Si no se han definido dispositivos no confiables, o si ningún dispositivo coincide con las reglas definidas, D1 siempre realiza **autenticación reforzada** y proporciona la lista de métodos de ID\&V disponibles.

Para conocer los requisitos previos de ID\&V, consulte [Requisitos previos para los métodos de ID\&V](/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md#prerequisites-for-id-and-v-methods).

#### Verificación OTP por SMS o correo electrónico

El siguiente diagrama de secuencia muestra el flujo cuando el usuario final elige OTP por SMS o correo electrónico para la verificación:

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FMbMWSw3y6RfljwhHmfyV%2FSequence%20Diagram%20-%20OTP%20verification%20by%20SMS%20or%20email.png?alt=media&amp;token=5bfc4ac1-3c89-4537-a02b-8d66b4dbecb2" alt=""><figcaption></figcaption></figure>

La `Entregar método de autenticación reforzada` en el paso `08` sigue correspondiendo al [Entregar OTP](/tokenization/es/integrate-the-d1-api/d1-api-reference/outbound-api-from-d1/consumer-api.md#post-banking-d1-v1-issuers-issuerid-consumers-consumerid-otp) API. Esta API entrega el método de ID\&V seleccionado, que en este caso es un OTP.

Si el backend del emisor gestiona la entrega del OTP, debe implementar [Entregar OTP](/tokenization/es/integrate-the-d1-api/d1-api-reference/outbound-api-from-d1/consumer-api.md#post-banking-d1-v1-issuers-issuerid-consumers-consumerid-otp) API y usar el `otp.reason` campo para distinguir esta solicitud de una solicitud de tokenización. Puede usar `deliveryChannel` para determinar el tipo de mensaje:

* `otp.reason` = `VINCULACIÓN DE DISPOSITIVO`
* `deliveryChannel` = `SMS` o `CORREO ELECTRÓNICO`

#### Verificación mediante la aplicación del emisor

El siguiente diagrama de secuencia muestra el flujo cuando el usuario final elige la aplicación del emisor como método de verificación:<br>

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FUZxPvli60oRSzkwbsL2O%2Fimage.png?alt=media&amp;token=29ef0c12-3ec1-47da-b710-6a9338ad6e10" alt=""><figcaption></figcaption></figure>

Como se describe en el [Flujo de alto nivel](/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md#high-level-flow) sección, el backend del emisor debe gestionar la integración requerida en el paso `[02]`. Los datos compartidos dependen del TSP. En comparación con un flujo de tokenización, utilice el siguiente mapeo para rellenar `StepupAuthenticationResult` correctamente:

<table><thead><tr><th width="228.45458984375">D1</th><th width="261.727294921875">Mastercard</th><th>Visa</th></tr></thead><tbody><tr><td><code>authenticationId</code></td><td><code>authenticationCorrelationId</code></td><td><code>lifeCycleTraceID</code></td></tr></tbody></table>

#### Verificación mediante la aplicación del emisor usando un disparador administrado por el emisor

El emisor puede admitir la verificación en la aplicación del emisor usando un mensaje PUSH. Esto evita depender de la aplicación del comerciante para activar la aplicación del emisor.

{% hint style="warning" %}
Esta opción solo se admite bajo estas condiciones:

* El emisor admite tarjetas Mastercard. Solo Mastercard puede propagar este tipo de opción de ID\&V al comerciante.
* El emisor no depende del servicio D1 OBO para enviar mensajes al usuario final. En ese caso, Thales no puede enviar el mensaje PUSH en nombre del emisor.
  {% endhint %}

El siguiente diagrama muestra este flujo:

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2Fo6Q0gRWxxCXM5Awa8Hpg%2FSequence%20Diagram%20-%20Verification%20by%20Issuer%20App%20with%20issuer-managed%20trigger.svg?alt=media&amp;token=e72948b6-59ea-46ea-9ad6-10bedd36b186" alt=""><figcaption></figcaption></figure>

La `Entregar método de autenticación reforzada` en el paso `04` sigue correspondiendo al [Entregar OTP](/tokenization/es/integrate-the-d1-api/d1-api-reference/outbound-api-from-d1/consumer-api.md#post-banking-d1-v1-issuers-issuerid-consumers-consumerid-otp) API. Esta API entrega el método de ID\&V seleccionado, en este caso un mensaje PUSH. Para identificar este caso, el emisor debe comprobar los siguientes campos:

* `otp.reason` = `VINCULACIÓN DE DISPOSITIVO`
* `deliveryChannel` = `PUSH`
* `deviceInformation.deviceReference`
* `digitalCardId`

Para informar del resultado a través de `StepupAuthenticationResult`, el emisor debe enviar el siguiente valor junto con `digitalCardId`:

* `authenticationId` = `deviceInformation.deviceReference`

{% hint style="warning" %}
En este caso, no `otp.value` se proporciona.

El emisor es libre de gestionar el contenido y el formato del mensaje PUSH.
{% endhint %}


---

# 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, and the optional `goal` query parameter:

```
GET https://docs.payments.thalescloud.io/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only/device-binding-flow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.