Si un pago exige la autenticación mediante 3D Secure, pero no podemos iniciarla, haremos un último intento de completarlo sin la autenticación. El resultado de este cargo alternativo actualiza el estado de PaymentIntent a uno de los siguientes:

• succeeded: el pago se ha completado y se ha creado un objeto Charge con el método de pago suministrado. No hay que hacer nada más.
• requires_capture: la solicitud se ha completado sin autenticación y puedes continuar para capturar los fondos.
• requires_payment_method: el cargo ha fallado y es posible que sea necesario otro método de pago.

Normalmente, un pago que active 3D Secure dará lugar a un PaymentIntent con el estado requires_action. A continuación te explicamos los pasos de un flujo de pago habitual que solicita 3D Secure:

1. El cliente proporciona la información de pago y se adjunta al PaymentIntent.
2. Stripe comprueba si se necesita 3D Secure. Esto se puede determinar mediante reglas de Radar, si se ha solicitado de forma manual en el pago y según otros factores.
3. Stripe determina lo siguiente sobre 3D Secure:
   1. Si no se necesita, continuamos e intentamos hacer el cargo en la tarjeta. En este momento, el banco puede devolver un «pago rechazado temporal», con el que se indica que es necesaria la autenticación para poder hacer el cargo correctamente.
   2. Si se necesita, vamos al siguiente paso para activar 3DS.
4. Stripe inicia 3D Secure.
5. Stripe ha podido solicitar 3D Secure y espera a que el cliente se autentique. El PaymentIntent pasa al estado requires_action.

Si los pasos 4 o 5 no son satisfactorios, el flujo de pago anterior cambiaría y se parecería al siguiente:

1. El cliente proporciona la información de pago y se adjunta al PaymentIntent.
2. Stripe comprueba si se necesita 3D Secure (en función de las reglas de Radar, si se ha solicitado de forma manual en el pago y según otros factores).
3. Stripe determina que se necesita 3D Secure e intenta llevar a cabo el proceso de autenticación.
4. Encontramos un problema al iniciar el proceso de 3D Secure. Puede deberse a diferentes motivos, como que la tarjeta no admita 3DS, que haya un error de procesamiento o que el servidor de 3D Secure del emisor esté caído, entre otros.
5. Aunque no se ha completado el proceso de 3DS satisfactoriamente, continuamos y hacemos un último intento de pago sin autenticación. De esta forma, el PaymentIntent cambia al estado succeeded, requires_capture o requires_payment_method, en función del resultado del pago.

Intentamos hacerlo así en vez de bloquear el pago de inmediato o devolver un error porque decidimos optimizar el proceso para la conversión.

Si el cargo alternativo falla, el estado del PaymentIntent cambia a requires_payment_method. En caso de que el cargo alternativo se haga satisfactoriamente, este no estará cubierto por la transferencia de responsabilidad, a no ser que tenga 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 Cómo usar Radar for Fraud Teams para evitar cargos sin transferencia de responsabilidad.