Plateforme PAYZEN. Définition de Web-services



Documents pareils
Définition des Webservices Ordre de paiement par . Version 1.0

Plateforme Systempay. Correspondance entre SP PLUS et SYSTEMPAY Paiement Simple et en plusieurs fois

Guide d implémentation. Réussir l intégration de Systempay

Plateforme PAYZEN. Intégration du module de paiement pour la plateforme Magento version 1.3.x.x. Paiement en plusieurs fois. Version 1.

Définition des Webservices Standards Systempay Version 2.7c

Guide d implémentation. Paiement par identifiant Fichier des cartes arrivant à expiration

Manuel d intégration API SOAP SMS ALLMYSMS.COM

Ajouter le moyen de paiement e-chèque-vacances (ANCV) Systempay 2.3

Guide d implémentation. Gestion des paiements par identifiant Gestion des paiements par abonnement

Définition des Webservices V4

Création d un compte Exchange (Vista / Seven)

Plateforme Systempay Descriptif de l interface avec la page de paiement

Guide d implémentation

Intégration du moteur d envoi de SMS pour : Prestashop

Guide d implémentation Interface avec la plateforme de paiement

Plateforme PAYZEN. Intégration du module de paiement pour la plateforme Magento 1.4 et supérieur. Version 1.5.1

FOIRE AUX QUESTIONS PAIEMENT PAR INTERNET. Nom de fichier : Monetico_Paiement_Foire_aux_Questions_v1.7 Numéro de version : 1.7 Date :

API HTTP DOCUMENTATION TECHNIQUE PLATEFORME SAAS D'ENVOI DE SMS. Version Mise à jour : 3 juillet 2015

Cette application développée en C# va récupérer un certain nombre d informations en ligne fournies par la ville de Paris :

Option site e-commerce

Intégration e-commerce. Version 0.5

Sécurisation des accès au CRM avec un certificat client générique

SOLUTION D ENVOI DE SMS POUR PROFESSIONNELS

Paiement sécurisé sur Internet

Documentation API Octopush

Mobyt Intégration par Webservice TABLE DES MATIERES

Dossier Technique. Détail des modifications apportées à GRR. Détail des modifications apportées à GRR Le 17/07/2008. Page 1/10

E-TRANSACTIONS. Guide du programmeur API Plug-in. Version 1.1

Manuel d'installation

Configuration d un client Outlook 2010

Licence Bio Informatique Année Premiers pas. Exercice 1 Hello World parce qu il faut bien commencer par quelque chose...

Alfstore workflow framework Spécification technique

Guide de configuration

Appui SIE :Développement de services web ADES/SIE

Titres de créances NégOciables Refonte Informatique et organisationnelle

Information sur l accés sécurisé aux services Baer Online Monaco

Documentation pour l envoi de SMS

Guide d installation CLX.PayMaker Office (3PC)

Prénom : Matricule : Sigle et titre du cours Groupe Trimestre INF1101 Algorithmes et structures de données Tous H2004. Loc Jeudi 29/4/2004

API Web Service TéléAlerte

Module de livraison DPD Magento

Tessi Documents Services ASPONE. Démo Webservices UpValue.

EJBCA PKI Open Source

Analyse de problème Certificat (clé-usb) Mac

Guide de connexion pour les sites sécurisés youroffice & yourassets

Principales failles de sécurité des applications Web Principes, parades et bonnes pratiques de développement

IN Cours 1. 1 Informatique, calculateurs. 2 Un premier programme en C

Gestion distribuée (par sockets) de banque en Java

Instructions et spécifications pour la transmission en format XML de déclarations par lots. 30 mai 2015 MODULE 1

CYCLE DE VIE DES TRANSACTIONS

CONTACT EXPRESS 2011 ASPIRATEUR D S

Plate-forme de tests des fichiers XML virements SEPA et prélèvements SEPA. Guide d'utilisation

Service d'authentification LDAP et SSO avec CAS

Perso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs

Quelques patterns pour la persistance des objets avec DAO DAO. Principe de base. Utilité des DTOs. Le modèle de conception DTO (Data Transfer Object)

CONTRAT D ADHESION AU SYSTEME DE PAIEMENT PAR CARTES BANCAIRES CB

