Si un pago requiere la autenticación mediante 3D Secure, pero no podemos iniciarla, realizaremos un último intento por completar el pago sin autenticación. El resultado de este cargo alternativo actualiza el estado de PaymentIntent a una de las siguientes opciones:

• succeeded: se completó el pago y se creó un cargo con el método de pago suministrado. No son necesarios otros pasos.
• requires_capture: se completó la solicitud sin autenticación, lo que te permite continuar con la captura de los fondos.
• requires_payment_method: no se pudo cobrar el cargo y es posible que sea necesario otro método de pago.

Generalmente, un pago que activa 3D Secure generará un elemento PaymentIntent con el estado requires_action. A continuación, proporcionamos una guía de un flujo de pago típico que requiere 3D Secure:

1. Tu cliente proporciona su información de pago, la cual se adjunta a PaymentIntent.
2. Stripe comprueba si 3D Secure es necesario. Esto se puede determinar según las reglas de Radar, si se solicitó manualmente para el pago y otros factores.
3. Stripe determina que 3D Secure
   1. no es necesario, por lo que avanzamos e intentamos cobrar a la tarjeta. En este punto, el banco puede enviar un «pago rechazado temporalmente», lo cual indica que la autenticación es necesaria para que el cargo se aplique correctamente.
   2. es necesario, por lo que continuamos con el siguiente paso para activar 3DS.
4. Stripe inicia 3D Secure.
5. Stripe pudo solicitar 3D Secure y ahora debemos esperar que el cliente se autentique. Payment Intent pasa al estado requires_action.

Si los pasos 4 o 5 no se completaron correctamente, el flujo de pago anterior cambiaría y se vería de la siguiente manera:

1. Tu cliente proporciona su información de pago, la cual se adjunta a PaymentIntent.
2. Stripe comprueba si 3D Secure es necesario (esto se determina según las reglas de Radar, si se solicitó manualmente para el pago y otros factores).
3. Stripe determina que 3D Secure es necesario e intenta realizar el proceso de autenticación.
4. Surge un problema al iniciar el proceso de 3D Secure. Esto puede suceder por diversos motivos, como que la tarjeta no admita 3DS, se produzca un error de procesamiento, el servidor de 3D Secure del emisor esté inactivo, etc.
5. Aunque 3DS no se completó correctamente, avanzamos y realizamos un último intento de pago sin autenticación. Esto hace que PaymentIntent pase a un estado succeeded, requires_capture o requires_payment_method, según el resultado del pago.

El motivo por el cual intentamos esto en lugar de bloquear inmediatamente el pago o mostrar un mensaje de error es que elegimos una optimización para la conversión.

Si el cargo alternativo genera un error, el estado de PaymentIntent se actualiza a requires_payment_method. Si este cargo alternativo se procesa correctamente, la transferencia de responsabilidad no cubre el cargo, a menos que el cargo alternativo presente el estado attempt_acknowledged en payment_method_details.card.three_d_secure.result.

Para obtener más información sobre los pagos no autenticados y la transferencia de responsabilidad, consulta el artículo Uso de Radar para Equipos de Fraude a fin de evitar cargos sin transferencia de responsabilidad.