Authentification 3-D Secure
3-Domain Secure™ (3-D Secure ou 3DS) est un protocole de sécurité qui ajoute une couche supplémentaire de sécurité aux achats en ligne en demandant aux titulaires de cartes de s'authentifier auprès de l'émetteur de la carte lorsqu'ils effectuent des paiements. Il permet d'éviter les transactions en ligne non autorisées, réduisant ainsi le risque de fraude, et peut protéger le commerçant contre les rétrofacturations si la transaction est authentifiée avec succès. Lorsqu'un titulaire de carte effectue un achat en ligne, l'émetteur utilise son serveur de contrôle d'accès (ACS) pour valider l'identité du titulaire de la carte.
3DS, également connu sous le nom de 3DS2 sur Mastercard Gateway, est la dernière version du protocole de sécurité, conçue pour renforcer la sécurité des achats en ligne tout en proposant des paiements fluides aux payeurs considérés comme à faible risque par le serveur de contrôle d'accès (ACS). Le serveur ACS détermine le risque en utilisant les informations fournies par le commerçant, les empreintes digitales du navigateur et les interactions précédentes avec le payeur. Le serveur ACS demande au payeur d'effectuer une action, par exemple, de saisir un code PIN, uniquement lorsqu'une vérification supplémentaire est requise pour authentifier le payeur, ce qui permet d'améliorer les taux de conversion. Les systèmes d'authentification pris en charge incluent Mastercard SecureCode™, Verified by Visa™, American Express SafeKey™, Diners Club/Discover ProtectBuy, JCB J/Secure, ITMX Local Switch EMVCo et MADA secure.
Terminologie
Le tableau suivant répertorie les principaux termes utilisés dans la documentation sur l'intégration 3DS.
| Terme | Description |
|---|---|
| API 3DS JavaScript | API JavaScript côté client qui permet de lancer l'authentification 3DS à partir du navigateur du payeur en utilisant une authentification basée sur la session.
Cette API est utilisée avec la méthode d'intégration Hosted Session. |
| Serveur de contrôle d'accès (ACS) | Composant qui fonctionne dans le domaine de l'émetteur, qui vérifie si l'authentification est disponible pour un numéro de carte et un type de dispositif, et authentifie des transactions spécifiques. |
| Appel de méthode ACS | Un appel qui permet à au serveur ACS de recueillir des données supplémentaires pour déterminer le score de risque pour le payeur. Lorsque l'authentification 3DS2 est disponible et lorsque les détails de l'appel ACS sont retournés dans la réponse après avoir lancé l'authentification, ces détails sont transmis au navigateur du payeur, et sont soumis sous forme de publication de formulaire dans une iFrame masquée, afin que le serveur ACS puisse collecter des données supplémentaires. |
| Canal d'authentification | Emplacement où a lieu où l'authentification 3DS, dans le navigateur du payeur, dans une application sur l'appareil mobile du payeur ou dans votre système sans aucun payeur présent pour interagir. |
| Motif de l'authentification | Objectif de l'action d'authentification 3DS. En général, vous souhaitez authentifier le payeur pour traiter un paiement pour une carte spécifique ou traiter une authentification de non-paiement où vous vérifiez simplement une nouvelle carte que le payeur souhaite stocker dans votre application ou sur votre site Web pour des paiements futurs. |
| Flux d'authentification | Flux d'authentification où le payeur est redirigé vers le serveur ACS et est tenu de répondre à une authentification pour s'identifier, car le serveur ACS ne dispose pas d'informations suffisantes sur le payeur pour le considérer comme à faible risque. |
| Flux sans friction | Flux d'authentification où le payeur n'est pas tenu de répondre à une authentification car le serveur ACS considère le payeur comme à faible risque. |
| Authentification du commerçant | Mécanisme qui permet au commerçant d'authentifier les demandes d'API auprès de la passerelle, par exemple, mot de passe/certificat/authentification de session. |
| API Payer Authentication (Authentification du payeur) | API côté serveur constituée de deux opérations, Initiate Authentication (Initier l'authentification) et Authenticate Payer (Authentifier le payeur), qui doivent être soumises de votre serveur au serveur de passerelle. Peut également être utilisée comme API côté client utilisant une authentification basée sur la session. Cette API est utilisée avec la méthode d'intégration Direct Payment. |
| Session de paiement | Une session de paiement, ou plus simplement une session, est un conteneur temporaire pour les champs de demande et les valeurs des opérations faisant référence à une session. Vous pouvez l'utiliser dans une opération pour référencer les champs de demande et les valeurs plutôt que de les fournir directement dans la demande d'opération. Lorsque la passerelle reçoit une opération référençant une session, elle crée la demande finale en combinant les champs de demande de la session et ceux fournis directement dans la demande. Pour plus d'informations, voir Principes de base des sessions. |
| Authentification de session | Authentification à l'aide d'une session de paiement. Cette méthode d'authentification permet aux payeurs de fournir leurs détails de paiement directement à la passerelle via une interaction côté client avec la passerelle, par l'intermédiaire du navigateur du payeur ou d'une application sur l'appareil mobile du payeur. Il utilise un mécanisme d'authentification HTTP de base (similaire à l'authentification par mot de passe) dans lequel vous devez indiquer « merchant.<your gateway merchant ID> » dans la partie userid et l'identifiant de session dans la partie password. Pour utiliser ce type d'authentification, vous devez d'abord créer une session en soumettant une demande de session (voir la rubrique Créer une session) de votre serveur vers le serveur de passerelle. |
Flux d'authentification 3DS
Le diagramme ci-dessous illustre le flux d'authentification pour un paiement pour lequel le payeur est authentifié à l'aide de l'authentification 3DS.
Le flux pour une authentification réussie est le suivant :
- Un payeur navigue sur votre site Web, sélectionne un ou plusieurs produits, accède à la page de paiement et choisit de payer avec une carte qui prend en charge 3DS.
- Envoyez la demande INITIATE AUTHENTICATION (Initier l'authentification) pour demander à la passerelle de vérifier auprès du système de cartes si la carte est inscrite à 3DS.
- Si l'authentification 3DS du payeur est disponible, la passerelle renvoie les détails de l'authentification de l'appel de méthode ACS pris en charge dans la réponse.
- Soumettez les détails de l'appel de la méthode ACS sous forme de publication de formulaire dans une iFrame masquée, afin que le serveur ACS puisse lancer l'authentification et collecter des données supplémentaires sur le payeur.
- Envoyez la demande AUTHENTICATE PAYER (Authentifier le payeur) pour demander à la passerelle d'effectuer l'authentification initiée.
- La passerelle vous fournit les détails de l'authentification en fonction du flux d'authentification :
- Flux fluide où l'authentification est terminée : la passerelle redirige le payeur directement sur votre site Web.
- Flux d'authentification où l'interaction de l'utilisateur est requise pour terminer l'authentification : si l'émetteur demande au payeur de répondre à une authentification, votre application redirige le navigateur Web du payeur vers le serveur ACS, qui présente son IU d'authentification. L'émetteur retourne le résultat de l'authentification à la passerelle. la passerelle redirige le payeur directement sur votre site Web.
- Soumettez le paiement pour traitement à l'aide de la demande AUTHORIZE (Autoriser) ou PAY (Payer) et incluez l'ID de transaction d'authentification 3DS dans la demande.
- Affichez la page de confirmation de commande au payeur.
authentication.redirect.html qui doivent être incluses dans le navigateur du payeur via une iFrame masquée. Cela permet de minimiser le temps d'attente pour les payeurs lorsqu'ils reçoivent une erreur « SERVER_BUSY ». Ajouter l'authentification 3DS à votre intégration
Conditions préalables
- Pour utiliser le service d'authentification 3DS de la passerelle :
- Vous devez être enregistré auprès de votre acquéreur pour utiliser 3DS.
- Votre profil de commerçant sur la passerelle doit être activé pour au moins un système 3DS pour une version 3DS prise en charge.
- Vous devez utiliser la version 57 de API ou une version ultérieure.
Modes d'authentification 3DS
- La passerelle prend en charge les modes d'authentification 3DS suivants :
- Authentication Only (Authentification uniquement) : vous effectuez l'authentification 3DS à l'aide de la passerelle. Vous pouvez choisir de soumettre le paiement (en utilisant les détails d'authentification) à un stade ultérieur via cette passerelle ou une autre passerelle.
- Transaction Authentication and Payment (Authentification et paiement) : vous effectuez l'authentification 3DS à l'aide de cette passerelle et procédez à la soumission du paiement (à l'aide des détails d'authentification) via cette passerelle.
- Transaction Pre-authenticated Payment (Paiement pré-authentifiée) : Vous effectuez l'authentification 3DS à l'aide d'un prestataire externe et fournissez les détails d'authentification lors de la soumission d'un paiement via cette passerelle.
Options d'intégration de l'authentification 3DS
La passerelle prend en charge les options d'intégration suivantes pour l'authentification 3DS.
| Méthode d'intégration | Intégration 3DS | Quand l'utiliser | Mode d'authentification pris en charge |
|---|---|---|---|
| Hosted Checkout | 3DS avec Hosted Checkout | Il s'agit de l'option d'intégration la plus simple. Si vous prenez en charge 3DS, l'authentification 3DS est automatiquement gérée par la Hosted Payment Page dans votre intégration Hosted Checkout. |
|
| Hosted Session | API 3DS JavaScript | Il s'agit d'une intégration JavaScript avec laquelle vous pouvez lancer l'authentification 3DS depuis la page de paiement de votre site Web. Utilisez cette option si vous souhaitez autoriser le payeur à soumettre ses informations de paiement directement à la passerelle à partir du navigateur. Pour lancer l'authentification 3DS et d'autres opérations 3DS directement à partir du navigateur du payeur, vous devez d'abord établir le canal d'authentification sur lequel votre serveur commerçant doit communiquer avec le serveur de la passerelle pour créer une session sur la passerelle. L'ID de session généré par la passerelle est ensuite inclus dans toutes les demandes d'authentification lancées par le navigateur comme champ de mot de passe (voir Options d'authentification). |
|
| Direct Payment | API Payer Authentication (Authentification du payeur) | Il s'agit d'une option d'intégration côté serveur qui vous donne un contrôle total sur votre intégration, mais nécessite le plus grand effort d'intégration. Utilisez cette option si vous devez personnaliser les interactions de l'API entre le navigateur du payeur et la passerelle. Vous devez effectuer les opérations nécessaires à la gestion des flux d'intégration 3DS directement depuis votre serveur commerçant vers le serveur passerelle. L'API Payer Authentication (Authentification du payeur) prend également en charge les sessions de paiement (voir Principes de base des sessions). |
|
| Intégration mobile | Intégré au SDK | Si vous prenez en charge l'authentification 3DS, vous pouvez lancer l'authentification avec un appel de fonction et le reste du processus est automatiquement géré par le SDK. |
|
Questions fréquentes
Comment afficher les détails de l'authentification dans Merchant Administration ?
Vous pouvez afficher les détails de l'authentification pour les authentifications individuelles et les authentifications ayant effectué le paiement dans Merchant Administration. Recherchez la commande ou la transaction sur la page de recherche et affichez les détails de l'authentification.
Comment récupérer les résultats de l'authentification 3DS ?
Si vous souhaitez récupérer les résultats de l'authentification à tout moment, utilisez l'opération RETRIEVE TRANSACTION (Extraire la transaction). Les champs utilisés uniquement lors de l'authentification, par exemple authentication.redirect.html, ne sont pas conservés sur la passerelle et ne sont donc pas retournés.
Comment soumettre une demande de paiement pré-authentifiée ?
Si vous avez utilisé un MPI 3DS externe (Merchant Plug-In) externe pour authentifier le payeur, vous devez transmettre les informations sur le résultat de l'authentification dans l'objet d'authentification de l'opération AUTHORIZE (Autoriser) ou PAY (Payer).
Le statut de la transaction étant déterminé si des champs spécifiques vous ont été fournis par le MPI 3DS externe, tous les champs sont facultatifs. Cependant, si vous disposez des données suivantes, fournissez-les :
authentication.3ds.acsEciIndicateur de commerce électronique qui vous est renvoyé dans le message de réponse d'authentification.
-
authentication.3ds.authenticationTokenValeur codée en base64, générée par l'émetteur de la carte, qui vous est renvoyée dans le message de réponse d'authentification.
Le résultat de l'appel de méthode ACS lancé via la publication du formulaire n'est pas fourni automatiquement et votre application doit envoyer la demande AUTHENTICATE PAYER (Authentifier le payeur) pour obtenir une réponse. -
authentication.3ds.transactionIdIdentifiant de transaction unique généré par la passerelle pour l'authentification 3DS. Ce champ correspond à l'identifiant attribué par le serveur d'annuaire du système.
-
authentication.3ds2.protocolVersionVersion du protocole 3DS utilisé pour effectuer l'authentification 3DS, au format spécifié par EMVCo. Par exemple, 2.1.0.
-
authentication.3ds2.transactionStatusRésultat de l'authentification du payeur auprès de l'émetteur.
-
authentication.3ds2.statusReasonCodeCode indiquant le motif du statut de la transaction retourné dans
authentication.3ds2.transactionStatus. Vous devez l'indiquer lorsqueauthentication.3ds2.transactionStatusretourneN,UouR. -
authentication.amountMontant de l'authentification. Vous devez renseigner ce champ lorsque le montant de l'authentification est différent de
order.amount. Consultez votre Your payment service provider avant d'utiliser ce champ. -
authentication.timeDate et heure de l'authentification du payeur. Vérifiez auprès de votre prestataire de services de paiement avant d'utiliser ce champ.
Si vous êtes un commerçant en ligne avec un lien d'acquéreur MADA en Arabie Saoudite et un payeur entièrement authentifié par 3DS en dehors de la passerelle, vous devez être intégré à l'API v76 ou à une version ultérieure et fournir les détails de l'authentification suivants dans l'opération AUTHORIZE (Autoriser) ou PAY (Payer) pour soumettre avec succès une transaction par carte MADA comarquées, MADA à badge unique ou internationale :
-
authentication.3ds2.acsReferenceNuméro de référence attribué par EMVCo au serveur ACS de l'émetteur lors de l'approbation ACS. Ce champ correspond au champ EMVCo
acsReferenceNumber. -
authentication.3ds2.dsReferenceNuméro de référence attribué par EMVCo au serveur d'annuaire (DS) après approbation de ce dernier. Ce champ correspond au champ EMVCo dsReferenceNumber.
-
authentication.3ds2.acsTransactionIdIdentifiant de transaction unique attribué par le serveur ACS pour identifier la transaction 3DS.
-
authentication.timeDate et heure de l'authentification du payeur. Ce champ correspond au champ EMVCo
purchaseDate. -
authentication.3ds.acsEciValeur de l'indicateur de commerce électronique (ECI) attribué par le serveur ACS de l'émetteur pour indiquer les résultats de la tentative d'authentification du payeur.
-
authentication.3ds.authenticationTokenValeur codée en base64 générée par l'émetteur. Ce champ correspond à la valeur Authentication (Authentification).
-
authentication.3ds.transactionIdID de la transaction. Ce champ correspond à l'ID de transaction DS.
-
authentication.3ds2.protocolVersionVersion du protocole 3DS utilisé pour effectuer l'authentification 3DS. Par exemple, 2.1.0.
-
authentication.3ds2.transactionStatusStatut de la transaction. Ce champ correspond au champ EMVCo
transStatus. -
authentication.3ds2.authenticationSchemeSystème d'authentification. Pour les transactions MADA comarquées authentifiées en externe, vous devez indiquer
MADA,MASTERCARDouVISApour spécifier l'authentification 3DS DS via laquelle la transaction a été authentifiée. Pour les transactions MADA à badge unique authentifiées en externe, vous pouvez indiquerMADAou ne pas soumettre ce champ. Pour les autres cartes, vous pouvez fournir le schéma d'authentification correspondant ou ne pas soumettre ce champ.
Comment puis-je soumettre une demande d'authentification hors paiement ?
Si vous souhaitez effectuer une authentification pour vérifier uniquement l'identité du payeur sans procéder au paiement, vous devez indiquer le but de l'authentification dans la demande INITIATE AUTHENTICATION (Initier l'authentification). Par exemple, si vous souhaitez authentifier lorsque celui-ci saisit les détails de sa carte pour une utilisation ultérieure lors de l'enregistrement d'un client ou de la création d'un compte sur votre site Web. La possibilité de terminer le processus d'authentification dans un environnement hors paiement améliore l'expérience du payeur et réduit ses taux d'abandon.
- Pour effectuer une authentification hors paiement, renseignez les champs suivants dans la demande INITIATE AUTHENTICATION (Initier l'authentification) :
order.currencyToute devise prise en charge sur vos liens d'acquéreur.authentication.purpose- Contexte dans lequel l'authentification du payeur est demandée. Vous pouvez spécifier l'un des éléments suivants :
- ADD_CARD : authentification effectuée avant que la carte d'un payeur ne soit stockée dans le fichier directement par vous ou en utilisant la fonction de Tokenization de la passerelle. Aucun paiement n'est en cours de traitement.
- MAINTAIN_CARD : authentification effectuée avant la mise à jour des détails de la carte d'un payeur stockée dans le fichier directement par vous ou en utilisant la fonction de Tokenization de la passerelle. Aucun paiement n'est en cours de traitement.
Si le système d'authentification ne prend pas en charge l'objectif que vous avez demandé, la passerelle renvoie AUTHENTICATION_NOT_SUPPORTED dans le champ de réponse authenticationStatus. Par défaut, la passerelle définit ce champ sur PAYMENT_TRANSACTION pour permettre l'utilisation de l'authentification pour une transaction de paiement.
Comment utiliser l'authentification 3DS en tant que commerçant agrégateur ?
Les commerçants agrégateurs peuvent permettre à leurs sous-commerçants d'utiliser l'API Payer Authentication (Authentification du payeur) sur la passerelle. Les sous-commerçants ne sont pas tenus d'avoir une relation contractuelle avec l'acquéreur ni avec la passerelle. Le commerçant agrégateur peut soumettre les détails du sous-commerçant requis pour lancer l'authentification via l'opération INITIATE AUTHENTICATION (Initier l'authentification). Pour plus d'informations, voir Agrégateur.
Comment les interactions 3DS sont-elles représentées sur la passerelle ?
L'API d'authentification du payeur enregistre les détails de l'authentification du payeur en utilisant l'authentification 3DS comme transaction AUTHENTICATION (Authentification) séparée sur la commande. Pour plus d'informations sur les transactions AUTHENTICATION (Authentification), reportez-vous à la liste des champs de réponse pour l'opération AUTHENTICATE PAYER (Authentifier le payeur).
Lorsque vous extrayez une commande à l'aide de l'opération RETRIEVE ORDER (Extraire la commande) ou recevez une réponse de l'API Reporting, elle peut comporter une transaction AUTHENTICATION (Authentification) supplémentaire. De même, lorsque vous utilisez les notifications Webhook, vous pouvez recevoir une notification supplémentaire pour la transaction AUTHENTICATION (Authentification).
Puis-je utiliser des jetons de réseau comme origine des fonds dans l'authentification du payeur ?
Vous pouvez utiliser des jetons de réseau pour l'authentification du payeur à compter de la version v57 de l'API. Pour des informations détaillées, voir Segmentation en jetons de réseau.
Si votre prestataire de services de paiement vous a activé pour la Tokenization de réseau, toute demande de jeton de passerelle adressée à la passerelle tente également de générer un jeton de réseau correspondant pour les systèmes activés, lorsque l'émetteur de la carte le prend en charge. La passerelle tente également la Tokenization de réseau pour toutes les cartes applicables déjà stockées dans le référentiel de jetons de la passerelle. La demande INITIATE AUTHENTICATION (Initier l'authentification) utilise le jeton de réseau, s'il est disponible. Dans le cas contraire, le FPAN (Funding PAN) stocké par rapport au jeton de passerelle est utilisé. Ce modèle ne prend actuellement en charge que les jetons MDES.
Puis-je utiliser des jetons de paiement mobile comme origine des fonds dans l'authentification du payeur ?
Vous pouvez utiliser des jetons de paiement mobile pour l'authentification du payeur à compter de la version 55 de l'API. Seuls les jetons de paiement obtenus à partir du SDK Google Pay sont pris en charge. Vous pouvez fournir un jeton de paiement crypté ou le PAN obtenu à partir d'un jeton de paiement décrypté pour l'authentification du payeur. La passerelle accepte uniquement les demandes d'authentification avec FPAN, les demandes avec DPAN sont rejetées. Pour fournir les détails de la carte via un jeton de paiement, renseignez les champs suivants :
-
order.walletProvider = GOOGLE_PAY -
sourceOfFunds.provided.card.devicePayment.paymentTokenJeton de paiement crypté obtenu à partir du SDK Google Pay. applicable uniquement si le jeton de paiement est décrypté par la passerelle.
-
sourceOfFunds.provided.card.numberClé JSON Google Pay PAN. applicable uniquement si vous avez vous-même décrypté le jeton de paiement.
Comment implémenter des intégrations avancées de sessions de paiement ?
Si vous avez utilisé une session de paiement (ID de session) pour stocker les détails de l'authentification, la demande POST soumise par le navigateur du payeur à votre site Web à la fin de la demande AUTHENTICATE PAYER (Authentifier le payeur) est paramétrée afin de vous permettre de déterminer le résultat de l'authentification. Les champs d'authentification individuels, par exemple, authentication.3ds2.transactionStatus.data, peuvent être utiles dans une intégration avancée ou si vous avez besoin d'indiquer les données d'authentification dans un paiement traité via une autre passerelle. Pour ce faire, vous pouvez soumettre une demande RETRIEVE TRANSACTION (Extraire la transaction) ou choisir de décrypter les données d'authentification cryptées comme suit :
- Créez une session à l'aide de l'opération CREATE SESSION (Créer une session).
- Ajoutez des données pertinentes à l'ID de session (renvoyé dans la réponse CREATE SESSION [Créer une session]) à l'aide de la demande UPDATE SESSION (Mettre à jour la session).
- Utilisez l'ID de session dans les demandes INITIATE AUTHENTICATION (Initier l'authentification) et AUTHENTICATE PAYER (Authentifier le payeur).
- La redirection du navigateur du payeur vers votre site Web contient les détails de l'authentification du payeur dans le champ
encryptedData. Il s'agit d'un objet JSON crypté contenant les données d'authentification obtenues au cours du processus d'authentification. Il contient les champs suivants :encryptedData.ciphertextauthentication.3ds.acsEciauthentication.3ds.authenticationTokenauthentication.3ds.transactionIdauthentication.3ds1.veResEnrolledauthentication.3ds1.paResStatusauthentication.3ds2.transactionStatusauthentication.3ds2.dsTransactionIdtransaction.authenticationStatusauthentication.3ds2.statusReasonCodesourceOfFunds.provided.card.numbersourceOfFunds.provided.card.expiry.monthsourceOfFunds.provided.card.expiry.yearsourceOfFunds.tokenorder.idtransaction.id
encryptedData.nonceencryptedData.tag
- Pour décrypter le contenu renvoyé dans le champ
encryptedData.ciphertext, utilisez la valeur dusession.aes256Keychamp (renvoyée dans la réponse CREATE SESSION [Créer une session]) en mode GCM. La clé encodée en Base64 est une clé secrète et ne doit être connue que de vous.
public final class SessionDataDecrypter {
/**
* The algorithm used for encryption/decryption
*/
private static final String SYMMETRIC_ALGORITHM = "AES/GCM/NoPadding";
/**
* The algorithm to be associated with the secret key material
*/
private static final String SYMMETRIC_KEY_TYPE = "AES";
/**
* The secret key associated with the session, as returned in the session.aes256Key in a Create Session response.
*/
private final byte[] key;
/**
* Constructs a new object with the given key. The key is Base64 encoded, as returned in the session.aes256Key
* field in a Create Session response. This key must be kept secret, as it may be used to encrypt, decrypt and
* authenticate data for that session.
*
* @param encodedKey Key to be used for decryption.
*/
public SessionDataDecrypter(String encodedKey) {
key = Base64.getDecoder().decode(encodedKey);
}
/**
* Performs decryption of the given ciphertext, using the key passed in the constructor and the associated nonce.
* The tag is used to authenticate the ciphertext.
*
* @param ciphertext Encrypted and authenticated session data
* @param nonce Nonce/Initialization vector associated with the ciphertext
* @param tag Authentication tag
* @return The decrypted session data
* @throws AEADBadTagException if the data cannot be authenticated with the given tag
* @throws InvalidKeyException if the key cannot be constructed properly. This may indicate that it has not been
* correctly retrieved from the response field
* @throws GeneralSecurityException other than {@link AEADBadTagException} and {@link InvalidKeyException}, should
* not be thrown in a correctly set up environment
*/
public String decrypt(String ciphertext, String nonce, String tag)
throws GeneralSecurityException {
Key keySpec = new SecretKeySpec(key, SYMMETRIC_KEY_TYPE);
// The Java crypto classes expect the ciphertext and tag to be a single input, so they need to be concatenated
byte[] encryptedBytes = Base64.getDecoder().decode(ciphertext);
byte[] tagBytes = Base64.getDecoder().decode(tag);
byte[] input = new byte[encryptedBytes.length + tagBytes.length];
System.arraycopy(encryptedBytes, 0, input, 0, encryptedBytes.length);
System.arraycopy(tagBytes, 0, input, encryptedBytes.length, tagBytes.length);
// Configure the cipher with AES, using GCM parameter specifying the nonce/initialization vector
byte[] iv = Base64.getDecoder().decode(nonce);
GCMParameterSpec parameterSpec = new GCMParameterSpec(tagBytes.length * Byte.SIZE, iv);
final Cipher decrypter = Cipher.getInstance(SYMMETRIC_ALGORITHM);
decrypter.init(Cipher.DECRYPT_MODE, keySpec, parameterSpec);
// Perform the decryption and return the value.
byte[] decryptedBytes = decrypter.doFinal(input);
return new String(decryptedBytes, StandardCharsets.UTF_8);
}
}
Que puis-je faire pour augmenter les chances d'un flux sans friction ?
La demande AUTHENTICATE PAYER (Authentifier le payeur) peut inclure de nombreuses informations sur le payeur et la transaction. Par exemple, vous pouvez fournir les données suivantes dans la demande à l'aide des champs de l'objet customer.account, ce qui aide le serveur ACS de l'émetteur à évaluer le niveau de risque associé à l'activité. Dans le cas de paiements légitimes, cela aide le serveur ACS à confirmer que le payeur est vraisemblablement le titulaire de la carte.
- Le payeur utilise-t-il un compte existant ?
customer.account.history.creationDate
- Depuis combien de temps le compte existe-t-il ?
-
customer.account.history.lastUpdated -
customer.account.history.passwordLastChanged
-
- À quelle fréquence le payeur a-t-il acheté chez vous ?
-
customer.account.history.addCardAttempts -
customer.account.history.annualActivity -
customer.account.history.recentActivity -
customer.account.history.shippingAddressDate
-
-
customer.account.history.issuerAuthentication.acsTransactionId -
customer.account.history.issuerAuthentication.time -
customer.account.history.issuerAuthentication.type
-
- Avez-vous observé une activité suspecte (par exemple, des tentatives de connexion infructueuses) sur le compte ?
-
customer.account.history.suspiciousActivity -
customer.account.authentication.method -
customer.account.authentication.time
-
Vous pouvez également renseigner les champs recommandés suivants pour chaque système de cartes dans la demande AUTHENTICATE PAYER (Authentifier le payeur). Cette liste n'est pas définitive et peut être sujette à modification.
Champs recommandés pour chaque système de cartes dans une demande AUTHENTICATE PAYER (Authentifier le payeur)
| Champ | Mastercard | Visa | American Express | Notes |
|---|---|---|---|---|
shipping.contact.email | - | - | Y | Requis pour calculer le risque du commerçant. |
shipping.method | - | - | Y | Requis pour calculer le risque du commerçant. |
order.valueTransfer.amount | - | - | Y | Requis pour calculer le risque du commerçant. Applicable uniquement aux cartes-cadeaux |
order.valueTransfer.numberOfCards | - | - | Y | Requis pour calculer le risque du commerçant. Applicable uniquement aux cartes-cadeaux. |
order.valueTransfer.currency | - | - | Y | Requis pour calculer le risque du commerçant. Applicable uniquement aux cartes-cadeaux. |
order.supply.preorderAvailabilityDate | - | - | Y | Requis pour calculer le risque du commerçant. |
order.supply.preorder | - | - | Y | Requis pour calculer le risque du commerçant. |
order.supply.reorder | - | - | Y | Requis pour calculer le risque du commerçant. |
order.valueTransfer.accountType | - | Y | - | Requis par Visa et par d'autres systèmes sur certains marchés (par exemple, au Brésil). Ne s'applique pas si order.valueTransfer.accountType = NOT_A_TRANSFER. |
Comment déterminer le statut d'authentification ?
La passerelle indique le statut d'authentification dans le champ transaction.authenticationStatus. Ce champ peut renvoyer l'une des valeurs suivantes, en fonction de l'étape d'authentification :
AUTHENTICATION_ATTEMPTEDL'authentification du payeur a été tentée et une preuve de tentative d'authentification a été obtenue.
AUTHENTICATION_AVAILABLEL'authentification du payeur est disponible pour le mode de paiement indiqué.
AUTHENTICATION_FAILEDLe payeur n'a pas été authentifié. Ne poursuivez pas cette transaction.
AUTHENTICATION_NOT_SUPPORTEDLa méthode d'authentification demandée n'est pas prise en charge pour ce mode de paiement.
AUTHENTICATION_NOT_IN_EFFECTAucune information d'authentification n'est associée à cette transaction.
AUTHENTICATION_PENDINGL'authentification du payeur est en attente de l'achèvement d'un processus d'authentification.
AUTHENTICATION_REJECTEDL'émetteur a rejeté la demande d'authentification et vous a demandé de ne pas tenter d'autoriser de paiement.
AUTHENTICATION_REQUIREDL'authentification du payeur est requise pour ce paiement, mais n'a pas été fournie.
AUTHENTICATION_SUCCESSFULLe payeur a été authentifié avec succès.
AUTHENTICATION_UNAVAILABLEle payeur n'a pas pu être authentifié pour des raisons techniques ou autres.
La durée de validité des données d'authentification de paiement peut dépendre de votre cas d'utilisation. Contactez votre prestataire de services de paiement si vous avez besoin de précisions.
Pour utiliser une transaction récurrente avec authentification, voir Transactions avec informations d'identification stockées.
Comment utiliser la conversion de devise dynamique avec l'authentification du payeur ?
Avant d'initier l'authentification du payeur, vous pouvez obtenir une estimation de taux par conversion de devise dynamique auprès du prestataire de services de conversion de devise dynamique en soumettant la demande PAYMENT OPTIONS INQUIRY (Demande d'options de paiement).
Si le prestataire de services de conversion de devise dynamique a fait une offre et que vous avez proposé cette offre au payeur, vous devez indiquer la réaction du payeur dans la demande INTIATE AUTHENTICATION (Initier l'authentification) :
- Si le payeur a accepté l'offre, utilisez :
currencyConversion.requestIdtel que renvoyé dans la réponse PAYMENT OPTIONS INQUIRY (Demande d'options de paiement)currencyConversion.uptake = ACCEPTED
- Si le payeur a décliné l'offre, utilisez :
currencyConversion.requestIdtel que renvoyé dans la réponse PAYMENT OPTIONS INQUIRY (Demande d'options de paiement)currencyConversion.uptake = DECLINED
Si la conversion de devise dynamique n'est pas requise pour cette transaction, soumettez la demande INITIATE AUTHENTICATION (Initier l'authentification) avec currencyConversion.uptake = NOT_REQUIRED.
Si vous êtes configuré pour utiliser la conversion de devise dynamique et ne renseignez pas currencyConversion.uptake dans la demande INITIATE AUTHENTICATION (Initier l'authentification), la réponse INITIATE AUTHENTICATION (Initier l'authentification) indique currencyConversion.uptake = NOT_REQUIRED.
Si le payeur accepte l'offre de conversion de devise dynamique, le traitement d'authentification du payeur utilise la devise du payeur et le montant du payeur. Dans tous les autres cas, le traitement d'authentification du payeur utilise le montant de la commande et la devise de la commande.
Vous pouvez utiliser les informations de conversion de devise dynamique fournies dans la demande INITIATE AUTHENTICATION (Initier l'authentification) sur la demande de paiement ultérieure en faisant référence à la transaction d'authentification (authentication.transactionId). Les informations de conversion de devise dynamique soumises lors de l'authentification du payeur s'appliquent à votre transaction de paiement.
Si vous le souhaitez, vous pouvez également soumettre les mêmes informations de conversion de devise dynamique lors des opérations de paiement ultérieures que celles soumises lors de l'authentification. Toutefois, si la transaction de paiement ultérieure, qui fait référence à la transaction d'authentification et contient des informations de conversion de devise dynamique différentes celles de l'authentification, la transaction de paiement est rejetée.
authentication.purpose = REFRESH_AUTHENTICATION).