Authentification avec 3D Secure

Vous pouvez intégrer l’authentification 3D Secure (3DS) à votre flux de paiement sur différentes plateformes, notamment Web, iOS, Android et React Native. Cette intégration exécute 3D Secure 2 (3DS2) si cette version est prise en charge par la banque du client, et utilise plutôt 3D Secure 1 dans le cas contraire. Pour utiliser le service 3DS de Stripe avec d’autres prestataires, contactez le service d’assistance.

Web

iOS

Android

Le client saisit ses informations de carte.

La banque du client évalue la transaction et peut lancer l’authentification 3D Secure.

Si la banque le demande, le client se soumet à une étape d’authentification supplémentaire.

Contrôler le flux 3DS

Stripe déclenche automatiquement l’authentification 3DS lorsque la réglementation l’impose, par exemple dans le cadre de l’authentification forte du client ou si un émetteur le demande avec un code de refus partiel authentication_required.

Vous pouvez également utiliser des règles Radar ou l’API pour déterminer dans quels cas inviter les clients à s’authentifier avec 3DS, sur la base des paramètres de votre choix. Cependant, toutes les transactions ne prennent pas en charge 3DS (par exemple, celles basées sur des portefeuilles ou les paiements hors session).

Lorsqu’un paiement déclenche 3DS, Stripe demande à l’utilisateur de s’authentifier pour finaliser le paiement, à condition que l’authentification 3DS soit disponible pour la carte en question. Selon le front-end que vous utilisez, vous pouvez afficher le flux 3DS.

Dans le cas d’un flux classique de l’API Payment Intent qui déclenche l’authentification 3DS :

1. L’utilisateur saisit ses informations de paiement, qui confirment un PaymentIntent, un SetupIntent ou associent un PaymentMethod à un objet Customer.
2. Stripe détermine si la transaction prend en charge et nécessite 3DS sur la base des mandats réglementaires, des règles Radar, des requêtes manuelles à l’API, des refus de paiement provisoires de l’émetteur et d’autres critères.
3. Si 3DS est :
   • Non requis : en raison, par exemple, d’une exemption, Stripe tente le paiement. Le PaymentIntent passe à l’état processing. Si l’émetteur le demande via un refus partiel de paiement, nous effectuons automatiquement une nouvelle tentative et poursuivons comme si 3DS était exigé.
   • Non pris en charge : le PaymentIntent passe à l’état requires_payment_method. En fonction de la raison pour laquelle 3DS a été déclenché, il peut être possible de poursuivre l’étape d’autorisation du paiement. Dans ce cas, le PaymentIntent passe à l’état processing.
   • Obligatoire : Stripe lance le flux d’authentification 3DS en contactant le serveur de contrôle d’accès 3D Secure (ACS) de l’émetteur de la carte et en lançant le flux 3DS.
4. Lorsque Stripe reçoit les informations de flux 3DS de l’émetteur, nous tentons l’authentification. Le PaymentIntent passe à l’état requires_action :
   • Découvrez ci-dessous comment afficher l’action 3DS requise. Les émetteurs peuvent demander différents types d’actions de flux 3DS, qui peuvent ne pas toujours se traduire par l’affichage d’une demande d’authentification 3DS (par exemple, un flux simple).
   • Si l’émetteur ne prend pas du tout en charge 3DS ou en cas de panne, Stripe peut tenter d’effectuer le paiement sans authentification, si cela est autorisé.
   • Data for 3DS authentication requests is typically provided by the customer at the time of the transaction. To reduce friction and the possibility of failed authentication, we might complete these requests with data we infer from other sources such as data collected from your customer during the payment flow, records related to your customer’s past transactions with you, or relevant information available from the customer’s card or issuers.
   • Si Stripe a déjà accès à toutes les données 3DS requises, notre serveur 3DS optimisé peut tenter de compléter la demande d’authentification pour vous tout en confirmant le PaymentIntent. Le PaymentIntent peut alors passer directement à l’état processing si le flux 3DS aboutit, ou à l’état requires_action si des étapes ou des données supplémentaires sont nécessaires pour compléter le flux 3DS.
