Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.
Commentaire: maj erreur écran

Image Removed

Contenu

Sommaire
maxLevel21
stylenone

 Image Added

Extrait
hiddentrue

Historique des évolutions

Le tableau ci-dessous liste les dernières modifications effectuées sur ce document.

Version

Date

Modifications

 Acteur

17/10/2009

1.A

Création du document


24/11/2009

1. B

Ajout de la partie 3DSecure DIRECT


24/10/2011

1.C

Correction du nom du champ authentication3DSecure


03/12/2012

1.D

Revue du document











Avertissement

Cette intégration n'est plus conforme à la nouvelle directive européenne. Veuillez vous reporter la documentation 3DSV2.



Introduction

Pré-requis bancaire et de connexion 3DSecure

Ce programme traitement repose sur la mise en place d'un contrôle supplémentaire lors d'un achat en ligne : en complément des données bancaires, l'acheteur validera son paiement en saisissant une donnée secrète que lui aura fourni sa banque.
Ce dispositif s'accompagne d'une évolution réglementaire appelée "liability shift" ou "transfert de responsabilité" dont le principe est de faire supporter le risque d'impayé émis pour contestation du porteur à la banque du porteur et non plus au commerçant, si le porteur a validé son paiement en renseignant les données 3D Secure et que le commerçant a respecté les mesures de sécurité énoncées dans les conditions générales de vente de son contrat de commerce électronique souscrit auprès de sa banque.

La solution de paiement Payline a déroulé une certification 3DSecure avec les banques, ainsi qu'avec Visa et MCI.

Souscription 

Le commerçant doit souscrire auprès de sa banque à un contrat VADS (VAD type 3D Secure).
Le commerçant informe Payline qu'il a souscrit à un contrat VADS avec 3DSecure, et le client souhaite souscrire à l'option 3DSecure.
L'équipe Payline, doit procéder à l'enregistrement du commerçant auprès de Visa et MCI, « un délai de 10 jours est nécessaire ».
Dès confirmation des réseaux Visa et MCI, l'équipe Payline informe le client commerçant qu'il va procéder à l'activation du contrat VADS.
Dès activation du contrat VADS, tous les flux transitant sur ce contrat seront des transactions 3DS.

Pre

Pré-requis d'

utilisation

utilisation de la solution de paiement Payline

La solution 3D Secure en mode interface Direct assure le transfert sécurisé des données sensibles et , traite les demandes d'authentification , et d'autorisation. Deux

Les points d'intégration supplémentaires (verifyEnrollment et doAuthorization) sont nécessaires :

, en plus du point d'intégration réalisant et récupérant
Avant de pouvoir utiliser les « webservice » VerifyEnrolment et doAuthorization de Payline, les informations nécessaires à votre authentification et à la mise en œuvre du flux HTTPS sécurisé par SSL V3 sont requises. De plus, un point de vente et un contrat doivent être correctement configurés sur le centre d'administration Payline. Si vous n'avez pas de point de vente, ni de contrat configuré sur le centre d'administration, vous devez vous rendre sur le centre d'administration Payline : https://homologation-admin.payline.com pour vous inscrire.
Pour toutes vos questions, n'hésitez pas à contacter notre équipe support à l'adresse suivante
support@payline.com
Les informations suivantes sont les données indispensables à l'utilisation des « webservice » verifyEnrolment et doAuthorization :
  • L'identifiant commerçant : MerchantID
  • La clé d'accès au service Payline : Accesskey
Lorsque vous réalisez des appels aux services web Payline, l'identifiant de compte commerçant (Merchand ID) et la clé d'accès (Merchant Access Key) doivent être obligatoirement présentés pour réaliser une authentification http. Les appels web services ne seront pas acceptés s'ils ne sont pas correctement authentifiés.
La méthode d'authentification utilisée s'appelle http Basic Authentification. Si l'identifiant de compte commerçant est 1234567890 et votre clé d'accès est DJMESHXYou6LmjQFdH, vous devez encoder en base64 la valeur de
1234567890:DJMESHXYou6LmjQFdH. La chaîne obtenue est à ajouter à l'entête HTTP comme dans l'exemple ci-dessous :
Authorization : Basic MTIzNDU2Nzg5MdpESk1FU0hYWW91NkxtalFGZEg=
Ne communiquez jamais votre clé d'accès (Merchant Access Key) à une tierce personne.
Payline utilise votre clé d'accès pour vous identifier en tant qu'expéditeur de vos demandes de paiement.
Aucun interlocuteur chez Payline ne la connaît et ne vous demandera cette information.
L'utilisation d'iframe n'est pas compatible avec une utilisation optimale et sécuritaire de Payline.

Exemple

Dans l'entête du message HTTP, il est nécessaire de préciser la valeur du champ Authorization. Dans cet exemple, lavaleurduchamp'Authorization'estBasic MTExMTExMTExOkFGanU5WEhwbFF6dmFtZmZPNzJM.
Si l'on décode MTExMTExMTExOkFGanU5WEhwbFF6dmFtZmZPNzJM (qui est encodé en base64), nous obtenons la valeur suivante : 111111111:AFju9XHplQzvamffO72L (merchantID : AccessKey).L'ajout de la valeur authorization dans l'entête de la trame dépend de la technologie utilisée. Si vous utilisez un client web service, il est préférable d'opérer de la manière suivante :
Exemple de code :

Bloc de code
 La variable login prend la valeur du merchantID 
 La variable password prend la valeur de l'accessKey
 //Construction de la requête verifyEnrolment avec les objets payment, card et orderRef
 $verifyEnrollmentRequest = array (
 'payment' => $this->payment($array['payment']),
 'card' => $this->card($array['card']),
 'orderRef' => $array['orderRef']
 );
 //Construction de l'entete du message public $header_soap;
 $this->header_soap = array();
 $this->header_soap['proxy_host'] = $this->proxy_host = PROXY_HOST;
 $this->header_soap['proxy_port'] = $this->proxy_port = PROXY_PORT;
 $this->header_soap['proxy_login'] = $this->proxy_login = PROXY_LOGIN;
 $this->header_soap['proxy_password'] = $this->proxy_password = PROXY_PASSWORD;
 $this->header_soap['login'] = $this->login = MERCHANT_ID;
 $this->header_soap['password'] = $this->password = ACCESS_KEY;
 $this->header_soap['style'] = SOAP_DOCUMENT;
 $this->header_soap['use'] = SOAP_LITERAL; 
 // Creation de l'instance SoapClient qui va permettre l'appel du WebService
 //Déclaration du endPoint ainsi que du header
 $client = new SoapClient('https://services.payline.com/V4/services/DirectPaymentAPI
 ', $this->header_soap); 
 //Appel du WebService
 $verifyEnrollmentResponse = $client->verifyEnrollment($verifyEnrollmentRequest); 
Si vous n'utilisez pas de client services web, il faut alors ajouter dans l'entête la valeur en brut comme dans l'impression écran : Authorization : Basic MTExMTExMTExOkFGanU5WEhwbFF6dmFtZmZPNzJM

3D-Secure en mode interface direct avec un paiement

Ce paragraphe présente les deux web services « verifyEnrollment et doAuthorization » permettant d'effectuer une transaction 3DSecure en utilisant le mode interface direct de la solution de paiement Payline.

Étape 1 : verifyEnrollment

Ce premier appel web service permet de vérifier l'éligibilité du porteur au dispositif 3DSecure, et donc de savoir si le porteur de la carte est bien enregistré auprès d'un Directory Server VISA ou Mastercard.
Voici un exemple de requête / réponse pour le web services verifyEnrollment :

verifyEnrollmentRequest verifyEnrollmentResponse

<impl:verifyEnrollmentRequest>
<impl:card>
<obj:number>4970100000325734</obj:number>
<obj:type>CB</obj:type>
<obj:expirationDate>0912</obj:expirationDate>
<obj:cvx>123</obj:cvx>
</impl:card>
<impl:payment>
<obj:amount>4050</obj:amount>
<obj:currency>978</obj:currency>
<obj:action>100</obj:action>
<obj:mode>CPT</obj:mode>
<obj:contractNumber>CB3DS</obj:contractNumber>
</impl:payment>
<impl:orderRef>REF0923847</impl:orderRef>
</impl:verifyEnrollmentRequest>

<verifyEnrollmentResponse>
<result>
<code>03000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Operation Successfull</longMessage>
</result> <actionUrl>

https://acs.modirum.com/mdpayacs/pareq

</actionUrl>
<actionMethod>POST</actionMethod>
<pareqFieldName>PaReq</pareqFieldName>
<pareqFieldValue>
eJxVkdtuwjAMhl+l4gGaA21ZkcnEOGhIYzAYQ9rNFFoPKq
ClScvh7ZeUMrbcxJ9jx/ZveN8oxP4co1KhgDFqLdfoJHGnw
XgrpM2QNQRMuzPMBRxR6SRLBXOpy4Hc0GSpaCPTQoCM
8qfRq2C86fkBkBphj2rUF+x6gFwRUrlH0e1NnRiPQCqCKCv
TQl0E9ymQG0CpdmJTFIc2IafTyV1n2XqH7rciGqUp/Zh3TM
TXKiuLJC9RA7EJQO59TUtraVPgnMRivPgMJkt/uNoO5Xzrl
5OBz5eDj5fZ8K0DxEZALAsUnJp2KQ8cGrY5a3tmosoPcm8
7E4PFzPGoa1utPXCwhbpX8Kh9+esBo7LCNLqIsPVg5rsR4
PmQpWgijKy/NsSoIzNGfd1n6D1bpaPCiNiklIdBJXXF9qfES
MY4DauvLACxGaTeIqmXbKx/y/8Ba4usNQ==
</pareqFieldValue>
<termUrlName>TermUrl</termUrlName>
<termUrlValue> </termUrlValue>
<mdFieldName>MD</mdFieldName>
<mdFieldValue>1Fz9nEnAZJNn8NvXEKDT</mdFieldValue>
</verifyEnrollmentResponse>

Une fois le verifyEnrollment effectué, l'authentification auprès du serveur ACS doit être effectuée. Pour cela, il est nécessaire d'envoyer les informations du verifyEnrollment sur le serveur d'authentification. Les informations attendues par le MPI sont le MD (pour le suivi de session) et le paReq (requête d'authentification).

