Si un paiement nécessite une authentification 3D Secure, mais que nous ne sommes pas en mesure de l'initier, nous tenterons une dernière fois d'effectuer le paiement sans authentification. Le résultat de ce paiement de repli met à jour l'état du PaymentIntent avec l'une des valeurs suivantes :

• succeeded : le paiement a été effectué et un débit a été créé avec le moyen de paiement fourni. Aucune autre étape n'est requise.
• requires_capture : la requête a été exécutée sans authentification, vous autorisant à poursuivre pour capturer les fonds.
• requires_payment_method : le paiement a échoué, ce qui peut nécessiter l'utilisation d'un autre moyen de paiement

En règle générale, un paiement qui déclenche 3D Secure donne lieu à un PaymentIntent dont l'état est requires_action. Nous vous présentons ci-dessous un flux de paiement typique faisant appel à 3D Secure :

1. Votre client fournit ses informations de paiement et celles-ci sont associées au PaymentIntent.
2. Stripe vérifie si une authentification 3D Secure est nécessaire. Cela peut être déterminé par les règles Radar, si la demande a été faite manuellement pour le paiement, et d'autres facteurs
3. Stripe détermine que 3D Secure
   1. n'est pas nécessaire et nous essayons donc de débiter la carte. À ce stade, la banque peut renvoyer un « soft decline » indiquant qu'une authentification est nécessaire pour que le paiement soit accepté
   2. est nécessaire et nous passons donc à l'étape suivante pour déclencher 3DS
4. Stripe lance 3D Secure
5. Stripe a pu demander l'authentification 3D Secure et nous attendons maintenant que le client s'authentifie. Le Payment Intent passe à l'état requires_action.

Si les étapes 4 ou 5 n'aboutissent pas, le flux de paiement ci-dessus sera modifié comme suit :

1. Votre client fournit ses informations de paiement et celles-ci sont associées au PaymentIntent.
2. Stripe vérifie si 3D Secure est nécessaire (déterminé par les règles Radar, si la demande a été faite manuellement pour le paiement, et d'autres facteurs).
3. Stripe détermine que 3D Secure est nécessaire et lance le processus d'authentification.
4. Nous rencontrons un problème lors du lancement du processus 3D Secure. Cela peut se produire pour diverses raisons, par exemple en cas d'incompatibilité de la carte avec le système 3DS, d'erreur de traitement, de panne du serveur 3D Secure de l'émetteur, etc.
5. Même si l'authentification 3DS n'a pas abouti, nous procédons à une dernière tentative de paiement sans authentification. Le PaymentIntent passe alors à l'état succeeded, requires_capture, ou requires_payment_method en fonction du résultat du paiement.

Si nous procédons ainsi au lieu de bloquer immédiatement le paiement ou de renvoyer une erreur, c'est parce que nous avons choisi d'optimiser la conversion.

Si le paiement de repli échoue, l'état du PaymentIntent passe à requires_payment_method. Dans le cas où ce paiement de repli est accepté, il n'est pas couvert par le transfert de responsabilité, sauf si le paiement de repli a un statut attempt_acknowledged sur payment_method_details.card.three_d_secure.result.

Pour plus d'informations sur les paiements non authentifiés et le transfert de responsabilité, voir Utilisation de Radar for Fraud Teams pour empêcher les paiements sans transfert de responsabilité