5. En fonction du résultat de l’authentification 3DS :
   • Authentifié : Stripe tente le paiement et le PaymentIntent passe à l’état processing.
   • Échec : le PaymentIntent passe à l’état requires_payment_method, indiquant que vous devez utiliser un autre moyen de paiement, ou que vous pouvez effectuer une nouvelle tentative d’authentification 3DS après une nouvelle confirmation.
   • Autres scénarios : en fonction de la raison pour laquelle le paiement a déclenché l’authentification 3DS, il peut être permis de poursuivre l’autorisation dans des cas particuliers. Par exemple, un résultat attempt_acknowledged entraîne un paiement et le PaymentIntent passe à l’état processing.
     • La création de mandats électroniques indiens pour les paiements récurrents constitue une exception. Tout résultat autre que authenticated est considéré comme un échec.
6. En fonction du résultat du paiement, le PaymentIntent passe à l’un des états suivants : succeeded, requires_capture ou requires_payment_method.

Pour déterminer si un paiement par carte a fait l’objet d’une tentative d’authentification 3DS ou prenait en charge cette méthode, lisez la propriété three_d_secure sur les informations de la carte au niveau de l’élément payment_method_details du paiement. Stripe renseigne la propriété three_d_secure lorsque le client tente d’authentifier la carte. L’attribut three_d_secure.result indique le résultat de l’authentification.

Utiliser des règles Radar dans le Dashboard

Stripe propose des règles Radar par défaut pour exiger dynamiquement 3DS lors de la création ou la confirmation d’un PaymentIntent ou d’un SetupIntent. Vous pouvez configurer ces règles dans votre Dashboard.

Si vous disposez de Radar for Fraud Teams, vous pouvez ajouter des règles 3DS personnalisées.

Demander manuellement une authentification 3DS avec l’API

La méthode de déclenchement par défaut de l’authentification 3DS consiste à utiliser Radar pour demander dynamiquement une authentification en fonction du niveau de risque et d’autres paramètres. Le déclenchement manuel de l’authentification 3DS est réservé aux utilisateurs avancés qui intègrent Stripe à leur propre moteur de fraude.

Pour déclencher l’authentification 3DS manuellement, définissez la méthode payment_method_options[card][request_three_d_secure] sur any ou challenge (flux complexe) en fonction de vos objectifs lors de la création ou de la confirmation d’un objet PaymentIntent ou SetupIntent, ou lors de la création d’une session Checkout. Ce processus est identique pour les paiements ponctuels et la configuration d’un moyen de paiement en vue de paiements futurs. Lorsque vous utilisez ce paramètre, Stripe procède à l’authentification 3DS sans prendre en compte les éventuelles règles Radar 3D Secure dynamique associées à l’objet PaymentIntent, SetupIntent ou à la session Checkout.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_4eC39HqLyjWDarjtT1zdp7dc
:" \
  -d amount=1000 \
  -d currency=usd \
  -d "payment_method_options[card][request_three_d_secure]"=any

Pour savoir quand vous devez fournir ce paramètre, définissez à quel moment votre moteur de fraude détecte le risque. Par exemple, si votre moteur de fraude n’inspecte que les informations de carte, vous savez s’il faut demander ou non une authentification 3DS avant de créer l’objet PaymentIntent ou SetupIntent. Si le moteur de fraude inspecte les informations de carte et de transaction, fournissez le paramètre pendant la confirmation, une fois que vous disposez de davantage d’informations. Transmettez ensuite le PaymentIntent ou le SetupIntent à votre client pour finaliser l’opération.

Découvrez comment utiliser le paramètre request_three_d_secure pour chaque cas de figure dans la documentation sur l’API :

• Créer un PaymentIntent
• Confirmer un PaymentIntent
• Créer un SetupIntent
• Confirmer un SetupIntent
• Créer une session Checkout

Définissez request_three_d_secure sur any pour déclencher manuellement l’authentification 3DS en favorisant un flux de type frictionless (simple), ce qui augmentera la probabilité que l’authentification soit effectuée sans solliciter d’informations supplémentaires de la part du client.