Envoi des informations

Pour envoyer ces informations, il suffit de créer un formulaire HTML regroupant les champs MD et paReq et pointant vers le serveur d'authentification.
Exemple de formulaire HTML :

Formulaire HTML

<form name="downloadForm" action="https://acs.modirum.com/mdpayacs/pareq" method="POST">
<input type="hidden" name="TermUrl" value="http://127.0.0.1/3DSecure/receive_form.php">
PAREQ : <input type="text" name="PaReq">
<br />
MD : <input type="text" name="MD">
<br />
<input type="submit" name="submit" value="Submit">
</form>

Les informations devant être envoyées au serveur d'authentification à travers le formulaire ci-dessus :
  • MD : suivi de la session : valeur à récupérer dans la réponse du verifyEnrollment
  • PaReq : requête d'authentification : valeur à récupérer dans le verifyEnrollment
  • TermURL : adresse où le serveur d'authentification envoie la réponse de l'authentification. Concrètement cette adresse doit être capable de récupérer un formulaire envoyé en « POST » et contenant la réponse de l'authentification de l'utilisateur.

Envoi Réception des informations retournées lors de l'authentification :des informations

Le serveur d'authentification envoi son message sur l'URL renseignée dans le paramètre TermURL (envoyé dans le formulaire précédent). Dans le formulaire de réponse, deux champs doivent être récupérés pour poursuivre la transaction en mode 3DSecure :

  • Le champ MD : toujours le même champ permettant le suivi de la session
  • le champ PaRes : Payer Authentication Response : chaine de caractères cryptée contenant la réponse du serveur d'authentification. La valeur du champ PaRes va permettre de valider ou non la transaction comme une transaction 3DSecure.
Ces deux champs sont récupérés et permettent de compléter le doAuthorizationRequest en mode 3DSecure
Exemple de script (ici écrit en PHP) permettant de récupérer la réponse à l'authentification :

Script PHP : receive_form.php

<?php
$pares = $_POST['PaRes'];
$md = $_POST['MD'];
echo "MD : ".$md."<br />PARES : ".$pares;
?> Remarque : ce script doit être placé sur un serveur web démarré et dans un dossier correspondant à l'adresse envoyé via le champ TermURL.
Exemple : si le serveur est en local il est tout à fait possible de mettre comme valeur :
TemrURL = http://127.0.0.1/3DSecure/receive_form.php

Étape 2 : doAuthorization avec les parametres 3DSecure

L'appel web service de la méthode doAuthorization permet d'effectuer directement la transaction avec les paramètres 3DSecure. Les paramètres renseignés : md / pares permettent de vérifier l'authentification et donc l'identité de l'utilisateur avant d'effectuer la transaction.

Si les paramètres sont corrects, la transaction est alors directement effectuée comme pour le doAuthorization classique.

doAuthorizationRequest

doAuthorizationResponse

<impl:doAuthorizationRequest>
<impl:payment>
<obj:amount>4150</obj:amount>
<obj:currency>978</obj:currency>
<obj:action>100</obj:action>
<obj:mode>CPT</obj:mode>
<obj:contractNumber>CB3DS</obj:contractNumber>
</impl:payment>
<impl:card>
<obj:number>4970105512345674</obj:number>
<obj:type>CB</obj:type>
<obj:expirationDate>0912</obj:expirationDate>
<obj:cvx>123</obj:cvx>
</impl:card>
<impl:order>
<obj:ref>REF023493</obj:ref>
<obj:country>FR</obj:country>
<obj:taxes>100</obj:taxes>
<obj:amount>1400</obj:amount>
<obj:currency>978</obj:currency>
<obj:date>28/01/2009 09:32</obj:date>
</impl:order>
<impl:buyer>
<obj:lastName>Dupond</obj:lastName>
<obj:firstName>Wilfried</obj:firstName>
<obj:email>wilfried.dupond@yahoo.fr</obj:email>
</impl:buyer>
<impl:authentication3DSecure>
<obj:md>xRtMifcy975D2EB3Zs8e</obj:md>
<obj:pares>
eJzFV2mTokoW/Ssd/T4a3ewKHZQq8LT8uWh9v0X8C9X
9dnSvZpwiZxtkQnR4/vcxQo0vM1a4/lI9R/BFjkEQryXL4
NU12Tb4MZVE1L1+PbVv/QJC+77/3xPfzNUWmgFEEZZ
k6R9fX0cle6U6nJcsH1bnKovDIruH7bTYMGmP5/2X9wl
2H14xxBT5b5PbbzFGVt8eCEo8aYT83umHcP/OLJ8Dvzb
YYYo8JPjlasmZySB7LnHxxTOXl6x8fSC1kadK0/86Mb7N
Dmzw2LW7JsXdOgDbKqGt0MWzXUzHgfeTiJHYyXt3Gvli
LP+N9W4D2XV0MrIQkUn+/iOLJrhOdX5t6je0MVLvrO6/
+UWyynOS9H7sYGAZ5U3lbmDcT3ZMMEcjDfJb20VXhTw
bWgWEOt2Ix04i1tmBAuFHx2aEgzgEtcaJzH8TLbsXbpj4r
…………
</obj:pares>
<obj:xid/>
<obj:eci/>
<obj:cavv/>
<obj:cavvAlgorithm/>
<obj:vadsResult/>
</impl:authentication3DSecure>
</impl:doAuthorizationRequest>

<doAuthorizationResponse>
<result>
<code>00000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Transaction approved</longMessage>
</result>
<transaction>
<id>90217095220928</id>
<date>17/02/09 09:52</date>
<isDuplicated>0</isDuplicated>
<isPossibleFraud>0</isPossibleFraud>
<fraudResult/>
<explanation/>
<threeDSecure>Y</threeDSecure>
<score/>
</transaction>
<authorization>
<number>A55A</number>
<date>17/02/09 09:52</date>
</authorization>
</doAuthorizationResponse>

3D-Secure en mode interface direct avec la possibilité ou pas d'effectuer un paiement

