sommaire

...

Introduction

...

Objet du document

Ce document décrit la procédure d’intégration de la solution de paiement sécurisé en ligne Payline en mode API AJAX dans votre site commerçant.

...

Public visé

Ce document est destiné aux commerçants et intégrateurs qui souhaitent utiliser le mode d’intégration « API AJAX » la solution de paiement Payline.

...

Liste des documents de référence

Nos documents sont disponibles sur notre site internet www.payline.com ou sur simple demande auprès de notre service support : support@payline.com

...

Avertissement

Ce document est la propriété exclusive de Monext. Toute reproduction intégrale ou partielle, toute utilisation par des tiers, ou toute communication à des tiers, sans accord préalable écrit de Monext est illicite.
Monext®, marque communautaire et internationale propriété exclusive de Monext Ltd et/ou des sociétés du groupe.
Payline®, marque nationale et internationale propriété exclusive de Monext et/ou des sociétés du groupe.

...

Contacts

Vous avez besoin d’aide, de conseil ou vous souhaitez simplement nous poser une question ? Contactez l’Assistance Payline par : support@payline.com
Pour toute question liée à la mise en place de la solution Payline, vous pouvez joindre notre assistance technique par mail support@payline.com, du lundi au vendredi de 09h00 à 18h00.

...

Principe général

...

Présentation

Aujourd’hui, Payline propose différentes interfaces de paiement pour un site commerçant :

• L’interface Web : le commerçant redirige son acheteur sur les pages de paiements hébergées par Payline. Les données de paiement sont ainsi recueillies directement par Payline et dégage le commerçant des contraintes PCI-DSS.

• L’interface directe : le commerçant développe sa propre page de paiement, récupère les données carte sur son serveur et appelle un web Service Payline pour réaliser la demande d’autorisation. Cette interface, utilisée notamment par les commerçants importants, permet une intégration complète de la page de paiement aux sites marchand mais les contraint à suivre les exigences PCI-DSS.

L’interface AJAX présentée dans ce document est une extension du mode direct. Le commerçant récupère les données carte sur  la page récapitulative de commande hébergée sur ses serveurs. Ce mode permet l’exécution de la demande d’autorisation en mode synchrone ou asynchrone (via stockage temporaire du CVV), l’usage des fonctionnalités de portefeuille et permet de se libérer des obligations PCI-DSS.

2.2. L’interface AJAX

Deux modes d’intégration seront proposés :

L’interface AJAX présentée est une extension du mode direct. Le commerçant récupère les données carte sur  la page récapitulative de commande hébergée sur ses serveurs. Ce mode permet l’exécution de la demande d’autorisation en mode synchrone ou asynchrone (via stockage temporaire du CVV), l’usage des fonctionnalités de portefeuille et permet de se libérer des obligations PCI-DSS.

L’interface AJAX

Deux modes d’intégration seront proposés :

• Le mode AJAX :
• Réservé
• Le mode AJAX :
• Réservé aux navigateurs les plus récents, capables d’effectuer des appels AJAX « cross-domain » : IE8+, Chrome, Firefox et Safari ;
• L’intégration du type JSON-P n’est pas compatible avec PCI-DSS (passage du numéro de carte dans l’URL étant interdit) .;
• Intégration asynchrone dans les sites et dans les app-mobile (encore plus transparent pour l’acheteur) ;
  
  
• Pour les navigateurs non compatibles, le mode POST avec redirection temporaire :
• le Le commerçant redirige brièvement l’acheteur sur Payline pour la tokenisation. Après traitement, Payline redirige de nouveau l’acheteur sur le site du commerçant . ;
• Payline n’affiche aucune page Web, la redirection est donc transparente pour l’acheteur ;
• Ce mode d’intégration est compatible avec tous les navigateurs actuels.

...

...

Prérequis et précautions

...

Périmètre applicable