25 septembre Migration des accès au Registre national en protocole X.25 vers le protocole TCP/IP, pour les utilisateurs du Registre national

Keyyo Guide de mise en service CTI / API / TAPI Keyyo

Documentation utilisateur "OK-MARCHE" Historique des modifications. 3.0 Mise à jour complète suite à version OK-MARCHE V2.2. de marchés publics

Modules ICI relais & EXAPAQ Predict v4.0

Processus 2D-Doc. Version : 1.1 Date : 16/11/2012 Pôle Convergence AGENCE NATIONALE DES TITRES SECURISÉS. Processus 2D-Doc.

Recherche dans un tableau

Application des Spécifications détaillées pour la Retraite, architecture portail à portail

Guide d utilisation pour W.access - Client

F O R M A T I O N S LOTUS NOTES. 8.5 Utilisateurs rue de la Bôle. E U R L. a u c a p i t a l d e

Un exemple d'authentification sécurisée utilisant les outils du Web : CAS. P-F. Bonnefoi

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

Documentation RBS Change E-Commerce Core

Compte Rendu d intégration d application

Connecter les formulaire d identification Qualifio à votre système d enregistrement (SSO) Mars 2012

Soon_AdvancedCache. Module Magento SOON. Rédacteur. Relecture & validation technique. Historique des révisions

Création, analyse de questionnaires et d'entretiens pour Windows 2008, 7, 8 et MacOs 10

TNT Express. Magento

Guide d utilisation du service e-banking

Manuel fournisseur : procédure pour prendre connaissance d une consultation en ligne et soumettre une offre. Version de février 2014 SNCF

Guide Utilisateur Transnet

WEBSERVICES. Michael Fortier. Master Informatique 2ème année. A308, Université de Paris 13

GUIDE UTILISATEUR ENVOYEZ ET RECEVEZ VOS SMS PAR

COMPRENDRE L ARCHITECTURE DES WEB SERVICES REST. Amosse EDOUARD, Doctorant

Mettre en place un accès sécurisé à travers Internet

Guide de l'utilisateur

Guide Numériser vers FTP

Utilisation de JAVA coté Application serveur couplé avec Oracle Forms Hafed Benteftifa Novembre 2008

Application web de gestion de comptes en banques

ENVOYEZ ET RECEVEZ VOS FAX ET SMS PAR !

ECR_DESCRIPTION CHAR(80), ECR_MONTANT NUMBER(10,2) NOT NULL, ECR_SENS CHAR(1) NOT NULL) ;

Introduction aux «Services Web»

TP WEBSERVICES. 1 Pré-requis. 1.1 L environnement de développement. 1.2 Les librairies nécessaires 1.3 SOAPUI

Paiement sécurisé sur Internet. Tableau de bord Commerçant

Serveur FTP. 20 décembre. Windows Server 2008R2

Sécurisation du réseau

Le front office (utilisateur client):

Spécifications techniques et fonctionnelles du multi-années pour les noms de domaine en.fr

OPTENET DCAgent Manuel d'utilisateur

Plateforme de vente aux enchères et de vente de gré à gré du ministre. Guide de l utilisateur

Erreurs les plus fréquentes Guide de dépannage

Sélection du contrôleur

Date : 16 novembre 2011 Version : 1. 2 Nombre de pages : 13

Sécurité des réseaux IPSec

Transcription:

Plateforme PAYZEN Définition de Web-services Ordre de paiement Version 1.1

Rédaction, Vérification, Approbation Rédaction Vérification Approbation Nom Date/Visa Nom Date/Visa Nom Date/Visa Lyra-Network 06/03/2013 Lyra-Network 06/03/2013 Lyra-Network 06/03/2013 Historique du document Version Auteur Date Commentaires 1.1 Lyra-Network 06/03/2013 Refonte de la documentation 1.0 Lyra-Network 24/06/2011 Version initiale. Confidentialité Toutes les informations contenues dans ce document sont considérées comme confidentielles. L utilisation de celles-ci en dehors du cadre de cette consultation ou la divulgation à des personnes extérieures est soumise à l approbation préalable de Lyra Network.