Il est possible d'utiliser la fonction 3DSecure implémentée sur la solution de paiement Payline, sans utiliser la fonction standard de Payline « effectuer un paiement », donc vous utiliserez uniquement les deux premières étapes décrites ci-dessous.
En effet l'Etape 3, permet d'effectuer une transaction de paiement en vous appuyant de la solution de paiement 3DSecure.

Étape 1 : appel du web service verifyEnrollment

Comme expliqué précédemment, cette première action permet de vérifier l'enrôlement de la carte de l'utilisateur. Les éléments obligatoires de la méthode verifyEnrollment sont :

  • card : numéro de carte / type / date d'expiration / cvx
  • payment : montant / devise / action / mode / numéro contrat
  • orderRef
Voici des données de test permettant d'obtenir un résultat positif : 03000 – Operation successfull :
  • amount = 1000
  • currency = 978
  • action = 101
  • mode = CPT
  • orderRef = RefTest01
  • number = 4970100000000238
  • type = CB
  • expirationDate = 0610
  • CVx : 123
Exemple de requête verifyEnrollment :

verifyEnrollmentRequest

verifyEnrollmentResponse

<impl:verifyEnrollmentRequest>
<impl:card>
<obj:number>4970100000325734</obj:number>
<obj:type>CB</obj:type>
<obj:expirationDate>0610</obj:expirationDate>
<obj:cvx>123</obj:cvx>
</impl:card>
<impl:payment>
<obj:amount>1000</obj:amount>
<obj:currency>978</obj:currency>
<obj:action>100</obj:action>
<obj:mode>CPT</obj:mode>
<obj:contractNumber>CB3DS</obj:contractNumber>
</impl:payment>
<impl:orderRef>RefTest01</impl:orderRef>
</impl:verifyEnrollmentRequest>

<verifyEnrollmentResponse>
<result>
<code>03000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Operation Successfull</longMessage>
</result> <actionUrl>

https://acs.modirum.com/mdpayacs/pareq

</actionUrl>
<actionMethod>POST</actionMethod>
<pareqFieldName>PaReq</pareqFieldName>
<pareqFieldValue>
eJxVkdtygjAQhl/F8QHcJAUBZ90Zj4MXbdHaXvSOC
TuVTkEM0OrU9ir7bfb4L253hnn+wro1TPjIdZ1+cC/Pxn3
lh0J4fcJksuED4TebOt+XJAdioBCuaHOM3qVlQ5jq
QCnnQ/fz1olTNc6hNFQWhnvxLysdqXbCOsWDcbM661X
aN77jvMYqefbqw4SoSRcrU6dpVyK4e0o59LOUBwG
dDdBrrDWevfQX8B2heclQ==
</pareqFieldValue>
<termUrlName>TermUrl</termUrlName>
<termUrlValue>

http://www.experian.fr

</termUrlValue>
<mdFieldName>MD</mdFieldName>
<mdFieldValue>8FPL0ihqQtuqr1GzmOCL</mdFieldValue>
</verifyEnrollmentResponse>

Dans la réponse du verifyEnrollment on distinguera deux parties d'éléments XML : l'élément result permet de récupérer la réponse concernant l'enrôlement ou non de la carte utilisée. Le résultat de la vérification est visible à travers les différents codes retour ainsi qu'avec les shortMessage et longMessage apportant un complément d'information au code retour. Le verifyEnrollment peut renvoyer les codes retours suivants :
  • 02101 - Internal Error - Internal Error
  • 02303 – Invalid Transaction – Invalid Contract Number
  • 02305 – Invalid Transaction - Invalid field format
  • 03000 - Operation Successfull – Operation Successfull
  • 03001- Operation Refused – Not Enrolled
  • 03002 - Operation Refused - Not participating
  • 03021 – Transaction Refused - Enrollment verification failed
  • 09201 - Access Refused - You do not have permissions to make this API call
La deuxième partie dans la réponse du verifyEnrollment sont les éléments renvoyés par le Directory Server et permettant le suivi de la transaction à venir :
  • PAReq : Payer Authentication Request : suite de caractères regroupant la requête à envoyer au serveur d'authentification, permet d'identifier la carte et son le titulaire.
  • MD : Merchant Date : identifiant permettant d'identifier le commerçant et de simuler une session entre les requêtes d'enrôlement et d'authentification sur les serveurs Access Control Server (ACS) et Merchant Plug-in (ou MPI).
  • actionURL : URL indiquant où doivent être envoyées les informations permettant de vérifier l'authentification de l'utilisateur (voir ci-dessous).
  • actionMethod : méthode devant être utilisée pour envoyée les informations au serveur d'authentification (voir ci-dessous).
Pour chaque élément, on trouve le nom du champ et la valeur du champ.
Exemple : paresFieldName / paresFieldValue.

Etape 1 : appel du web service verifyEnrollment

Suivi technique des appels « webservice » :

Image Removed Détail du verifyEnrollment Image Removed

Etape 2 : authentification

Une fois le verifyEnrollment effectué, l'authentification auprès du serveur ACS doit être effectuée. Pour cela, il est nécessaire d'envoyer les informations du verifyEnrollment sur le serveur d'authentification. Les informations attendues par le MPI sont le MD (pour le suivi de session) et le paReq (requête d'authentification).

Envoi des informations

Pour envoyer ces informations, il suffit de créer un formulaire HTML regroupant les champs MD et paReq et pointant vers le serveur d'authentification.
Exemple de formulaire HTML :

Formulaire HTML

<form name="downloadForm" action="https://acs.modirum.com/mdpayacs/pareq" method="POST">
<input type="hidden" name="TermUrl" value="http://127.0.0.1/3DSecure/receive_form.php">
PAREQ : <input type="text" name="PaReq">
<br />
MD : <input type="text" name="MD">
<br />
<input type="submit" name="submit" value="Submit">
</form>

Les informations devant être envoyées au serveur d'authentification à travers le formulaire ci-dessus :
  • MD : suivi de la session : valeur à récupérer dans la réponse du verifyEnrollment
  • PaReq : requête d'authentification : valeur à récupérer dans le verifyEnrollment
  • TermURL : adresse où le serveur d'authentification envoie la réponse de l'authentification. Concrètement cette adresse doit être capable de récupérer un formulaire envoyé en « POST » et contenant la réponse de l'authentification de l'utilisateur.

Réception des informations retournées lors de l'authentification

Le serveur d'authentification envoi son message sur l'URL renseignée dans le paramètre TermURL (envoyé dans le formulaire précédent). Dans le formulaire de réponse, deux champs doivent être récupérés pour poursuivre la transaction en mode 3DSecure :
le champ MD : toujours le même champ permettant le suivi de la session
le champ PaRes : Payer Authentication Response : chaine de caractères cryptée contenant la réponse du serveur d'authentification. La valeur du champ PaRes va permettre de valider ou non la transaction comme une transaction 3DSecure.
Ces deux champs sont récupérés et permettent de compléter le doAuthorizationRequest en mode 3DSecure
(Voir Etape 3 : doAuthorization).
Exemple de script (ici écrit en PHP) permettant de récupérer la réponse à l'authentification :

Script PHP : receive_form.php

<?php
$pares = $_POST['PaRes'];
$md = $_POST['MD'];
echo "MD : ".$md."<br />PARES : ".$pares;
?> Remarque : ce script doit être placé sur un serveur web démarré et dans un dossier correspondant à l'adresse envoyé via le champ TermURL.
Exemple : si le serveur est en local il est tout à fait possible de mettre comme valeur :
TemrURL = http://127.0.0.1/3DSecure/receive_form.php

Visualisation sur le centre d'administration

Image Removed

Etape 3 : doAutorization

La dernière étape dans le cadre d'une transaction 3DSecure via l'interface Payline DIRECT est l'envoi d'une requête doAuthorization. Comme dans le cadre d'une transaction classique, le doAuthorization contiendra les champs obligatoires suivant :

  • payment : informations sur la transaction : montant, devise, contrat, etc.
  • card : informations sur la carte de paiement : numéro, type, date d'expiration, etc.
  • order : information sur la commande : référence, montant, pays, etc.
    Et donc dans le cadre d'un paiement 3DSecure, la requête doAuthorization devra être complétée avec les informations renvoyées par le serveur d'authentification :
  • MD : suivi de session 3DSecure.
  • PaRes : résultat de l'authentification.
