Contenu
Sommaire | ||||
---|---|---|---|---|
|
Extrait | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
Historique des évolutionsLe tableau ci-dessous liste les dernières modifications effectuées sur ce document.
|
Introduction
Pré-requis bancaire et de connexion 3DSecure
Ce programme 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.
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 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-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 et traite les demandes d'authentification, d'autorisation. Un point d'intégration supplémentaire (verifyEnrollment) est nécessaire pour assurer l'authentification, en plus du point d'intégration réalisant l'autorisation et (doAuthorization) et récupérant le résultat de la transaction (gettransactionDetails).
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.
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 :
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> | <verifyEnrollmentResponse> </actionUrl> |
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"> |
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 |
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> | <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 :
|
|
Exemple de requête verifyEnrollment :
verifyEnrollmentRequest | verifyEnrollmentResponse |
<impl:verifyEnrollmentRequest> | <verifyEnrollmentResponse> </actionUrl> </termUrlValue> |
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.
Étape 1 : appel du web service verifyEnrollment
Suivi technique des appels « webservice » :
Détail du verifyEnrollment
É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.modirum.com/mdpayacs/pareq" method="POST"> |
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 |
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
É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> | <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 :
Détail de la transaction 3DSecure
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/
- 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.
Schéma récapitulatif : paiement 3DSecure
Données entrées / sorties du
serviceweb vrifyEnrollment Données EntréesElé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
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.
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
service web verifyEnrollment
Inclusion d'extrait Webservice - verifyEnrollmentRequest Webservice - verifyEnrollmentRequest nopanel true
Inclusion d'extrait | ||||||
---|---|---|---|---|---|---|
|
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)
Inclusion d'extrait | ||||||
---|---|---|---|---|---|---|
|
Inclusion d'extrait | ||||||
---|---|---|---|---|---|---|
|
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
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
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…
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