SOMMAIRE 1. Présentation... 4 2. Description des types... 5 2.1: PaymentOfferInfo... 5 2.2: PaymentOfferEntity... 6 2.3: PaymentOfferResponse... 7 2.4: Description des codes réponse... 7 3. Description des methodes... 8 3.1: Note Importante... 8 3.2: Create... 8 3.3: Update... 9 4. Signature... 9 4.1: Mode de calcul... 9 4.2: Exemple pour la méthode create... 11 5. L url serveur... 11 6. Annexes... 12 6.1: Les variables utilisateurs... 12 7. ASSISTANCE TECHNIQUE... 12

1. PRESENTATION Ce document présente le webservice paymentoffer qui permet d automatiser les actions réalisables manuellement depuis l outil de gestion de caisse commerçant concernant les ordres de paiement par mail c'est-à-dire la création et la modification des ordres. Ces webservices ont été développés suivant le protocole SOAP (Simple Object Access Protocol) et sont décrits par le fichier wsdl suivant : https://secure.payzen.eu/vads-ws/paymentoffer-v1?wsdl Afin de sécuriser les échanges, les webservices (SOAP) sont cryptés grâce au protocole HTTPS. De plus un mécanisme de signature a été mis en place afin de valider et d authentifier l échange des données. Il est possible d utiliser ce service pour créer ou modifier des ordres. Chaque création / modification correspond à un envoi de mail au(x) destinataires(s) représenté(s) par une liste d adresses email. Dans le cas d un envoi multiple, un ordre est créé par destinataire. Il y a donc autant d ordres que de destinataires, même s il s agit d un point de vue du commerçant d un même ordre. Ceci s explique par le fait qu il faille faire correspondre une transaction par destinataire. Dans le cas d un envoi multiple, le champ référence (si valorisé) est alors incrémenté de 1 sur 3 caractères numériques concaténés à la référence avec un tiret. Ex : [ref]-001, [ref]-002 Si le commerçant dans le champ référence met la valeur «recouvrement», et que l ordre est envoyé à trois destinataires (ou trois clients) alors 3 ordres seront créés avec les références suivantes: - Recouvrement-001 - Recouvrement-002 - Recouvrement-003 Il est possible de désactiver l envoi d email au client. La réponse renvoyée par le serveur contient la liste des ordres créés. Chaque ordre est donc associé à un identifiant numérique, une adresse email et un lien http contenant les informations de paiement. Ainsi, un commerçant peut utiliser son propre outil de mailing et insérer un lien de paiement valide pour un ordre et destinataire donnés. En mode modification, il est également possible de mettre à jour un ordre sans pour autant renvoyé de mail.

2. DESCRIPTION DES TYPES 2.1: PaymentOfferInfo Ce type permet de décrire les paramètres pour une création d un ordre de paiement par mail. Il doit être instancié avec au minimum les champs obligatoires valorisés par le système client. Cet objet sera passé en paramètre à la méthode de création d un ordre. Nom du champ Type Obligatoire Description shopid Long n8 Identifiant de la boutique reference String Correspond à l order id de la transaction, ou référence de an24 la commande. recipients Array[1- Liste des adresses emails : un ordre est créé par 100] destinataire (min 1, max 100). subject String an255 Objet de l email envoyé message String an2000 Corps de l email envoyé sendmail boolean Envoie l email au destinataire si égal à true ctxmode String Contexte de sollicitation de la plateforme de paiement. Deux valeurs possibles : TEST ou PRODUCTION device String En version 1.0 ne peut être que «MAIL» amount long Montant de la transaction en plus petite unité monétaire. Soit pour la devise Euro un montant de 10,50 euros correspond à amount=1050. currency int Devise (Code monnaie ISO 4217, Euro : 978) validity Date Date de validité de l ordre : ne peut être antérieure à la date courante et de peut dépasser 90 jours à venir Cette date devra être exprimée au format w3c. exemple : 2013-03-14T23:00:00+00:00 validationmode int 0 = Automatique, 1 = Manuel Automatique : Le paiement sera remis en banque de manière automatique. Manuel : Pour être remis en banque le marchand devra effectuée une action sur l outil de gestion SYSTEMPAY locale String Ce paramètre définit la langue affichée sur la page de paiement lorsque l utilisateur destinataire de l ordre procède à la transaction. Valeur possibles : de,en,es,fr,it,ja,nl,pt,zh