Ces deux éléments seront placés dans l'élément : <authentication3DSecure> comme indiqué dans l'exemple doAuthorization suivant :

doAuthorizationRequest

doAuthorizationResponse

<doAuthorizationRequest>
<payment>
<amount>1000</amount>
<currency>978</currency>
<action>100</action>
<mode>CPT</mode>
<contractNumber>CB3DS</contractNumber>
</payment>
<card>
<number>4970100000325734</number>
<type>CB</type>
<expirationDate>1212</expirationDate>
<cvx>123</cvx>
</card>
<order>
<ref>REF0989</ref>
<amount>1000</amount>
<currency>978</currency>
<date>24/02/2008 09:28</date>
</order>
<authentication3DSecure>
<md>2vS6uabMBUzx9LrEDS9c</md>
<pares>eJzFV2mvosoW/Sudvh9NN7NKhzYpRlEL
avfp887t93Lz8gYSYtV216q9qbV2VTFmcosi3ojC+y1
i888rZg/0qH6aCopcLGiCnoxtdKvTS7nCvqJfcQb52Z
pjJMYgP7pMEd1kfkUvF3OKQV4dBvk1an9/tOoplj49
RLN1UHfmeQhwdz9JtohaMojeI4+QkjvmHUN4pmk
CntW1....................
</pares>
</authentication3DSecure>
</doAuthorizationRequest>

<doAuthorizationResponse>
<result>
<code>00000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Transaction approved</longMessage>
</result>
<transaction>
<id>90224141650893</id>
<date>24/02/09 14:16</date>
<isDuplicated>0</isDuplicated>
<isPossibleFraud>0</isPossibleFraud>
<fraudResult/>
<explanation/>
<threeDSecure>Y</threeDSecure>
<score xsi:nil="true" />
</transaction>
<authorization>
<number>A55A</number>
<date>24/02/09 14:16</date>
</authorization>
</doAuthorizationResponse>

Visualisation du centre d'administration

Le résultat de la transaction 3DSecure est alors visible dans le centre d'administration Payline : sur les résultats d'une recherche et dans le détail de la transaction onglet 3DSecure :
Ecran recherche des transactions : Image Removed

Image Removed

Détail de la transaction 3DSecure Image Removed Image Removed

Annexe

Paramétrage de SOAP UI

Téléchargement de SOAP UI :
SOAP UI est une application permettant de faire des appels web services. Dans l'environnement Payline, ce client web services va vous permettre d'envoyer des requêtes à l'API Payline de façon à créer des transactions de test, vérifier le format des réponses de l'API ou tout simplement vérifier le format des informations que vous envoyées à Payline.
SOAP UI 2.5 est disponible en version gratuite ou en version professionnelle, vous pouvez le télécharger sur le site http://www.soapui.org/

Ajout d'un projet Payline : dans SOAP UI, créer un nouveau projet : File / New SOAP UI Project avec les propriétés suivantes : La création du projet génère l'ensemble des APIs Payline : DirectPaymentAPI, ExtendedAPI, WebPaymentAPI, MassPaymentAPI, ainsi que les services de chaque API : exemple : doAuthorization, doCapture, doWebPayment, etc.
Pour chaque service, une requête, nommée « Request 1 », a automatiquement été générée.
Configuration des requêtes SOAP : chaque requête générée pour les services Payline doit être configurées de façon à atteindre l'application Payline.
Configuration du « endpoint » : ouvrir une requête, par exemple le doAuthorization, en effectuant un double clic sur « Request 1 ». Puis dans la barre d'adresse cliquer sur « Add new end point » (voir screenshot ci-dessous) et ajouter l'adresse :

Vous devez vérifier la clé d'accès des services et configuration le paramétrage SOAP UI.


3D-Secure en mode interface direct avec un paiement

Les étapes suivantes présentents les deux web services verifyEnrollment et doAuthorization permettant de reéaliser une transaction 3DSecure en utilisant le mode interface direct de la solution de paiement Payline.


Etape 1 : verifyEnrollment

Ce premier appel web service permet de vérifier l'éligibilité du porteur au dispositif 3DSecure, et donc de savoir si le porteur de la carte est bien enregistré auprès d'un Directory Server VISA ou Mastercard.


Voici un exemple de requête / réponse pour le web services verifyEnrollment :

verifyEnrollmentRequest

verifyEnrollmentResponse

<impl:verifyEnrollmentRequest>
<impl:card>
<obj:number>4970100000325734</obj:number>
<obj:type>CB</obj:type>
<obj:expirationDate>0912</obj:expirationDate>
<obj:cvx>123</obj:cvx>
</impl:card>
<impl:payment>
<obj:amount>4050</obj:amount>
<obj:currency>978</obj:currency>
<obj:action>100</obj:action>
<obj:mode>CPT</obj:mode>
<obj:contractNumber>CB3DS</obj:contractNumber>
</impl:payment>
<impl:orderRef>REF0923847</impl:orderRef>
</impl:verifyEnrollmentRequest>

<verifyEnrollmentResponse>
<result>
<code>03000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Operation Successfull</longMessage>
</result>
<actionUrl>https://acs.banque.com/mdpayacs/pareq</actionUrl>  <actionMethod>POST</actionMethod>
<pareqFieldName>PaReq</pareqFieldName>
<pareqFieldValue> 
eJxVkdtuwjAMhl+l4gGaA21ZkcnEOGhIYzAYQ9rNFFoPKq
ClScvh7ZeUMrbcxJ9jx/ZveN8oxP4co1KhgDFqLdfoJHGnw
XgrpM2QNQRMuzPMBRxR6SRLBXOpy4Hc0GSpaCPTQoCM
8qfRq2C86fkBkBphj2rUF+x6gFwRUrlH0e1NnRiPQCqCKCv
TQl0E9ymQG0CpdmJTFIc2IafTyV1n2XqH7rciGqUp/Zh3TM
TXKiuLJC9RA7EJQO59TUtraVPgnMRivPgMJkt/uNoO5Xzrl
5OBz5eDj5fZ8K0DxEZALAsUnJp2KQ8cGrY5a3tmosoPcm8
7E4PFzPGoa1utPXCwhbpX8Kh9+esBo7LCNLqIsPVg5rsR4
PmQpWgijKy/NsSoIzNGfd1n6D1bpaPCiNiklIdBJXXF9qfES
MY4DauvLACxGaTeIqmXbKx/y/8Ba4usNQ==
</pareqFieldValue> 

<termUrlName>TermUrl</termUrlName>
<termUrlValue>  </termUrlValue>
<mdFieldName>MD</mdFieldName>
<mdFieldValue>1Fz9nEnAZJNn8NvXEKDT</mdFieldValue>
</verifyEnrollmentResponse>


Une fois le verifyEnrollment réalisé, l'authentification auprès du serveur ACS doit être effectuée. Pour cela, il est nécessaire d'envoyer les informations du verifyEnrollment sur le serveur d'authentification.

Envoi des informations

Pour envoyer ces informations :

  • en POST alors créer un formulaire HTML.
  • en GET alors constuire.


POST : Les informations seront envoyées au serveur d'authentification à travers le formulaire ci-dessous.
Les noms des champs et des valeurs sont récupérés dynamiquement du verifyEnrollmentResponse : 

  • Suivi de la session : 
    • mdFieldName = MD
    • mdFieldValue = 1Fz9nEnAZJNn8NvXEKDT

  • Valeur de la requête d'authentification :  
    • pareqFieldName = PaReq
    • pareqFieldValue  = eJxVkdtuwjAMhl+l4gGaA...

  • Adresse su rlaquelle l'acheteur est redirigé al a fin de l'authentification. Le Pares sera rajouté a la fin de cette URL : 
    • termUrlName = TermUrl
      termUrlValue  = http://demoShop/3DSecure/receive_form.php

  • Adresse du serveur d'authentification : cette adresse doit récupérer un formulaire envoyé en POST.
    • actionUrl = https://acs.banque.com/mdpayacs/pareq

Exemple de formulaire HTML pour réaliser un test sur votre serveur :

Formulaire HTML

