Si un paiement nécessite une authentification 3D Secure, mais que nous ne parvenons pas à l'initier, nous ferons une dernière tentative pour finaliser le paiement sans authentification. Suite à ce paiement de remplacement, le statut de PaymentIntent est mis à jour et affiche 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 demande a été traitée sans authentification, vous permettant ainsi de continuer à capturer les fonds ;
• requires_payment_method : le paiement a échoué, ce qui pourrait exiger le recours à un autre moyen de paiement.

En général, un paiement qui déclenche 3D Secure se traduira par un PaymentIntent dont le statut sera requires_action. Voici l'aperçu d'un tunnel de paiement classique qui nécessite 3D Secure :

1. Votre client fournit ses informations de paiement et celles-ci sont jointes au PaymentIntent.
2. Stripe vérifie si 3D Secure est nécessaire. Cette nécessité peut être déterminée grâce aux règles Radar, selon si la demande pour le paiement est manuelle et en fonction d'autres facteurs.
3. Stripe détermine que 3D Secure
   1. n'est pas nécessaire, nous poursuivons nos opérations et essayons de débiter la carte. À ce stade, la banque peut renvoyer un « refus de paiement provisoire » indiquant qu'une authentification est requise pour que le débit réussisse.
   2. est nécessaire, nous passons donc à l'étape suivante pour déclencher 3DS.
4. Stripe lance 3D Secure.
5. Stripe a pu demander à utiliser 3D Secure et nous attendons maintenant que le client s'authentifie. Le Payment Intent passe au statut requires_action.

Si les étapes 4 ou 5 échouent, le tunnel de paiement ci-dessus s'adapte comme suit :

1. Votre client fournit ses informations de paiement et celles-ci sont jointes au PaymentIntent.
2. Stripe vérifie si 3D Secure est nécessaire (d'après les règles Radar, selon si la demande pour le paiement est manuelle et en fonction d'autres facteurs).
3. Stripe détermine que 3D Secure est nécessaire et tente le processus d'authentification.
4. Nous rencontrons un problème lors du démarrage du processus 3D Secure. Cela peut se produire pour diverses raisons, par exemple, la carte ne prend pas en charge 3DS, une erreur de traitement est survenue, le serveur 3D Secure de l'émetteur est en panne, etc.
5. Même si 3DS n'a pas abouti, nous poursuivons nos opérations et effectuons une dernière tentative de paiement sans authentification. PaymentIntent passe ainsi au statut succeeded, requires_capture ou requires_payment_method en fonction du résultat du paiement.

Nous optons pour cette solution plutôt que de bloquer immédiatement le paiement ou de renvoyer une erreur, car nous préférons optimiser la conversion.

Si le paiement de remplacement échoue, le statut de PaymentIntent devient alors requires_payment_method. Dans le cas où ce paiement de remplacement aboutit, il n'est pas couvert par le transfert de responsabilité, à moins que son statut attempt_acknowledged soit payment_method_details.card.three_d_secure.result.

Pour plus d'informations sur les paiements non authentifiés et le transfert de responsabilité, consultez la page Utilisation de Radar for Fraud Teams pour éviter les paiements sans transfert de responsabilité.