Le mode d’intégration avec l’API AJAX sur la solution de paiement Payline n’est pas adapté pour traiter les moyens de paiements avec redirection (Paypal, PaysafeCard, …) ou non soumis aux règles de PCI-DSS (vouchers prépayés, comptes eWallet, …).

...

Pour tous les autres moyens de paiement, le marchand peut utiliser l’API directe.

...

Sécurité

La collecte des données de paiement par le site marchand implique un risque plus élevé pour le commerçant. Ce mode d’intégration nécessite donc une application rigoureuse des standards de sécurité.

...

Le point 1 est particulièrement important : le marchand doit vérifier régulièrement si le script d’appel à la fonction getToken a été modifié. Si tel est le cas, il doit s’assurer que les préconisations restent valides.

...

Prérequis techniques

Pour les serveurs PHP les exemples de code fonctionnent :

• Avec la bibliothèque gzdecode.php. qui est optionnelle jusqu’à la version 5.4.0 (disponible en standard pour les versions supérieures) ;
• Avec les modules mcrypt et php_soap, qui sont à activer.

Pour les serveurs J2E, afin de pouvoir accéder aux fonctions de chiffrement avec des clés supérieures à 128 bits, il faut installer le package Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy (http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html).

...

Description fonctionnelle

...

Cinématique d’un paiement simple

Voici les étapes principales d’un paiement avec cette nouvelle interface :

1. L’acheteur valide son panier, le navigateur envoie une requête http sur le serveur commerçant ;
2. Le serveur commerçant :
1. génère une référence unique de commande ;
2. chiffre avec sa clé d’accès la chaine composée de la référence commande et du numéro de contrat ;
3. construit et renvoie le formulaire au navigateur ;
3. L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…) ;
4. Le navigateur réalise un appel à la servlet Payline « getToken » ;
5. La servlet Payline traite la requête :
1. déchiffre les données à partir de la clé commerçant ;
2. affecte un CVV virtuel à la transaction (valable pour une seule commande) ;
3. tokenize le numéro de carte ;
4. chiffre, à partir de la clé du commerçant, le token, la date d’expiration et le CVV virtuel (+ autres infos sur la carte) ;
5. retourne les données au navigateur avec éventuellement une redirection http vers la « returnURL » (http 302 en mode synchrone) ;
6. Le navigateur réalise un appel au site du commerçant pour passer les données du formulaire (sans les données bancaires) avec le message chiffré par Payline ;
7. Le serveur commerçant :
1. déchiffre le message avec sa clé d’accès pour obtenir : le token, la date d’expiration et le CVV virtuel.
2. vérifie que la référence de commande déchiffrée est bien celle attendue ;
3. appelle le WS Payline « doAuthorization » avec les données déchiffrées ;
8. Le WS Payline « doAuthorization » :
1. appelle le tokenizer pour obtenir le numéro de carte à partir du token ;
2. récupère le CVV à partir du CVV virtuel ;
3. appelle la banque du commerçant pour réaliser une demande d’autorisation ;
4. réalise les contrôles anti-fraude-fraude ;
5. retourne le résultat au commerçant.

Figure 1 : Cinématique d’un paiement simple (sans 3DS)

...

Cinématique d’un paiement 3DSecure

Voici les étapes principales pour un paiement 3DSecure :

1. L’acheteur valide son panier, le navigateur envoie une requête http sur le serveur commerçant ;
2. Le serveur commerçant génère un formulaire comme dans la cinématique précédente ;
3. L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…) ;
4. Le navigateur :
1. appelle la servlet « getToken » ;
2. appelle le serveur du commerçant avec les données Payline et les autres données du formulaire.
5. Le serveur du commerçant :
1. déchiffre les données Payline pour récupérer le token, la date d’expiration et le CVV virtuel ;
2. stocke dans la session de l’acheteur ces données ;
3. appelle le WS Payline « verifyEnrollment » avec le token et la date d’expiration.
6. Le WS Payline « verifyEnrollment » :
1. déduit le numéro de carte réel à partir du token carte ;
2. demande au MPI l’adresse de l’ACS de l’acheteur.
7. L’acheteur :
1. est redirigé sur l’ACS de sa banque ;
2. s’identifie ;
3. est redirigé sur le site du commerçant (cf. TERM_URL).
8. Le serveur commerçant appelle le WS Payline « doAuthorization » avec le token, la date d’expiration, le CVV virtuel et le PARes ;
9. Le WS Payline « doAuthorization » :
1. déduit le numéro de carte réel à partir du token carte ;
2. récupère le CVV à partir du CVV virtuel ;
3. appelle le MPI pour vérifier le PARes ;
4. appelle la banque du commerçant pour réaliser une demande d’autorisation ;continue avec les autres étapes de la première cinématique …
5. réalise les contrôles anti-fraude ;
6. retourne le résultat au commerçant.
   
   