<form name="downloadForm" action="https://acs.banque.com/mdpayacs/pareq" method="POST">
<input type="hidden" name="TermUrl" value="http://demoShop/3DSecure/receive_form.php">
PAREQ : <input type="text" name="PaReq">
<br />
MD : <input type="text" name="MD">
<br />
<input type="submit" name="submit" value="Submit">
</form>

Réception des informations retournées lors de l'authentification

Le serveur d'authentification envoi son message sur l'URL renseignée dans le paramètre TermURL (envoyé dans le formulaire précédent). Dans le formulaire de réponse, deux champs doivent être récupérés pour poursuivre la transaction en mode 3DSecure :

  • Le champ MD : toujours le même champ permettant le suivi de la session
  • le champ PaRes (Payer Authentication Response) : chaine de caractères cryptée contenant la réponse du serveur d'authentification. La valeur du champ PaRes va permettre de valider ou non la transaction comme une transaction 3DSecure.


Ces deux champs sont récupérés et permettent de compléter le doAuthorizationRequest en mode 3DSecure.

Exemple de script (ici écrit en PHP) permettant de récupérer la réponse à l'authentification :

Script PHP : receive_form.php

<?php
$pares = $_POST['PaRes'];
$md = $_POST['MD'];

echo "MD : ".$md."<br />PARES : ".$pares;
?>


Remarque : ce script doit être placé sur un serveur web démarré et dans un dossier correspondant à l'adresse envoyé via le champ TermURL.


Exemple : si le serveur est en local il est tout à fait possible de mettre comme valeur :
TermURL = http://127.0.0.1/3DSecure/receive_form.php

Etape 2 : doAuthorizathion avec les paramètres 3D Secure

L'appel web service de la méthode doAuthorization permet d'effectuer directement la transaction avec les paramètres 3DSecure.
Les paramètres renseignés : md / pares permettent de vérifier l'authentification et donc l'identité de l'utilisateur avant d'effectuer la transaction.

Si les paramètres sont corrects, la transaction est alors directement effectuée comme pour le doAuthorization classique.


doAuthorizationRequest

doAuthorizationResponse

<impl:doAuthorizationRequest>
<impl:payment>
<obj:amount>4150</obj:amount>
<obj:currency>978</obj:currency>
<obj:action>100</obj:action>
<obj:mode>CPT</obj:mode>
<obj:contractNumber>CB3DS</obj:contractNumber>
</impl:payment>
<impl:card>
<obj:number>4970105512345674</obj:number>
<obj:type>CB</obj:type>
<obj:expirationDate>0912</obj:expirationDate>
<obj:cvx>123</obj:cvx>
</impl:card>
<impl:order>
<obj:ref>REF023493</obj:ref>
<obj:country>FR</obj:country>
<obj:taxes>100</obj:taxes>
<obj:amount>1400</obj:amount>
<obj:currency>978</obj:currency>
<obj:date>28/01/2009 09:32</obj:date>
</impl:order>
<impl:buyer>
<obj:lastName>Dupond</obj:lastName>
<obj:firstName>Wilfried</obj:firstName>
<obj:email>wilfried.dupond@yahoo.fr</obj:email>
</impl:buyer>
<impl:authentication3DSecure>
<obj:md>xRtMifcy975D2EB3Zs8e</obj:md>
<obj:pares>
eJzFV2mTokoW/Ssd/T4a3ewKHZQq8LT8uWh9v0X8C9X
9dnSvZpwiZxtkQnR4/vcxQo0vM1a4/lI9R/BFjkEQryXL4
NU12Tb4MZVE1L1+PbVv/QJC+77/3xPfzNUWmgFEEZZ
k6R9fX0cle6U6nJcsH1bnKovDIruH7bTYMGmP5/2X9wl
2H14xxBT5b5PbbzFGVt8eCEo8aYT83umHcP/OLJ8Dvzb
YYYo8JPjlasmZySB7LnHxxTOXl6x8fSC1kadK0/86Mb7N
Dmzw2LW7JsXdOgDbKqGt0MWzXUzHgfeTiJHYyXt3Gvli
LP+N9W4D2XV0MrIQkUn+/iOLJrhOdX5t6je0MVLvrO6/
+UWyynOS9H7sYGAZ5U3lbmDcT3ZMMEcjDfJb20VXhTw
bWgWEOt2Ix04i1tmBAuFHx2aEgzgEtcaJzH8TLbsXbpj4r
…………
</obj:pares>
<obj:xid/>
<obj:eci/>
<obj:cavv/>
<obj:cavvAlgorithm/>
<obj:vadsResult/>
</impl:authentication3DSecure>
</impl:doAuthorizationRequest>

<doAuthorizationResponse>
<result>
<code>00000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Transaction approved</longMessage>
</result>
<transaction>
<id>90217095220928</id>
<date>17/02/09 09:52</date>
<isDuplicated>0</isDuplicated>
<isPossibleFraud>0</isPossibleFraud>
<fraudResult/>
<explanation/>
<threeDSecure>Y</threeDSecure>
<score/>
</transaction>
<authorization>
<number>A55A</number>
<date>17/02/09 09:52</date>
</authorization>
</doAuthorizationResponse>



Extrait
hiddentrue

3D-Secure en mode interface direct avec la possibilité ou pas d'effectuer un paiement

Il est possible d'utiliser la fonction 3DSecure implémentée sur la solution de paiement Payline, sans utiliser la fonction standard de Payline « effectuer un paiement », donc vous utiliserez uniquement les deux premières étapes décrites ci-dessous.
En effet l'Etape 3, permet d'effectuer une transaction de paiement en vous appuyant de la solution de paiement 3DSecure.

Étape 1 : appel du web service verifyEnrollment

Comme expliqué précédemment, cette première action permet de vérifier l'enrôlement de la carte de l'utilisateur. Les éléments obligatoires de la méthode verifyEnrollment sont :

  • card : numéro de carte / type / date d'expiration / cvx
  • payment : montant / devise / action / mode / numéro contrat
  • orderRef


Voici des données de test permettant d'obtenir un résultat positif : 03000 – Operation successfull :

  • amount = 1000
  • currency = 978
  • action = 101
  • mode = CPT
  • orderRef = RefTest01
  • number = 4970100000000238
  • type = CB
  • expirationDate = 0610
  • CVx : 123


Exemple de requête verifyEnrollment :

verifyEnrollmentRequest

verifyEnrollmentResponse

<impl:verifyEnrollmentRequest>
<impl:card>
<obj:number>4970100000325734</obj:number>
<obj:type>CB</obj:type>
<obj:expirationDate>0610</obj:expirationDate>
<obj:cvx>123</obj:cvx>
</impl:card>
<impl:payment>
<obj:amount>1000</obj:amount>
<obj:currency>978</obj:currency>
<obj:action>100</obj:action>
<obj:mode>CPT</obj:mode>
<obj:contractNumber>CB3DS</obj:contractNumber>
</impl:payment>
<impl:orderRef>RefTest01</impl:orderRef>
</impl:verifyEnrollmentRequest>

<verifyEnrollmentResponse>
<result>
<code>03000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Operation Successfull</longMessage>
</result> <actionUrl>

https://acs.modirum.com/mdpayacs/pareq

</actionUrl>
<actionMethod>POST</actionMethod>
<pareqFieldName>PaReq</pareqFieldName>
<pareqFieldValue>
eJxVkdtygjAQhl/F8QHcJAUBZ90Zj4MXbdHaXvSOC
TuVTkEM0OrU9ir7bfb4L253hnn+wro1TPjIdZ1+cC/Pxn3
lh0J4fcJksuED4TebOt+XJAdioBCuaHOM3qVlQ5jq
QCnnQ/fz1olTNc6hNFQWhnvxLysdqXbCOsWDcbM661X
aN77jvMYqefbqw4SoSRcrU6dpVyK4e0o59LOUBwG
dDdBrrDWevfQX8B2heclQ==
</pareqFieldValue>
<termUrlName>TermUrl</termUrlName>
<termUrlValue>

http://www.experian.fr

</termUrlValue>
<mdFieldName>MD</mdFieldName>
<mdFieldValue>8FPL0ihqQtuqr1GzmOCL</mdFieldValue>
</verifyEnrollmentResponse>



