Se um pagamento exigir autenticação do 3D Secure, mas nós não conseguirmos iniciar o processo, tentaremos concluir o pagamento sem autenticação. Os resultados dessa cobrança de fallback atualizam o status do PaymentIntent para uma destas opções:

• succeeded: O pagamento foi concluído e uma cobrança foi criada com a forma de pagamento informada. Nenhuma outra ação é necessária.
• requires_capture: A solicitação foi concluída sem autenticação, permitindo a continuação da captura dos fundos.
• requires_payment_method: Houve falha na cobrança, o que pode exigir outra forma de pagamento.

Geralmente, quando um pagamento aciona o 3D Secure, o resultado é um PaymentIntent com o status requires_action. Veja aqui a explicação de um fluxo de pagamento que costuma exigir o protocolo 3D Secure:

1. O cliente fornece os dados de pagamento, que são então anexados ao PaymentIntent.
2. A Stripe verifica se a transação requer o 3D Secure. Isso pode ser determinado com base nas regras do Radar (por exemplo, se o 3D Secure foi solicitado manualmente para o pagamento), entre outros fatores
3. A Stripe determina que o 3D Secure
   1. não é exigido e, por isso, tentamos fazer a cobrança do cartão. Nesta etapa, o banco pode emitir uma "recusa simples" para indicar que a autenticação é exigida para a execução da cobrança
   2. é exigido e, por isso, passamos à etapa seguinte: acionar o 3DS
4. A Stripe inicia o 3D Secure
5. A Stripe conseguiu solicitar o 3D Secure e fica aguardando a autenticação do cliente. O status do PaymentIntent muda para requires_action.

Se houvesse falha nas etapas 4 ou 5, o fluxo de pagamento acima mudaria para algo mais ou menos assim:

1. O cliente fornece os dados de pagamento, que são então anexados ao PaymentIntent.
2. A Stripe verifica se o 3D Secure é exigido, o que pode ser determinado com base nas regras do Radar (por exemplo, se ele foi solicitado manualmente para o pagamento), entre outros fatores.
3. A Stripe determina que o 3D Secure é exigido e tenta iniciar o processo de autenticação.
4. Surge um problema quando iniciamos o processo do 3D Secure. Os motivos podem variar: o cartão não aceita o 3DS, erro de processamento, o servidor 3D Secure do emissor está indisponível etc.
5. Mesmo não tendo concluído o processo do 3DS, fazemos uma última tentativa de pagamento sem autenticação. Isso faz o status do PaymentIntent mudar para succeeded, requires_capture ou requires_payment_method, dependendo do resultado do pagamento.

Nosso motivo para fazer isso, em vez de bloquear imediatamente o pagamento ou retornar um erro, é o intuito de otimizar a conversão.

Se houver falha na cobrança de fallback, o status do PaymentIntent será atualizado para requires_payment_method. Caso essa cobrança de fallback seja concluída, a cobrança não será coberta por transferência de responsabilidade, a menos que o status da cobrança de fallback seja mostrado como attempt_acknowledged em payment_method_details.card.three_d_secure.result.

Para obter mais informações sobre pagamentos não autenticados e transferência de responsabilidade, consulte Uso do Radar for Fraud Teams para evitar cobranças sem transferência de responsabilidade