Figure 2 : Cinématique d’un paiement simple avec 3DSecure

...

Cinématique d’un paiement 3DSecure déclenché par le module anti-fraude

...

 Figure 3 : Cinématique d’un paiement avec 3DSecure déclenché par le module LCLF

...

Voici les étapes principales pour un paiement 3DSecure déclenché par le module anti-fraude :

1. L’acheteur valide son panier, le navigateur envoie une requête http sur le serveur commerçant
2. Le serveur commerçant génère un formulaire comme dans la cinématique précédente
3. L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…)
4. Le navigateur :
1. appelle la servlet Payline « getToken » ;
2. appelle le serveur du commerçant avec les données Payline et les autres données du formulaire.
5. Le serveur du commerçant :
6. décrypte les données Payline pour récupérer le token, la date d’expiration et le CVV virtuel ;
7. stocke dans la session de l’acheteur ses données ;
8. comme dans la cinématique précédente
9. L’acheteur saisit et valide ses données (paiement, adresse de facturation, etc…)
10. Le navigateur :
1. appelle la servlet Payline « getToken » ;
2. appelle le serveur du commerçant avec les données Payline et les autres données du formulaire.
11. Le serveur du commerçant :
1. décrypte les données Payline pour récupérer le token, la date d’expiration et le CVV virtuel ;
2. stocke dans la session de l’acheteur ses données ;
3. appelle le WS Payline « doAuthorization » avec le token, la date d’expiration et le CVV virtuel ;
12. Le WS Payline « doAuthorization » :
1. appelle le tokenizer pour obtenir le numéro de carte ;
2. réalise les contrôles 3DSecure ;
3. renvoie un code d’erreur 02715 « Authentication3DSecure is mandatory ».
13. 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 :

1. Le WS Payline « verifyEnrollment » :
1. déduit le numéro de carte réel à partir du token carte ;
2. demande au MPI l’adresse de l’ACS de l’acheteur.
2. L’acheteur :
1. est redirigé sur l’ACS de sa banque ;
2. s’identifie ;
3. est redirigé sur le site du commerçant (cf. TERM_URL).
3. Le serveur commerçant appelle le WS Payline « doAuthorization » avec le token, la date d’expiration, le CVV virtuel et le
CVV virtuel 
4. PARes ;
5. Le WS Payline « doAuthorization » ::
1. déduit le numéro de carte réel à partir du token carte ;
2. récupère le CVV à partir du CVV virtuel ;
3. appelle le MPI pour vérifier le PARes ;
4. appelle la banque du commerçant pour réaliser une demande d’autorisation appelle le tokenizer pour obtenir le numéro de carte ;
5. réalise les contrôles 3DSecure ;
6. renvoie un code d’erreur 02715 « Authentication3DSecure is mandatory ».
6. Le serveur du commerçant appelle le WS Payline « verifyEnrollment » avec le token et la date d’expiration.

 

1. anti-fraude ;
2. retourne le résultat au commerçant.

 Figure 3 : Cinématique d’un paiement avec 3DSecure déclenché par le module LCLFOn reprend à partir de l’étape 6 de la cinématique 3DS précédente.

 

4.4. Cinématique d’enregistrement d’une carte dans un portefeuille

...