Authentification avec 3D Secure

You can integrate 3D Secure (3DS) authentication into your checkout flow on multiple platforms, including Web, iOS, Android, and React Native. This integration runs 3D Secure 2 (3DS2) when supported by the customer’s bank and falls back to 3D Secure 1 otherwise. You can also perform 3DS authentication on Stripe while acquiring the transaction with another payment service provider (PSP) by using the Standalone 3DS product.

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 triggers 3DS automatically if mandated by regulations such as Strong Customer Authentication in Europe, industry guidelines such as the Credit Card Security Guidelines in Japan, if requested by an issuer with a soft decline code, or if certain Stripe optimizations apply.

You can also use Radar or the API to decide when to prompt users for 3DS authentication. This allows you to customize the authentication process for each user based on your chosen parameters. However, not all transactions support 3DS, for example wallets or off-session payments.

When a payment triggers 3DS, the card issuer requires the customer to authenticate to complete the payment, as long as 3DS authentication is supported for that card. While Stripe initiates the authentication request, the requirement comes from the issuer. Depending on the frontend you’re using, this might require you to display the 3DS Flow.

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. When 3DS flow information is received from the issuer, Stripe submits the request for the issuer to authenticate the cardholder. The PaymentIntent transitions to a status of 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é.
   • Les données des demandes d’authentification 3DS sont généralement fournies par le client au moment de la transaction. Pour faciliter la transaction et réduire le risque d’échec de l’authentification, nous pouvons compléter ces demandes par des informations provenant d’autres sources. Il peut s’agir de données saisies par votre client dans le tunnel de paiement, de données de transactions antérieures entre vous et un client, ou d’informations pertinentes provenant de la carte du client ou de l’émetteur.
   • 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 provides fraud controls to dynamically request 3DS when creating or confirming a PaymentIntent or SetupIntent. You can configure these rules in your 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

The default method to trigger 3DS is using Radar to dynamically request 3D Secure based on risk level and other requirements. Triggering 3DS manually is for advanced users integrating Stripe with their own fraud engine.

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_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -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.

Stripe’s mandatory authentication rules run automatically, regardless of whether or not you manually request 3DS. Any 3DS requests from you are additional to those required for 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_BQokikJOvBiI2HlWgH4olfQ2
:" \
  --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 un code CVC, un code postal et date d’expiration future pour déclencher des flux de contestation d’authentification 3DS dans un environnement de 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 dans un environnement de test pour déclencher l’authentification sur des cartes de test. En savoir plus sur les moyens de tester vos règles Radar.

Litiges et transfert de responsabilité

The liability shift rule typically applies to payments successfully authenticated using 3D Secure. In some cases, liability shift applies with equivalent cryptograms, such as Apple Pay or Google Pay. If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer.

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 généralement 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.

Liability shift might also occur when the card network requires 3DS, but it isn’t available for the card or issuer. This can happen if the issuer’s 3DS provider is down or if the issuer doesn’t support it, despite the card network requiring support. During the payment process, the cardholder isn’t prompted to complete 3DS authentication, because the card isn’t enrolled. Although the cardholder didn’t complete 3DS authentication, liability can still shift to the issuer.

Stripe renvoie l’indicateur d’e-commerce (ECI) demandé dans le electronic_commerce_indicator du résultat de l’authentification 3DS. Cet indicateur peut aider à déterminer si un paiement doit respecter la règle du transfert de responsabilité. Dans la mesure où l’authentification 3DS intervient après la réponse initiale du Payment Intent, elle provient généralement d’un événement charge.succeeded envoyé à l’un de vos endpoints de webhook configurés ou à d’autres destinations d’événement. L’ECI demandé peut être déclassé dans la réponse de l’émetteur, ce que nous n’affichons pas.

Sometimes payments that are successfully authenticated using 3DS don’t fall under liability shift. This is rare and can happen, for example, if you have an excessive level of fraud on your account and are enrolled in a fraud monitoring program. Certain networks have also exempted some industries from liability shift. For example, Visa doesn’t support liability shift for businesses engaging in wire transfer or money orders, non-financial institutions offering foreign or non-fiat currency, or stored-value card purchase or load.

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.