Définition des Webservices Systempay

Transcription

Définition des Webservices
Systempay
Version 1.2c
Historique du document
Version
Auteur
Date
Commentaires
1.2c
Lyra-Network
06/12/2013
Modification du champ threeDsResult. Précision apportée quant
à l’utilisation de ce champ dans le cas d’une carte non enrôlée.
Détails ajoutés sur le code erreur 9 – Erreur technique.
1.2b
Lyra-Network
10/07/2013
Précision sur la redirection vers l’ACS
Ajout des cartes de test en annexes
1.2a
Lyra-Network
03/05/2012
1.2
Lyra-Network
14/12/2011
1.1
Lyra-Network
20/06/2011
1.0
Lyra-Network
20/06/2011
Ajout de la méthode sendVEReqAndbuildPAReqByIdentifierTx
Suppression des méthodes :
buildPAReqByOrderIdentifierTx
sendVEReqByOrderIdentifierTx
sendVEReqTx
buildPAReqTx
Ajout de nouveaux codes d’erreur
Ajout de la méthode buildPAReqByOrderIdentifierTx
Modification apportées sur le maintien de la session HTTP en
mode TEST
Ajout des méthodes :
sendVEReqAndbuildPAReqTx
sendVEReqByOrderIdentifierTx
Précisions ajoutées concernant le maintien de la session HTTP
Version initiale.
Confidentialité
Toutes les informations contenues dans ce document sont considérées comme confidentielles. L’utilisation de
celles-ci en dehors du cadre de cette consultation ou la divulgation à des personnes extérieures est soumise
à l’approbation préalable de Lyra Network.
SOMMAIRE
1
2
3
4
Présentation ......................................................................................................... 1
Notions de timeout .............................................................................................. 1
Description des codes erreurs ........................................................................... 3
Description des types ......................................................................................... 4
4.1 threeDSecureResponse............................................................................................................4
4.2 paResInfo ....................................................................................................................................4
4.3 veResPAReqInfo ........................................................................................................................5
5 Signature .............................................................................................................. 6
6 Description des méthodes et cinématique ...................................................... 7
6.1 Maintien de la session HTTP entre chaque requête ...........................................................8
6.2 Principe de fonctionnement de l’authentification 3D-Secure ........................................9
6.3 Vérification d’enrôlement et génération de la demande d’authentification 3DS .. 10
6.3.1 Paiement classique ................................................................................................. 10
6.3.2 Paiement en 1 clic (paiement par identifiant) ......................................................... 11
6.4 Redirection vers l’ACS ........................................................................................................... 12
6.5 Récupération de la réponse de l’ACS ............................................................................... 14
6.6 Analyse de l’authentification 3DS (analyzePAResTx) ...................................................... 15
7 Annexes ............................................................................................................. 16
1 Présentation
Ce document présente les webservices 3-D Secure qui permettent de réaliser des vérifications sur
l’enrôlement d’une carte et de rediriger le porteur vers l’ACS de la banque émettrice.
Les résultats des requêtes présentées dans ce document serviront à renseigner le paramètre
threeDSResult lors d’une requête de paiement.
(cf. Guide_d_implementation_standard_WebService.pdf)
Ces webservices ont été développés suivant le protocole SOAP (Simple Object Access Protocol) et
sont décrits par le fichier wsdl suivant :
https://paiement.systempay.fr/vads-ws/threeds-v1?wsdl
Afin de sécuriser les échanges, les webservices (SOAP) sont cryptés grâce au protocole HTTPS. De
plus un mécanisme de signature a été mis en place afin de valider et d’authentifier l’échange des
données. (cf. chapitre Signature)
2 Notions de timeout
Le traitement d’une requête webservices s’articule autour d’un enchainement d’événements
asynchrones comme l’envoi de la requête via le réseau du site marchand, le transport des
informations sur le réseau internet, le traitement du paiement par la plateforme, l’interrogation des
serveurs bancaires, etc.
Un incident peut survenir à chaque étape et augmenter le temps du traitement (et donc
implicitement le temps d’attente pour l’acheteur).
Une requête peut voir sa réponse retardée pour de multiples raisons comme par exemple :
• Un temps de réponse long de la part de l’émetteur du porteur de la carte, (cas des cartes
étrangères, cas de période de forte charge comme les soldes, ..)
• Un temps de réponse long de la part de l’acquéreur lors de la transmission et de la
réception de la demande d’autorisation
• Un temps de réponse long du côté de votre application suite à une charge importante
• Un temps de réponse long de la plateforme de paiement.
• Un problème de peering sur Internet qui peut entrainer des pertes de messages, etc…
Ce qui veut dire que suivant le timeout que vous positionnez dans votre application, vous pouvez
ne pas recevoir de réponse alors que le traitement asynchrone continue à s’exécuter côté
plateforme de paiement.
Vous devez donc gérer les cas de timeout qui mal traités peuvent donner un mauvais résultat à
l’acheteur.
Afin d’être le plus réactif possible vis-à-vis de l’acheteur, il est conseillé de mettre en place un
timeout sur non réponse et d’adapter le traitement pour informer l’acheteur.
Systempay – Description des webservices
@Lyra Network- 1/16
_____________
__________________________________________________________
Le marchand veillera à bien configurer la valeur du timeout, car plus ce délai
sera court, plus le nombre de requêtes en timeout sur le site marchand augmentera.
_____________________
__________________________________________________
Le temps moyen de traitement par la plateforme étant inférieur à 5 secondes, un timeout de 20s à
30s est tout à fait acceptable.
ATTENTION
Un temps de traitement plus long ne doit pas être confondu avec un paiement refusé.
Le paiement peut être accepté même si votre requête échoue en timeout. Car la
demande de paiement dépend d’évènements asynchrones non stoppés par le
déclenchement du timeout.
Le marchand devra donc mettre en place un traitement particulier pour les requêtes en timeout.
Si vous n’avez pas récupéré la réponse à votre requête WS à la fin de votre timeout, il ne faut pas
forcément informer l’utilisateur que son paiement a été refusé.
Car il risque de tenter un nouveau paiement alors qu’entre-temps son paiement a réellement
abouti après la fin de votre timeout (traitement asynchrone).
Vous devez plutôt suivant vos contraintes:
•
•
Soit l’informer que son règlement est en cours et revenir vers lui une fois que vous connaissez
le statut final de votre paiement. Car le risque est que l’acheteur tente de multiples
paiements.
Soit le notifier du refus parce que vous savez que vous ne validerez pas son paiement
Systempay – Description des webservices 3-D Secure
@Lyra Network- 2/ 16
3 Description des codes erreurs
Error
Code
Description
0
1
2
3
Action réalisée avec succès
Action non autorisée
Mauvaise signature
Aucune brand localisée
Erreur lors de la détermination de la plage de la
carte
Aucun contrat adéquat trouvé
Spécification du contrat ambigüe, plusieurs sont
disponibles
Marchand non enrôlé
Signature de l’ACS invalide
4
5
6
7
8
Error
Code
Description
9
10
11
12
13
Erreur technique
Mauvais paramètres
Format de date incorrect
3D Secure désactivé
Identifiant non trouvé
14
98
PAN non trouvé
Erreur de traitement sur l’ACS
99
Erreur inconnue
Précisions sur les codes d’erreurs
ErrorCode 0 :
Indique que l’action demandée a été réalisée avec succès, traduisant ainsi que le format de la
requête est correct.
Remarque :
Lors d’une demande d’analyse d’authentification 3DS (méthode analyze), ce code d’erreur ne
doit pas être confondu avec le champ status qui est le seul à donner le résultat de
l’authentification du porteur.
Ainsi on pourra avoir un errorCode à 0 et un status à N, traduisant que l’analyse s’est déroulée
avec succès mais que le porteur ne s’est pas authentifié correctement.
-
ErrorCode 9 :
Ce code erreur correspond à une erreur technique qui peut avoir plusieurs causes.
La plus fréquente étant l’envoi d’un mauvais numéro de contrat commerçant
(createCardInfo.contractNumber) dans la requête.
4 Description des types
4.1
threeDSecureResponse
Ce type permet de décrire la réponse de l’ensemble des webservices 3DS.
Elle sera complétée par un type de réponse spécifique à chaque requête.
Nom du champ
errorCode
errorDetail
timestamp
Type
int
String
long
signature
String
Description
Code d’erreur
Détail de l’erreur si le champ errorCode est différent de 0
Timestamp permettant la génération de signature
unique
Signature de la Réponse (cf. ci-dessous)
La signature permet de valider l’intégrité de la réponse, le calcul de cette signature se fait en
prenant les paramètres dans l’ordre suivant :
errorCode, errorDetail, timestamp
4.2
paResInfo
Il s’agit de la réponse renvoyée par le serveur lors d’une requête analysePAResTx.
Elle contient le résultat de l’authentification 3-D Secure
Nom du champ
brand
enrolled
Type
String
String
status
String
eci
xid
cavv
cavvAlgorithm
String
String
String
String
Description
Brand de la carte (« VISA » ou « MASTERCARD »)
Statut enrôlement porteur :
• « Y » : Enrôlé
• « N » : Non enrôlé
• « U » : Inconnu
Statut authentification du porteur :
• « Y » : Authentifié 3DS
• « N » : Erreur Authentification
• « U » : Authentification impossible
• « A » : Essai d’authentification
ECI
Numéro de transaction marchand
Certificat de l’ACS
Algorithme CAVV :
• « 0 » : HMAC
• « 1 » : CVV
• « 2 » : CVV_ATN
• « 3 » : Mastercard SPA
errorCode, errorDetail, timestamp, brand, enrolled, status, eci, xid, cavv, cavvAlgorithm
4.3
veResPAReqInfo
Réponse renvoyée lors d’une requête
sendVEReqAndbuildPAReqTx
sendVEReqAndbuildPAReqByIdentifierTx.
Elle contient le résultat de la demande d’enrôlement ainsi que le message encodé qui sera
transmis par le navigateur client à l’ACS.
Nom du champ
requestId
Type
String
enrolled
String
acsUrl
acctId
encodedPareq
brand
String
String
String
String
Description
numéro de requête, à rappeler dans les appels analyzePAResTx
Statut d’enrôlement du porteur :
• « Y » : Enrôlé
• « N » : Non enrôlé
• « U » : Inconnu
Url de l’ACS à contacter, présent uniquement si enrolled=Y
certificat renvoyé par le Directory Server
message PAReq encodé, prêt à envoyer à l’ACS
Réseau de carte
errorCode, errorDetail, timestamp, requestId, enrolled, acsUrl, acctId, encodedPareq
5 Signature
Un certificat est nécessaire pour dialoguer avec la plateforme de paiement. Il est mis à
disposition de toutes les personnes habilitées à la consultation des certificats dans votre outil
de gestion de caisse à l’emplacement suivant : Paramètres / Boutique / Certificat. Il existe deux
certificats différents : un pour la plateforme de test et un pour la plateforme de production.
La signature sera générée comme suit :
• Création d'une chaîne de caractère représentant la concaténation des paramètres,
séparés par le caractère "+".
• Ajout à cette chaîne d'un "certificat " numérique (de test ou de production selon le
contexte).
• Hachage de la chaîne résultante avec l'algorithme SHA1.
La plateforme de paiement effectuera obligatoirement la vérification de la signature. Il est de la
responsabilité du commerçant de vérifier à son tour la signature transmise en retour.
L’ordre des champs doit être respecté.
Les champs de type numérique ne doivent pas avoir de 0 à gauche du digit le plus significatif.
Les champs de type bool prennent les valeurs suivantes :
- 1 pour vrai (true)
- 0 pour faux (false)
Les champs de type String non renseignés seront vides.
En mode TEST, en cas de mauvais calcul de signature, le code erreur renvoyé est
« BAD_SIGNATURE » et, la chaine de caractère utilisée pour la signature côté serveur est alors
renvoyée dans le champ errorDetail.
6 Description des méthodes et cinématique
Les WebServices 3D-S décrits dans ce document doivent respecter la cinématique suivante :
Demande de vérification d’enrôlement (veReq)
Construction du message codé (PAReq)
Soumission d’un formulaire auto posté contenant le PAReq
Analyse de la réponse renvoyée par l’ACS (PARes)
Important :
L’architecture de la plateforme de paiement reposant sur un ensemble de serveurs avec
répartition de charge, il est nécessaire que chaque requête associée à un même paiement soit
réalisée avec la même session HTTP afin d’assurer la continuité du processus.
Pour cela, à chaque requête sendVEReqAndbuildPAReqTx, une session est créée coté serveur.
L’ID de la session est renvoyé dans l’entête HTTP de la réponse. Il devra être retourné dans les
requêtes analysePAResTx suivantes.
__________________________________________________________________________________________
Note concernant le mode TEST :
Afin de conserver la continuité des transactions en mode test, il sera nécessaire de
transmettre l’identifiant de la session lors de la redirection vers l’ACS.
Ceci devra se faire en concaténant :
L’url de l’ACS obtenue dans la réponse veResPAReqInfo
L’identifiant de session renvoyé dans l’entête http, séparés par « ;jsessionid= »
La syntaxe à respecter est : ${URL};jsessionid=${session}
Exemple :
<form name="Form" method="post" action="https://paiement.systempay.fr/vadspayment/acs.silent_authenticate.a;jsessionid=B420BF68835F6563FB6E4B289ABB9080.bdxvad
3" >
...
</form>
EN MODE PRODUCTION VOUS NE DEVEZ EN AUCUN CAS TRANSMETTRE UN
IDENTIFIANT DE SESSION A L’ACS
__________________________________________________________________________________________
6.1
Maintien de la session HTTP entre chaque requête
En java
Une fois le client WebService créé (port), utiliser la méthode signalée en gras dans le code suivant :
Service service = Service.create(wsdlURL, qname);
ThreeDSecure port = service.getPort(ThreeDSecure.class);
((BindingProvider) port).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY,
true);
Cela permet au serveur de ne pas ignorer les infos de session associées à la requête http et de
maintenir un cookie avec l’ID de session.
En PHP
Après l’appel à la fonction sendVEReqAndBuildPAReqTx, la session est créée côté serveur et
renvoyée dans les headers HTTP de la réponse. Pour les méthodes suivantes de la même
transaction, il faut récupérer ce header et le transmettre en tant que cookie dans la requête HTTP.
Voici un exemple de code pour récupérer l’id de session et le transmettre :
/* La méthode ci-dessous permet de récupérer l’entête HTTP de la réponse */
$header = $client->__getLastResponseHeaders();
/* Dans la chaîne de caractère obtenue, nous recherchons la présence de l’ID de la
session HTTP, stockée dans l’élément "JSESSIONID" : */
if(!preg_match("#JSESSIONID=([A-Za-z0-9\.]+)#",$header, $matches)){
return "Aucun ID de Session Renvoyé.";//Cas d’erreur technique;
}
$cookie = $matches[1];
/*La méthode ci-dessous permet de spécifier un cookie qui sera envoyé dans chaque entête
http */
$client->__setCookie ("JSESSIONID", $cookie);
Il est donc nécessaire de stocker cet id de session car lors du retour de l’ACS, dé corrélé des
requêtes sendVEReqAndbuildPAReqTx, il faut également l’envoyer.
6.2
Principe de fonctionnement de l’authentification 3D-Secure
Cinématique du paiement :
L’acheteur valide sa commande sur le site marchand.
Il saisit ses données cartes sur le site marchand pour procéder au paiement.
Le site marchand contacte Systempay (méthode sendVEReqAndBuildPAResTx)
Systempay, via son MPI, interroge le directory VISA ou Mastercard.
Si la carte n’est pas enrôlée, Systempay renvoie au marchand les informations utiles pour la
création d’une transaction (à renseigner dans le champ threeDSResult de la méthode
create par exemple)
Si la carte est enrôlée, Systempay renvoie au marchand les informations
suivantes (veResPAReqInfo):
- L’URL du site internet de la banque du porteur (ACS) vers laquelle le marchand
devra rediriger l’acheteur.
- Le message PAReq encodé
- L’identifiant de la requête (requestId)
Le site marchand sauvegarde dans le champ MD l’identifiant de session contenu dans l’entête
de la réponse (JSESSIONID) ainsi que l’identifiant de la requête (requestId) contenu dans la
réponse veResPAReqInfo
Le site marchand envoie au navigateur de l’acheteur une requête http POST avec les
informations contenues dans le veResPAReqInfo ainsi que le champ MD.
L’acheteur est redirigé vers sur le site de la banque émettrice (ACS) et s’authentifie
A la fin de l’authentification, l’acheteur est redirigé vers le site marchand et son navigateur
effectue une requête POST à destination du site marchand contenant les champs MD et PARes
Le site marchand récupère ces deux champs et les transmet à Systempay pour vérifier
l’authentification (méthode analyzePAResTx)
Le MPI de Systempay vérifie les données contenues dans le PARes :
l’acheteur ne s’est pas authentifié, le paiement sera refusé.
Le marchand peut :
Soit transmettre le résultat de l’authentification 3DS dans le champ threeDSResult de la
méthode create.
Ceci aboutira à la création d’une transaction refusée, visible dans le back office.
Soit arrêter le processus de paiement et indiquer à l’acheteur que le paiement est
refusé.
l’acheteur s’est authentifié, le marchand doit alors valoriser le champ threeDSResult de la
méthode create avec le résultat de l’authentification 3DS. Systempay procèdera alors à la
demande d’autorisation.
6.3
6.3.1
Vérification d’enrôlement et génération de la demande d’authentification 3DS
Paiement classique
La méthode sendVEReqAndBuildPAReqTx permet de faire une demande de vérification
d’enrôlement auprès des Directory Servers VISA ou MasterCard et de générer le message envoyé
par le navigateur du client lors de la requête d’authentification du payeur (PAReq) vers l’ACS.
Cette fonction prend en entrée les paramètres suivants :
Nom du champ
Type
shopId
contractNumber
String
String
ctxMode
String
cardNumber
browserUserAgent
browserAccept
purchaseAmount
purchaseCurrency
cardExpiry
wsSignature
String
String
String
String
String
String
String
Description
Obligatoire
Identifiant de la boutique
Numéro de contrat commerçant
Contexte de sollicitation de la plateforme de paiement
("TEST", "PRODUCTION")
Numéro de carte du porteur
Header « User-Agent » du navigateur du client
Header « Accept » du navigateur du client
Montant de la transaction en plus petite unité monétaire
Devise (Code monnaie ISO 4217, Euro : 978)
Date d'expiration de la carte, format YYMM
Signature (cf ci-dessous)
Le calcul de la signature se fait en prenant les paramètres dans l’ordre suivant :
shopId, , contractNumber, ctxMode, cardNumber, browserUserAgent, browserAccept,
purchaseAmount, purchaseCurrency, cardExpiry
Cette fonction retourne une réponse du type veResPAReqInfo contenant le résultat de la
demande d’enrôlement ainsi que le message PAReq codé dans le cas où le champ enrolled est
valorisé à « Y »
Cas des cartes non enrôlées ou dont le statut d’enrôlement est inconnu
Si le champ enrolled est valorisé à ‘N’ ou ‘Y’, alors la cinématique d’authentification 3-D Secure
s’arrête.
Si le marchand souhaite réaliser un paiement (via la méthode create) il doit impérativement
valoriser le champ threeDSResult comme suit :
Nom du champ
Type
brand
enrolled
String
String
authStatus
eci
xid
cavv
cavvAlgorithm
String
String
String
String
String
Description
Obligatoire
Brand de la carte ("VISA" ou "MASTERCARD")
Statut enrôlement porteur :
•
"N" : Non enrôlé
•
"U" : Inconnu
Ne pas envoyer
Ne pas envoyer
Ne pas envoyer
Ne pas envoyer
Ne pas envoyer
Cas des cartes enrôlées
Si le champ enrolled est valorisé à ‘N’ ou ‘Y’, alors la cinématique d’authentification 3-D Secure
doit continuer (cf. chapitre Redirection vers l’ACS)
6.3.2
Paiement en 1 clic (paiement par identifiant)
La méthode sendVEReqAndBuildPAReqByIdentifierTx permet de faire une demande de vérification
d’enrôlement auprès des Directory Servers VISA ou MasterCard en passant en paramètre
l’identifiant d’un compte carte et de générer le message envoyé par le navigateur du client lors
de la requête d’authentification du payeur (PAReq) vers l’ACS.
Nom du champ
Type
shopId
contractNumber
ctxMode
String
String
String
identifier
browserUserAgent
browserAccept
purchaseAmount
String
String
String
String
purchaseCurrency
wsSignature
String
String
Description
Obligatoire
Contexte de sollicitation de la plateforme de
paiement ("TEST", "PRODUCTION")
Identifiant du compte carte
Header « User-Agent » du navigateur du client
Header « Accept » du navigateur du client
Montant de la transaction en plus petite unité
monétaire
Devise (Code monnaie ISO 4217, Euro : 978)
shopId, contractNumber, ctxMode, identifier, browserUserAgent, browserAccept,
purchaseAmount, purchaseCurrency
Cette fonction retourne une réponse du type veResPAReqInfo contenant le résultat de la
demande d’enrôlement ainsi que le message PAReq codé dans le cas où le champ enrolled est
valorisé à « Y ».
______________________________________________________________________________________________
Note:
D’après le protocole français ERT 27, même en cas d’authentification réussie, le paiement
ne sera pas garanti.
La méthode create (ws-identifiant) ne possède donc pas de paramètre d’entrée
acceptant le résultat de l’authentification 3DS.
______________________________________________________________________________________________
6.4
Redirection vers l’ACS
Après avoir récupéré le contenu du veResPAReqInfo, il faut rediriger le navigateur du client vers son
ACS, en renvoyant une page HTML avec un formulaire POST auto soumis.
L'url de l'ACS est utilisée comme action du POST, la valeur est celle retournée dans le champ
veResPAReqInfo.acsUrl).
Il faut également disposer d’une url de retour sur le serveur pour récupérer la réponse de l'ACS (elle
aussi par POST).
Ce formulaire doit obligatoirement contenir les champs suivants (attention à bien respecter les
majuscules) :
Nom du champ
Type
PaReq
String
TermUrl
String
MD
String
Description
Obligatoire
Message codé, retourné par l’appel de la
méthode sendVEReqAndBuildPaReqTx (champ
veResPAReqInfo.encodedPAReq
URL de retour dans laquelle sera analysé le retour
de l’authentification 3-D Secure
‘Merchant DATA’. Il s’agit de données qui seront
restituées lors de la réponse de l’ACS. Par
commodité il est conseillé de valoriser ce champ
avec l’id de session et le requestId afin de
reprendre facilement le traitement,
par exemple sous la forme suivante :
« id_de_session+requestId »
__________________________________________________________________________________________
Rappel concernant le mode TEST :
Afin de conserver la continuité des transactions en mode test, il sera nécessaire de
transmettre l’identifiant de la session lors de la redirection vers l’ACS.
Ceci devra se faire en concaténant :
L’url de l’ACS obtenue dans la réponse veResPAReqInfo
L’identifiant de session renvoyé dans l’entête http, séparés par « ;jsessionid= »
La syntaxe à respecter est : ${URL};jsessionid=${session}
Exemple :
<form name="Form" method="post" action="https://paiement.systempay.fr/vadspayment/acs.silent_authenticate.a;jsessionid=B420BF68835F6563FB6E4B289ABB9080.bdxvad
3" >
...
</form>
EN MODE PRODUCTION VOUS NE DEVEZ EN AUCUN CAS TRANSMETTRE UN
IDENTIFIANT DE SESSION A L’ACS
__________________________________________________________________________________________
Exemple de page de redirection
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
<title>---</title>
<script type="text/javascript">
<!-function submitForm(){
document.redirectForm.submit();
}
-->
</script>
</head>
<body onLoad="setTimeout(\'submitForm()'.'\',500);">
<span class="message">redirection ACS</span>
<br/>
<br/>
<br/>
<form name="redirectForm" action="acsUrl" method="POST">
<input type="hidden" name="PaReq" value="encodedPareq"/>
<input type="hidden" name="TermUrl" value="url_de_retour"/>
<input type="hidden" name="MD" value="requestId" />
<noscript><input type="submit" name="Go" value="Click to continue"/></noscript>
</form>
</body>
</html>
6.5
Récupération de la réponse de l’ACS
Il est nécessaire de mettre en place une URL de retour de l’ACS pour que celui-ci puisse nous
renvoyer les données du PARes.
Les paramètres renvoyés par l’ACS sont les suivants :
•
•
PaRes : contient le message PARes
MD : contient le Merchant Data envoyé lors de l’appel à l’ACS
Il convient alors d’extraire du champ MD les valeurs de l’id de session et du requestId pour ensuite
les utiliser lors de l’appel à la méthode analyzePAResTx.
Exemple de page de retour :
Dans cet exemple, le champ MD a été composé de l’id de la session et de l’identifiant de la
requête, séparés par le caractère « + » :
<?php
session_start();
?>
<html>
<head></head>
<body>
<?php
$PaRes = $_POST['PaRes'];
list($JSESSIONID, $requestId) = explode("+",$_POST['MD']);
//Initialisation du client SOAP
$client = new soapclient($wsdl,array('trace' =>1));
//Définition du cookie qui sera envoyé avec la requête SOAP
$client-> __setCookie('JSESSIONID', $JSESSIONID);
Appel de la méthode analysePAResTx
…
</body>
</html>
6.6
Analyse de l’authentification 3DS (analyzePAResTx)
Cette fonction permet de soumettre à la plateforme de paiement le message PARes reçu après
l’authentification 3D-S.
Nom du champ
Type
shopId
contractNumber
ctxMode
String
String
String
requestId
pares
wsSignature
String
String
String
Description
Obligatoire
Contexte de sollicitation de la plateforme de
paiement ("TEST", "PRODUCTION")
numéro de requête
Message PaRes encodé, reçu de l’ACS
shopId, contractNumber, ctxMode, requestId, pares
Cette fonction retourne une réponse du type paResInfo. Elle contient le message PAReq codé.
Cette réponse est ensuite utilisée pour renseigner le champ threeDsResult lors d’une requête de
paiement :
Le marchand devra obligatoirement fournir tous les champs: brand, enrolled, authStatus, xid.
Dans le cas où l’internaute s’est correctement authentifié (status= "Y" ou "A")
Les champs eci, cavv et cavvAlgorithm deviennent obligatoires.
Dans le cas où l’internaute ne s’est pas authentifié (status= "N" ou "U"),
les champs eci, cavv et cavvAlgorithm ne doivent pas être envoyés
________________________________________________________________________________________________
Remarque :
Le message PARes peut comporter des caractères de retour à la ligne (‘CR’, ‘LF’ ou
‘\r’,’\n’).
Ces caractères sont remplacés par un simple LF par certains framework au moment de
l’appel au WS. C’est le cas notamment en ASP.NET.
Afin de ne pas rencontrer des problèmes de calcul de signature, il est conseillé de
supprimer les retours à la ligne avant le calcul de signature.
Cette suppression n’altère pas l’intégrité du message PARes.
________________________________________________________________________________________________
7 Annexes
Ci dessous la liste des numéros de carte à utiliser en mode TEST :
Numéro de carte
Résultat du test
4970100000000000 - 5970100300000000 - 5000550000000000
Paiement accepté avec authentification 3-D Secure
4970100000000009 – 5970100300000009 - 5000550000000009
Paiement avec authentification 3-D Secure interactive
4970100000000003 - 5970100300000003 - 5000550000000003
Paiement accepté, commerçant non enrôlé 3-D Secure
4970100000000001 - 5970100300000001 - 5000550000000001
Paiement accepté, internaute non enrôlé 3-D Secure
4970100000000002 - 5970100300000002 - 5000550000000002
Paiement refusé, transaction à forcer, contacter
l'émetteur de carte
4970100000000007 - 5970100300023006 - 5000550000023006
Paiement accepté, garantie de paiement = NO
4970100000000097 - 5970100300000097 - 5000550000000097
4970100000000098 - 5970100300000098 - 5000550000000098
4970100000000099 - 5970100300000099 - 5000550000000099
Paiement refusé pour cause d'authentification 3-D
Secure échouée, l'internaute n'est pas parvenu à
s'authentifier
Paiement refusé (autorisation refusée pour cause de
plafond dépassé)
Paiement refusé, autorisation refusée suite à erreur dans
le cryptogramme visuel saisi
La date d’expiration et le cryptogramme sont à votre libre choix (Ex: date mars 2020 et
cryptogramme = 123
Toutes les transactions réalisées en mode TEST sont visibles par les personnes habilitées sur
le back office, dans le menu Gestion/ Transactions de TEST ».
__________________________________________________________________________________________
Les résultats des tests ci-dessus sont conditionnés par l’état d’enrôlement de votre contrat.
Tant que vous ne recevez pas le mail vous informant de l’activation de la garantie 3D- Secure,
les paiements de tests seront réalisés sans 3DS.
__________________________________________________________________________________________

Définition des Webservices Systempay

Transcription

Documents pareils

Guide_d`implémentation_WebServices_plages de BINs

Parure Yemandja ouvert String + collier Yemandja ouvert Marque

Moorea Mini maillot 2 pièces string. Soutien gorge lycra

Guide des cartes de test

Juliette String réalisé dans un jolie tulle brodé décoré par

Quand arrêtera-‐t-‐on, dans les entreprises, de porter le string ?

Niagara micro Micro string noir, réalisé dans une très belle

String Humour Elephant Bleu SL

Ensemble Scarlett Ensemble Sout. gorge et string en