Dans la réponse du verifyEnrollment on distinguera deux parties d'éléments XML : l'élément result permet de récupérer la réponse concernant l'enrôlement ou non de la carte utilisée. Le résultat de la vérification est visible à travers les différents codes retour ainsi qu'avec les shortMessage et longMessage apportant un complément d'information au code retour. Le verifyEnrollment peut renvoyer les codes retours suivants :

  • 02101 - Internal Error - Internal Error
  • 02303 – Invalid Transaction – Invalid Contract Number
  • 02305 – Invalid Transaction - Invalid field format
  • 03000 - Operation Successfull – Operation Successfull
  • 03001- Operation Refused – Not Enrolled
  • 03002 - Operation Refused - Not participating
  • 03021 – Transaction Refused - Enrollment verification failed
  • 09201 - Access Refused - You do not have permissions to make this API call


La deuxième partie dans la réponse du verifyEnrollment sont les éléments renvoyés par le Directory Server et permettant le suivi de la transaction à venir :

  • PAReq : Payer Authentication Request : suite de caractères regroupant la requête à envoyer au serveur d'authentification, permet d'identifier la carte et son le titulaire.
  • MD : Merchant Date : identifiant permettant d'identifier le commerçant et de simuler une session entre les requêtes d'enrôlement et d'authentification sur les serveurs Access Control Server (ACS) et Merchant Plug-in (ou MPI).
  • actionURL : URL indiquant où doivent être envoyées les informations permettant de vérifier l'authentification de l'utilisateur (voir ci-dessous). URL de la banque sur laquelle il faut rediriger l'acheteur.
  • actionMethod : méthode devant être utilisée pour envoyée les informations au serveur d'authentification (voir ci-dessous).



Pour chaque élément, on trouve le nom du champ et la valeur du champ.
Exemple : paresFieldName / paresFieldValue.


Étape 2 : authentification

Une fois le verifyEnrollment effectué, l'authentification auprès du serveur ACS doit être effectuée. Pour cela, il est nécessaire d'envoyer les informations du verifyEnrollment sur le serveur d'authentification. Les informations attendues par le MPI sont le MD (pour le suivi de session) et le paReq (requête d'authentification).

Envoi des informations

Pour envoyer ces informations, il suffit de créer un formulaire HTML regroupant les champs MD et paReq et pointant vers le serveur d'authentification.


Exemple de formulaire HTML :

Formulaire HTML

<form name="downloadForm" action="https://acs.banque.com/mdpayacs/pareq" method="POST">
<input type="hidden" name="TermUrl" value="http://demoShop/3DSecure/receive_form.php">
PAREQ : <input type="text" name="PaReq">
<br />
MD : <input type="text" name="MD">
<br />
<input type="submit" name="submit" value="Submit">
</form>




Les informations devant être envoyées au serveur d'authentification à travers le formulaire ci-dessus :

  • MD : suivi de la session : valeur à récupérer dans la réponse du verifyEnrollment
  • PaReq : requête d'authentification : valeur à récupérer dans le verifyEnrollment
  • TermURL : adresse où le serveur d'authentification envoie la réponse de l'authentification. Concrètement cette adresse doit être capable de récupérer un formulaire envoyé en « POST » et contenant la réponse de l'authentification de l'utilisateur.

Attention ces valeurs sont générés de manière dynamique et se renouvelleront à chaque demande.

Réception des informations retournées lors de l'authentification


Le serveur d'authentification envoi son message sur l'URL renseignée dans le paramètre TermURL (envoyé dans le formulaire précédent). Dans le formulaire de réponse, deux champs doivent être récupérés pour poursuivre la transaction en mode 3DSecure :
le champ MD : toujours le même champ permettant le suivi de la session
le champ PaRes : Payer Authentication Response : chaine de caractères cryptée contenant la réponse du serveur d'authentification. La valeur du champ PaRes va permettre de valider ou non la transaction comme une transaction 3DSecure.
Ces deux champs sont récupérés et permettent de compléter le doAuthorizationRequest en mode 3DSecure
(Voir Etape 3 : doAuthorization).

Exemple de script (ici écrit en PHP) permettant de récupérer la réponse à l'authentification :

Script PHP : receive_form.php

<?php
$pares = $_POST['PaRes'];
$md = $_POST['MD'];

echo "MD : ".$md."<br />PARES : ".$pares;
?>


Remarque : ce script doit être placé sur un serveur web démarré et dans un dossier correspondant à l'adresse envoyé via le champ TermURL.
Exemple : si le serveur est en local il est tout à fait possible de mettre comme valeur :
TemrURL = http://demoShop/3DSecure/receive_form.php

Étape 3 : doAutorization

La dernière étape dans le cadre d'une transaction 3DSecure via l'interface Payline DIRECT est l'envoi d'une requête doAuthorization. Comme dans le cadre d'une transaction classique, le doAuthorization contiendra les champs obligatoires suivant :

  • payment : informations sur la transaction : montant, devise, contrat, etc.
  • card : informations sur la carte de paiement : numéro, type, date d'expiration, etc.
  • order : information sur la commande : référence, montant, pays, etc.
    Et donc dans le cadre d'un paiement 3DSecure, la requête doAuthorization devra être complétée avec les informations renvoyées par le serveur d'authentification :
  • MD : suivi de session 3DSecure.
  • PaRes : résultat de l'authentification.


Ces deux éléments seront placés dans l'élément : <authentication3DSecure> comme indiqué dans l'exemple doAuthorization suivant :


doAuthorizationRequest

doAuthorizationResponse

<doAuthorizationRequest>
<payment>
<amount>1000</amount>
<currency>978</currency>
<action>100</action>
<mode>CPT</mode>
<contractNumber>CB3DS</contractNumber>
</payment>
<card>
<number>4970100000325734</number>
<type>CB</type>
<expirationDate>1212</expirationDate>
<cvx>123</cvx>
</card>
<order>
<ref>REF0989</ref>
<amount>1000</amount>
<currency>978</currency>
<date>24/02/2008 09:28</date>
</order>
<authentication3DSecure>
<md>2vS6uabMBUzx9LrEDS9c</md>
<pares>eJzFV2mvosoW/Sudvh9NN7NKhzYpRlEL
avfp887t93Lz8gYSYtV216q9qbV2VTFmcosi3ojC+y1
i888rZg/0qH6aCopcLGiCnoxtdKvTS7nCvqJfcQb52Z
pjJMYgP7pMEd1kfkUvF3OKQV4dBvk1an9/tOoplj49
RLN1UHfmeQhwdz9JtohaMojeI4+QkjvmHUN4pmk
CntW1....................

</pares>
</authentication3DSecure>
</doAuthorizationRequest>

<doAuthorizationResponse>
<result>
<code>00000</code>
<shortMessage>ACCEPTED</shortMessage>
<longMessage>Transaction approved</longMessage>
</result>
<transaction>
<id>90224141650893</id>
<date>24/02/09 14:16</date>
<isDuplicated>0</isDuplicated>
<isPossibleFraud>0</isPossibleFraud>
<fraudResult/>
<explanation/>
<threeDSecure>Y</threeDSecure>
<score xsi:nil="true" />
</transaction>
<authorization>
<number>A55A</number>
<date>24/02/09 14:16</date>
</authorization>
</doAuthorizationResponse>



Centre administration

Menu 'Suivi technique des appels webservice' pour retrouver l'appel du web service verifyEnrollment permet de voir le détail du verifyEnrollment.

Le résultat de la transaction 3DSecure est alors visible dans le centre d'administration Payline : sur les résultats d'une recherche et dans le détail de la transaction onglet 3DSecure : écran recherche des transactions et Détail de la transaction 3DSecure.


Image Added

Image Added



