If a payment requires 3D Secure authentication but we are unable to initiate it, we will make a final attempt to complete the payment without authentication. The results from this fallback charge updates the PaymentIntent status to one of the following:

• succeeded: The payment completed, creating a Charge with the supplied payment method. No further steps are required.
• requires_capture: The request completed without authentication, allowing you to continue to capture the funds.
• requires_payment_method: The charge failed potentially requiring a another payment method

Typically, a payment that triggers 3D Secure will result in a PaymentIntent with a status of requires_action. Here is a walkthrough of a typical payment flow that requests 3D Secure:

1. Your customer provides their payment information and it is attached to the PaymentIntent.
2. Stripe checks if 3D Secure is needed. This can be determined from Radar rules, whether it was manually requested for the payment, and other factors
3. Stripe determines that 3D Secure is
   1. not required so we go ahead and attempt to charge the card. At this point, the bank can send back a "soft decline" indicating that authentication is required for the charge to succeed
   2. required so we continue to the next step to trigger 3DS
4. Stripe starts 3D Secure
5. Stripe was able to request 3D secure and now we wait for the customer to authenticate. The Payment Intent transitions to a status of requires_action.

If steps 4 or 5 is not successful, then the above payment flow would change to look something like this:

1. Your customer provides their payment information and it is attached to the PaymentIntent.
2. Stripe check if 3D Secure is needed (determined from Radar rules, whether it was manually requested for the payment, and other factors).
3. Stripe determines that 3D Secure is required and attempts the authentication process.
4. We run into an issue while starting the 3D Secure process. This could happen for a variety of reasons such as the card not supporting 3DS, a processing error, issuer’s 3D Secure server is down, etc.
5. Even though 3DS wasn’t successfully completed, we go ahead and make a final payment attempt w/o authentication. This causes the PaymentIntent to transition to a status of succeeded, requires_capture, or requires_payment_method depending on the outcome of the payment.

The reason we attempt this instead of immediately blocking the payment or returning an error, is that we are choosing to optimize for conversion.

If the fallback charge fails, then the PaymentIntent status updates to requires_payment_method. In the event that this fallback charge is successful, the charge is not covered by liability shift, unless the fallback charge has an attempt_acknowledged status on payment_method_details.card.three_d_secure.result.

For more information on unauthenticated payments and Liability Shift see Using Radar for Fraud Teams to prevent charges without Liability Shift