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 3DS Secure 1 dans le cas contraire. Vous pouvez également effectuer l’authentification 3DS sur Stripe lors de l’acquisition de la transaction avec un autre prestataire de paiement (PSP) en utilisant le produit 3DS autonome.

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 des réglementations telles que l’authentification forte du client en Europe s’appliquent, si des directives du secteur (telles que les directives de sécurité relatives aux cartes de crédit au Japon) l’exigent, si un émetteur le demande avec un code de refus temporaire ou lorsque certaines optimisations Stripe s’appliquent.

Vous pouvez également utiliser Radar ou l’API pour décider quand inviter les utilisateurs à s’authentifier par 3DS. Cela vous permet de personnaliser le processus d’authentification pour chaque utilisateur en fonction des paramètres que vous avez choisis. Cependant, certaines transactions ne prennent pas en charge 3DS, par exemple les wallets ou les paiements hors session.

Lorsqu’un paiement déclenche l’authentification 3DS, l’émetteur de la carte peut exiger que le client s’authentifie pour finaliser le paiement, à condition que l’authentification 3DS soit prise en charge pour cette carte. Bien que Stripe initie la demande d’authentification, l’exigence provient de l’émetteur. Selon le front-end que vous utilisez, cela peut vous obliger à 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 3DS (ACS) de l’émetteur de la carte et en lançant le flux 3DS.
4. Lorsque les informations sur le flux 3DS sont reçues de l’émetteur, Stripe soumet la requête à l’émetteur afin d’authentifier le titulaire de la carte. 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é.
   • 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 propose des contrôles anti-fraude pour exiger l’authentification 3DS de manière dynamique lors de la création ou de 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 par défaut pour déclencher le 3DS consiste à utiliser Radar pour demander dynamiquement le 3D Secure en fonction du niveau de risque et d’autres exigences. Le déclenchement manuel du 3DS est destiné aux utilisateurs avancés qui intègrent Stripe à leur propre moteur de détection des fraudes.

Pour déclencher 3DS manuellement, définissez payment_method_options[card][request_three_d_secure] en fonction de ce pour quoi vous souhaitez optimiser soit lors de la création ou de la confirmation d’une PaymentIntent ou SetupIntent, soit lors de la création d’une Checkout Session. Ce processus est le même pour les paiements uniques ou lors de la mise en place d’un moyen de paiement pour les paiements futurs. Lorsque vous fournissez ce paramètre, Stripe tente d’effectuer 3DS et remplace toute dynamic 3D Secure Radar rules sur PaymentIntent, SetupIntent ou Paiement Session.

Les API Stripe ne permettent pas de désactiver manuellement la 3DS.

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_VePHdqKTYQjKNInc7u56JBrQ
:" \
  -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 de Stripe en matière d’authentification obligatoire sont exécutées automatiquement, que vous demandiez manuellement l’authentification 3DS ou non. Vos demandes d’authentification 3DS s’ajoutent à celles requises pour 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_VePHdqKTYQjKNInc7u56JBrQ
:" \
  --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é

La règle de transfert de responsabilité s’applique généralement aux paiements authentifiés à l’aide de 3DS. Dans certains cas, elle s’applique à l’aide d’un cryptogramme équivalent comme Apple Pay ou Google Pay. Si un titulaire de carte conteste un paiement 3DS pour fraude, vous transférez généralement 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 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.

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 pour l’émetteur. Cela peut se produire si le fournisseur 3DS de l’émetteur est indisponible ou si l’émetteur ne prend pas en charge 3DS, alors que le réseau de la carte l’impose. 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. Même si le titulaire de la carte n’a pas effectué l’authentification 3DS, la responsabilité de la transaction peut être transférée à l’émetteur.

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.

Il est également possible que le transfert de responsabilité soit déclassé après l’autorisation, ou que le système de rejet du litige du réseau de cartes ne réussisse pas à capturer le transfert de responsabilité pour une transaction. Dans ce cas, si vous réfutez le litige, Stripe ajoute automatiquement l’ECI demandée et le résultat de l’authentification 3DS du paiement à vos informations de preuve, mais nous vous recommandons également d’inclure des détails 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.