Authentification des cartes et 3D Secure

Pour renforcer la protection contre la fraude, le protocole 3D Secure (3DS) impose aux clients d’effectuer une étape de vérification supplémentaire auprès de l’émetteur de leur carte au moment du paiement. En général, le client est redirigé vers une page d’authentification sur le site web de sa banque, et doit saisir le mot de passe associé à la carte ou un code reçu par SMS. Ce processus est déjà mis en œuvre par les principaux réseaux de cartes bancaires, avec notamment Visa Secure et Mastercard Identity Check. Regardez notre vidéo pour découvrir un exemple de tunnel de paiement authentifié.

Dans le cadre de la directive européenne DSP2 et des réglementations similaires au Royaume-Uni, en Inde et en Australie relatives à l’authentification forte du client, les paiements par carte bancaire peuvent être soumis au protocole 3DS. L’authentification 3DS est facultative dans les autres régions, mais peut être utilisée comme mesure de lutte contre la fraude.

Web

iOS

Android

Étape 1 : Le client saisit ses informations de carte.

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

Étape 3 : Si la banque le demande, le client effectue une étape d’authentification supplémentaire.

Stripe prend en charge le protocole 3D Secure 2. Votre intégration l’applique lorsque la banque du client le permet, et utilise le protocole 3D Secure 1 dans le cas contraire.

Paiements contestés et transfert de responsabilité

La règle de transfert de responsabilité s’applique aux paiements qui sont authentifiés à l’aide de 3D Secure. Si un titulaire de carte conteste un paiement 3D Secure pour fraude, vous transférez la responsabilité à l’émetteur de la carte.

En pratique, cela signifie que vous ne devriez pas recevoir de litiges marqués comme frauduleux du moment où le paiement était couvert par la règle de transfert de responsabilité, mais vous recevrez tout de même une alerte de fraude précoce. Il est toujours possible 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 essentiellement d’une demande de renseignements.

Si vous recevez une demande pour un paiement authentifié par 3D Secure, il est impératif d’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, veillez à soumettre suffisamment d’informations sur le paiement. Indiquez notamment ce qui a été commandé (biens physiques, 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.

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é certaines industries 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, des établissements non financiers proposant des devises étrangères ou non fiduciaires, ni des achats ou chargements de cartes préapprovisionnées.

Dans de très rares cas, le transfert de responsabilité peut être déclassé après l’autorisation, ou le système de rejet du litige des réseaux de cartes peut ne pas détecter le transfert de responsabilité pour une transaction. Dans ces cas, si vous choisissez de contester le litige, Stripe ajoute automatiquement 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.

Configurer l’activation du flux 3D Secure

Stripe déclenche automatiquement l’authentification 3DS lorsque la réglementation l’impose, par exemple dans le cadre de l’authentification forte du client. 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.

Pour déterminer si un paiement par carte a fait l’objet d’une tentative d’authentification 3DS, lisez la propriété three_d_secure dans 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.succeeded indique si l’authentification a réussi ou non.

Lorsque vous exécutez 3D Secure, Stripe demande à votre client de s’authentifier pour finaliser le paiement, à condition que l’authentification 3DS soit disponible pour la carte bancaire en question.

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.

Dans le cas d’un flux de paiement classique qui déclenche l’authentification 3D Secure :

1. Le client saisit ses informations de paiement, qui sont ensuite associées à un PaymentIntent.
2. Stripe détermine si la transaction nécessite une authentification 3D Secure sur base des règles Radar, des requêtes manuelles et d’autres critères.
3. Si l’authentification 3D Secure est :
   • Non obligatoire : Stripe tente le paiement. Si la banque l’exige, le client doit ensuite effectuer une étape d’authentification supplémentaire pour que le paiement réussisse.
   • Obligatoire : Stripe lance le flux d’authentification 3D Secure en contactant le serveur 3D Secure de l’émetteur de la carte et en créant une source 3D Secure.
4. Lorsque Stripe exige l’authentification 3D Secure et que la tentative se solde par :
   • Une réussite : le PaymentIntent passe à l’état requires_action. Une fois que le client a terminé l’étape d’authentification 3D Secure, Stripe tente le paiement et le PaymentIntent passe à l’état processing.
   • Un échec : Stripe effectue une dernière tentative pour finaliser le paiement sans authentification. En fonction du résultat, le PaymentIntent passe à l’un des états suivants : succeeded, requires_capture ou requires_payment_method.

Utiliser des règles Radar dans le Dashboard

Stripe propose les trois règles Radar par défaut suivantes 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 pour obliger vos clients à effectuer une étape d’authentification supplémentaire lorsque l’émetteur de leur carte exige 3DS :

Request 3D Secure if 3D Secure is required for card Disabled by default

Request 3D Secure if 3D Secure is supported for card Disabled by default

Request 3D Secure if 3D Secure is recommended for card Disabled by default

Si vous disposez de Radar for Fraud Teams, vous pouvez ajouter des règles 3DS personnalisées en suivant la syntaxe décrite dans notre documentation sur les règles. Radar demande alors une authentification 3DS pour les paiements qui correspondent à ces règles. Dans l’exemple ci-dessous, la règle activée demande une authentification 3DS pour les tentatives de paiement dont le montant dépasse 500 $ et dont le niveau de risque est considéré comme supérieur à la normale.

Request 3D Secure if :amount_in_usd: > 500.00 and :risk_level: != ‘normal’

Règles personnalisées pour 3D Secure et transfert de responsabilité

Si vous utilisez Radar for Fraud Teams, vous pouvez personnaliser vos règles pour optimiser la réussite des paiements et vérifier que tous les paiements effectués pendant une session sont authentifiés. Vous pouvez par exemple définir les actions suivantes :

Demander manuellement une authentification 3D Secure 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 lors de la création ou de la confirmation d’un objet PaymentIntent ou SetupIntent. Ce processus est identique pour les paiements ponctuels et les futurs paiements hors session. 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 ou SetupIntent.

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 terminer 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 objet PaymentIntent
• Confirmer un objet PaymentIntent
• Créer un objet SetupIntent
• Confirmer un objet SetupIntent

Lorsque vous définissez la propriété request_three_d_secure sur any, Stripe demande à votre client de s’authentifier pour réaliser le paiement, à condition que l’authentification 3DS soit disponible sur sa carte. Dans le cas contraire, le paiement se poursuit normalement.

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

Afficher le flux 3D Secure

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 3D Secure

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 de 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.