...
des évolutionsLe tableau ci-dessous liste les dernières modifications effectuées sur ce document.
|
...
|
...
|
Table des matières
...
| 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 document décrit l'utilisation de la fonction 3DSecure en mode interface direct
...
Ce document est destiné aux commerçants et intégrateurs qui souhaitent utiliser la solution de paiement Payline.
...
- Email : support@payline.com
...
- L'identifiant commerçant : MerchantID
- La clé d'accès au service Payline : Accesskey
...
Exemple
...
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.
...
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 :
...
<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>Operation Successfull</shortMessage>
<longMessage>Operation Successfull</longMessage>
</result> <actionUrl>
...
</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>
...
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 :
...
<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>
Ce 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.
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 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.
Pré-requis d'utilisation de la solution de paiement Payline
La solution 3D Secure en mode interface Direct assure le transfert sécurisé des données sensibles, traite les demandes d'authentification et d'autorisation.
Les points d'intégration :
- verifyEnrollment est nécessaire pour assurer l'authentification et doAuthorization pour réaliser l'autorisation ;
- récupérer le résultat de la transaction avec gettransactionDetails.
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> | <verifyEnrollmentResponse> <termUrlName>TermUrl</termUrlName> |
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
- termUrlName = TermUrl
- 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"> |
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 |
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> | <doAuthorizationResponse> |
| Extrait | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
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. Étape 1 : appel du web service verifyEnrollmentComme 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 :
Étape 2 : authentificationUne 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 informationsPour envoyer ces informations, il suffit de créer un formulaire HTML regroupant les champs MD et paReq et pointant vers le serveur d'authentification.
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
Étape 3 : doAutorizationLa 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 :
|
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.
Schéma du paiement 3D Secure
- 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. - 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. - Le commerçant peut déclencher une demande d’autorisation et de validation de paiement en appelant le service doAuthorizationRequest.
- Le commerçant récupère les détails de la transaction en appelant le service getTransactionDetails.
| Extrait | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||
|
...
- 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.
...
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.
...
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.
...
<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>Transaction approved</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>
...
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.
...
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
...
|
|
...
<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>Operation Successfull</shortMessage>
<longMessage>Operation Successfull</longMessage>
</result> <actionUrl>
...
</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>
...
</termUrlValue>
<mdFieldName>MD</mdFieldName>
<mdFieldValue>8FPL0ihqQtuqr1GzmOCL</mdFieldValue>
</verifyEnrollmentResponse>
...
- 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
...
- 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).
...
Etape 1 : appel du web service verifyEnrollment
Suivi technique des appels « webservice » :
Détail du verifyEnrollment
...
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).
...
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 :
...
<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>
...
Visualisation sur le centre d'administration
...
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 :
...
doAuthorizationRequest
...
doAuthorizationResponse
...
<doAuthorizationResponse>
<result>
<code>00000</code>
<shortMessage>Transaction approved</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
...
Paramétrage de SOAP UI
...
- nom du projet : Payline
- WSDL : entrez l'URL du WSDL Payline disponible en homologation :
http://www.payline.com/wsdl/v4_0/homologation/DirectPaymentAPI.wsdl
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 :
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
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.
...
Données entrées / sorties du serviceweb vrifyEnrollment
...
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
...
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.
...
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
...
Message court du résultat 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
...
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 |
Payment.Action | Code de la fonction de paiement | oui | N3 | 100 : Autorisation |
Payment.Mode | Mode de paiement : comptant, différé | oui | AN3 | CPT : Comptant |
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 |
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 |
Order.Date | La date de la commande chez le commerçant | Non | AN18 | Format à respecter : dd/mm/yyyy |
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: | Non | N1 | Ne plus utiliser, champ obsolète |
authentication3DSecure.vadsResult | Résumé des opérations 3DSecure | Non | AN4 | Ne plus utiliser, champ obsolète |
...
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 |
|
|
...
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… |
...
- RESPONSE
- RESULT
- TRANSACTION
- AUTHORIZATION
Elément | Description | Format | Exemple |
|---|---|---|---|
Result.Code | Le code de retour du web service : | N5 | cf. liste complète en annexe tableau « Liste des codes retours » dans le Guide d'intégration |
Result.ShortMessage | Message court du résultat 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 |
Transaction.isDuplicated | Cet indicateur est retourné par Payline dans le cas de transaction en doublon | AN1 | 1 = Il existe un risque de fraude |
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 |
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 |
...