> 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/casos-de-uso/posalta/verificacion-del-token.md).

# Verificación del token

El flujo de verificación del token se aplica a los tokens creados para uso en tarjeta almacenada (COF) o comercio electrónico.

En este caso, normalmente el token se crea sin verificación adicional más allá de la validación básica de la tarjeta. El TSP almacena el token en lugar de aprovisionarlo a un dispositivo.

Un comerciante puede activar la verificación del token para aumentar el nivel de confianza de un token.

Visa y Mastercard admiten este flujo bajo diferentes nombres:

* Visa: **Cloud Token Framework (CTF)**
* Mastercard: **Autenticación posterior a la tokenización para tarjeta almacenada y Click to Pay seguros**

Hay dos tipos de solicitud de verificación de token:

1. **Vincular un token a un dispositivo o clave de acceso**. Como el token de comercio electrónico está basado en la nube, la vinculación permite al comerciante usar las capacidades del dispositivo para proteger las transacciones con token y limitar el uso del token a un dispositivo específico. Esto aumenta el nivel de confianza del token.
2. **Solicitar verificación del titular de la tarjeta**. Un usuario final que haya iniciado sesión en una app o sitio web del comerciante puede realizar acciones sensibles, como cambiar una dirección de correo electrónico o una contraseña. Si la cuenta tiene métodos de pago almacenados, el comerciante puede solicitar la verificación del titular de la tarjeta para confirmar que el usuario final es el titular de la tarjeta.

En ambos casos, el backend del emisor devuelve una decisión, como lo hace para una solicitud de tokenización:

* `verde`: aprobar
* `amarillo`: aprobar con autenticación reforzada
* `rojo`: rechazar

La siguiente tabla resume el efecto de cada decisión para cada tipo de solicitud:

| Decisión                                         | Solicitud de vinculación                                                                                                                                                                | Solicitud de verificación del titular de la tarjeta                                                                                                                                 |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `verde` — aprobar                                | El comerciante asocia el token de pago con el dispositivo.                                                                                                                              | El comerciante trata el resultado como confirmación de la identidad del titular de la tarjeta y aprueba el cambio de cuenta solicitado.                                             |
| `amarillo` — aprobar con autenticación reforzada | El comerciante presenta los métodos de ID\&V compatibles al usuario final. El comerciante no realiza ninguna asociación hasta recibir la confirmación del resultado de la verificación. | El comerciante presenta los métodos de ID\&V compatibles al usuario final. El comerciante no realiza ninguna acción hasta recibir la confirmación del resultado de la verificación. |
| `rojo` — rechazar                                | El comerciante no realiza ninguna asociación.                                                                                                                                           | El comerciante no realiza ninguna acción.                                                                                                                                           |

Si la decisión es `amarillo`, el emisor debe proporcionar la lista de métodos de ID\&V que pueden autenticar al titular de la tarjeta.

Como la ID\&V se realiza en tiempo real, no utilice el servicio de atención al cliente como método de ID\&V. Mastercard no admite este método.

En todas las redes de pago, el emisor debe admitir los siguientes métodos de ID\&V cuando estén disponibles:

| Tipos de métodos de ID\&V | Visa                      | Mastercard                                                             |
| ------------------------- | ------------------------- | ---------------------------------------------------------------------- |
| `cell_phone`              | Igual que en tokenización | Igual que en tokenización                                              |
| `email`                   | Igual que en tokenización | Igual que en tokenización                                              |
| `push`                    | No aplica                 | Ver detalles a continuación                                            |
| `bank_app`                | Igual que en tokenización | Igual que en tokenización + el modo de activación push está disponible |

Mastercard admite dos métodos adicionales que solo se aplican a la autenticación posterior a la tokenización:

* `push`: El emisor envía un OTP en un mensaje push que abre la aplicación del emisor. El emisor debe agregar este nuevo tipo en la lista de métodos de ID\&V que se usarán en caso de autenticación reforzada. 
* `bank_app`: El emisor puede enviar un mensaje push que abre la aplicación del emisor. No se genera ningún OTP. Para admitir este método, el emisor debe agregar el tipo `bank_app` en la lista de métodos de ID\&V que se utilizarán y luego asignar al `valor` = PUSH\_NOTIFICATION.

Estos métodos mejoran la interacción entre el comerciante y el usuario final.


---

# 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/classic-tokenization/es/casos-de-uso/posalta/verificacion-del-token.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.