FAQ – 3DS 2.2

Estimated reading: 3 minutes

Choix du flux

Dois-je utiliser le flux BRW ou le flux 3RI ?

Le critère est qui initie la transaction et si le porteur est présent, pas le rang de la transaction :

BRW → transaction initiée par le client (CIT), porteur présent qui valide lui-même le paiement. À utiliser pour la première authentification d’une carte comme pour tout paiement où le client agit en séance.
3RI → transaction initiée par le marchand (MIT), porteur absent, sur la base d’une CIT authentifiée antérieure (référencée via threeDSReqPriorRef).

Voir la vue d’ensemble de la section et la page MIT.

Puis-je utiliser le flux BRW pour mes transactions récurrentes / initiées par le marchand ?

Non. Le BRW suppose un navigateur et un porteur présents. L’employer pour des MIT entraîne friction inutile, soft declines et non-conformité DSP2. Pour ces transactions, utilisez le 3RI, qui s’appuie sur l’acsTransID de la CIT initiale. Une MIT peut toutefois être exceptionnellement requalifiée en CIT par l’émetteur ; dans ce cas, rejouez une CIT (BRW) avec le porteur.

Environnement de test

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

👉 Consultez la liste des cartes de test de l’environnement RCT.

Erreurs et statuts d’authentification 3DS

Mon versioning retourne une erreur 404 « Card account number not found in card ranges from Directory Server ». Que faire ?

La carte utilisée n’est pas enrôlée 3DS 2.2 : la transaction ne peut pas se faire en 3DS 2.2. Nous conseillons de prévoir un basculement vers un paiement en 3DS1 pour ce type de carte.

La requête Result retourne transStatus = U. Comment l’interpréter ?

La valeur U signifie que l’authentification / vérification n’a pas pu se faire (problème technique ou autre).

Côté SmartForm : lors du challenge, seules les valeurs Y et A valident le challenge et permettent de continuer le paiement. Les autres valeurs font échouer le challenge et le paiement.
Côté CustomForm : le comportement peut différer. Vous pouvez utiliser la valeur U pour retenter un challenge ; en cas de nouvel échec, basculer en 3DS1, ou considérer le paiement comme refusé. Ces différents traitements sont possibles.

SmartForm vs CustomForm : le SmartForm est la page de paiement hébergée par

Après soumission du formulaire à l’acsURL, le client revient sans CRES mais avec un paramètre ERROR (base64) et un THREEDSSESSIONDATA vide. Que faire ?

Vérifiez que tout votre process 3DS2 se déroule sur une seule et même page via la solution d’iframe. Si le processus est conforme, 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, grâce à la solution d’iframe.

Erreur 303 « acquirerBIN, acquirerMerchantID not recognized » lors de l’authentification. Que faire ?

Il s’agit soit d’un contrat qui n’est pas 3DS2, soit d’un autre problème. Dans ce dernier cas, contactez le support technique en fournissant le numéro de contrat monétique (si connu) et les autres informations utiles.

Erreur 203 « Validation of 3DS Requestor Authentication data failed […] » pour le champ merchant.merchantName. Que signifie-t-elle ?

L’erreur 203 signale un caractère invalide dans le paramètre merchant.merchantName.

Erreur « There is no unique source of card » dans la clé card data. Que signifie-t-elle ?

Cette erreur, commune à toute la plateforme, survient lorsque vous envoyez les informations de carte deux fois : par exemple un cardToken et un cardId, ou un PAN et un cardToken. N’envoyez qu’une seule source de carte.

Illustration de l'erreur de source de carte

Autorisation bancaire

L’API transaction retourne « Soft Decline » alors que threeDSServerTransID est bien celui retourné par le CRES. Que faire ?

Le soft decline (code A1) est renvoyé par la banque lorsque le 3DS n’est pas présent dans la transaction. Vérifiez qu’aucun champ 3ds[...] n’est manquant — voir les données à transmettre sur la page BRW, étape Transaction.

Codes retour banque 5 et 12 (hors 3DS)

Ces codes proviennent de l’autorisation bancaire et ne sont pas spécifiques au 3DS.

Code 5 : la banque refuse sans donner de statut particulier (CVV erroné ou autre décision que nous ne connaissons pas). Ce statut ne permet pas d’affirmer que la banque refusera l’autorisation après d’autres tentatives.
Code 12 : la banque refuse sans donner de statut particulier. Causes possibles : transaction invalide ; CAVV erroné ou invalide (le CAVV est le cryptogramme d’authentification fourni par l’ACS lors du 3DS, à ne pas confondre avec le CVV) ; ou autre décision que nous ne connaissons pas.