Schéma du paiement 3D Secure


  1. Le consommateur valide son panier afin que le marchand prépare la page web où seront renseignés les données de paiement. 
    Un message « VEReq » (Verification enrollment request) permet l’accès au Directory Serveur afin de vérifier l’inscription de la carte dans l’annuaire contenant les cartes déclarées « enrôlées » 3-D Secure et de fournir l'URL de l'ACS correspondants.
    La réponse « VERes » (Verification enrollment response) contenant le résultat de l’authentification sera retourné au Merchand Plug-in (MPI) pour gérer le dialogue avec le Directory et l’ACS en vue de permettre à l’acheteur de s’authentifier.
  2. Le commerçant redirige le consommateur sur l'URL de l'ACS pour l'authentification.
    La demande « PAReq » (Payer authentification request) permet l’accès à l’ACS de la banque du porteur pour déclencher la phase d’authentification.
    La réponse « PARes »(Payer authentification response), contenant le résultat de l’authentification du porteur de la carte sera transmis au commerçant.
  3. Le commerçant peut déclencher une demande d’autorisation et de validation de paiement en appelant le service doAuthorizationRequest.
  4. Le commerçant récupère les détails de la transaction en appelant le service getTransactionDetails.

Image Added



Extrait
hiddentrue

Diagramme draw.io
bordertrue
diagramNamePayline Diagramme 3DSv1 Direct
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1113
revision2