Exemple d initialisation en java: private PaymentOfferInfo initinfo() { PaymentOfferInfo info = new PaymentOfferInfo(); info.setshopid(pdv_id); info.setamount(1000); info.setcurrency(978); info.setctxmode("production"); info.getrecipients().add(mail1); info.getrecipients().add(mail2); info.setlocale("fr"); info.setmessage(body); info.setreference("ref-ordre"); info.setdevice(paymentdevice.mail.tostring()); info.setsubject(subject); info.setvalidationmode(0); info.setvalidity(utilwstests.getnewdate(90)); info.setsendmail(true); return info; } 2.2: PaymentOfferEntity Ce type permet de décrire les paramètres pour une modification d un ordre de paiement par mail. Il doit être instancié avec au minimum les champs obligatoires valorisés par le système client. Cet objet sera passé en paramètre à la méthode de modification d un ordre. La différence avec l objet de type PaymentOfferInfo c est qu il contient l identifiant de l ordre et non pas une liste d adresse email mais l adresse email du destinataire de l ordre (un ordre correspond à un destinataire). Nom du champ Type Obligatoire Description shopid Long n8 Identifiant de la boutique offerid Long an32 Identifiant de l ordre paymenturl Url de paiement de l ordre sendmail boolean Envoie l email au destinataire si égal à true reference String Correspond à l order id de la transaction, ou référence de an24 la commande. recipients Array[1- Liste des adresses emails : un ordre a été créé par 100] destinataire (min 1, max 100). subject String an255 Objet de l email envoyé message String an2000 Corps de l email envoyé ctxmode String Contexte de sollicitation de la plateforme de paiement. Deux valeurs possibles : TEST ou PRODUCTION device String En version 1.0 ne peut être que «MAIL» amount long Montant de la transaction en plus petite unité monétaire. Soit pour la devise Euro un montant de 10,50 euros correspond à amount=1050. currency int Devise (Code monnaie ISO 4217, Euro : 978) validity Date Date de validité de l ordre : ne peut être antérieure à la date courante et de peut dépasser 90 jours à venir Cette date devra être exprimée au format w3c. exemple : 2013-03-14T23:00:00+00:00

Nom du champ Type Obligatoire Description validationmode int 0 = Automatique, 1 = Manuel Automatique : Le paiement sera remis en banque de manière automatique. Manuel : Pour être remis en banque le marchand devra effectuée une action sur l outil de gestion SYSTEMPAY locale String Ce paramètre définit la langue affichée sur la page de paiement lorsque l utilisateur destinataire de l ordre procède à la transaction. Valeur possibles : de,en,es,fr,it,ja,nl,pt,zh 2.3: PaymentOfferResponse Il s agit de l objet réponse renvoyé par le serveur lors d une requête de création ou modification d un ordre. Si l opération est un succès, l objet contient la liste des identifiants des ordres créées ou modifiées sinon contient un code erreur. Nom du champ Type Description offerentities list[1-100] Liste des ordres créés ou modifiées. Liste contenant des objets de type PaymentOfferEntity. reponsecode String Code réponse renvoyé par le serveur. returnmessage String Description en anglais du champ reponsecode. extendedcode String Renvoyé en mode TEST si erreur de signature Décrit la chaine sans le certificat servant au calcul de la signature avant le hachage SHA1. 2.4: Description des codes réponse responsecode Description OK Action réalisée avec succès NOT_ALLOWED Action non autorisé NOT_AUTHORIZED Modification de l ordre spécifié interdite 1 OFFER_NOT_FOUND L identifiant de l ordre n existe pas BAD_SIGNATURE Mauvaise signature RECIPIENTS La liste des destinataires ne peut-être nulle ou vide et ne doit pas dépasser le nombre de 100 adresses de courriel RECIPIENT L adresse de courriel spécifiée est invalide SUBJECT L objet du message ne peut être nul MESSAGE Le corps du mail ne peut être nul CTX_MODE Le mode de connexion ne peut-être que «TEST» ou «PRODUCTION» DEVICE En version 1.0 ne peut être valorisé que par «MAIL» VALIDITY_DATE Paramètre validity invalide AMOUNT Paramètre amount invalide VALIDATION_MODE Paramètre validationmode invalide SYSTEM_FAILURE Erreur serveur 1 La modification d un ordre est possible dans les 2 cas suivants : - Aucun paiement associé à cet ordre. - Un ou plusieurs paiements refusés associé à cet ordre.

