> 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/cardholder-verification-flow.md).
# Flujo de verificación del titular de la tarjeta
El comercio activa este flujo cuando el usuario final solicita una operación sensible que puede utilizar los instrumentos de pago asociados.
Por ejemplo, este flujo puede aplicarse cuando el usuario final actualiza datos como una dirección de correo electrónico. La dirección de correo electrónico puede servir como un ID único cuando el usuario final inicia sesión en el sitio web del comercio.
D1 recibe la solicitud a través del TSP correspondiente y gestiona el flujo. El backend del emisor no necesita nuevas API ni flujos de trabajo.
Para estas solicitudes, D1 requiere sistemáticamente autenticación reforzada y devuelve la lista de métodos de ID\&V que admite el emisor.
Las siguientes secciones proporcionan diagramas detallados.
### 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.
{% hint style="warning" %}
Este caso de uso aún no es compatible con Mastercard.
{% endhint %}
Para los requisitos previos de los métodos 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 de OTP por SMS o correo electrónico
El siguiente diagrama de secuencia muestra el flujo cuando el usuario final elige SMS o correo electrónico OTP como método de verificación:
La `Entregar método de autenticación reforzada` en el paso `08` sigue correspondiendo a la [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 de 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` = `VERIFICACIÓN-DEL-TITULAR-DE-LA-TARJETA`
* `deliveryChannel` = `SMS` o `CORREO ELECTRÓNICO`
#### Verificación por la aplicación del emisor
El siguiente diagrama de secuencia muestra el flujo cuando el usuario final selecciona la aplicación del emisor como método de verificación:
Como se describe en la [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 tener en cuenta la integración requerida en el paso `[02]`. Los datos compartidos dependen del TSP. En comparación con un flujo de tokenización, use el siguiente mapeo para completar `StepupAuthenticationResult` correctamente:
D1
Visa
authenticationId
lifeCycleTraceID
{% hint style="info" %}
**Resultado no exitoso**
`StepupAuthenticationResult` admite un `fallido` resultado de verificación para compatibilidad futura. Sin embargo, Visa no proporciona una interfaz dedicada para informar un resultado no exitoso.
Si la verificación falla, Visa recomienda suspender el token.
Suspender el token podría hacer que el usuario final se ponga en contacto con el servicio de atención al cliente o llevar al comercio a eliminar el token.
{% 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/cardholder-verification-flow.md?ask=&goal=
```
`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.