Définissez request_three_d_secure sur challenge pour déclencher l’authentification 3DS via un flux de type challenge (complexe), qui oblige le client à répondre à une demande d’authentification active.

Stripe ne peut pas garantir votre choix, car c’est l’émetteur qui détermine le flux d’authentification final. Pour prendre connaissance du flux d’authentification utilisé, examinez l’attribut authentication_flow de la propriété three_d_secure de l’objet Charge ou SetupAttempt. Pour en savoir plus sur les flux 3DS, lisez notre guide.

Les règles SCA de Stripe s’exécutent automatiquement, que vous demandiez l’authentification 3DS manuellement ou non. Aucune invite 3DS supplémentaire n’est obligatoire dans le cadre de la SCA.

Afficher le flux 3DS

next_action: {
    type: 'redirect_to_url',
    redirect_to_url: {
      url: 'https://hooks.stripe.com/...',
      return_url: 'https://mysite.com'
    }
}

var action = intent.next_action;
  if (action && action.type === 'redirect_to_url') {
    window.location = action.redirect_to_url.url;
  }

stripe.confirmCardPayment(
  '{{PAYMENT_INTENT_CLIENT_SECRET}}',
  {
    payment_method: {card: cardElement},
    return_url: 'https://example.com/return_url'
  },
  // Disable the default next action handling.
  {handleActions: false}
).then(function(result) {
  // Handle result.error or result.paymentIntent
  // More details in Step 2.
});

curl https://api.stripe.com/v1/payment_intents/{{PAYMENT_INTENT_ID}}/confirm \
  -u "
sk_test_4eC39HqLyjWDarjtT1zdp7dc
:" \
  --data-urlencode return_url="https://example.com/return_url"

var iframe = document.createElement('iframe');
  iframe.src = paymentIntent.next_action.redirect_to_url.url;
  iframe.width = 600;
  iframe.height = 400;
  yourContainer.appendChild(iframe);

window.top.postMessage('3DS-authentication-complete');

function on3DSComplete() {
    // Hide the 3DS UI
    yourContainer.remove();

    // Check the PaymentIntent
    stripe.retrievePaymentIntent('{{PAYMENT_INTENT_CLIENT_SECRET}}')
      .then(function(result) {
        if (result.error) {
          // PaymentIntent client secret was invalid
        } else {
          if (result.paymentIntent.status === 'succeeded') {
            // Show your customer that the payment has succeeded
          } else if (result.paymentIntent.status === 'requires_payment_method') {
            // Authentication failed, prompt the customer to enter another payment method
          }
        }
      });
  }

  window.addEventListener('message', function(ev) {
    if (ev.data === '3DS-authentication-complete') {
      on3DSComplete();
    }
  }, false);

Tester le flux 3DS

Utilisez une carte de test Stripe avec n’importe quel CVC, code postal et date d’expiration postérieure à la date du jour pour déclencher des demandes d’authentification 3DS en mode test.

Lorsque vous créez une intégration avec vos clés API de test, une page d’authentification factice s’affiche. Sur cette page, vous pouvez autoriser ou annuler le paiement. L’autorisation du paiement simule une authentification réussie et vous redirige vers l’URL de redirection spécifiée. En cliquant sur le bouton Échec, vous simulez une tentative d’authentification infructueuse.

Pour les autres cartes de test Visa et Mastercard, aucune authentification ne sera demandée.

Vous pouvez créer des règles Radar personnalisées en mode test pour déclencher l’authentification sur des cartes de test. Cliquez ici pour en savoir plus sur le test de vos règles Radar.

Litiges et transfert de responsabilité

La règle de transfert de responsabilité s’applique aux paiements authentifiés à l’aide de 3D Secure, ou d’un cryptogramme équivalent comme Apple Pay ou Google Pay dans certains cas. Si un titulaire de carte conteste un paiement 3DS pour fraude, vous transférez la responsabilité à l’émetteur de la carte.

