Se un pagamento richiede l'autenticazione 3D Secure ma noi non siamo in grado di avviarlo, faremo un ultimo tentativo per completare il pagamento senza autenticazione. I risultati di questo addebito alternativo aggiornano lo stato di PaymentIntent in uno dei seguenti:

• riuscito: Il pagamento è stato effettuato ed è stato creato un addebito con la modalità di pagamento fornita. Non sono richiesti ulteriori passaggi.
• requires_capture: La richiesta è completata senza autenticazione, consentendoti di continuare ad acquisire i fondi.
• requires_payment_method: L'addebito non è andato a buon fine probabilmente perché richiede un'altra modalità di pagamento

Generalmente, un pagamento che attiva 3D Secure comporterà un PaymentIntent con lo stato requires_action. Ecco una spiegazione dettagliata di un tipico flusso di pagamento che richiede 3D Secure:

1. il tuo cliente fornisce le informazioni sul pagamento, che sono allegate al PaymentIntent.
2. Stripe controlla se è necessario 3D Secure. Ciò può essere determinato dalle regole Radar, se è stato richiesto manualmente per il pagamento e altri fattori
3. Stripe stabilisce che 3D Secure è
   1. non richiesto, quindi andiamo avanti e tentiamo di eseguire l'addebito sulla carta. A questo punto, la banca può restituire un "pagamento rifiutato non grave" che indica che è necessaria l'autenticazione affinché l'addebito vada a buon fine
   2. richiesto, così continuiamo con il passaggio successivo per attivare 3DS
4. Stripe avvia 3D Secure
5. Stripe è riuscita a richiedere 3D Secure e ora attendiamo che il cliente si autentichi. Il Payment Intent passa allo stato requires_action.

Se i passaggi 4 o 5 non vanno a buon fine, il flusso di pagamento di cui sopra cambierà in questo modo:

1. il tuo cliente fornisce le informazioni sul pagamento, che sono allegate al PaymentIntent.
2. Stripe controlla se 3D Secure è necessario (in base alle regole Radar, se è stato richiesto manualmente per il pagamento e altri fattori).
3. Stripe stabilisce che è necessario 3D Secure e tenta il processo di autenticazione.
4. Ci imbattiamo in un problema mentre iniziamo il processo 3D Secure. Ciò potrebbe accadere per molti motivi, ad esempio la carta non supporta 3DS, errore di elaborazione, il server 3D Secure della società emittente è fuori uso, ecc.
5. Anche se 3DS non è stato completato con successo, andiamo avanti e facciamo un ultimo tentativo di pagamento senza autenticazione. In questo modo il PaymentIntent passa allo stato riuscito, requires_capture o requires_payment_method a seconda del risultato del pagamento.

Il motivo per cui tentiamo di fare ciò anziché bloccare immediatamente il pagamento o generare un errore è che stiamo scegliendo di ottimizzare la conversione.

Se l'addebito alternativo non va a buon fine, lo stato del PaymentIntent viene aggiornato in requires_payment_method. Nel caso in cui questo addebito alternativo vada a buon fine, l'addebito non è coperto dalla traslazione di responsabilità, a meno che l'addebito alternativo non abbia lo stato attempt_acknowledged su payment_method_details.card.three_d_secure.result.

Per ulteriori informazioni sui pagamenti non autenticati e sulla traslazione di responsabilità, consulta Usare Radar for Fraud Teams per evitare addebiti senza traslazione di responsabilità