3. DESCRIPTION DES METHODES 3.1: Note Importante Si le champ sendmail est valorisé à true alors le client ou les clients recevront un mail contenant une URL de paiement unique pour chaque client. Si le champ sendmail est valorisé à false alors le client ou les clients ne recevront pas de mail contenant une URL de paiement unique pour chaque client. A charge du marchant de récupérer les URL de paiements afin de les faire parvenir au client final dans le canal de son choix. 3.2: Create Cette fonction permet de créer les ordres de paiement. Entrée : La fonction create prend en entrée les paramètres suivants : Nom du champ Type Description Obligatoire info PaymentOfferInfo Se référer au chapitre 2.1 wssignature String Se référer au chapitre 4 SIGNATURE Exemple xml généré : <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://v1.paymentoffer.ws.vads.lyra.com/"><soap-env:body> <ns1:create> <info> <shopid>12345678</shopid> <ctxmode>test</ctxmode> <subject>bonjour veuillez trouver ci joint un lien de paiement</subject> <message>bonjour veuillez trouver ci joint un lien de paiement</message> <device>mail</device> <reférence>cmd123</reference> <validity>2013-03-14t23:00:00+00:00</validity> <amount>1000</amount> <validationmode>0</validationmode> <currency>978</currency> <locale>fr</locale> <sendmail>true</sendmail> <recipients>test@test.fr</recipients> <recipients>test1@test.fr</recipients> </info> <signature>1ee15221a1b9c062e01ba4a790e46581418f72fb</signature> </ns1:create> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Signature : Se référer au chapitre 4 SIGNATURE Réponse : Cette fonction retourne une réponse du type PaymentOfferResponse. Se référer au chapitre 2. 3.3: Update Cette fonction permet de modifier les ordres de paiement. Cette fonction prend en entrée les paramètres suivants : Nom du champ Type Description Obligatoire entity PaymentOfferEntity Se référer au chapitre 2.1 wssignature String Se référer au chapitre 4 SIGNATURE Signature : Se référer au chapitre 4 SIGNATURE Réponse : Cette fonction retourne une réponse du type PaymentOfferResponse. Se référer au chapitre 2. 4. SIGNATURE 4.1: Mode de calcul Un certificat est nécessaire pour dialoguer avec la plateforme de paiement. Il est mis à disposition de toutes les personnes habilitées à la consultation des certificats dans votre outil de gestion de caisse à l emplacement suivant : Paramètres / Boutique / Certificat. Attention le certificat à utiliser est différent en fonction du mode utilisé : TEST ou PRODUCTION. La signature sera générée comme suit : Création d'une chaîne de caractère représentant la concaténation des paramètres, séparés par le caractère "+". Ajout à cette chaîne d'un "certificat " numérique (de test ou de production selon le contexte). Hachage de la chaîne résultante avec l'algorithme SHA1. La plateforme de paiement effectuera obligatoirement la vérification de la signature.

L'ordre des champs doit être respecté tel que : 1. Mode création : shopid, reference, ctxmode, amount, currency, locale, message, recipients, subject, validationmode, validity, sendmail 2. Mode modification : shopid, offerid, reference, ctxmode, amount, currency, locale, message, recipient, subject, validationmode, validity, sendmail Champs de type date : Les champs de type date dans le calcul de la signature doivent être formatés de la manière suivante : YYYYMMDD soit pour le 2013-03-14T23:00:00+00:00: 20130314. Champs recipients La chaine pour ce champ devra être encadrée par [] Chaque adresse mail devra être séparée d une virgule et d un espace. Soit pour 2 mails la chaîne pour ce champ sera : [email1, email2] Remarque : Un champ de type string optionnel non envoyé devra être toutefois pris en compte et seront considéré comme vide Les champs de type numérique ne doivent pas avoir de 0 à gauche du digit le plus significatif. Les champs de type bool prennent les valeurs suivantes : 1 pour vrai (true) 0 pour faux (false) Les champs de type String non renseignés seront vides.