Si une carte ne prend pas en charge 3DS ou qu’une erreur survient pendant le processus d’authentification, le paiement se poursuit normalement. Dans ce cas, la responsabilité n’est généralement pas transférée à l’émetteur, car aucune authentification 3DS n’a été effectuée.

En pratique, cela signifie que vous ne recevrez pas de litiges pour fraude si le paiement était couvert par la règle de transfert de responsabilité, mais que vous pourrez tout de même recevoir une alerte de suspicion de fraude. Il se peut que vous receviez un faible pourcentage de litiges pour fraude : vous trouverez ci-dessous une liste de quelques cas où la règle du transfert de responsabilité est susceptible de ne pas s’appliquer.

Il est possible que vous receviez une demande d’informations concernant un paiement authentifié à l’aide de 3DS. Ce type de litige n’entraîne pas de contestation de paiement car il s’agit uniquement d’une demande de renseignements.

Si vous recevez une demande pour un paiement authentifié par 3D Secure, vous devez y répondre, faute de quoi la banque du titulaire de la carte peut initier une contestation de paiement « sans réponse » qui pourrait invalider le transfert de responsabilité. Pour éviter cette situation, vous devez soumettre suffisamment d’informations sur le paiement. Indiquez notamment ce qui a été commandé (biens matériels, produits électroniques ou services, etc.), mais aussi comment et à quel destinataire la livraison a été effectuée.

Un transfert de responsabilité peut également intervenir lorsque le réseau de la carte exige une authentification 3DS, mais que cette méthode n’est pas disponible pour la carte ou l’émetteur. Cette situation peut se produire si le serveur 3DS de l’émetteur est indisponible ou si l’émetteur ne prend pas en charge le protocole 3DS alors que le réseau de la carte impose de le faire. En effet, dans un tel cas, le titulaire de la carte n’est pas invité à procéder à l’authentification 3DS au cours du processus de paiement puisque sa carte n’y est pas inscrite. Pour autant, la responsabilité de la transaction peut bel et bien être transférée à l’émetteur.

Stripe renvoie l’indicateur d’e-commerce (ECI) demandé dans le paramètre electronic_commerce_indicator du résultat de l’authentification 3DS. Cet indicateur peut aider à déterminer si un paiement doit être soumis à la règle de transfert de responsabilité. Comme l’authentification 3DS se produit à la suite de la réponse initiale du Payment Intent, vous l’obtiendrez généralement à partir de l’événement charge.succeeded envoyé à l’une de vos destinations d’événement. L’ECI demandé peut être déclassé dans la réponse de l’émetteur, ce que nous n’affichons pas.

Certains paiements peuvent faire l’objet d’une authentification 3DS réussie sans transfert de responsabilité. Cette situation est rare, mais peut se produire si votre compte présente un taux élevé de fraude et que vous êtes inscrit à un programme de surveillance contre la fraude. Certains réseaux ont également exempté certains secteur d’activité du transfert de responsabilité. Par exemple, Visa ne prend pas en charge le transfert de responsabilité des entreprises effectuant des virements bancaires ou des mandats postaux, des établissements non financiers proposant des devises étrangères ou non fiduciaires, ni des achats ou chargements de cartes prépayées.

Dans de rares cas, le transfert de responsabilité peut être déclassé après l’autorisation, ou le système de rejet des litiges des réseaux de cartes peut ne pas détecter le transfert de responsabilité pour une transaction. Dans ce cas, si vous contestez le litige, Stripe ajoute automatiquement l’ECI demandé et le résultat de l’authentification 3DS du paiement aux détails de vos preuves. Nous vous encourageons toutefois à fournir des informations supplémentaires pour augmenter vos chances de remporter le litige.

Règles Radar personnalisées pour 3DS et transfert de responsabilité

Si vous disposez de Radar for Fraud Teams, vous pouvez personnaliser vos règles pour déterminer quand exiger 3DS et comment gérer chaque résultat d’authentification et transfert de responsabilité spécifique. Les règles d’authentification forte du client (SCA) de Stripe s’exécutent automatiquement et indépendamment des règles Radar personnalisées, et bloquent les paiements non authentifiés, sauf exemption.