FAQ 3DS 2.2

Foire aux questions autour du 3-D Secure 2.0.

Existe-t-il des cartes de test pour des transactions 3DS2 en environnement RCT ?

Ma transaction a reçu le code retour banque 5, qu’est-ce que ça signifie ?

• Cela signifie, que la banque refuse sans donner de statut particulier.
  Cela peut être un code CVV erroné ou une autre décision que nous ne connaissons pas.
  Ce statut ne permet pas d’affirmer que la banque n’acceptera pas l’autorisation après d’autres tentatives.

Ma transaction a reçu le code retour banque 12, qu’est-ce que ça signifie ?

• Cela signifie que la banque refuse sans donner de statut particulier.
  La raison peut être :
        – Simplement une transaction invalide
        – Un code 75 de la part de la banque émetteur (le code PIN de la carte a été trop de fois incorrecte)
        – Un CVV erroné (fournit par l’ACS lors d’une authentification 3DS)
        – Ou une autre décision que nous ne connaissons pas.

L’API transaction me retourne une erreur « Soft Decline » pourtant le paramètre « threeDSServerTransID » est bien celui retourné par le cres.
Comment devons-nous interpréter ce retour et que devons-nous faire ?

• Le soft decline est renvoyé par la banque lorsque que le 3DS n’est pas présent dans la transaction.
  Il faut vérifier s’il manque des champs présentés dans cette partie de la documentation : https://ref-api.centralpay.net/payment#106-3ds-sub-object

Ma requête du Versioning me retourne une erreur « 404 » avec le message « Card account number not found in card ranges from Directory Server ».
Qu’est-ce que ça signifie et que dois-je faire ?

• Cela signifie que la carte utilisée n’est pas enrôlée 3DS2.0 et que la transaction ne peut pas se faire en 3DS2.0.
  Pour ce cas, nous conseillons de prévoir un basculement vers un paiement en 3DS1 pour ce genre de carte.

La réponse de la requête Result nous a renvoyé le transStatus à U.
Comment devons-nous interpréter ce retour et que devons-nous faire dans ce cas ?

• La valeur U de transStatus en réponse de la requête result signifie que l’authentification ou la vérification n’a pas pu se faire suite à un problème technique ou autres problèmes.
  Du côté du smart form lors du challenge avec la requête result, seules les valeurs Y et A permettent de valider le challenge et continuer le paiement.
  Les autres valeurs font échouer le challenge et le paiement.
  Mais dans le cas d’un custom form le fonctionnement peut être différent, vous pouvez utiliser la valeur U pour faire une nouvelle tentative de challenge et si ça échoue encore alors le paiement passe en 3DS1 ou est refusé, ou alors pour directement retenter le paiement en 3DS1 ou le considérer comme un échec de paiement.
  Ces différents cas sont possibles à réaliser.

Nous avons soumis le formulaire à l’URL retournée par l’authentication avec le base64EncodedChallengeRequest.
Mais le client est aussitôt revenu sur notre site sans CRES mais avec un paramètre ERROR contenant la valeur « eyJ0aHJlZURTU…Mi4xLjAifQ== » ainsi que le paramètre « THREEDSSESSIONDATA » qui lui était vide.
Comment devons-nous interpréter ce retour et que devons-nous faire dans ce cas ?

• Lorsque vous avez un retour de ce genre, il faut vérifier que votre processus du 3DS2 se déroule bien sûr une seule et même page avec la solution d’un iframe.
  Si le processus est conforme, alors contactez le support technique avec les informations nécessaires.

Pour rappel, toutes les étapes du formulaire se réalisent sur une seule et même page sans redirection vers une page bancaire ou autre.
Cela se fait grâce à la solution de l'Iframe.
Toute la procédure du 3DS2.0 se passe sur la même page !

Nous avons reçu une erreur 303 : « acquirerBIN, acquirerMerchantID not recognized » lors d’un appel à l’authentication.
Comment devons-nous interpréter ce retour et que devons-nous faire dans ce cas ?

• Il s’agit soit du contrat qui n’est pas 3DS2, soit d’autres problèmes.
  Dans le cas d’un autre problème, il faut alors contacter le support technique en fournissant le numéro de contrat monétique (si connu) et les autres informations pouvant être nécessaire.

Sur l’étape d’authentication, nous avons eu une erreur 203 : « Validation of 3DS Requestor Authentication data failed.
Data element not in the required format or value is invalid » pour le champ merchant.merchantName.
Comment devons-nous interpréter ce retour et que devons-nous faire dans ce cas ?

• L’erreur 203 signifie qu’il y a un caractère invalide dans le paramètre « merchant.merchantName ».

Lors d’un test d’appel de la fonction 3DS2 « authentication », l’erreur suivante est retournée dans la clé « card data » : « There is no unique source of card ».
Qu’est-ce que cela signifie ?

• L’erreur « There is no unique source of card » est commune à toute la plateforme et est présent lorsque vous envoyez des informations de cartes deux fois : par exemple via un cardToken et un cardId ou un PAN et un cardToken etc…