4.2: Exemple pour la méthode create Champs envoyés : <info> <shopid>12345678</shopid> <ctxmode>test</ctxmode> <subject>paiement de votre facture</subject> <message>bonjour veuillez trouver ci joint un lien de paiement</message> <device>mail</device> <validity>2013-03-14t23:00:00+00:00</validity> <amount>1000</amount> <validationmode>0</validationmode> <currency>978</currency> <locale>fr</locale> <sendmail>false</sendmail> <recipients>test@test.fr</recipients> <recipients>test1@test.fr</recipients> </info> Dans cet exemple le champ optionnel reference n est pas envoyé Chaîne obtenue avant hachage : 12345678++TEST+1000+978+fr+Bonjour veuillez trouver ci joint un lien de paiement+[test@test.fr, test1@test.fr]+bonjour veuillez trouver ci joint un lien de paiement+0+20130314+1+1111111111111111 1111111111111111 correspond au certificat disponible dans le Backoffice de la solution de paiement. Signature après algorithme SHA1 pour la chaîne ci-dessus : 1ee15221a1b9c062e01ba4a790e46581418f72fb En mode TEST, en cas de mauvais calcul de signature, le code erreur renvoyé est «BAD_SIGNATURE» et, la chaine de caractère utilisée pour la signature côté serveur est alors renvoyée dans le champ extendedcode. 5. L URL SERVEUR Lorsque l URL associé a un ordre de paiement fait l objet d un paiement alors l url serveur est appelée si elle renseignée dans le back office de la solution de paiement. Cet appel contient tous les paramètres de réponse lié au paiement. Ces paramètres sont décrits dans le guide d implémentation du formulaire de paiement V2 disponible sur le site documentaire. Parmi les paramètres de réponse, la variable vads_payment_src sera valorisée à TK (source de paiement par token) et la variable vads_token_id valorisé par l identifiant public de l ordre de paiement. De cette façon, vous serez en mesure d identifier la provenance de l appel et d appliquer le traitement adéquat.

6. ANNEXES 6.1: Les variables utilisateurs Quatre variables utilisateur sont disponibles. Elles permettent d enrichir le contenu de l objet et du corps de l email avec les valeurs suivantes : Attribut de l ordre Date de création Date de validité Montant Référence Url de paiement Variable %creation_date% %end_date% %amount% %reference% %url% En mode création, la variable %creation_date% est valorisée par la date du jour. En mode modification, cette variable est valorisée par la date de création enregistrée au moment de la création. Elle n est donc pas modifiable. La variable %amount% intègre dynamiquement la devise, et est calculée en fonction de la locale. Par exemple pour un ordre créé avec la locale «fr» (France), la devise euro et un montant de 13,25 la variable sera résolue de la manière suivante : «13,25 EUR» Si on remplace la locale «fr» par «en» (Angleterre) la résolution aura la forme suivante : «EUR13.25» Exemple : - Amount = 10025 - Validity = 12/06/2011 - Reference = AZ - Subject = Ordre %reference% du %start_date% au %end_date% de %amount% Si la locale est «fr», l objet de l email envoyé aura l affichage suivant : «Ordre AZ du [date du jour] au 12/06/2011 de 100,25 EUR» La variable %url% permet de placer l url de paiement dans le texte du corps de message. Si la variable n est pas utilisée, l url de paiement est automatiquement insérée à la fin du message. Ces variables sont disponibles et donc résolues dans l objet de l email et le corps du message. Aucune de ces variables n est obligatoire. 7. ASSISTANCE TECHNIQUE Pour tout problème d accès à le back office Payzen, il convient d utiliser les liens «compte bloqué» ou «mot de passe oublié» disponible sur la page de connexion de le back office Payzen. Pour toute question technique, vous pouvez nous contacter par téléphone au Accessible les jours ouvrés du lundi au vendredi de 09h00 à 18h00 (heure légale française). (Tarification de ce numéro: Coût d un appel local depuis un poste fixe)