| Extrait | ||
|---|---|---|
| ||
todo : refaire les schema ref cmd en api direct ? prerequis et secu ? wallet api direct ? |
| Sommaire | ||||
|---|---|---|---|---|
|
...
- L’acheteur valide son panier, le navigateur envoie une requête http sur le serveur commerçant ;
- Le serveur commerçant :
- génère une référence unique de commande ;
- chiffre avec sa clé d’accès la chaine composée de la référence commande et du numéro de contrat ;
- construit et renvoie le formulaire au navigateur ;
- L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…) ;
- Le serveur commerçant : appelle le WS Payline « doAuthorization » avec les données de paiement ;
- Le WS Payline « doAuthorization » :
- appelle la banque du commerçant pour réaliser une demande d’autorisation ;
- réalise les contrôles anti-fraude ;
- retourne le résultat au commerçant.
...
Figure 1 : Cinématique d’un paiement simple (sans 3DS)
Cinématique d’un paiement 3DSecure
...
- L’acheteur valide son panier, le navigateur envoie une requête http sur le serveur commerçant ;
- Le serveur commerçant génère un formulaire comme dans la cinématique précédente ;précédente.
- L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…) ;.
- Le serveur du commerçant :
- déchiffre les données Payline pour récupérer le PANnuméro de la carte, la date d’expiration et le CVV ;
- stocke dans la session de l’acheteur ces données ;
- appelle le WS Payline « verifyEnrollment » avec le PANnuméro de la carte, CVV et la date d’expiration.
- Le WS Payline « verifyEnrollment » demande au MPI l’adresse de l’ACS de l’acheteur.
- L’acheteur :
- est redirigé sur l’ACS de sa banque ;
- s’identifie ;
- est redirigé sur le site du commerçant (cf. TERM_URL) ;.
- Le serveur commerçant appelle le WS Payline « doAuthorization » avec le PANnuméro de la carte, la date d’expiration, le CVV et le PARes ;PARes.
- Le WS Payline « doAuthorization » :
- appelle le MPI pour vérifier le PARes ;
- appelle la banque du commerçant pour réaliser une demande d’autorisation ;
- réalise les contrôles anti-fraude ;
- retourne le résultat au commerçant.
...
- L’acheteur valide son panier, le navigateur envoie une requête http sur le serveur commerçant.
- Le serveur commerçant génère un formulaire comme dans la cinématique précédente.
- L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…).
- Le navigateur :
- appelle la servlet Payline « getToken » ; appelle le serveur
- navigateur appelle le serveur du commerçant avec les données Payline et les autres données du formulaire
- de paiement.
- Le serveur du commerçant : décrypte les données Payline pour récupérer le token, la date d’expiration et le CVV virtuel ;
- stocke dans la session de l’acheteur ses données ;
- appelle le WS Payline « doAuthorization » avec le tokennuméro de la carte, la date d’expiration et le CVV virtuel ;.
- Le WS Payline « doAuthorization » : appelle le tokenizer pour obtenir le numéro de carte ;
- réalise les contrôles 3DSecure ;
- renvoie un code d’erreur 02715 « Authentication3DSecure is mandatory ».
- Le serveur du commerçant appelle le WS Payline « verifyEnrollment » avec le token et la date d’expiration.
Le traitement reprend à partir de l’étape 6 de la cinématique 3DS précédente :
- Le WS Payline « verifyEnrollment » :
- déduit le numéro de carte réel à partir du token carte ;
- verifyEnrollment demande au MPI l’adresse de l’ACS de l’acheteur.
- L’acheteur :
- est redirigé sur l’ACS de sa banque ;
- s’identifie ;
- est redirigé sur le site du commerçant (cf. TERM_URL).
- Le serveur commerçant appelle le WS Payline « doAuthorization » avec le tokennuméro de la carte, la date d’expiration, le CVV virtuel et le PARes ;PARes.
- Le WS Payline « doAuthorization » :
- déduit le numéro de carte réel à partir du token carte ; récupère le CVV à partir du CVV virtuel ;
- appelle le MPI pour vérifier le PARes ;
- appelle la banque du commerçant pour réaliser une demande d’autorisation ;
- réalise les contrôles anti-fraude ;
- retourne le résultat au commerçant.
Figure 3 : Cinématique d’un paiement avec 3DSecure déclenché par le module LCLF
Cinématique d’enregistrement d’une carte dans un portefeuille => wallet api direct ?
Dans ce scénario, aucun paiement n’est réalisé.
...
- Le navigateur de l’acheteur envoie les données de la carte à Payline (sur le module des pages Web de paiement) ;
- Payline retourne un token chiffré si les données sont conformes (cf. la première cinématique) ;
- Le navigateur retourne ces données au serveur commerçant ;
- Le serveur commerçant :
- déchiffre les données pour récupérer : le token, la date d’expiration et le CVV virtuel ;
- appelle le WS Payline « createWallet ».
- Le WS Payline « createWallet » :
- appelle le tokenizer pour récupérer le numéro de carte réel et retransforme le CVV virtuel en CVV réel ;
- envoie une demande d’autorisation pour scoring à la banque du commerçant (ex : autorisation à 1 euro ou demande d'information selon la banque).
...
Dans cette cinématique, le commerçant a conservé au préalable le token PAN de la carte ( et la date d’expiration ) dans sa base de données lors du premier paiement. La page de paiement affiche les cartes associées à ce compte acheteur.
Le commerçant a la possibilité de collecter le CVV auprès de son acheteur et le fournir lors de l’appel « doAuthorization » ou d’effectuer une transaction sans CVV.
Lorsque l’acheteur valide la commande :
- Le serveur commerçant :
- recherche le token numéro de la carte associé au client ;
- appelle WS Payline « doAuthorization » avec le token la carte, avec ou sans CVV et un code action 120 ou 121.
- Le WS Payline « doAuthorization »
- appelle le tokenizer pour récupérer le numéro de carte réel ;
- envoie une autorisation à la banque du commerçant.
Implémentation
Modification de la gestion des clés commerçant
Les commerçants qui vont utiliser les paiements en mode AJAX doivent générer une clé d’accès à Payline avec le nouveau module de gestion. Ce nouveau module permet d’attribuer une référence de clé à chaque clé générée. Il est accessible au travers du centre d’administration dans le menu « Configuration ».
Cette référence est à utiliser dans les appels à la fonction getToken décrite ci-après.
La clé elle-même garde les mêmes usages qu’auparavant.
Figure 6 : nouvel écran de génération de clé d’accès
Fonction de création de token
Description
Ce service est développé sous la forme d’une Servlet nommée « getToken ». Il est à appeler au niveau de la page du commerçant pour obtenir le token de la carte de l’acheteur (requête AJAX ou requête POST+redirection).
Données en entrée
...
Nom du champ
...
Obligatoire
...
Format
...
Commentaire
...
Données à générer par le commerçant
...
accessKeyRef
...
O
...
AN(20)
...
Référence de la clé d’accès du commerçant
Ex : IWdJoDqyGT6wOQVIf3zM
...
data
...
O
...
AN
...
Données commerçant :
- chiffrées en AES256
- encodées en base64_url.
Clé secrète : SHA-256 de la clé d’accès commerçant
Contenu : tableau spécifique ci-dessous
...
returnURL
...
F
...
AN
...
URL de retour sur le site du commerçant.
À utiliser pour les requêtes POST+redirection
...
Données de la carte saisies par l’acheteur
...
cardNumber
...
O
...
N(19)
...
Numéro de la carte
...
cardExpirationDate
...
F
...
MMYY
...
Date d’expiration
Obligatoire pour CB/Visa/Mastercard/Amex
...
cardCvx
...
F
...
N(4)
...
CVV
Obligatoire pour CB/Visa/Mastercard/Amex
Le champ data contient les informations suivantes (valeurs séparées par des points virgules) :
...
Index
...
Valeur
...
Obligatoire
...
Format
...
1
...
Identifiant du commerçant
...
O
...
AN(19)
...
2
...
Référence unique de commande générée par le commerçant
...
O
...
N(50)
...
3
...
Numéro de contrat
...
O
...
AN(50)
Remarque : Le nombre de requêtes getToken est limité à 3 tentatives pour chaque référence commande. Si vous obtenez 3 erreurs lors d’une commande, il faudra re-générer une chaine chiffrée qui se base sur une nouvelle référence de commande.
Données en sortie
Le service retourne soit une liste de valeur encodées, soit un code erreur si la fonction ne s’est pas déroulée correctement.
...
Nom du champ
...
Obligatoire
...
Format
...
Commentaire
...
Données à générer par le commerçant
...
data
...
F
...
AN
...
Retourné si la fonction se déroule correctement.
Données :
- compressées avec l'algorithme gzip
- chiffrées en AES256
- encodées en base64_url
Clé secrète : la même qu'en entrée
Contenu : tableau ci-dessous
Exemple : 497910Aztyqdeidn1234;1113;v456…
...
errorCode
...
F
...
N(5)
...
Fourni en cas d’erreur, cf. tableau suivant
Le champ data contient les informations suivantes (valeurs séparées par des points virgules) :
...
Index
...
Valeur
...
Obligatoire
...
Format
...
1
...
Token associé au numéro de de carte
Ex : 497910AztyqdEGdn123
...
O
...
AN(19)
...
2
...
Date d’expiration de la carte (même donnée qu’en entrée)
...
F
...
MMYY
...
3
...
CVV virtuel, il devra être restitué dans la demande d’autorisation sans être modifié
Ex. : v456
...
F
...
AN(5)
...
4
...
Référence commande identique à celle passée en entrée.
Pour éviter un éventuel rejeu, le commerçant doit contrôler que cette référence est bien celle attendue. Si tel n’est pas le cas, il doit refuser la transaction et envoyer une annulation à Payline
...
O
...
AN(50)
...
5
...
Type de carte
Ex. : VISA
...
O
...
AN
...
6
...
Indicateur « isCVD » (carte virtuelle)
...
O
...
Y ou N
...
7
...
Code pays de la carte
Ex. : FR
...
F
...
AN(2)
...
8
...
Code produit de la carte
Ex. : L (pour Electron)
...
F
...
AN(3)
...
9
...
Code de la banque émettrice de la carte
Ex : 30003
...
F
...
AN(11)
API webservice
Les
Codes d’erreur
...
Code
...
Message court
...
Message long
...
09101
...
Transaction refused
...
Accès non autorisé
...
09102
...
Transaction refused
...
Compte commerçant bloqué ou désactivé
...
02703
...
Transaction refused
...
Action non autorisée
...
02303
...
Transaction refused
...
Numéro de contrat invalide
...
02623
...
Transaction refused
...
Nombre d’essai maximal atteint
...
02624
...
Transaction refused
...
Carte expirée
...
02625
...
Transaction refused
...
Format du numéro de carte incorrect
...
02626
...
Transaction refused
...
Format de la date d’expiration incorrect ou date non fournie
...
02627
...
Transaction refused
...
Format du CVV incorrect ou CVV non fourni
...
02628
...
Transaction refused
...
Format de l’URL de retour incorrect
...
02631
...
Transaction refused
...
Délai d’attente expiré
API webservice
Les webservices Payline ont évolué de façon à être compatible avec le paiement en mode Ajax.Pour cela le champ « card.token » a été ajouté dans les paramètres d’entrée des webservices suivants :en mode Direct.
- doAuthorization
- createWallet
- updateWallet
- verifyAuthentication
- verifyEnrollment
- doCredit
- doDebit
...
Les URL des serveurs Payline à utiliser sont :
Homologation : https://homologation-webpayment.payline.com/webpayment/getToken
Production : https://secure.payline.com/webpayment/getToken
Exemples d’implémentation
...