https://homologation.payline.com/V4/services/DirectPaymentAPI Effectuer la même opération pour les autres API en ajoutant les « end point » suivant :
  • https://homologation.payline.com/V4/services/WebPaymentAPI pour les requêtes de l'API Web
  • https://homologation.payline.com/V4/services/MassPaymentAPI pour les requêtes de l'API Mass
  • https://homologation.payline.com/V4/services/ExtendedPaymentAPI pour les requêtes de l'API Extended

    Image Removed

    Configuration de l'autorisation commerçant : pour pouvoir communiquer avec l'API Payline, une autorisation est obligatoire. Cette autorisation permet de vous identifier avec votre compte commerçant sur l'API Payline.
    Pour cela, cliquez sur Auth (en bas à droite dans la fenêtre de la requête) et entrer vos informations de connexions à l'environnement Payline :
    • Username : votre identifiant commerçant
    • Password : votre clé d'accès

    Configuration de la requête : compléter les champs de la requête en remplaçant les « ? » par les vos valeurs : numéro de contrat, montant, informations de la carte bancaire, informations sur la commande, etc.
    Lancer la requête : pour cela cliquez sur Play (la flèche verte) en haut à gauche dans la fenêtre de la requête SOAP. La réponse de l'API Payline s'affiche alors dans le cadre de droite.

    Schéma récapitulatif : paiement 3DSecure

    Image Removed

    Données entrées / sorties du serviceweb vrifyEnrollment

    Données Entrées

    Elément

    Commentaire

    Requis

    Type

    Exemple

    Authorization

    Dans l'entête de la trame http. Ne doit pas être présent dans le corps du message.
    (concaténation du
    « merchantID:accessKey » l'ensemble étant encodé en base64)

    Oui

    Basic
    MTExMTExMTExOkFGanU
    5WEhwbFF6dmFtZmZPNzJ M

    Payment.Amount

    le montant du paiement à réaliser. Le
    montant doit être formulé dans la plus petite unité de la devise.

    Oui

    N12

    pour un montant de 60€,
    vous devez mettre la valeur 6000.

    Payment.Currency

    le code ISO de la devise du paiement

    Oui

    N3

    978 : euros

    Payment.Action

    Code de la fonction de paiement

    Oui

    N3

    100 : Autorisation
    101 : Autor+Valid
    Cf guide intégration

    Payment.Mode

    Mode CPT

    Oui

    AN3

    CPT : Comptant

    Payment.ContractNumber

    Le numéro du contrat de paiement qui
    représente un moyen de paiement.

    Oui

    AN50

    Le «ContractNumber»

    Payment.DifferedAction
    Date

    Date effective de l'action. Elle doit être
    inférieure à la date du jour + 7 jours.

    Non

    AN8

    Card.Number

    Numéro de carte (en clair)

    Oui

    N19

    Card.Type

    Type de carte utilisé pour la
    transaction.

    Oui

    AN40

    CB VISA MC

    Card.ExpirationDate

    Date d'expiration de la carte (en clair)

    oui

    N4

    Format à respecter :
    mmyy

    Card.CVX

    Cryptogramme visuel au dos de la carte de crédit.

    Oui

    N10

    Card.OwnerBirthdayDate

    Date d'anniversaire du porteur.

    Non

    N6

    Format à respecter :
    ddmmyy

    Card.Password

    Mot de passe crypté

    Non

    AN16

    OrderRef

    Référence de la commande.

    Oui

    AN50

    mdFieldValue

    Valeur du merchantData (Cette valeur
    doit être unique). Il est préférable de laisser vide ce champ.

    Non

    AN20

    Ce champ est à
    disposition du commerçant, 3DSVerify le positionne s'il ne le reçoit pas.

    Données de sorties

    Elément

    Description

    Format

    Exemple

    Result.Code

    Le code de retour du web service :
    03000 : Operation Successful
    03001 : Not enrolled
    03022 : Authentication verification failed
    ….

    N5

    cf. liste complète dans le tableau du guide intégration

    Result.ShortMessage

    Résultat de l'état de la transaction

    AN50

    Result.LongMessage

    Message du résultat de la transaction

    AN255

    actionUrl

    URL de l'ACS

    AN255

    actionMethod

    Méthode d'envoi .Retourne une valeur POST ou
    GET. Post par défaut.

    AN255

    pareqFieldName

    Nom du champ "Pareq à Poster

    AN5

    pareqFieldValue

    Contient la Valeur du champ PaReq

    AN100 à
    400

    termurlFieldName

    Contient le nom du champ "TermUrl" à Poster

    AN50

    termurlFieldValue

    Contient la valeur du champ "TermUrl".

    AN255

    mdFieldName

    Contient le nom du champ "MD field" à Poster

    AN50

    mdFieldValue

    Contient la valeur du champ "MD field"

    AN20

    mpiResult

    Renvoie la lettre du champ 59-412

    A1

    Y, N, U dans le cas de l'enrôlement

    authentication3DSec
    ure.md

    Merchant data
    Valeur fournie si carte non enrôlée

    AN20

    Même valeur que mdFieldValue

    authentication3DSec
    ure.xid

    Identifiant de transaction Unique
    Valeur fournie si carte non enrôlée

    ANP28

    Encodé en base64

    authentication3DSec
    ure.cavv

    Cardholder Authentication Verification Value
    déterminé par l'ACS.
    Valeur fournie si carte non enrôlée

    ANP28

    Vide dans verifyEnrolment

    authentication3DSecure.cavvAlgorithm

    Entier positif précisant l'algorithme utilisé pour la
    génération CAVV. Les valeurs possibles actuelles sont:
    0 = HMAC (SET™ TransStain),
    1 = CVV,
    2 = CVV avec ATN,
    3 = MasterCard AAV
    Valeur fournie si carte non enrôlée

    N1

    authentication3DSecure.vadsResult

    Résumé des opérations 3DSecure
    Valeur fournie si carte non enrôlée

    AN8

    Valeur binaire volontairement
    encodée en
    héxadécimal par
    3DSVerify

    authentication3DSec
    ure.typeSecurisation

    Renvoie la valeur du type de sécurisation
    Valeur fournie si carte non enrolée

    N2

    authentication3DSecure.eci

    Electronic Commerce Indicator.

    AN2

    Données entrées / sorties du serviceweb doAutorization

    La fonction « do Authorization» réalise une demande d'autorisation de débit au serveur d'autorisation de votre établissement bancaire.
    Requête à envoyer
    La requête « doAuthorizationRequest » doit avoir la structure suivante :

    • REQUEST
      • PAYMENT
      • CARD
      • ORDER
        • ORDER_DETAILS (occurrences 0 – 100)
      • BUYER
      • AUTHENTICATION3DSECURE
      • PRIVATE_DATA_LIST
        • PRIVATE_DATA (occurrences 0 – 100)

    Elément

    Description

    Requis

    Type

    Exemple

    Payment.Amount

    Montant de la transaction dans la plus petite unité de la devise

    oui

    N12

    la valeur 100 correspond à 1 €

    Payment.Currency

    Code de la devise du paiement

    oui

    N3

    978 : euros
    840 : dollars US

    Payment.Action

    Code de la fonction de paiement

    oui

    N3

    100 : Autorisation
    101 : Autorisation + validation

    Payment.Mode

    Mode de paiement : comptant, différé

    oui

    AN3

    CPT : Comptant
    DIF : Différé

    Payment.ContractNumber

    le code ou numéro de votre contrat VAD qui représente le moyen de paiement que vous souhaitez utiliser

    oui

    AN50

    Payment.DifferedActionDate

    Date effective de l'action. Elle doit être inférieure à la date du jour + 7 jours.

    non1

    AN8

    Format à respecter : dd/mm/yy

    Card.Number

    Numéro de carte

    oui

    N19

    Card.Type

    Type de carte utilisé pour la transaction

    oui

    AN40

    CB : visa / mastercard
    AMEX : American express
    cf. liste complète en annexe

    Card.ExpirationDate

    Date d'expiration de la carte

    Non3

    N4

    Format à respecter : mmyy

    Card.CVX

    Cryptogramme visuel au dos de la carte de crédit

    non3

    N10

    Card.OwnerBirthdayDate

    Date d'anniversaire du porteur

    non3

    N6

    Format à respecter : ddmmyy

    Card.Password

    Mot de passe crypté

    non3

    AN16

    Order.Ref

    Référence de la commande. Cette référence doit être unique car elle est utilisée pour le contrôle des doublons.

    Oui

    AN50

    12345678

    Order.Origin

    Origine de la commande 

    Non5

    AN50

    SVI_#12

    Order.Country

    Le code du pays dans lequel la commande a été effectué

    Non

    AN3

    FR

    Order.Taxes

    Le montant des taxes sur la commande dans la plus petite unité de la devise

    Non

    N12

    la valeur 100 correspond à 1 €

    Order.Amount

    Le montant de la commande dans la plus petite unité de la devise. Généralement le même montant que Payment.Amount

    Oui

    N12

    la valeur 100 correspond à 1 €

    Order.Currency

    Le code de la devise utilisée lors de la commande.

    Oui

    N3

    978 : euros
    840 : dollars US

    Order.Date

    La date de la commande chez le commerçant

    Non

    AN18

    Format à respecter : dd/mm/yyyy
    HH24:mi

    Order.Details

    Informations sur les articles commandés

    Non

    Tableau « OrderDetails »

    Buyer.LastName

    Nom de l'acheteur

    Non

    AN100

    Buyer.FirstName

    Prénom de l'acheteur

    Non

    AN100

    Buyer.Email

    Adresse email de l'acheteur

    Non

    AN150

    Buyer.ShippingAddress.Name

    Nom ou numéro d'immeuble

    Non

    AN100

    Buyer.ShippingAddress.Street1

    Nom de rue

    Non

    AN100

    Buyer.ShippingAddress.Street2

    Complément du nom de rue

    Non

    AN100

    Buyer.ShippingAddress.CityName

    Ville

    Non

    AN40

    Buyer.ShippingAddress.ZipCode

    Code postal

    Non

    AN20

    Buyer.ShippingAddress.Country

    Pays

    Non

    AN2

    Buyer.ShippingAddress.Phone

    Téléphone

    Non

    AN15

    Buyer.AccountCreateDate

    La date de création du compte de l'acheteur

    Non

    AN8

    Format à respecter : dd/mm/yy

    AccountAverageAmount

    Le montant moyen des achats de cet acheteur

    Non

    N10

    Buyer.AccountOrderCount

    Le nombre de commande passé par cet acheteur

    Non

    N10

    Buyer.WalletId

    L'identifiant du portefeuille virtuel de votre client.

    Non²

    AN50

    PrivateDataList

    Vos propres informations personnelles

    Non

    Tableau « PrivateData »

    authentication3DSecure.md

    Renvoyé en POST par l'ACS

    Non4

    AN20

    authentication3DSecure.pares

    Renvoyé en POST par l'ACS

    Non4

    AN

    authentication3DSecure.xid

    Identifiant de transaction Unique

    Non

    AN20

    Ne plus utiliser, champ obsolète

    authentication3DSecure.eci

    Electronic Commerce Indicator. A passer dans l'autorisation

    Non

    AN2

    Ne plus utiliser, champ obsolète

    authentication3DSecure.cavv

    Cardholder Authentication Verification Value déterminé par l'ACS.

    Non

    AN26-28

    Ne plus utiliser, champ obsolète

    authentication3DSecure.cavvAlgorithm

    Entier positif précisant l'algorithme utilisé pour la génération CAVV. Les valeurs possibles actuelles sont:
    0 = HMAC (SET™ TransStain),
    1 = CVV,
    2 = CVV avec ATN,
    3 = MasterCard AAV

    Non

    N1

    Ne plus utiliser, champ obsolète

    authentication3DSecure.vadsResult

    Résumé des opérations 3DSecure

    Non

    AN4

    Ne plus utiliser, champ obsolète

    1 - Lorsque le champ Payment.Mode prend la valeur « DIF », la date Payment.DifferedActionDate est obligatoire. Dans les autres modes de paiement, ce champ doit être vide.
    2 - Ne pas renseigner pour cette fonction.
    3 - Veuillez vous référer à l'annexe « Erreur ! Source du renvoi introuvable. ».
    4 - Obligatoire pour toutes les transactions 3DSecure.
    5 - Si l'option MOTO est activée, alors la valeur de l'attribut Order.Orign sera « MO » ou « TO ».
    Pour chaque ligne de détail d'une commande (OrderDetails) :

    Elément

    Commentaire

    Requis

    Format

    Exemple

    Ref

    Référence de l'article

    Non

    AN50

    Price

    Prix de l'article dans la plus petite unité de la devise

    Non

    N12

    Quantity

    Quantité d'articles

    Non

    N5

    Comment

    Commentaire

    Non

    Pour chaque donnée privée (PrivateData) :

    Elément

    Commentaire

    Requis

    Format

    Exemple

    Key

    La clé qui vous permet de filtrer vos transactions de paiement

    Oui

    AN50

    user

    Value

    La valeur associée à la clé

    Oui

    AN50

    dupond or durand, etc…

    Réponse en retour Le message « doAuthorizationResponse » est la réponse faite par Payline à une demande d'autorisation de débit. Il vous permet d'obtenir, entre autres, le numéro unique de la transaction sur Payline et le n° d'autorisation de débit délivré par votre établissement bancaire.
    La réponse a la structure suivante :
    • RESPONSE
    • RESULT
    • TRANSACTION
    • AUTHORIZATION

    Elément

    Description

    Format

    Exemple

    Result.Code

    Le code de retour du web service :
    00000 : Transaction approved
    023xx : Invalid Transaction
    01xxx : Transaction refused
    021xx : Internal Error

    N5

    cf. liste complète en annexe tableau « Liste des codes retours » dans le Guide d'intégration

    Result.ShortMessage

    Résultat de l'état de la transaction

    AN50

    Result.LongMessage

    Message du résultat de la transaction

    AN255

    Transaction.Id

    Identifiant unique de la transaction Payline

    AN50

    Transaction.IsPossibleFraud

    Cet indicateur est calculé en fonction des critères définis par le commerçant

    AN1

    1 = Il existe un risque de fraude
    0 = Aucun risque de fraude détecté

    Transaction.isDuplicated

    Cet indicateur est retourné par Payline dans le cas de transaction en doublon

    AN1

    1 = Il existe un risque de fraude
    0 = Aucun risque de fraude détecté

    Transaction.Date

    Date et heure de la transaction Payline

    AN16

    Format : dd/mm/yyyy HH24:MI

    Transaction.fraudResult

    Code de la fraude

    AN50

    Transaction.explanation

    Motif du refus en cas de fraude

    AN50

    Transaction.ThreeDSecure

    Cet indicateur est retourné par Payline lors d'une transaction 3DSecure

    AN1

    Y = Transaction en mode 3DSecure
    N = Transaction en mode non 3DSecure

    Transaction.score

    Scoring de la possibilité de fraude

    N5

    Score de 0 à 10

    Authorization.Number

    Numéro d'autorisation délivré par le serveur d'autorisation acquéreur. Ce champ est renseigné si la demande d'autorisation est accordée*.

    N6

    123456

    Authorization.Date

    Date et heure de l'autorisation

    AN16

    Format : dd/mm/yyyy HH24:MI

    - en fonction de votre configuration de compte, Payline peut accorder un paiement sans en faire la demande au SAA. Dans ce cas, le n° d'autorisation est vide.