> 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/card-tokenization-request/processing-the-response/approve-with-step-up-authentication.md).

# Aprobar con autenticación adicional

{% hint style="info" %}
La autenticación reforzada se utiliza normalmente para la tokenización con **Carteras xPay**. No se aplica a la tokenización iniciada por un comerciante de comercio electrónico.
{% endhint %}

Una decisión de autenticación reforzada (**AMARILLO**) significa que D1 ha aprobado condicionalmente **Tokenización**. Antes de que la red de pago **TSP** pueda aprovisionar y activar la tarjeta digital, el **Usuario final** debe completar un paso adicional de autenticación (un **ID\&V** método).

### Qué sucede a continuación

1. D1 devuelve una **AMARILLO** decisión a la red de pago **TSP**, junto con los métodos de ID\&V compatibles.
2. El **solicitante del token** solicita al **Usuario final** que complete uno de los métodos compatibles.
3. Si la autenticación tiene éxito, la red de pago **TSP** completa el aprovisionamiento y activa la tarjeta digital (comportamiento de la red de pago).
4. D1 puede notificar a su **backend del emisor** el resultado de la tokenización y, opcionalmente, enviar **Usuario final** notificaciones (según lo que habilitó durante **la incorporación a D1**). Para obtener más detalles, consulte [Procesamiento de la respuesta](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-response.md#notifications).

### Desencadenantes comunes

La autenticación reforzada suele activarse cuando D1 detecta un riesgo mayor, por ejemplo:

* Discordancia del número de teléfono entre **Usuario final** los datos proporcionados por el **emisor** y el número de teléfono proporcionado por la red de pago **TSP**. Consulte [Motor de decisiones > Usuario final (consumidor)](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-decision/decision-engine.md#end-user-consumer).
* Falta **CSC** para un método de captura en el que se espera el CSC. Consulte [Motor de decisiones > Captura de tarjeta](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-decision/decision-engine.md#card-capture).

### Métodos de ID\&V compatibles

Cuando D1 devuelve **AMARILLO**, proporciona a la red de pago **TSP** la lista de métodos de ID\&V compatibles.

* [OTP por SMS/correo electrónico](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication/otp-by-sms-email.md) – La red de pago genera el **OTP**. El **emisor** (o D1 en nombre del **emisor**) lo entrega al **Usuario final**.
* [backend de autenticación en la aplicación](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication/in-app-authentication-with-issuer-backend.md) – El **Usuario final** se autentica en la **aplicación del emisor**, y el **emisor** activa la tarjeta digital.
* [Servicio de atención al cliente](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication/customer-service.md) – El **Usuario final** se autentica a través del **emisor**proceso de atención al cliente de ’s.

{% hint style="warning" %}
Los métodos que se pueden usar dependen de la capacidad del emisor para proporcionar los datos requeridos. Por ejemplo, si el emisor no tiene datos de contacto como una dirección de correo electrónico o un número de teléfono, esos métodos no estarán disponibles.
{% endhint %}

{% hint style="info" %}
Si no quieres que D1 envíe OTP, debes admitir el [API de entrega de OTP](/tokenization/es/integrate-the-d1-api/d1-api-summary.md).
{% 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/card-tokenization-request/processing-the-response/approve-with-step-up-authentication.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.